[PATCH] D119599: [clang-format] Add option to align compound assignments like `+=`

2022-03-09 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks accepted this revision.
HazardyKnusperkeks added a comment.

Thanks for your patience. :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119599

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


[PATCH] D121177: [modules] Merge equivalent extensions and diagnose ivar redeclarations for extensions loaded from different modules.

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

In D121177#3371695 , @vsapsai wrote:

> Thanks for the review, Chuanqi! I believe you were touching recently 
> `isSameEntity`. Do you have any concerns about using 
> `StructuralEquivalenceContext` instead of `isSameEntity`? I've decided to go 
> with `StructuralEquivalenceContext` because at this point we are still 
> dealing with deserialization and deduplication while 
> `ASTContext::isSameEntity` kinda assumes that all deduplication is already 
> done, at least based on the comment
>
>   // Objective-C classes and protocols with the same name always match.
>   if (isa(X) || isa(X))
> return true;

Yeah, I was touching `isSameEntity`. But I don't know about 
`StructuralEquivalenceContext`. I just skipped over the implementation of 
`StructuralEquivalenceContext`. I feel like it would be OK if we could assume 
the input is duplicated indeed. 
I see it is guaranteed by `lookupInstanceVariable(Identifier)` now. I don't 
know much about ObjC. But I feel a little bit strange. Is it possible that two 
distinct variable with the same identifier in ObjC? If it is impossible, I 
think it might be OK.




Comment at: clang/include/clang/Serialization/ASTReader.h:1110
+  template 
+  using DuplicateDecls = std::pair;
+

vsapsai wrote:
> ChuanqiXu wrote:
> > How about change the name to:
> > ```
> >   template 
> >   using DuplicateObjDecls = std::pair;
> > ```
> > 
> > to clarify it is only used for ObjC. So the developer of other languages 
> > would skip this when reading.
> Would `DuplicateObjCDecls` work? `ObjC` part is common enough and I want to 
> avoid just `Obj` because it can imply "Object" which is not the goal. Also we 
> have `getObjCObjectType` which doesn't help with disambiguating the meaning 
> of "Obj".
Yeah, it should be `ObjC`. It's my typo originally.



Comment at: clang/include/clang/Serialization/ASTReader.h:1117
+  llvm::MapVector,
+  llvm::SmallVector, 4>>
+  PendingExtensionIvarRedeclarations;

vsapsai wrote:
> ChuanqiXu wrote:
> > It looks a little bit odd for me to use `Vector` for duplicate vars. 
> > Especially, the structure is `Vector>`. I feel it is better with 
> > `llvm::SmallSet`. If the order is important here, I think 
> > `llvm::SmallSetVector` might be an option.
> I'm not sure the use of `llvm::SmallSet` is warranted here. We deserialize 
> each ObjCIvarDecl from each module (and corresponding DeclContext) only once, 
> so we don't have to ensure there are no repeated pairs of same ObjCIvarDecl. 
> And for stable diagnostic we need to use some kind of ordered container. Also 
> a bunch of other "Pending..." fields don't use sets as uniqueness is enforced 
> in different ways.
Oh, I got it. `llvm::SmallVector` might not be wrong in this case. And for the 
mapping relationship, `llvm::SmallMapVector` is considerable too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121177

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


[PATCH] D107141: [Inline-asm] Add diagnosts for unsupported inline assembly arguments

2022-03-09 Thread Phoebe Wang via Phabricator via cfe-commits
pengfei updated this revision to Diff 414277.
pengfei added a comment.

Remove outdated comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107141

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/Sema/SemaStmtAsm.cpp
  clang/test/Sema/asm.c

Index: clang/test/Sema/asm.c
===
--- clang/test/Sema/asm.c
+++ clang/test/Sema/asm.c
@@ -313,3 +313,51 @@
   asm ("jne %l0":::);
   asm goto ("jne %l0"lab);
 }
+
+typedef struct _st_size64 {
+  int a;
+  char b;
+} st_size64;
+
+typedef struct _st_size96 {
+  int a;
+  int b;
+  int c;
+} st_size96;
+
+typedef struct _st_size16 {
+  char a;
+  char b;
+} st_size16;
+
+typedef struct _st_size32 {
+  char a;
+  char b;
+  char c;
+  char d;
+} st_size32;
+
+typedef struct _st_size128 {
+  int a;
+  int b;
+  int c;
+  int d;
+} st_size128;
+
+void test19(long long x)
+{
+  st_size64 a;
+  st_size96 b;
+  st_size16 c;
+  st_size32 d;
+  st_size128 e;
+  asm ("" : "=rm" (a): "0" (1)); // no-error
+  asm ("" : "=rm" (d): "0" (1)); // no-error
+  asm ("" : "=rm" (c): "0" (x)); // no-error
+  asm ("" : "=rm" (x): "0" (a)); // no-error
+  asm ("" : "=rm" (a): "0" (d)); // no-error
+  // Check the output size is pow of 2
+  asm ("" : "=rm" (b): "0" (1)); // expected-error {{impossible constraint in asm: can't store value into a register}}
+  asm ("" : "=rm" (e): "0" (1)); // no-error
+  asm ("" : "=rm" (x): "0" (e)); // no-error
+}
Index: clang/lib/Sema/SemaStmtAsm.cpp
===
--- clang/lib/Sema/SemaStmtAsm.cpp
+++ clang/lib/Sema/SemaStmtAsm.cpp
@@ -618,14 +618,16 @@
   AD_Int, AD_FP, AD_Other
 } InputDomain, OutputDomain;
 
-if (InTy->isIntegerType() || InTy->isPointerType())
+if (InTy->isIntegerType() || InTy->isPointerType() ||
+InTy->isStructureType() || InTy->isConstantArrayType())
   InputDomain = AD_Int;
 else if (InTy->isRealFloatingType())
   InputDomain = AD_FP;
 else
   InputDomain = AD_Other;
 
-if (OutTy->isIntegerType() || OutTy->isPointerType())
+if (OutTy->isIntegerType() || OutTy->isPointerType() ||
+OutTy->isStructureType() || OutTy->isConstantArrayType())
   OutputDomain = AD_Int;
 else if (OutTy->isRealFloatingType())
   OutputDomain = AD_FP;
@@ -667,8 +669,15 @@
 // output was a register, just extend the shorter one to the size of the
 // larger one.
 if (!SmallerValueMentioned && InputDomain != AD_Other &&
-OutputConstraintInfos[TiedTo].allowsRegister())
+OutputConstraintInfos[TiedTo].allowsRegister()) {
+  // FIXME: GCC supports the OutSize to be 128 at maximum. Currently codegen
+  // crash when the size larger than the register size. So we limit it here.
+  if (OutputDomain == AD_Int &&
+  Context.getIntTypeForBitwidth(OutSize, /*Signed*/ false).isNull())
+targetDiag(OutputExpr->getExprLoc(), diag::err_store_value_to_reg);
+
   continue;
+}
 
 // Either both of the operands were mentioned or the smaller one was
 // mentioned.  One more special case that we'll allow: if the tied input is
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -2725,9 +2725,8 @@
   QualType Ty = getContext().getIntTypeForBitwidth(Size, /*Signed*/ false);
   if (Ty.isNull()) {
 const Expr *OutExpr = S.getOutputExpr(i);
-CGM.Error(
-OutExpr->getExprLoc(),
-"impossible constraint in asm: can't store value into a register");
+CGM.getDiags().Report(OutExpr->getExprLoc(),
+  diag::err_store_value_to_reg);
 return;
   }
   Dest = MakeAddrLValue(A, Ty);
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -8763,6 +8763,8 @@
 " in asm %select{input|output}1 with a memory constraint '%2'">;
   def err_asm_input_duplicate_match : Error<
 "more than one input constraint matches the same output '%0'">;
+  def err_store_value_to_reg : Error<
+"impossible constraint in asm: can't store value into a register">;
 
   def warn_asm_label_on_auto_decl : Warning<
 "ignored asm label '%0' on automatic variable">;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D107141: [Inline-asm] Add diagnosts for unsupported inline assembly arguments

2022-03-09 Thread Phoebe Wang via Phabricator via cfe-commits
pengfei added inline comments.



Comment at: clang/lib/Sema/SemaStmtAsm.cpp:679
+  !llvm::isPowerOf2_32(OutSize))
+targetDiag(OutputExpr->getExprLoc(), diag::err_store_value_to_reg);
+

jyu2 wrote:
> Error message is not very clear to me.  I think we should create more 
> specified error message there.  Like power of two, or size <  8 or > pointer 
> size?
> 
> Using error message selector.
Use `getIntTypeForBitwidth` instead. So we don't need to check for each case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107141

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


[PATCH] D107141: [Inline-asm] Add diagnosts for unsupported inline assembly arguments

2022-03-09 Thread Phoebe Wang via Phabricator via cfe-commits
pengfei updated this revision to Diff 414276.
pengfei added a comment.

Address review comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107141

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/Sema/SemaStmtAsm.cpp
  clang/test/Sema/asm.c

Index: clang/test/Sema/asm.c
===
--- clang/test/Sema/asm.c
+++ clang/test/Sema/asm.c
@@ -313,3 +313,52 @@
   asm ("jne %l0":::);
   asm goto ("jne %l0"lab);
 }
+
+typedef struct _st_size64 {
+  int a;
+  char b;
+} st_size64;
+
+typedef struct _st_size96 {
+  int a;
+  int b;
+  int c;
+} st_size96;
+
+typedef struct _st_size16 {
+  char a;
+  char b;
+} st_size16;
+
+typedef struct _st_size32 {
+  char a;
+  char b;
+  char c;
+  char d;
+} st_size32;
+
+typedef struct _st_size128 {
+  int a;
+  int b;
+  int c;
+  int d;
+} st_size128;
+
+void test19(long long x)
+{
+  st_size64 a;
+  st_size96 b;
+  st_size16 c;
+  st_size32 d;
+  st_size128 e;
+  asm ("" : "=rm" (a): "0" (1)); // no-error
+  asm ("" : "=rm" (d): "0" (1)); // no-error
+  asm ("" : "=rm" (c): "0" (x)); // no-error
+  asm ("" : "=rm" (x): "0" (a)); // no-error
+  asm ("" : "=rm" (a): "0" (d)); // no-error
+  // Check the output size is pow of 2
+  asm ("" : "=rm" (b): "0" (1)); // expected-error {{impossible constraint in asm: can't store value into a register}}
+  // Check the output size is <= 64
+  asm ("" : "=rm" (e): "0" (1)); // no-error
+  asm ("" : "=rm" (x): "0" (e)); // no-error
+}
Index: clang/lib/Sema/SemaStmtAsm.cpp
===
--- clang/lib/Sema/SemaStmtAsm.cpp
+++ clang/lib/Sema/SemaStmtAsm.cpp
@@ -618,14 +618,16 @@
   AD_Int, AD_FP, AD_Other
 } InputDomain, OutputDomain;
 
-if (InTy->isIntegerType() || InTy->isPointerType())
+if (InTy->isIntegerType() || InTy->isPointerType() ||
+InTy->isStructureType() || InTy->isConstantArrayType())
   InputDomain = AD_Int;
 else if (InTy->isRealFloatingType())
   InputDomain = AD_FP;
 else
   InputDomain = AD_Other;
 
-if (OutTy->isIntegerType() || OutTy->isPointerType())
+if (OutTy->isIntegerType() || OutTy->isPointerType() ||
+OutTy->isStructureType() || OutTy->isConstantArrayType())
   OutputDomain = AD_Int;
 else if (OutTy->isRealFloatingType())
   OutputDomain = AD_FP;
@@ -667,8 +669,15 @@
 // output was a register, just extend the shorter one to the size of the
 // larger one.
 if (!SmallerValueMentioned && InputDomain != AD_Other &&
-OutputConstraintInfos[TiedTo].allowsRegister())
+OutputConstraintInfos[TiedTo].allowsRegister()) {
+  // FIXME: GCC supports the OutSize to be 128 at maximum. Currently codegen
+  // crash when the size larger than the register size. So we limit it here.
+  if (OutputDomain == AD_Int &&
+  Context.getIntTypeForBitwidth(OutSize, /*Signed*/ false).isNull())
+targetDiag(OutputExpr->getExprLoc(), diag::err_store_value_to_reg);
+
   continue;
+}
 
 // Either both of the operands were mentioned or the smaller one was
 // mentioned.  One more special case that we'll allow: if the tied input is
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -2725,9 +2725,8 @@
   QualType Ty = getContext().getIntTypeForBitwidth(Size, /*Signed*/ false);
   if (Ty.isNull()) {
 const Expr *OutExpr = S.getOutputExpr(i);
-CGM.Error(
-OutExpr->getExprLoc(),
-"impossible constraint in asm: can't store value into a register");
+CGM.getDiags().Report(OutExpr->getExprLoc(),
+  diag::err_store_value_to_reg);
 return;
   }
   Dest = MakeAddrLValue(A, Ty);
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -8763,6 +8763,8 @@
 " in asm %select{input|output}1 with a memory constraint '%2'">;
   def err_asm_input_duplicate_match : Error<
 "more than one input constraint matches the same output '%0'">;
+  def err_store_value_to_reg : Error<
+"impossible constraint in asm: can't store value into a register">;
 
   def warn_asm_label_on_auto_decl : Warning<
 "ignored asm label '%0' on automatic variable">;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D120296: [Attr] Fix a btf_type_tag AST generation bug

2022-03-09 Thread Yonghong Song via Phabricator via cfe-commits
yonghong-song added a comment.

@aaron.ballman @erichkeane Hopefully I addressed your comments. Could you take 
a look again?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120296

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


[PATCH] D121352: [clang-format] Handle "// clang-format off" for RemoveBracesLLVM

2022-03-09 Thread Owen Pan via Phabricator via cfe-commits
owenpan created this revision.
owenpan added reviewers: MyDeveloperDay, curdeius, HazardyKnusperkeks.
owenpan added a project: clang-format.
Herald added a project: All.
owenpan 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/D121352

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -24805,6 +24805,19 @@
"}",
Style);
 
+  verifyFormat("// clang-format off\n"
+   "// comment\n"
+   "while (i > 0) { --i; }\n"
+   "// clang-format on\n"
+   "while (j < 0)\n"
+   "  ++j;",
+   "// clang-format off\n"
+   "// comment\n"
+   "while (i > 0) { --i; }\n"
+   "// clang-format on\n"
+   "while (j < 0) { ++j; }",
+   Style);
+
   verifyFormat("if (a)\n"
"  b; // comment\n"
"else if (c)\n"
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -1808,7 +1808,8 @@
   removeBraces(Line->Children, Result);
   if (!Line->Affected)
 continue;
-  for (FormatToken *Token = Line->First; Token; Token = Token->Next) {
+  for (FormatToken *Token = Line->First; Token && !Token->Finalized;
+   Token = Token->Next) {
 if (!Token->Optional)
   continue;
 assert(Token->isOneOf(tok::l_brace, tok::r_brace));


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -24805,6 +24805,19 @@
"}",
Style);
 
+  verifyFormat("// clang-format off\n"
+   "// comment\n"
+   "while (i > 0) { --i; }\n"
+   "// clang-format on\n"
+   "while (j < 0)\n"
+   "  ++j;",
+   "// clang-format off\n"
+   "// comment\n"
+   "while (i > 0) { --i; }\n"
+   "// clang-format on\n"
+   "while (j < 0) { ++j; }",
+   Style);
+
   verifyFormat("if (a)\n"
"  b; // comment\n"
"else if (c)\n"
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -1808,7 +1808,8 @@
   removeBraces(Line->Children, Result);
   if (!Line->Affected)
 continue;
-  for (FormatToken *Token = Line->First; Token; Token = Token->Next) {
+  for (FormatToken *Token = Line->First; Token && !Token->Finalized;
+   Token = Token->Next) {
 if (!Token->Optional)
   continue;
 assert(Token->isOneOf(tok::l_brace, tok::r_brace));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D121177: [modules] Merge equivalent extensions and diagnose ivar redeclarations for extensions loaded from different modules.

2022-03-09 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai added a comment.

Thanks for the review, Chuanqi! I believe you were touching recently 
`isSameEntity`. Do you have any concerns about using 
`StructuralEquivalenceContext` instead of `isSameEntity`? I've decided to go 
with `StructuralEquivalenceContext` because at this point we are still dealing 
with deserialization and deduplication while `ASTContext::isSameEntity` kinda 
assumes that all deduplication is already done, at least based on the comment

  // Objective-C classes and protocols with the same name always match.
  if (isa(X) || isa(X))
return true;




Comment at: clang/include/clang/Serialization/ASTReader.h:1110
+  template 
+  using DuplicateDecls = std::pair;
+

ChuanqiXu wrote:
> How about change the name to:
> ```
>   template 
>   using DuplicateObjDecls = std::pair;
> ```
> 
> to clarify it is only used for ObjC. So the developer of other languages 
> would skip this when reading.
Would `DuplicateObjCDecls` work? `ObjC` part is common enough and I want to 
avoid just `Obj` because it can imply "Object" which is not the goal. Also we 
have `getObjCObjectType` which doesn't help with disambiguating the meaning of 
"Obj".



Comment at: clang/include/clang/Serialization/ASTReader.h:1112-1115
+  /// When resolving duplicate ivars from extensions we don't error out
+  /// immediately but check if can merge identical extensions. Not checking
+  /// extensions for equality immediately because ivar deserialization isn't
+  /// over yet at that point.

ChuanqiXu wrote:
> Similarly, I suggest to add words or change the name to clarify it is used in 
> ObjC only.
Thanks for sharing your perspective, I'll make it more obvious it is 
ObjC-related.



Comment at: clang/include/clang/Serialization/ASTReader.h:1117
+  llvm::MapVector,
+  llvm::SmallVector, 4>>
+  PendingExtensionIvarRedeclarations;

ChuanqiXu wrote:
> It looks a little bit odd for me to use `Vector` for duplicate vars. 
> Especially, the structure is `Vector>`. I feel it is better with 
> `llvm::SmallSet`. If the order is important here, I think 
> `llvm::SmallSetVector` might be an option.
I'm not sure the use of `llvm::SmallSet` is warranted here. We deserialize each 
ObjCIvarDecl from each module (and corresponding DeclContext) only once, so we 
don't have to ensure there are no repeated pairs of same ObjCIvarDecl. And for 
stable diagnostic we need to use some kind of ordered container. Also a bunch 
of other "Pending..." fields don't use sets as uniqueness is enforced in 
different ways.



Comment at: clang/lib/Serialization/ASTReaderDecl.cpp:1249-1251
+if (auto *ParentExt = dyn_cast(IVD->getDeclContext())) {
+  if (auto *PrevParentExt =
+  dyn_cast(PrevIvar->getDeclContext())) {

ChuanqiXu wrote:
> nit:
> ```
> auto *ParentExt = dyn_cast(IVD->getDeclContext());
> auto *PrevParentExt = dyn_cast(PrevIvar->getDeclContext());
> if (ParentExt && PrevParentExt) {
> 
> }
> ```
> 
> We could reduce one identation in this way. Codes with less identation looks 
> better.
Thanks, good point, will change it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121177

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


[PATCH] D120296: [Attr] Fix a btf_type_tag AST generation bug

2022-03-09 Thread Yonghong Song via Phabricator via cfe-commits
yonghong-song updated this revision to Diff 414267.
yonghong-song added a comment.

- use BTFTypeTagAttr instead of Attr in PropertiesBase.td


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120296

Files:
  clang/include/clang-c/Index.h
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/ASTNodeTraverser.h
  clang/include/clang/AST/PropertiesBase.td
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeLoc.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/TypeNodes.td
  clang/include/clang/Serialization/ASTRecordReader.h
  clang/include/clang/Serialization/ASTRecordWriter.h
  clang/include/clang/Serialization/TypeBitCodes.def
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/CodeGen/attr-btf_type_tag-similar-type.c
  clang/test/PCH/btf_type_tag_attr.c
  clang/test/Sema/attr-btf_type_tag.c
  clang/tools/libclang/CIndex.cpp
  clang/tools/libclang/CXType.cpp

Index: clang/tools/libclang/CXType.cpp
===
--- clang/tools/libclang/CXType.cpp
+++ clang/tools/libclang/CXType.cpp
@@ -116,6 +116,7 @@
 TKCASE(Elaborated);
 TKCASE(Pipe);
 TKCASE(Attributed);
+TKCASE(BTFTagAttributed);
 TKCASE(Atomic);
 default:
   return CXType_Unexposed;
@@ -136,6 +137,10 @@
 return MakeCXType(ATT->getEquivalentType(), TU);
   }
 }
+if (auto *ATT = T->getAs()) {
+  if (!(TU->ParsingOptions & CXTranslationUnit_IncludeAttributedTypes))
+return MakeCXType(ATT->getWrappedType(), TU);
+}
 // Handle paren types as the original type
 if (auto *PTT = T->getAs()) {
   return MakeCXType(PTT->getInnerType(), TU);
@@ -610,6 +615,7 @@
 TKIND(Elaborated);
 TKIND(Pipe);
 TKIND(Attributed);
+TKIND(BTFTagAttributed);
 TKIND(BFloat16);
 #define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) TKIND(Id);
 #include "clang/Basic/OpenCLImageTypes.def"
@@ -1051,6 +1057,9 @@
   if (auto *ATT = T->getAs())
 return MakeCXType(ATT->getModifiedType(), GetTU(CT));
 
+  if (auto *ATT = T->getAs())
+return MakeCXType(ATT->getWrappedType(), GetTU(CT));
+
   return MakeCXType(QualType(), GetTU(CT));
 }
 
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -1672,6 +1672,10 @@
   return Visit(TL.getModifiedLoc());
 }
 
+bool CursorVisitor::VisitBTFTagAttributedTypeLoc(BTFTagAttributedTypeLoc TL) {
+  return Visit(TL.getWrappedLoc());
+}
+
 bool CursorVisitor::VisitFunctionTypeLoc(FunctionTypeLoc TL,
  bool SkipResultType) {
   if (!SkipResultType && Visit(TL.getReturnLoc()))
Index: clang/test/Sema/attr-btf_type_tag.c
===
--- clang/test/Sema/attr-btf_type_tag.c
+++ clang/test/Sema/attr-btf_type_tag.c
@@ -23,3 +23,15 @@
 int __tag4 * __tag5 * __tag6 *foo1(struct t __tag1 * __tag2 * __tag3 *a1) {
   return (int __tag4 * __tag5 * __tag6 *)a1[0][0]->d;
 }
+
+// The btf_type_tag attribute will be ignored during _Generic type matching
+int g1 = _Generic((int *)0, int __tag1 *: 0);
+int g2 = _Generic((int __tag1 *)0, int *: 0);
+
+// The btf_type_tag attribute will be ignored during overloadable type matching
+void __attribute__((overloadable)) bar1(int __tag1 *a);
+void __attribute__((overloadable)) bar2(int *a);
+void foo2(int *a, int __tag1 *b) {
+  bar1(a);
+  bar2(b);
+}
Index: clang/test/PCH/btf_type_tag_attr.c
===
--- /dev/null
+++ clang/test/PCH/btf_type_tag_attr.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -emit-pch -o %t %s
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -include-pch %t \
+// RUN:   -fsyntax-only -verify %s
+
+// expected-no-diagnostics
+
+int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag2"))) *p;
Index: clang/test/CodeGen/attr-btf_type_tag-similar-type.c
===
--- /dev/null
+++ clang/test/CodeGen/attr-btf_type_tag-similar-type.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -triple %itanium_abi_triple -debug-info-kind=limited -S -emit-llvm -o - %s | FileCheck %s
+
+struct map_value {
+int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a;
+int 

[PATCH] D120296: [Attr] Fix a btf_type_tag AST generation bug

2022-03-09 Thread Yonghong Song via Phabricator via cfe-commits
yonghong-song updated this revision to Diff 414263.
yonghong-song added a comment.

- further clang-format fixes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120296

Files:
  clang/include/clang-c/Index.h
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/ASTNodeTraverser.h
  clang/include/clang/AST/PropertiesBase.td
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeLoc.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/TypeNodes.td
  clang/include/clang/Serialization/ASTRecordWriter.h
  clang/include/clang/Serialization/TypeBitCodes.def
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/CodeGen/attr-btf_type_tag-similar-type.c
  clang/test/PCH/btf_type_tag_attr.c
  clang/test/Sema/attr-btf_type_tag.c
  clang/tools/libclang/CIndex.cpp
  clang/tools/libclang/CXType.cpp

Index: clang/tools/libclang/CXType.cpp
===
--- clang/tools/libclang/CXType.cpp
+++ clang/tools/libclang/CXType.cpp
@@ -116,6 +116,7 @@
 TKCASE(Elaborated);
 TKCASE(Pipe);
 TKCASE(Attributed);
+TKCASE(BTFTagAttributed);
 TKCASE(Atomic);
 default:
   return CXType_Unexposed;
@@ -136,6 +137,10 @@
 return MakeCXType(ATT->getEquivalentType(), TU);
   }
 }
+if (auto *ATT = T->getAs()) {
+  if (!(TU->ParsingOptions & CXTranslationUnit_IncludeAttributedTypes))
+return MakeCXType(ATT->getWrappedType(), TU);
+}
 // Handle paren types as the original type
 if (auto *PTT = T->getAs()) {
   return MakeCXType(PTT->getInnerType(), TU);
@@ -610,6 +615,7 @@
 TKIND(Elaborated);
 TKIND(Pipe);
 TKIND(Attributed);
+TKIND(BTFTagAttributed);
 TKIND(BFloat16);
 #define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) TKIND(Id);
 #include "clang/Basic/OpenCLImageTypes.def"
@@ -1051,6 +1057,9 @@
   if (auto *ATT = T->getAs())
 return MakeCXType(ATT->getModifiedType(), GetTU(CT));
 
+  if (auto *ATT = T->getAs())
+return MakeCXType(ATT->getWrappedType(), GetTU(CT));
+
   return MakeCXType(QualType(), GetTU(CT));
 }
 
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -1672,6 +1672,10 @@
   return Visit(TL.getModifiedLoc());
 }
 
+bool CursorVisitor::VisitBTFTagAttributedTypeLoc(BTFTagAttributedTypeLoc TL) {
+  return Visit(TL.getWrappedLoc());
+}
+
 bool CursorVisitor::VisitFunctionTypeLoc(FunctionTypeLoc TL,
  bool SkipResultType) {
   if (!SkipResultType && Visit(TL.getReturnLoc()))
Index: clang/test/Sema/attr-btf_type_tag.c
===
--- clang/test/Sema/attr-btf_type_tag.c
+++ clang/test/Sema/attr-btf_type_tag.c
@@ -23,3 +23,15 @@
 int __tag4 * __tag5 * __tag6 *foo1(struct t __tag1 * __tag2 * __tag3 *a1) {
   return (int __tag4 * __tag5 * __tag6 *)a1[0][0]->d;
 }
+
+// The btf_type_tag attribute will be ignored during _Generic type matching
+int g1 = _Generic((int *)0, int __tag1 *: 0);
+int g2 = _Generic((int __tag1 *)0, int *: 0);
+
+// The btf_type_tag attribute will be ignored during overloadable type matching
+void __attribute__((overloadable)) bar1(int __tag1 *a);
+void __attribute__((overloadable)) bar2(int *a);
+void foo2(int *a, int __tag1 *b) {
+  bar1(a);
+  bar2(b);
+}
Index: clang/test/PCH/btf_type_tag_attr.c
===
--- /dev/null
+++ clang/test/PCH/btf_type_tag_attr.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -emit-pch -o %t %s
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -include-pch %t \
+// RUN:   -fsyntax-only -verify %s
+
+// expected-no-diagnostics
+
+int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag2"))) *p;
Index: clang/test/CodeGen/attr-btf_type_tag-similar-type.c
===
--- /dev/null
+++ clang/test/CodeGen/attr-btf_type_tag-similar-type.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -triple %itanium_abi_triple -debug-info-kind=limited -S -emit-llvm -o - %s | FileCheck %s
+
+struct map_value {
+int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a;
+int __attribute__((btf_type_tag("tag2"))) __attribute__((btf_type_tag("tag4"))) *b;
+};
+
+struct map_value 

[clang] 89c94c2 - [clang][Driver] Get darwin -Xarch_ working for subtypes, again.

2022-03-09 Thread Ahmed Bougacha via cfe-commits

Author: Ahmed Bougacha
Date: 2022-03-09T18:21:45-08:00
New Revision: 89c94c242c7ddcc700aba6af7243dcac7a9a4ef2

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

LOG: [clang][Driver] Get darwin -Xarch_ working for subtypes, again.

35ca7d9ddf4 broke 471c4f829934 for -arch flags that don't map 1:1
to the triple arch.  This has been broken for the many years since.
It hasn't mattered much since then, mostly because few people use it,
but also because it works for x86_64/i386, armv7/armv7s
don't differ much, arm64 is its own arch, and arm64/arm64_32 have
different arches (and it's a rare combination anyway).

But arm64/arm64e exposes this issue again.

Patch by: Justin Bogner 
with some added tests.

Added: 


Modified: 
clang/lib/Driver/ToolChains/Darwin.cpp
clang/test/Driver/darwin-xarch.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index 005236c4476f4..a11cd3fbaa71c 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -2487,12 +2487,9 @@ DerivedArgList *MachO::TranslateArgs(const 
DerivedArgList ,
 if (A->getOption().matches(options::OPT_Xarch__)) {
   // Skip this argument unless the architecture matches either the 
toolchain
   // triple arch, or the arch being bound.
-  llvm::Triple::ArchType XarchArch =
-  tools::darwin::getArchTypeForMachOArchName(A->getValue(0));
-  if (!(XarchArch == getArch() ||
-(!BoundArch.empty() &&
- XarchArch ==
- tools::darwin::getArchTypeForMachOArchName(BoundArch
+  StringRef XarchArch = A->getValue(0);
+  if (!(XarchArch == getArchName() ||
+(!BoundArch.empty() && XarchArch == BoundArch)))
 continue;
 
   Arg *OriginalArg = A;

diff  --git a/clang/test/Driver/darwin-xarch.c 
b/clang/test/Driver/darwin-xarch.c
index 3014236f8ccda..0df17fda7b0e3 100644
--- a/clang/test/Driver/darwin-xarch.c
+++ b/clang/test/Driver/darwin-xarch.c
@@ -18,3 +18,32 @@
 // RUN: FileCheck --check-prefix=CHECK-ARMV7-LINK < %t %s
 //
 // CHECK-ARMV7-LINK: ld{{.*}} "-arch" "armv7"{{.*}} "-some-linker-arg"
+
+
+// RUN: %clang -target armv7s-apple-ios7 -### \
+// RUN:   -arch armv7  -Xarch_armv7  -DARMV7=1 \
+// RUN:   -arch armv7s -Xarch_armv7s -DARMV7S=1 \
+// RUN:   -c %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-ARMV7S < %t %s
+//
+// CHECK-ARMV7S: clang{{.*}}" "-cc1" "-triple" "thumbv7-apple-ios7.0.0"
+// CHECK-ARMV7S-NOT:  "-D" "ARMV7S=1"
+// CHECK-ARMV7S-SAME: "-D" "ARMV7=1"
+//
+// CHECK-ARMV7S: clang{{.*}}" "-cc1" "-triple" "thumbv7s-apple-ios7.0.0"
+// CHECK-ARMV7S-NOT:  "-D" "ARMV7=1"
+// CHECK-ARMV7S-SAME: "-D" "ARMV7S=1"
+
+// RUN: %clang -target arm64-apple-ios14 -### \
+// RUN:   -arch arm64  -Xarch_arm64  -DARM64=1 \
+// RUN:   -arch arm64e -Xarch_arm64e -DARM64E=1 \
+// RUN:   -c %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-ARM64 < %t %s
+//
+// CHECK-ARM64: clang{{.*}}" "-cc1" "-triple" "arm64-apple-ios14.0.0"
+// CHECK-ARM64-NOT:  "-D" "ARM64E=1"
+// CHECK-ARM64-SAME: "-D" "ARM64=1"
+//
+// CHECK-ARM64: clang{{.*}}" "-cc1" "-triple" "arm64e-apple-ios14.0.0"
+// CHECK-ARM64-NOT:  "-D" "ARM64=1"
+// CHECK-ARM64-SAME: "-D" "ARM64E=1"



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


[PATCH] D118352: [clang][ABI] New c++20 modules mangling scheme

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

In D118352#3371425 , @h-vetinari 
wrote:

> Something must have gone wrong... communication-wise... as @urnathan seems to 
> have abandoned (resp. resigned from) all modules PRs. Hope any 
> misunderstandings or grievances can be worked out!

Oh, yeah... it is surprising...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118352

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


[PATCH] D121302: [HIP] Fix -fno-gpu-sanitize

2022-03-09 Thread Yaxun Liu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGda9a70313d60: [HIP] Fix -fno-gpu-sanitize (authored by 
yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121302

Files:
  clang/lib/Driver/ToolChains/HIPAMD.cpp
  clang/test/Driver/hip-sanitize-options.hip


Index: clang/test/Driver/hip-sanitize-options.hip
===
--- clang/test/Driver/hip-sanitize-options.hip
+++ clang/test/Driver/hip-sanitize-options.hip
@@ -35,6 +35,20 @@
 // RUN:   -fsanitize=leak -nogpuinc --rocm-path=%S/Inputs/rocm \
 // RUN:   %s 2>&1 | FileCheck -check-prefixes=XNACKNEG %s
 
+// Check -fno-gpu-sanitize with supported and unsupported GPU.
+// Sanitizer should be disabled for all GPU's and there should be no warnings 
about unsupported
+// GPU.
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu 
--offload-arch=gfx900:xnack- \
+// RUN:   --offload-arch=gfx900:xnack+ --offload-arch=gfx906 
-fsanitize=address -fno-gpu-sanitize \
+// RUN:   -fsanitize=leak -nogpuinc --rocm-path=%S/Inputs/rocm \
+// RUN:   %s 2>&1 | FileCheck -check-prefixes=NOGPU %s
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu 
--offload-arch=gfx900:xnack- \
+// RUN:   --offload-arch=gfx900:xnack+ --offload-arch=gfx906 
-fsanitize=address -fno-gpu-sanitize \
+// RUN:   -fsanitize=leak -nogpuinc --rocm-path=%S/Inputs/rocm \
+// RUN:   %s 2>&1 | FileCheck -check-prefixes=NOGPUNEG %s
+
 // CHECK-NOT: {{"[^"]*clang[^"]*".* "-fcuda-is-device".* "-fsanitize=address"}}
 // CHECK-NOT: {{"[^"]*clang[^"]*".* "-fcuda-is-device".* "-mlink-bitcode-file" 
".*asanrtl.bc"}}
 // CHECK-NOT: {{"[^"]*lld(\.exe){0,1}".* ".*hip.bc"}}
@@ -65,3 +79,22 @@
 // XNACKNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx900".* "-target-feature" "-xnack"}}
 // XNACKNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx906"}}
 // XNACKNEG-NOT: {{"[^"]*lld(\.exe){0,1}".* ".*hip.bc"}}
+
+// NOGPU-DAG: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* "-target-feature" 
"\+xnack"}}
+// NOGPU-DAG: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* "-target-feature" 
"-xnack"}}
+// NOGPU-DAG: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx906"}}
+// NOGPU-DAG: {{"[^"]*clang[^"]*".* "-triple" "x86_64-unknown-linux-gnu".* 
"-fsanitize=address,leak"}}
+// NOGPUNEG-NOT: warning: ignoring '-fsanitize=leak' option as it is not 
currently supported for target 'amdgcn-amd-amdhsa'
+// NOGPUNEG-NOT: warning: ignoring '-fsanitize=address' option as it is not 
currently supported for offload arch 'gfx900:xnack-'. Use it with an offload 
arch containing 'xnack+' instead
+// NOGPUNEG-NOT: warning: ignoring '-fsanitize=address' option as it is not 
currently supported for offload arch 'gfx906'. Use it with an offload arch 
containing 'xnack+' instead
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx900".* "-target-feature" "\+xnack".* "-fsanitize=address"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* 
"-target-feature" "\+xnack".* "-fsanitize=address,leak"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* 
"-target-feature" "-xnack".* "-fsanitize=address,leak"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx906".* 
"-fsanitize=address,leak"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* 
"-target-feature" "\+xnack".* "-fsanitize=address"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* 
"-target-feature" "-xnack".* "-fsanitize=address"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx906".* 
"-fsanitize=address"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx900".* "-target-feature" "\+xnack"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx900".* "-target-feature" "-xnack"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx906"}}
+// NOGPUNEG-NOT: {{"[^"]*lld(\.exe){0,1}".* ".*hip.bc"}}
Index: clang/lib/Driver/ToolChains/HIPAMD.cpp
===
--- clang/lib/Driver/ToolChains/HIPAMD.cpp
+++ clang/lib/Driver/ToolChains/HIPAMD.cpp
@@ -47,7 +47,7 @@
 return false;
 
   if (!DriverArgs.hasFlag(options::OPT_fgpu_sanitize,
-  -options::OPT_fno_gpu_sanitize))
+  options::OPT_fno_gpu_sanitize))
 return true;
 
   auto  = TC.getDriver().getDiags();
@@ -162,6 +162,8 @@
   getProgramPaths().push_back(getDriver().Dir);
 
   // Diagnose unsupported sanitizer options only once.
+  if (!Args.hasFlag(options::OPT_fgpu_sanitize, options::OPT_fno_gpu_sanitize))
+return;
   for 

[clang] da9a703 - [HIP] Fix -fno-gpu-sanitize

2022-03-09 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2022-03-09T20:58:50-05:00
New Revision: da9a70313d60572c1e1e630ecf2dad7a0fa5d7ff

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

LOG: [HIP] Fix -fno-gpu-sanitize

Fix a typo about -fno-gpu-sanitize handling and disable warnings when
-fno-gpu-sanitize is specified.

Reviewed by: Artem Belevich

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/HIPAMD.cpp
clang/test/Driver/hip-sanitize-options.hip

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/HIPAMD.cpp 
b/clang/lib/Driver/ToolChains/HIPAMD.cpp
index 4a952530993e8..7497d7521d559 100644
--- a/clang/lib/Driver/ToolChains/HIPAMD.cpp
+++ b/clang/lib/Driver/ToolChains/HIPAMD.cpp
@@ -47,7 +47,7 @@ static bool shouldSkipSanitizeOption(const ToolChain ,
 return false;
 
   if (!DriverArgs.hasFlag(options::OPT_fgpu_sanitize,
-  -options::OPT_fno_gpu_sanitize))
+  options::OPT_fno_gpu_sanitize))
 return true;
 
   auto  = TC.getDriver().getDiags();
@@ -162,6 +162,8 @@ HIPAMDToolChain::HIPAMDToolChain(const Driver , const 
llvm::Triple ,
   getProgramPaths().push_back(getDriver().Dir);
 
   // Diagnose unsupported sanitizer options only once.
+  if (!Args.hasFlag(options::OPT_fgpu_sanitize, options::OPT_fno_gpu_sanitize))
+return;
   for (auto A : Args.filtered(options::OPT_fsanitize_EQ)) {
 SanitizerMask K = parseSanitizerValue(A->getValue(), 
/*AllowGroups=*/false);
 if (K != SanitizerKind::Address)

diff  --git a/clang/test/Driver/hip-sanitize-options.hip 
b/clang/test/Driver/hip-sanitize-options.hip
index b79a3addff691..5d2b2e91e 100644
--- a/clang/test/Driver/hip-sanitize-options.hip
+++ b/clang/test/Driver/hip-sanitize-options.hip
@@ -35,6 +35,20 @@
 // RUN:   -fsanitize=leak -nogpuinc --rocm-path=%S/Inputs/rocm \
 // RUN:   %s 2>&1 | FileCheck -check-prefixes=XNACKNEG %s
 
+// Check -fno-gpu-sanitize with supported and unsupported GPU.
+// Sanitizer should be disabled for all GPU's and there should be no warnings 
about unsupported
+// GPU.
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu 
--offload-arch=gfx900:xnack- \
+// RUN:   --offload-arch=gfx900:xnack+ --offload-arch=gfx906 
-fsanitize=address -fno-gpu-sanitize \
+// RUN:   -fsanitize=leak -nogpuinc --rocm-path=%S/Inputs/rocm \
+// RUN:   %s 2>&1 | FileCheck -check-prefixes=NOGPU %s
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu 
--offload-arch=gfx900:xnack- \
+// RUN:   --offload-arch=gfx900:xnack+ --offload-arch=gfx906 
-fsanitize=address -fno-gpu-sanitize \
+// RUN:   -fsanitize=leak -nogpuinc --rocm-path=%S/Inputs/rocm \
+// RUN:   %s 2>&1 | FileCheck -check-prefixes=NOGPUNEG %s
+
 // CHECK-NOT: {{"[^"]*clang[^"]*".* "-fcuda-is-device".* "-fsanitize=address"}}
 // CHECK-NOT: {{"[^"]*clang[^"]*".* "-fcuda-is-device".* "-mlink-bitcode-file" 
".*asanrtl.bc"}}
 // CHECK-NOT: {{"[^"]*lld(\.exe){0,1}".* ".*hip.bc"}}
@@ -65,3 +79,22 @@
 // XNACKNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx900".* "-target-feature" "-xnack"}}
 // XNACKNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx906"}}
 // XNACKNEG-NOT: {{"[^"]*lld(\.exe){0,1}".* ".*hip.bc"}}
+
+// NOGPU-DAG: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* "-target-feature" 
"\+xnack"}}
+// NOGPU-DAG: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* "-target-feature" 
"-xnack"}}
+// NOGPU-DAG: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx906"}}
+// NOGPU-DAG: {{"[^"]*clang[^"]*".* "-triple" "x86_64-unknown-linux-gnu".* 
"-fsanitize=address,leak"}}
+// NOGPUNEG-NOT: warning: ignoring '-fsanitize=leak' option as it is not 
currently supported for target 'amdgcn-amd-amdhsa'
+// NOGPUNEG-NOT: warning: ignoring '-fsanitize=address' option as it is not 
currently supported for offload arch 'gfx900:xnack-'. Use it with an offload 
arch containing 'xnack+' instead
+// NOGPUNEG-NOT: warning: ignoring '-fsanitize=address' option as it is not 
currently supported for offload arch 'gfx906'. Use it with an offload arch 
containing 'xnack+' instead
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx900".* "-target-feature" "\+xnack".* "-fsanitize=address"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* 
"-target-feature" "\+xnack".* "-fsanitize=address,leak"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* 
"-target-feature" "-xnack".* "-fsanitize=address,leak"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx906".* 
"-fsanitize=address,leak"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* 
"-target-feature" "\+xnack".* "-fsanitize=address"}}
+// NOGPUNEG-NOT: 

[PATCH] D120132: [HIP] Fix HIP include path

2022-03-09 Thread Yaxun Liu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG6730b44480fc: [HIP] Fix HIP include path (authored by 
yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120132

Files:
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/test/Driver/hip-include-path.hip
  clang/test/Driver/rocm-detect.hip


Index: clang/test/Driver/rocm-detect.hip
===
--- clang/test/Driver/rocm-detect.hip
+++ clang/test/Driver/rocm-detect.hip
@@ -90,7 +90,7 @@
 // SPACK: Found HIP installation: 
[[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5, version 4.0.20214-a2917cd
 // SPACK: "-triple" "amdgcn-amd-amdhsa"
 // SPACK-SAME: "-mlink-builtin-bitcode" 
"[[DIR]]/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/hip.bc"
-// SPACK-SAME: "-internal-isystem" 
"[[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5/include"
+// SPACK-SAME: "-idirafter" 
"[[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5/include"
 
 // SPACK-MULT: InstalledDir: 
[[DIR:.*]]/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/bin
 // SPACK-MULT-DAG: Cannot use SPACK package hip-4.0.0 at [[DIR]] due to 
multiple installations for the same version
@@ -101,12 +101,12 @@
 // SPACK-SET: Found HIP installation: [[DIR]]/hip-4.0.0-abcd, version 
4.0.20214-a2917cd
 // SPACK-SET: "-triple" "amdgcn-amd-amdhsa"
 // SPACK-SET-SAME: "-mlink-builtin-bitcode" 
"[[DIR]]/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/hip.bc"
-// SPACK-SET-SAME: "-internal-isystem" "[[DIR]]/hip-4.0.0-abcd/include"
+// SPACK-SET-SAME: "-idirafter" "[[DIR]]/hip-4.0.0-abcd/include"
 
 // SPACK-MISS: InstalledDir: 
[[DIR:.*]]/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/bin
 // SPACK-MISS-DAG: SPACK package hip-4.0.0 not found at [[DIR]]
 // SPACK-MISS-NOT: Found HIP installation: 
[[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5, version 4.0.20214-a2917cd
-// SPACK-MISS-NOT: "-internal-isystem" 
"[[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5/include"
+// SPACK-MISS-NOT: "-idirafter" 
"[[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5/include"
 
 // SPACK-MISS-SILENT-NOT: SPACK package hip-{{.*}} not found at
 // SPACK-MISS-SILENT-NOT: Found HIP installation
Index: clang/test/Driver/hip-include-path.hip
===
--- clang/test/Driver/hip-include-path.hip
+++ clang/test/Driver/hip-include-path.hip
@@ -19,24 +19,24 @@
 // COMMON-LABEL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
 // CLANG-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
 // NOCLANG-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
-// HIP-SAME: "-internal-isystem" "{{[^"]*}}Inputs/rocm/include"
-// NOHIP-NOT: "{{.*}}Inputs/rocm/include"
+// HIP-SAME: "-idirafter" "{{[^"]*}}Inputs/rocm/include"
 // HIP-SAME: "-include" "__clang_hip_runtime_wrapper.h"
 // NOHIP-NOT: "-include" "__clang_hip_runtime_wrapper.h"
 // skip check of standard C++ include path
 // CLANG-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"
 // NOCLANG-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"
+// NOHIP-NOT: "{{.*}}Inputs/rocm/include"
 
 // COMMON-LABEL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
 // CLANG-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
 // NOCLANG-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
-// HIP-SAME: "-internal-isystem" "{{[^"]*}}Inputs/rocm/include"
-// NOHIP-NOT: "{{.*}}Inputs/rocm/include"
+// HIP-SAME: "-idirafter" "{{[^"]*}}Inputs/rocm/include"
 // HIP-SAME: "-include" "__clang_hip_runtime_wrapper.h"
 // NOHIP-NOT: "-include" "__clang_hip_runtime_wrapper.h"
 // skip check of standard C++ include path
 // CLANG-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"
 // NOCLANG-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"
+// NOHIP-NOT: "{{.*}}Inputs/rocm/include"
 
 // RUN: %clang -c -### -target x86_64-unknown-linux-gnu --cuda-gpu-arch=gfx900 
\
 // RUN:   -std=c++11 --rocm-path=%S/Inputs/rocm -nogpulib %s 2>&1 \
@@ -45,7 +45,7 @@
 // ROCM35-LABEL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
 // ROCM35-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
 // ROCM35-SAME: "-internal-isystem" "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}"
-// ROCM35-SAME: "-internal-isystem" "{{[^"]*}}Inputs/rocm/include"
+// ROCM35-SAME: "-idirafter" "{{[^"]*}}Inputs/rocm/include"
 // ROCM35-NOT: "-include" "__clang_hip_runtime_wrapper.h"
 // skip check of standard C++ include path
 // ROCM35-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"
Index: clang/lib/Driver/ToolChains/AMDGPU.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ 

[clang] 6730b44 - [HIP] Fix HIP include path

2022-03-09 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2022-03-09T20:57:27-05:00
New Revision: 6730b44480fcce18bfbbae0c46719250e9eae425

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

LOG: [HIP] Fix HIP include path

The clang compiler prepends the HIP header include paths to the search
list using -internal-isystem when building for the HIP language. This
prevents warnings related to things like reserved identifiers when
including the HIP headers even when ROCm is installed in a non-system
directory, such as /opt/rocm.

However, when HIP is installed in /usr, then the prepended include
path would be /usr/include. That is a problem, because the C standard
library headers are stored in /usr/include and the C++ standard
library headers must come before the C library headers in the search
path list (because the C++ standard library headers use #include_next
to include the C standard library headers).

While the HIP wrapper headers _do_ need to be earlier in the search
than the C++ headers, those headers get their own subdirectory and
their own explicit -internal-isystem argument. This include path is for
 and , which do not require a
particular search ordering with respect to the C or C++ headers. Thus,
HIP include path is added after other system include paths.

With contribution from Cordell Bloor.

Reviewed by: Artem Belevich

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/AMDGPU.cpp
clang/test/Driver/hip-include-path.hip
clang/test/Driver/rocm-detect.hip

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/AMDGPU.cpp 
b/clang/lib/Driver/ToolChains/AMDGPU.cpp
index 596fe5b2a2029..8df86ca4f4784 100644
--- a/clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -517,7 +517,7 @@ void RocmInstallationDetector::AddHIPIncludeArgs(const 
ArgList ,
 return;
   }
 
-  CC1Args.push_back("-internal-isystem");
+  CC1Args.push_back("-idirafter");
   CC1Args.push_back(DriverArgs.MakeArgString(getIncludePath()));
   if (UsesRuntimeWrapper)
 CC1Args.append({"-include", "__clang_hip_runtime_wrapper.h"});

diff  --git a/clang/test/Driver/hip-include-path.hip 
b/clang/test/Driver/hip-include-path.hip
index dce42f58fdf5e..92f2fab6c24cf 100644
--- a/clang/test/Driver/hip-include-path.hip
+++ b/clang/test/Driver/hip-include-path.hip
@@ -19,24 +19,24 @@
 // COMMON-LABEL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
 // CLANG-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
 // NOCLANG-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
-// HIP-SAME: "-internal-isystem" "{{[^"]*}}Inputs/rocm/include"
-// NOHIP-NOT: "{{.*}}Inputs/rocm/include"
+// HIP-SAME: "-idirafter" "{{[^"]*}}Inputs/rocm/include"
 // HIP-SAME: "-include" "__clang_hip_runtime_wrapper.h"
 // NOHIP-NOT: "-include" "__clang_hip_runtime_wrapper.h"
 // skip check of standard C++ include path
 // CLANG-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"
 // NOCLANG-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"
+// NOHIP-NOT: "{{.*}}Inputs/rocm/include"
 
 // COMMON-LABEL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
 // CLANG-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
 // NOCLANG-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
-// HIP-SAME: "-internal-isystem" "{{[^"]*}}Inputs/rocm/include"
-// NOHIP-NOT: "{{.*}}Inputs/rocm/include"
+// HIP-SAME: "-idirafter" "{{[^"]*}}Inputs/rocm/include"
 // HIP-SAME: "-include" "__clang_hip_runtime_wrapper.h"
 // NOHIP-NOT: "-include" "__clang_hip_runtime_wrapper.h"
 // skip check of standard C++ include path
 // CLANG-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"
 // NOCLANG-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"
+// NOHIP-NOT: "{{.*}}Inputs/rocm/include"
 
 // RUN: %clang -c -### -target x86_64-unknown-linux-gnu --cuda-gpu-arch=gfx900 
\
 // RUN:   -std=c++11 --rocm-path=%S/Inputs/rocm -nogpulib %s 2>&1 \
@@ -45,7 +45,7 @@
 // ROCM35-LABEL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
 // ROCM35-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
 // ROCM35-SAME: "-internal-isystem" "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}"
-// ROCM35-SAME: "-internal-isystem" "{{[^"]*}}Inputs/rocm/include"
+// ROCM35-SAME: "-idirafter" "{{[^"]*}}Inputs/rocm/include"
 // ROCM35-NOT: "-include" "__clang_hip_runtime_wrapper.h"
 // skip check of standard C++ include path
 // ROCM35-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"

diff  --git a/clang/test/Driver/rocm-detect.hip 
b/clang/test/Driver/rocm-detect.hip
index 3ab0175cf1f15..7166c42e9691e 100644
--- a/clang/test/Driver/rocm-detect.hip
+++ 

[PATCH] D120610: [DebugInfo] Include DW_TAG_skeleton_unit when looking for parent UnitDie

2022-03-09 Thread Wenlei He via Phabricator via cfe-commits
wenlei added a comment.

In D120610#3348997 , @dblaikie wrote:

> This should include a test - and could you describe more about where this 
> issue came up/what motivated the change?

Sure, sorry for the delay as I just got back to this today. I sent the fix 
first hoping to get a sanity check as we were a bit puzzled how come nobody hit 
this in the past.

Here's what happened for the ICE - we needed to add template types when 
constructing subprogram die for template functions (`addTemplateParams`) for 
the skeleton CU, this is done through `getOrCreateContextDIE` which involves 
finding/creating parent DIEs. For that, we sometimes need to retrieve top level 
DIE (`getOrCreateContextDIE` -> `getUnitDie`). Before this fix, we end up with 
nullptr from `getUnitDie`, so some DIEs created in that process has `getUnit()` 
being null which leads to ICE on access.

I added a test case that would cause ICE without this fix (the set of flags 
there is minimum).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120610

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


[PATCH] D120296: [Attr] Fix a btf_type_tag AST generation bug

2022-03-09 Thread Yonghong Song via Phabricator via cfe-commits
yonghong-song updated this revision to Diff 414252.
yonghong-song added a comment.

- clang-format fix
- change variable names to be llvm compliant.
- remove Attr from BTFTagAttributedTypeLoc as it can be retrieved from the 
BTFTagAttributedType
- Also transform the attribute in TreeTransform
- add additional test with _Generic and overloadable attribute


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120296

Files:
  clang/include/clang-c/Index.h
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/ASTNodeTraverser.h
  clang/include/clang/AST/PropertiesBase.td
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeLoc.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/TypeNodes.td
  clang/include/clang/Serialization/ASTRecordWriter.h
  clang/include/clang/Serialization/TypeBitCodes.def
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/CodeGen/attr-btf_type_tag-similar-type.c
  clang/test/PCH/btf_type_tag_attr.c
  clang/test/Sema/attr-btf_type_tag.c
  clang/tools/libclang/CIndex.cpp
  clang/tools/libclang/CXType.cpp

Index: clang/tools/libclang/CXType.cpp
===
--- clang/tools/libclang/CXType.cpp
+++ clang/tools/libclang/CXType.cpp
@@ -116,6 +116,7 @@
 TKCASE(Elaborated);
 TKCASE(Pipe);
 TKCASE(Attributed);
+TKCASE(BTFTagAttributed);
 TKCASE(Atomic);
 default:
   return CXType_Unexposed;
@@ -136,6 +137,10 @@
 return MakeCXType(ATT->getEquivalentType(), TU);
   }
 }
+if (auto *ATT = T->getAs()) {
+  if (!(TU->ParsingOptions & CXTranslationUnit_IncludeAttributedTypes))
+return MakeCXType(ATT->getWrappedType(), TU);
+}
 // Handle paren types as the original type
 if (auto *PTT = T->getAs()) {
   return MakeCXType(PTT->getInnerType(), TU);
@@ -610,6 +615,7 @@
 TKIND(Elaborated);
 TKIND(Pipe);
 TKIND(Attributed);
+TKIND(BTFTagAttributed);
 TKIND(BFloat16);
 #define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) TKIND(Id);
 #include "clang/Basic/OpenCLImageTypes.def"
@@ -1051,6 +1057,9 @@
   if (auto *ATT = T->getAs())
 return MakeCXType(ATT->getModifiedType(), GetTU(CT));
 
+  if (auto *ATT = T->getAs())
+return MakeCXType(ATT->getWrappedType(), GetTU(CT));
+
   return MakeCXType(QualType(), GetTU(CT));
 }
 
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -1672,6 +1672,10 @@
   return Visit(TL.getModifiedLoc());
 }
 
+bool CursorVisitor::VisitBTFTagAttributedTypeLoc(BTFTagAttributedTypeLoc TL) {
+  return Visit(TL.getWrappedLoc());
+}
+
 bool CursorVisitor::VisitFunctionTypeLoc(FunctionTypeLoc TL,
  bool SkipResultType) {
   if (!SkipResultType && Visit(TL.getReturnLoc()))
Index: clang/test/Sema/attr-btf_type_tag.c
===
--- clang/test/Sema/attr-btf_type_tag.c
+++ clang/test/Sema/attr-btf_type_tag.c
@@ -23,3 +23,15 @@
 int __tag4 * __tag5 * __tag6 *foo1(struct t __tag1 * __tag2 * __tag3 *a1) {
   return (int __tag4 * __tag5 * __tag6 *)a1[0][0]->d;
 }
+
+// The btf_type_tag attribute will be ignored during _Generic type matching
+int g1 = _Generic((int *)0, int __tag1 *: 0);
+int g2 = _Generic((int __tag1 *)0, int *: 0);
+
+// The btf_type_tag attribute will be ignored during overloadable type matching
+void __attribute__((overloadable)) bar1(int __tag1 *a);
+void __attribute__((overloadable)) bar2(int *a);
+void foo2(int *a, int __tag1 *b) {
+  bar1(a);
+  bar2(b);
+}
Index: clang/test/PCH/btf_type_tag_attr.c
===
--- /dev/null
+++ clang/test/PCH/btf_type_tag_attr.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -emit-pch -o %t %s
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -include-pch %t \
+// RUN:   -fsyntax-only -verify %s
+
+// expected-no-diagnostics
+
+int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag2"))) *p;
Index: clang/test/CodeGen/attr-btf_type_tag-similar-type.c
===
--- /dev/null
+++ clang/test/CodeGen/attr-btf_type_tag-similar-type.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -triple %itanium_abi_triple -debug-info-kind=limited -S -emit-llvm -o - %s | 

[PATCH] D120610: [DebugInfo] Include DW_TAG_skeleton_unit when looking for parent UnitDie

2022-03-09 Thread Wenlei He via Phabricator via cfe-commits
wenlei updated this revision to Diff 414251.
wenlei added a comment.
Herald added projects: clang, All.
Herald added a subscriber: cfe-commits.

Add test case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120610

Files:
  clang/test/CodeGen/split-debug-inlining-template.c
  llvm/lib/CodeGen/AsmPrinter/DIE.cpp


Index: llvm/lib/CodeGen/AsmPrinter/DIE.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/DIE.cpp
+++ llvm/lib/CodeGen/AsmPrinter/DIE.cpp
@@ -204,6 +204,7 @@
   const DIE *p = this;
   while (p) {
 if (p->getTag() == dwarf::DW_TAG_compile_unit ||
+p->getTag() == dwarf::DW_TAG_skeleton_unit ||
 p->getTag() == dwarf::DW_TAG_type_unit)
   return p;
 p = p->getParent();
Index: clang/test/CodeGen/split-debug-inlining-template.c
===
--- /dev/null
+++ clang/test/CodeGen/split-debug-inlining-template.c
@@ -0,0 +1,16 @@
+// Check that we handle template types for split-dwarf-inlining without ICE.
+// RUN: %clang_cc1 -emit-obj -fdebug-info-for-profiling -fsplit-dwarf-inlining 
-debug-info-kind=constructor -dwarf-version=5 -split-dwarf-file %t.dwo -O2 -o 
%t.o -x c++ %s
+
+struct container {
+  int size();
+};
+
+template 
+int Range(T ) {
+  return x.size();
+}
+
+int main() {
+  container v;
+  return Range(v);
+}


Index: llvm/lib/CodeGen/AsmPrinter/DIE.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/DIE.cpp
+++ llvm/lib/CodeGen/AsmPrinter/DIE.cpp
@@ -204,6 +204,7 @@
   const DIE *p = this;
   while (p) {
 if (p->getTag() == dwarf::DW_TAG_compile_unit ||
+p->getTag() == dwarf::DW_TAG_skeleton_unit ||
 p->getTag() == dwarf::DW_TAG_type_unit)
   return p;
 p = p->getParent();
Index: clang/test/CodeGen/split-debug-inlining-template.c
===
--- /dev/null
+++ clang/test/CodeGen/split-debug-inlining-template.c
@@ -0,0 +1,16 @@
+// Check that we handle template types for split-dwarf-inlining without ICE.
+// RUN: %clang_cc1 -emit-obj -fdebug-info-for-profiling -fsplit-dwarf-inlining -debug-info-kind=constructor -dwarf-version=5 -split-dwarf-file %t.dwo -O2 -o %t.o -x c++ %s
+
+struct container {
+  int size();
+};
+
+template 
+int Range(T ) {
+  return x.size();
+}
+
+int main() {
+  container v;
+  return Range(v);
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 9abeb80 - [Driver][OpenBSD] Disable unwind tables on Arm

2022-03-09 Thread Brad Smith via cfe-commits

Author: Brad Smith
Date: 2022-03-09T20:33:16-05:00
New Revision: 9abeb80e80d0f2e9dd7603491d33fa0683a33ac1

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

LOG: [Driver][OpenBSD] Disable unwind tables on Arm

Arm is not quite ready for unwinding yet.

Added: 


Modified: 
clang/lib/Driver/ToolChains/OpenBSD.cpp
clang/lib/Driver/ToolChains/OpenBSD.h
clang/test/Driver/openbsd.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/OpenBSD.cpp 
b/clang/lib/Driver/ToolChains/OpenBSD.cpp
index 7f19587f5f824..249a00ebb003a 100644
--- a/clang/lib/Driver/ToolChains/OpenBSD.cpp
+++ b/clang/lib/Driver/ToolChains/OpenBSD.cpp
@@ -345,3 +345,12 @@ Tool *OpenBSD::buildAssembler() const {
 Tool *OpenBSD::buildLinker() const { return new tools::openbsd::Linker(*this); 
}
 
 bool OpenBSD::HasNativeLLVMSupport() const { return true; }
+
+bool OpenBSD::IsUnwindTablesDefault(const ArgList ) const {
+switch (getArch()) {
+  case llvm::Triple::arm:
+return false;
+  default:
+return true;
+}
+}

diff  --git a/clang/lib/Driver/ToolChains/OpenBSD.h 
b/clang/lib/Driver/ToolChains/OpenBSD.h
index 9d668711b91b3..2d4c4e34520b7 100644
--- a/clang/lib/Driver/ToolChains/OpenBSD.h
+++ b/clang/lib/Driver/ToolChains/OpenBSD.h
@@ -82,9 +82,7 @@ class LLVM_LIBRARY_VISIBILITY OpenBSD : public Generic_ELF {
   std::string getCompilerRT(const llvm::opt::ArgList , StringRef 
Component,
 FileType Type = ToolChain::FT_Static) const 
override;
 
-  bool IsUnwindTablesDefault(const llvm::opt::ArgList ) const override {
-return true;
-  }
+  bool IsUnwindTablesDefault(const llvm::opt::ArgList ) const override;
 
   LangOptions::StackProtectorMode
   GetDefaultStackProtectorLevel(bool KernelOrKext) const override {

diff  --git a/clang/test/Driver/openbsd.c b/clang/test/Driver/openbsd.c
index 9a811c1932329..594f90ab3a386 100644
--- a/clang/test/Driver/openbsd.c
+++ b/clang/test/Driver/openbsd.c
@@ -121,7 +121,8 @@
 
 // Check that unwind tables are enabled
 // RUN: %clang -target arm-unknown-openbsd -### -S %s 2>&1 | \
-// RUN: FileCheck -check-prefix=UNWIND-TABLES %s
+// RUN: FileCheck -check-prefix=NO-UNWIND-TABLES %s
 // RUN: %clang -target mips64-unknown-openbsd -### -S %s 2>&1 | \
 // RUN: FileCheck -check-prefix=UNWIND-TABLES %s
 // UNWIND-TABLES: "-funwind-tables=2"
+// NO-UNWIND-TABLES-NOT: "-funwind-tables=2"



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


[PATCH] D121176: [ASTStructuralEquivalence] Add support for comparing ObjCCategoryDecl.

2022-03-09 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai marked 2 inline comments as done.
vsapsai added a comment.

`check-lldb` has the following tests failing

  lldb-shell :: Expr/TestIRMemoryMap.test
  lldb-shell :: Process/TestEnvironment.test
  lldb-shell :: Register/x86-64-gp-read.test
  lldb-shell :: Register/x86-64-read.test
  lldb-shell :: Register/x86-64-ymm-read.test
  lldb-shell :: Register/x86-multithread-read.test
  lldb-shell :: Register/x86-multithread-write.test

All of them look irrelevant as they are failing with various "file not found" 
errors, e.g., cstdlib, cstdint, cinttypes. I guess my local toolchain 
configuration differs from LLDB expectations.




Comment at: clang/lib/AST/ASTStructuralEquivalence.cpp:1971
+return false;
+  unsigned SlotsToCheck = NumArgs > 0 ? NumArgs : 1;
+  for (unsigned I = 0; I < SlotsToCheck; ++I) {

vsapsai wrote:
> shafik wrote:
> > I am curious what case are we catching here? Does `NumArgs` ever have the 
> > value `1`?
> Here I'm trying to handle the case with argument-less methods. For example, 
> `-(void)test;` has 0 arguments but we still want to compare the first slot. 
> At the moment I don't know how to clarify the code to make the intention 
> clearer. Can add a comment explaining the intention (though there is a test 
> that should catch breaking code accidentally).
> 
> And to answer your question, `NumArgs` can have value `1`.
Added a comment.



Comment at: clang/lib/AST/ASTStructuralEquivalence.cpp:1989
+   ++ParamT1, ++ParamT2) {
+if (!IsStructurallyEquivalent(Context, *ParamT1, *ParamT2))
+  return false;

vsapsai wrote:
> a_sidorin wrote:
> > Should we check if the parameter count is different?
> Mismatch in the number of parameters should be caught by `NumArgs != 
> Selector2.getNumArgs()` earlier. But I think it makes sense to add an 
> assertion verifying `param_size` is equal at this point.
Added an assertion for `param_size` (not triggered during running the test 
suite).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121176

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


[PATCH] D121176: [ASTStructuralEquivalence] Add support for comparing ObjCCategoryDecl.

2022-03-09 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai updated this revision to Diff 414244.
vsapsai added a comment.

Add a comment and an assertion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121176

Files:
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/unittests/AST/StructuralEquivalenceTest.cpp

Index: clang/unittests/AST/StructuralEquivalenceTest.cpp
===
--- clang/unittests/AST/StructuralEquivalenceTest.cpp
+++ clang/unittests/AST/StructuralEquivalenceTest.cpp
@@ -1120,6 +1120,188 @@
   EXPECT_FALSE(testStructuralMatch(t));
 }
 
+struct StructuralEquivalenceObjCCategoryTest : StructuralEquivalenceTest {};
+
+TEST_F(StructuralEquivalenceObjCCategoryTest, MatchinCategoryNames) {
+  auto t = makeDecls("@interface A @end @interface A(X) @end",
+   "@interface A @end @interface A(X) @end",
+   Lang_OBJCXX, objcCategoryDecl());
+  EXPECT_TRUE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceObjCCategoryTest, CategoriesForDifferentClasses) {
+  auto t = makeDecls("@interface A @end @interface A(X) @end",
+   "@interface B @end @interface B(X) @end",
+   Lang_OBJCXX, objcCategoryDecl());
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceObjCCategoryTest, CategoriesWithDifferentNames) {
+  auto t = makeDecls("@interface A @end @interface A(X) @end",
+   "@interface A @end @interface A(Y) @end",
+   Lang_OBJCXX, objcCategoryDecl());
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceObjCCategoryTest, CategoryAndExtension) {
+  auto t = makeDecls("@interface A @end @interface A(X) @end",
+   "@interface A @end @interface A() @end",
+   Lang_OBJCXX, objcCategoryDecl());
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceObjCCategoryTest, MatchingProtocols) {
+  auto t = makeDecls(
+  "@protocol P @end @interface A @end @interface A(X) @end",
+  "@protocol P @end @interface A @end @interface A(X) @end", Lang_OBJCXX,
+  objcCategoryDecl());
+  EXPECT_TRUE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceObjCCategoryTest, DifferentProtocols) {
+  auto t = makeDecls(
+  "@protocol P @end @interface A @end @interface A(X) @end",
+  "@protocol Q @end @interface A @end @interface A(X) @end", Lang_OBJCXX,
+  objcCategoryDecl());
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceObjCCategoryTest, DifferentProtocolsOrder) {
+  auto t = makeDecls(
+  "@protocol P @end @protocol Q @end @interface A @end @interface A(X) @end",
+  "@protocol P @end @protocol Q @end @interface A @end @interface A(X) @end",
+  Lang_OBJCXX, objcCategoryDecl());
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceObjCCategoryTest, MatchingIvars) {
+  auto t = makeDecls(
+  "@interface A @end @interface A() { int x; } @end",
+  "@interface A @end @interface A() { int x; } @end", Lang_OBJCXX,
+  objcCategoryDecl());
+  EXPECT_TRUE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceObjCCategoryTest, DifferentIvarName) {
+  auto t = makeDecls(
+  "@interface A @end @interface A() { int x; } @end",
+  "@interface A @end @interface A() { int y; } @end", Lang_OBJCXX,
+  objcCategoryDecl());
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceObjCCategoryTest, DifferentIvarType) {
+  auto t = makeDecls(
+  "@interface A @end @interface A() { int x; } @end",
+  "@interface A @end @interface A() { float x; } @end", Lang_OBJCXX,
+  objcCategoryDecl());
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceObjCCategoryTest, DifferentIvarBitfieldWidth) {
+  auto t = makeDecls(
+  "@interface A @end @interface A() { int x: 1; } @end",
+  "@interface A @end @interface A() { int x: 2; } @end", Lang_OBJCXX,
+  objcCategoryDecl());
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceObjCCategoryTest, DifferentIvarVisibility) {
+  auto t = makeDecls(
+  "@interface A @end @interface A() { @public int x; } @end",
+  "@interface A @end @interface A() { @protected int x; } @end",
+  Lang_OBJCXX, objcCategoryDecl());
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceObjCCategoryTest, DifferentIvarNumber) {
+  auto t = makeDecls(
+  "@interface A @end @interface A() { int x; } @end",
+  "@interface A @end @interface A() {} @end", Lang_OBJCXX,
+  objcCategoryDecl());
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceObjCCategoryTest, DifferentIvarOrder) {
+  auto t = makeDecls(
+  "@interface A @end 

[PATCH] D115907: [misexpect] Re-implement MisExpect Diagnostics

2022-03-09 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth added a comment.

MisExpect was originally intended to be quite strict, so that developers would 
audit their code and re-evaluate the correctness of their annotations,or if 
they were needed at all.

I think I'm still of a mind that getting flagged by MisExpect indicates that a 
different annotation would be more beneficial, such as 
`llvm.expect.with.probability`.

Regardless, I agree its good to give users an option to relax the checking when 
they want to, so I will add an option that allows them to specify a scaling 
factor for the threshold.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115907

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


[PATCH] D115907: [misexpect] Re-implement MisExpect Diagnostics

2022-03-09 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

Please also consider https://github.com/llvm/llvm-project/issues/46534


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115907

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


[PATCH] D115907: [misexpect] Re-implement MisExpect Diagnostics

2022-03-09 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth marked 6 inline comments as done.
paulkirth added inline comments.



Comment at: clang/lib/CodeGen/CodeGenAction.cpp:1203
 
+  if (CodeGenOpts.MisExpect) {
+Ctx.setMisExpectWarningRequested(true);

tejohnson wrote:
> Out of curiosity, since I am less familiar with clang than llvm, when is this 
> path taken vs where this is done at line 336 in HandleTranslationUnit?
> 
> Also, it might be nice to have this code placed either consistently before or 
> after the OptRecordFile handling in these two locations, so it is easier to 
> compare.
That was a good catch, I had forgotten to remove this after patching in line 
366. I moved that a bit a few lines lower to fit more nicely, and removed this 
one entirely.



Comment at: llvm/docs/MisExpect.rst:2
+===
+Misexpect
+===

tejohnson wrote:
> I don't see a mention of -Wmisexpect in the document. Should there be 
> user-facing clang documentation, this seems more specific to the LLVM 
> implementation?
I will update the patch to include similar documentation this for clang.

Additionally, my understanding is that documentation for warnings is 
auto-generated from the tablegen, so that at least will be available 
automatically.





Comment at: llvm/docs/MisExpect.rst:22
+The MisExpect checks in the LLVM backend follow a simple procedure: if the
+profiling counter associated with an instruction using the ``llvm.expect``
+intrinsic was too low along the expected path, then it emits a diagnostic

tejohnson wrote:
> Suggest using "profile weight" not profiling counter since we don't really 
> have profile counters associated with instructions (rather with edges in the 
> MST, at least in the IR PGO).
> 
> Also, doesn't the profile weight being too low only handle the LIKELY case? 
> What about something being marked UNLIKELY with a hot/high profile weight? 
> edit: After looking through the implementation, I think the comparison only 
> being done in this direction is based on the way it is implemented, but it is 
> unclear from this documentation here how the comparison is handling things 
> being off in either direction.
Maybe my mental model is off here, but doesn't the `llvm.expect` intrinsic mark 
a specific value as the 'likely' or expected value? So if you want to mark a 
branch as unlikely, you're essentially marking the other half of it as 'hot'.

We could change the comparison to compare all parts of the branch weights too, 
but the case of an 'unlikely' branch being too hot in my model is captured by 
the 'likely' branch becoming too 'cold'.

If that is incorrect, I'd really appreciate some guidance on how to model this 
more accurately.



Comment at: llvm/docs/MisExpect.rst:39
+``-unlikely-branch-weight`` LLVM options. During verification, if the
+profile count is less than the calculated threshold, then we will emit a
+remark or warning detailing a potential performance regression. The

tejohnson wrote:
> s/count/weight/
> 
> Also, similar to my earlier comment, what about an expect UNLIKELY branch 
> with a high profile weight?
I think I've reworded this to clarify things a bit more, but let me know if it 
still needs some polish.



Comment at: llvm/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp:109
 
+  SI.setCondition(ArgValue);
+

tejohnson wrote:
> Is there a reason why this line has changed ordering w.r.t. setMetadata?
I think I actually restored this to what it was before the original MisExpect 
patch, but there is no need for that, so I've removed it.



Comment at: llvm/lib/Transforms/Utils/MisExpect.cpp:170
+
+  if (ProfileCount < ScaledThreshold)
+emitMisexpectDiagnostic(I, Ctx, ProfileCount, CaseTotal);

tejohnson wrote:
> Is this too strict - i.e. what if they are off by only a small amount?
Maybe. I don't know what a good default fudge factor would be, though. Maybe 
use 5%, and expose a flag that can override it?

Another approach is that the values used by `llvm.expect` can be changed via 
clang flags, which will update the weights checked against. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115907

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


[PATCH] D118511: Add a warning for not packing non-POD members in packed structs

2022-03-09 Thread Tom Stellard via Phabricator via cfe-commits
tstellar added a comment.

I'm fine with reverting if you think this is the best solution.  I just would 
like to conclude soon so I can make the final release candidate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118511

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


[PATCH] D118352: [clang][ABI] New c++20 modules mangling scheme

2022-03-09 Thread H. Vetinari via Phabricator via cfe-commits
h-vetinari added a comment.

Something must have gone wrong... communication-wise... as @urnathan seems to 
have abandoned (resp. resigned from) all modules PRs. Hope any 
misunderstandings or grievances can be worked out!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118352

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


[PATCH] D115907: [misexpect] Re-implement MisExpect Diagnostics

2022-03-09 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth updated this revision to Diff 414230.
paulkirth added a comment.

Consolodate common code, clarify documentation, and address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115907

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Profile/Inputs/misexpect-branch-nonconst-expect-arg.proftext
  clang/test/Profile/Inputs/misexpect-branch.proftext
  clang/test/Profile/Inputs/misexpect-switch-default-only.proftext
  clang/test/Profile/Inputs/misexpect-switch-default.proftext
  clang/test/Profile/Inputs/misexpect-switch-nonconst.proftext
  clang/test/Profile/Inputs/misexpect-switch.proftext
  clang/test/Profile/misexpect-branch-cold.c
  clang/test/Profile/misexpect-branch-nonconst-expected-val.c
  clang/test/Profile/misexpect-branch-unpredictable.c
  clang/test/Profile/misexpect-branch.c
  clang/test/Profile/misexpect-switch-default.c
  clang/test/Profile/misexpect-switch-nonconst.c
  clang/test/Profile/misexpect-switch-only-default-case.c
  clang/test/Profile/misexpect-switch.c
  llvm/docs/MisExpect.rst
  llvm/include/llvm/IR/DiagnosticInfo.h
  llvm/include/llvm/IR/LLVMContext.h
  llvm/include/llvm/Target/TargetOptions.h
  llvm/include/llvm/Transforms/Utils/MisExpect.h
  llvm/lib/IR/DiagnosticInfo.cpp
  llvm/lib/IR/LLVMContext.cpp
  llvm/lib/IR/LLVMContextImpl.h
  llvm/lib/Transforms/IPO/SampleProfile.cpp
  llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
  llvm/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp
  llvm/lib/Transforms/Utils/CMakeLists.txt
  llvm/lib/Transforms/Utils/MisExpect.cpp
  llvm/test/Transforms/PGOProfile/Inputs/misexpect-branch-correct.proftext
  llvm/test/Transforms/PGOProfile/Inputs/misexpect-branch.proftext
  llvm/test/Transforms/PGOProfile/Inputs/misexpect-switch-correct.proftext
  llvm/test/Transforms/PGOProfile/Inputs/misexpect-switch.proftext
  llvm/test/Transforms/PGOProfile/misexpect-branch-correct.ll
  llvm/test/Transforms/PGOProfile/misexpect-branch-stripped.ll
  llvm/test/Transforms/PGOProfile/misexpect-branch-unpredictable.ll
  llvm/test/Transforms/PGOProfile/misexpect-branch.ll
  llvm/test/Transforms/PGOProfile/misexpect-switch-default.ll
  llvm/test/Transforms/PGOProfile/misexpect-switch.ll

Index: llvm/test/Transforms/PGOProfile/misexpect-switch.ll
===
--- /dev/null
+++ llvm/test/Transforms/PGOProfile/misexpect-switch.ll
@@ -0,0 +1,290 @@
+; RUN: llvm-profdata merge %S/Inputs/misexpect-switch.proftext -o %t.profdata
+; RUN: llvm-profdata merge %S/Inputs/misexpect-switch-correct.proftext -o %t.c.profdata
+
+; RUN: opt < %s -lower-expect -pgo-instr-use -pgo-test-profile-file=%t.profdata -S -pgo-warn-misexpect 2>&1 | FileCheck %s --check-prefix=WARNING
+; RUN: opt < %s -lower-expect -pgo-instr-use -pgo-test-profile-file=%t.profdata -S -pass-remarks=misexpect 2>&1 | FileCheck %s --check-prefix=REMARK
+; RUN: opt < %s -lower-expect -pgo-instr-use -pgo-test-profile-file=%t.profdata -S -pgo-warn-misexpect -pass-remarks=misexpect 2>&1 | FileCheck %s --check-prefix=BOTH
+; RUN: opt < %s -lower-expect -pgo-instr-use -pgo-test-profile-file=%t.profdata -S 2>&1 | FileCheck %s --check-prefix=DISABLED
+
+; New PM
+; RUN: opt < %s -passes="function(lower-expect),pgo-instr-use" -pgo-test-profile-file=%t.profdata -pgo-warn-misexpect -S 2>&1 | FileCheck %s --check-prefix=WARNING
+; RUN: opt < %s -passes="function(lower-expect),pgo-instr-use" -pgo-test-profile-file=%t.profdata -pass-remarks=misexpect -S 2>&1 | FileCheck %s --check-prefix=REMARK
+; RUN: opt < %s -passes="function(lower-expect),pgo-instr-use" -pgo-test-profile-file=%t.profdata -pgo-warn-misexpect -pass-remarks=misexpect -S 2>&1 | FileCheck %s --check-prefix=BOTH
+; RUN: opt < %s -passes="function(lower-expect),pgo-instr-use" -pgo-test-profile-file=%t.profdata -S 2>&1 | FileCheck %s --check-prefix=DISABLED
+
+; RUN: opt < %s -lower-expect -pgo-instr-use -pgo-test-profile-file=%t.c.profdata -S -pgo-warn-misexpect -pass-remarks=misexpect 2>&1 | FileCheck %s --check-prefix=CORRECT
+; RUN: opt < %s -passes="function(lower-expect),pgo-instr-use" -pgo-test-profile-file=%t.c.profdata -pgo-warn-misexpect -pass-remarks=misexpect -S 2>&1 | FileCheck %s --check-prefix=CORRECT
+
+; WARNING-DAG: warning: misexpect-switch.c:26:30: 0.00%
+; WARNING-NOT: remark: misexpect-switch.c:26:30: Potential performance regression from use of the llvm.expect intrinsic: Annotation was correct on 0.00% (0 / 8112) of profiled executions.
+
+; REMARK-NOT: warning: misexpect-switch.c:26:30: 0.00%
+; REMARK-DAG: remark: misexpect-switch.c:26:30: Potential performance regression from use of the llvm.expect intrinsic: Annotation was correct on 0.00% (0 / 

[PATCH] D121233: [pseudo] Move pseudoparser from clang to clang-tools-extra

2022-03-09 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

Thanks Aaron, and my apologies for being easily frustrated.

In D121233#3370992 , @aaron.ballman 
wrote:

> 2. The layout of clang-tools-extra in terms of test directories is 
> problematic and it'd sure be nice if someday someone moved the test 
> directories under the individual tools instead of using a top-level test 
> directory.

I'd really like to enable this.
I think the blocker is mostly the amount of boilerplate needed to set up test 
directories. 
These required files are mostly boilerplate:

- test/CMakeLists.txt (deps are meaningful, rest is boilerplate)
- test/lit.site.cfg.py.in
- test/lit.cfg.py
- test/Unit/lit.site.cfg.py.in (this patch puts these under unittest/ instead, 
but either way)
- test/Unit/lit.cfg.py

Creating 10 more copies of each of those seems a little irresponsible, 
especially for tools that are "lightly maintained". So it's hard to say with a 
straight face that restructuring them all is a good idea, and maybe this 
motivated the original clang-tools-extra structure.
But if those files were generated/eliminated somehow, restructuring would be 
very simple patches that didn't add more cruft to maintain.

It's not obvious to me exactly how to do this (lit.* files affect both 
discovery and configuration) but I'll dig into this more tomorrow.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121233

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


[PATCH] D120527: [OpaquePtr][AArch64] Use elementtype on ldxr/stxr

2022-03-09 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks updated this revision to Diff 414225.
aeubanks added a comment.
Herald added a project: All.

address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120527

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/arm_acle.c
  clang/test/CodeGen/builtins-arm-exclusive.c
  clang/test/CodeGenCXX/builtins-arm-exclusive.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
  llvm/test/CodeGen/AArch64/GlobalISel/arm64-irtranslator.ll
  llvm/test/CodeGen/AArch64/arm64-ldxr-stxr.ll
  llvm/test/CodeGen/AArch64/arm64_32-atomics.ll
  llvm/test/Transforms/AtomicExpand/AArch64/expand-atomicrmw-xchg-fp.ll
  llvm/test/Transforms/ConstantHoisting/AArch64/const-hoist-intrinsics.ll
  llvm/test/Verifier/aarch64-ldstxr.ll

Index: llvm/test/Verifier/aarch64-ldstxr.ll
===
--- /dev/null
+++ llvm/test/Verifier/aarch64-ldstxr.ll
@@ -0,0 +1,19 @@
+; RUN: not opt -passes=verify -S < %s 2>&1 | FileCheck %s
+
+define void @f(i32* %p) {
+; CHECK: Intrinsic requires elementtype attribute on first argument
+  %a = call i64 @llvm.aarch64.ldxr.p0i32(i32* %p)
+; CHECK: Intrinsic requires elementtype attribute on second argument
+  %c = call i32 @llvm.aarch64.stxr.p0i32(i64 0, i32* %p)
+
+; CHECK: Intrinsic requires elementtype attribute on first argument
+  %a2 = call i64 @llvm.aarch64.ldaxr.p0i32(i32* %p)
+; CHECK: Intrinsic requires elementtype attribute on second argument
+  %c2 = call i32 @llvm.aarch64.stlxr.p0i32(i64 0, i32* %p)
+  ret void
+}
+
+declare i64 @llvm.aarch64.ldxr.p0i32(i32*)
+declare i64 @llvm.aarch64.ldaxr.p0i32(i32*)
+declare i32 @llvm.aarch64.stxr.p0i32(i64, i32*)
+declare i32 @llvm.aarch64.stlxr.p0i32(i64, i32*)
Index: llvm/test/Transforms/ConstantHoisting/AArch64/const-hoist-intrinsics.ll
===
--- llvm/test/Transforms/ConstantHoisting/AArch64/const-hoist-intrinsics.ll
+++ llvm/test/Transforms/ConstantHoisting/AArch64/const-hoist-intrinsics.ll
@@ -9,26 +9,26 @@
 ; CHECK-NEXT:[[CONST:%.*]] = bitcast i64 -9223372036317904832 to i64
 ; CHECK-NEXT:[[PTR_0:%.*]] = getelementptr i64, i64* [[PTR:%.*]], i64 0
 ; CHECK-NEXT:[[CONST_MAT:%.*]] = add i64 [[CONST]], -64
-; CHECK-NEXT:[[BAR_0:%.*]] = call i32 @llvm.aarch64.stxr.p0i64(i64 [[CONST_MAT]], i64* [[PTR_0]])
+; CHECK-NEXT:[[BAR_0:%.*]] = call i32 @llvm.aarch64.stxr.p0i64(i64 [[CONST_MAT]], i64* elementtype(i64) [[PTR_0]])
 ; CHECK-NEXT:[[PTR_1:%.*]] = getelementptr i64, i64* [[PTR]], i64 1
-; CHECK-NEXT:[[BAR_1:%.*]] = call i32 @llvm.aarch64.stxr.p0i64(i64 [[CONST]], i64* [[PTR_1]])
+; CHECK-NEXT:[[BAR_1:%.*]] = call i32 @llvm.aarch64.stxr.p0i64(i64 [[CONST]], i64* elementtype(i64) [[PTR_1]])
 ; CHECK-NEXT:[[PTR_2:%.*]] = getelementptr i64, i64* [[PTR]], i64 2
 ; CHECK-NEXT:[[CONST_MAT1:%.*]] = add i64 [[CONST]], 64
-; CHECK-NEXT:[[BAR_2:%.*]] = call i32 @llvm.aarch64.stxr.p0i64(i64 [[CONST_MAT1]], i64* [[PTR_2]])
+; CHECK-NEXT:[[BAR_2:%.*]] = call i32 @llvm.aarch64.stxr.p0i64(i64 [[CONST_MAT1]], i64* elementtype(i64) [[PTR_2]])
 ; CHECK-NEXT:[[PTR_3:%.*]] = getelementptr i64, i64* [[PTR]], i64 3
 ; CHECK-NEXT:[[CONST_MAT2:%.*]] = add i64 [[CONST]], 128
-; CHECK-NEXT:[[BAR_3:%.*]] = call i32 @llvm.aarch64.stxr.p0i64(i64 [[CONST_MAT2]], i64* [[PTR_3]])
+; CHECK-NEXT:[[BAR_3:%.*]] = call i32 @llvm.aarch64.stxr.p0i64(i64 [[CONST_MAT2]], i64* elementtype(i64) [[PTR_3]])
 ; CHECK-NEXT:ret void
 ;
 entry:
   %ptr.0 = getelementptr i64, i64* %ptr, i64 0
-  %bar.0 = call i32 @llvm.aarch64.stxr.p0i64(i64 -9223372036317904896, i64* %ptr.0)
+  %bar.0 = call i32 @llvm.aarch64.stxr.p0i64(i64 -9223372036317904896, i64* elementtype(i64) %ptr.0)
   %ptr.1 = getelementptr i64, i64* %ptr, i64 1
-  %bar.1 = call i32 @llvm.aarch64.stxr.p0i64(i64 -9223372036317904832,  i64* %ptr.1)
+  %bar.1 = call i32 @llvm.aarch64.stxr.p0i64(i64 -9223372036317904832,  i64* elementtype(i64) %ptr.1)
   %ptr.2 = getelementptr i64, i64* %ptr, i64 2
-  %bar.2 = call i32 @llvm.aarch64.stxr.p0i64(i64 -9223372036317904768, i64* %ptr.2)
+  %bar.2 = call i32 @llvm.aarch64.stxr.p0i64(i64 -9223372036317904768, i64* elementtype(i64) %ptr.2)
   %ptr.3 = getelementptr i64, i64* %ptr, i64 3
-  %bar.3 = call i32 @llvm.aarch64.stxr.p0i64(i64 -9223372036317904704, i64* %ptr.3)
+  %bar.3 = call i32 @llvm.aarch64.stxr.p0i64(i64 -9223372036317904704, i64* elementtype(i64) %ptr.3)
   ret void
 }
 
Index: llvm/test/Transforms/AtomicExpand/AArch64/expand-atomicrmw-xchg-fp.ll
===
--- llvm/test/Transforms/AtomicExpand/AArch64/expand-atomicrmw-xchg-fp.ll
+++ llvm/test/Transforms/AtomicExpand/AArch64/expand-atomicrmw-xchg-fp.ll
@@ -8,10 +8,10 @@
 ; CHECK-NEXT:[[TMP2:%.*]] = bitcast half [[VAL:%.*]] to i16
 ; CHECK-NEXT:br label 

[PATCH] D120296: [Attr] Fix a btf_type_tag AST generation bug

2022-03-09 Thread Yonghong Song via Phabricator via cfe-commits
yonghong-song added a comment.

@aaron.ballman Thanks for the review! I will address all your comments and will 
also add tests with `_Generic` and `__attribute__((overloadable))`.




Comment at: clang/include/clang/AST/Type.h:4797
+
+  BTFTagAttributedType(QualType canon, QualType wrapped,
+   BTFTypeTagAttr *attr)

aaron.ballman wrote:
> You should fix the formatting issue, but also, the parameter names don't 
> match the usual naming conventions (please don't replace `attr` with `Attr` 
> though; that's a type name, so go with something else like `BTFAttr`).
Will do. Sorry, I didn't spend effort on formatting itself as I know I will 
need to make revisions. But indeed should do it regardless!



Comment at: clang/include/clang/AST/Type.h:4804
+  QualType getWrappedType() const { return WrappedType; }
+  BTFTypeTagAttr *getAttr() const { return Attr; }
+

aaron.ballman wrote:
> Should this be returning a `const BTFTypeTagAttr *` instead?
Yes, will use 'const BTFTypeTagAttr *` in the next revision.



Comment at: clang/include/clang/AST/TypeLoc.h:904-917
+struct BTFTagAttributedLocInfo {
+  const Attr *TypeAttr;
+};
+
+/// Type source information for an btf_tag attributed type.
+class BTFTagAttributedTypeLoc
+: public ConcreteTypeLoc This seems a bit suspicious to me -- we are store the same attribute twice 
> (once on the `BTFTagAttributedType` and once on its type loc). Do we need to 
> do that, or can we have the type loc reach through the type pointer to get 
> the attribute from there? (Alternatively, do we want to require callers to 
> have access to an `BTFTagAttributedTypeLoc` in order to query the attribute, 
> similar to how `AttributedType`/`AttributedTypeLoc` work?)
Good point. Will change
```
struct BTFTagAttributedLocInfo {
  const Attr *TypeAttr;
};
```
to
```
struct BTFTagAttributedLocInfo {
};
```
since we can get the attribute from the `BTFTagAttributedType` itself.



Comment at: clang/include/clang/AST/TypeLoc.h:925
+
+  void initializeLocal(ASTContext , SourceLocation loc) {
+setAttr(nullptr);

aaron.ballman wrote:
> `loc` is unused? (and should have its identifier removed if this is on 
> purpose)
loc is needed in the parameter for this function. For example, in 
QualifiedTypeLoc, we have
```
  /// Initializes the local data of this type source info block to
  /// provide no information.
  void initializeLocal(ASTContext , SourceLocation Loc) {
// do nothing
  }
```



Comment at: clang/include/clang/Serialization/ASTRecordWriter.h:126-127
 
+  /// Write an Attr object.
+  void writeAttr(Attr *attr) { AddAttr(attr); }
+

aaron.ballman wrote:
> This doesn't appear to be used? Or is this called automagically because of 
> the changes in `TypeProperties.td`?
It is used because the changes in `TypeProperties.td`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120296

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


[PATCH] D120936: [Sema][Windows] Don't special-case void* in __unaligned conversions.

2022-03-09 Thread Reid Kleckner via Phabricator via cfe-commits
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

lgtm, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120936

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


[PATCH] D121269: [clang-format] Fix namespace format when the name is followed by a macro

2022-03-09 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu updated this revision to Diff 414222.
zequanwu marked 2 inline comments as done.
zequanwu added a comment.

Refactor.
Add a test for `namespace A __attribute__((availability(macos, 
introduced=10.15))) {`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121269

Files:
  clang/lib/Format/NamespaceEndCommentsFixer.cpp
  clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp

Index: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
===
--- clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
+++ clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
@@ -189,6 +189,49 @@
 "int i;\n"
 "int j;\n"
 "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A M(x)",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ(
+  "#define B __attribute__((availability(macos, introduced=10.15)))\n"
+  "namespace A B {\n"
+  "int i;\n"
+  "int j;\n"
+  "}// namespace A B",
+  fixNamespaceEndComments(
+  "#define B __attribute__((availability(macos, introduced=10.15)))\n"
+  "namespace A B {\n"
+  "int i;\n"
+  "int j;\n"
+  "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A::B M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::B",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A::B M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ(
+  "namespace A __attribute__((availability(macos, introduced=10.15))) {\n"
+  "int i;\n"
+  "int j;\n"
+  "}// namespace A",
+  fixNamespaceEndComments(
+  "namespace A __attribute__((availability(macos, introduced=10.15))) "
+  "{\n"
+  "int i;\n"
+  "int j;\n"
+  "}"));
   EXPECT_EQ("inline namespace A {\n"
 "int i;\n"
 "int j;\n"
Index: clang/lib/Format/NamespaceEndCommentsFixer.cpp
===
--- clang/lib/Format/NamespaceEndCommentsFixer.cpp
+++ clang/lib/Format/NamespaceEndCommentsFixer.cpp
@@ -13,6 +13,7 @@
 //===--===//
 
 #include "NamespaceEndCommentsFixer.h"
+#include "clang/Basic/TokenKinds.h"
 #include "llvm/Support/Debug.h"
 #include "llvm/Support/Regex.h"
 
@@ -22,6 +23,39 @@
 namespace format {
 
 namespace {
+// Iterates all tokens starting from StartTok to EndTok and apply Fn to all
+// tokens between them including StartTok and EndTok. Returns the token after
+// EndTok.
+const FormatToken *
+processTokens(const FormatToken *Tok, tok::TokenKind StartTok,
+  tok::TokenKind EndTok,
+  llvm::function_ref Fn) {
+  if (!Tok || !Tok->is(StartTok))
+return Tok;
+  int NestLevel = 0;
+  do {
+if (Tok->is(StartTok))
+  ++NestLevel;
+else if (Tok->is(EndTok))
+  --NestLevel;
+if (Fn)
+  Fn(Tok);
+Tok = Tok->getNextNonComment();
+  } while (Tok && NestLevel > 0);
+  return Tok;
+}
+
+const FormatToken *skipAttribute(const FormatToken *Tok) {
+  if (!Tok)
+return nullptr;
+  if (Tok->is(tok::kw___attribute)) {
+Tok = Tok->getNextNonComment();
+Tok = processTokens(Tok, tok::l_paren, tok::r_paren, nullptr);
+  } else if (Tok->is(tok::l_square))
+Tok = processTokens(Tok, tok::l_square, tok::r_square, nullptr);
+  return Tok;
+}
+
 // Computes the name of a namespace given the namespace token.
 // Returns "" for anonymous namespace.
 std::string computeName(const FormatToken *NamespaceTok) {
@@ -41,44 +75,67 @@
 }
   } else {
 // Skip attributes.
-if (Tok && Tok->is(tok::l_square)) {
-  for (int NestLevel = 1; NestLevel > 0;) {
-Tok = Tok->getNextNonComment();
-if (!Tok)
-  break;
-if (Tok->is(tok::l_square))
-  ++NestLevel;
-else if (Tok->is(tok::r_square))
-  --NestLevel;
-  }
-  if (Tok)
-Tok = Tok->getNextNonComment();
-}
+Tok = skipAttribute(Tok);
 
-// Use the string after `namespace` as a name candidate until `{` or `::` or
-// `(`. If the name is empty, use the candicate.
 std::string FirstNSName;
 // For `namespace [[foo]] A::B::inline C {` or
 // `namespace MACRO1 MACRO2 A::B::inline C {`, returns "A::B::inline C".
 // Peek for the first '::' (or '{' or '(')) and then return 

[PATCH] D119599: [clang-format] Add option to align compound assignments like `+=`

2022-03-09 Thread sstwcw via Phabricator via cfe-commits
sstwcw added a comment.

Any more problems with this revision?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119599

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


[PATCH] D121122: Set FLT_EVAL_METHOD to -1 when fast-math is enabled.

2022-03-09 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam updated this revision to Diff 414216.

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

https://reviews.llvm.org/D121122

Files:
  clang/lib/Lex/PPMacroExpansion.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/test/CodeGen/eval-method-fast-math.c

Index: clang/test/CodeGen/eval-method-fast-math.c
===
--- /dev/null
+++ clang/test/CodeGen/eval-method-fast-math.c
@@ -0,0 +1,87 @@
+// RUN: %clang_cc1 -fexperimental-strict-floating-point  \
+// RUN: -triple x86_64-linux-gnu -emit-llvm -o - %s  \
+// RUN: | FileCheck %s -check-prefixes=CHECK
+
+// RUN: %clang_cc1 -triple i386--linux -emit-llvm -o - %s \
+// RUN: | FileCheck %s -check-prefixes=CHECK-EXT
+
+// RUN: %clang_cc1 -fexperimental-strict-floating-point  \
+// RUN: -mreassociate -freciprocal-math -ffp-contract=fast \
+// RUN: -ffast-math -triple x86_64-linux-gnu \
+// RUN: -emit-llvm -o - %s \
+// RUN: | FileCheck %s -check-prefixes=CHECK-FAST
+
+// RUN: %clang_cc1 -triple i386--linux -mreassociate -freciprocal-math \
+// RUN: -ffp-contract=fast -ffast-math -emit-llvm -o - %s \
+// RUN: | FileCheck %s -check-prefixes=CHECK-FAST
+
+float res;
+int add(float a, float b, float c) {
+  // CHECK: fadd float
+  // CHECK: load float, float*
+  // CHECK: fadd float
+  // CHECK: store float
+  // CHECK-FAST: fadd fast float
+  // CHECK-FAST: load float, float*
+  // CHECK-FAST: fadd fast float
+  // CHECK: ret i32 0
+  // CHECK-EXT: ret i32 2
+  // CHECK-FAST: ret i32 -1
+  res = a + b + c;
+  return __FLT_EVAL_METHOD__;
+}
+
+int add_precise(float a, float b, float c) {
+#pragma float_control(precise, on)
+  // CHECK: fadd float
+  // CHECK: load float, float*
+  // CHECK: fadd float
+  // CHECK: store float
+  // CHECK: ret i32 0
+  // CHECK-FAST: ret i32 -1
+  res = a + b + c;
+  return __FLT_EVAL_METHOD__;
+}
+
+#pragma float_control(push)
+#pragma float_control(precise, on)
+int add_precise_1(float a, float b, float c) {
+  // CHECK: fadd float
+  // CHECK: load float, float*
+  // CHECK: fadd float
+  // CHECK: store float
+  // CHECK: ret i32 0
+  // CHECK-FAST: ret i32 -1
+  res = a + b + c;
+  return __FLT_EVAL_METHOD__;
+}
+#pragma float_control(pop)
+
+int add_not_precise(float a, float b, float c) {
+  // Fast-math is enabled with this pragma.
+#pragma float_control(precise, off)
+  // CHECK-FAST: fadd fast float
+  // CHECK-FAST: load float, float*
+  // CHECK-FAST: fadd fast float
+  // CHECK-FAST: ret i32 -1
+  res = a + b + c;
+  return __FLT_EVAL_METHOD__;
+}
+
+#pragma float_control(push)
+// Fast-math is enabled with this pragma.
+#pragma float_control(precise, off)
+int add_not_precise_1(float a, float b, float c) {
+  // CHECK-FAST: fadd fast float
+  // CHECK-FAST: load float, float*
+  // CHECK-FAST: fadd fast float
+  // CHECK-FAST: ret i32 -1
+  res = a + b + c;
+  return __FLT_EVAL_METHOD__;
+}
+#pragma float_control(pop)
+
+int getFPEvalMethod() {
+  // CHECK: ret i32 0
+  return __FLT_EVAL_METHOD__;
+}
Index: clang/lib/Sema/SemaAttr.cpp
===
--- clang/lib/Sema/SemaAttr.cpp
+++ clang/lib/Sema/SemaAttr.cpp
@@ -517,6 +517,9 @@
 else
   NewFPFeatures.setFPPreciseEnabled(false);
 FpPragmaStack.Act(Loc, Action, StringRef(), NewFPFeatures);
+// Fast-math is enabled.
+PP.setCurrentFPEvalMethod(
+Loc, LangOptions::FPEvalMethodKind::FEM_Indeterminable);
 break;
   case PFC_Except:
 if (!isPreciseFPEnabled())
@@ -540,6 +543,12 @@
 }
 FpPragmaStack.Act(Loc, Action, StringRef(), NewFPFeatures);
 NewFPFeatures = FpPragmaStack.CurrentValue;
+if (CurFPFeatures.getAllowFPReassociate() ||
+CurFPFeatures.getAllowReciprocal())
+  // Since we are popping the pragma, we don't want to be passing
+  // a location here.
+  PP.setCurrentFPEvalMethod(SourceLocation(),
+CurFPFeatures.getFPEvalMethod());
 break;
   }
   CurFPFeatures = NewFPFeatures.applyOverrides(getLangOpts());
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -254,6 +254,10 @@
 PP.setCurrentFPEvalMethod(SourceLocation(),
   getLangOpts().getFPEvalMethod());
   CurFPFeatures.setFPEvalMethod(PP.getCurrentFPEvalMethod());
+  // Fast-math is enabled.
+  if (getLangOpts().AllowFPReassoc || getLangOpts().AllowRecip)
+PP.setCurrentFPEvalMethod(SourceLocation(),
+  LangOptions::FEM_Indeterminable);
 }
 
 // Anchor Sema's type info to this TU.
Index: clang/lib/Lex/PPMacroExpansion.cpp
===
--- clang/lib/Lex/PPMacroExpansion.cpp
+++ clang/lib/Lex/PPMacroExpansion.cpp
@@ -1577,14 +1577,35 @@
 Tok.setKind(tok::string_literal);
   } else if (II == Ident__FLT_EVAL_METHOD__) {
 // 

[PATCH] D121328: Disable -Wmissing-prototypes for internal linkage functions that aren't explicitly marked "static"""

2022-03-09 Thread Manoj Gupta via Phabricator via cfe-commits
manojgupta added a comment.

For the background, we had hit this in Chrome OS when building bluetooth code.

This is the one of structs hitting the issue where the warning got promoted to 
an error:

typedef struct {

private:

  static std::string AppendCapability(std::string& result, bool append,
  const std::string& name) {
   
  }

} btav_a2dp_codec_config_t;

Previously this was a warning that was suppressed in this code upstream using 
-Wno-non-c-typedef-for-linkage  but now it turns into a non-suppressible error.

The exact code actually comes from aosp, but this is the Chrome OS public 
accessible copy:
https://chromium.googlesource.com/aosp/platform/packages/modules/Bluetooth/+/main/system/include/hardware/bt_av.h


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121328

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


[PATCH] D120949: [clang][AST matchers] adding attributedStmt AST matcher

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



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2733
+/// \endcode
+AST_MATCHER_P(AttributedStmt, isAttr, attr::Kind, AttrKind) {
+  return llvm::any_of(Node.getAttrs(),

This definitely seems more like `hasAttr` than `isAttr` to me. An 
AttributedStmt *is* the (sugar) statement, and *has* the attribute(s).

Maybe rather `describesAttr` so people don't confuse this for one that walks 
up, though?



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2713-2714
+/// \endcode
+extern const internal::VariadicDynCastAllOfMatcher
+attributedStmt;
+

jdoerfert wrote:
> aaron.ballman wrote:
> > Design-wise, I'm on the fence here. AST matchers match the AST nodes that 
> > Clang produces, and from that perspective, this makes a lot of sense. But 
> > `AttributedStmt` is a bit of a hack in some ways, and do we want to expose 
> > that hack to AST matcher users? e.g., is there a reason we shouldn't make 
> > `returnStmt(hasAttr(attr::Likely))` work directly rather than making the 
> > user pick their way through the `AttributedStmt`? This is more in line with 
> > how you check for a declaration with a particular attribute and seems like 
> > the more natural way to surface this.
> > 
> > For the moment, since this is following the current AST structure in Clang, 
> > I think this is fine. But I'm curious if @klimek or perhaps @sammccall has 
> > an opinion here.
> I think a way to find any kind of statement (or expression) that has a 
> specific attribute is very useful. How that should look, idk.
TL;DR: I think this matcher fits the current design best. 
`returnStmt(hasAttr())` sounds awesome, but I think it's a significant new 
concept, and a cross-cutting project like traversal modes.

---

returnStmt(hasAttr()) is definitely nicer in isolation (and in combination with 
how decls work).
It's definitely potentially confusing to not match the AST. The AST is unlikely 
to be fixed because (IIUC) we don't want to burden each stmt with tracking if 
it has attrs.
So I think the easy answer is this patch gets it right.

The inconsistency with decls is annoying, and maybe worse it doesn't yield a 
simple way to express "a return statement, maybe with an attribute, I don't 
care" unless you're searching recursively anyway, and this should almost be the 
default.
`returnStmt(hasAttr())` suggests that it would enable this, maybe by skipping 
over the AttributedStmt with some fancy traversal mode, and then looking it up 
again in the hasAttr matcher from the parent map.

I think this would be a less brittle way to handle mostly-transparent nodes 
that you nevertheless want to be able to match the contents of sometimes. The 
current options (explicitly unwrap, rely on recursive search, and traversal 
modes) all seem to have significant limitations.
However this is a pretty general idea (and I guess a pretty large project), and 
I don't think it's worth introducing just for AttributedStmt.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120949

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


[PATCH] D121269: [clang-format] Fix namespace format when the name is followed by a macro

2022-03-09 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius added inline comments.



Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:192
 "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A M(x) {\n"

curdeius wrote:
> zequanwu wrote:
> > zequanwu wrote:
> > > curdeius wrote:
> > > > MyDeveloperDay wrote:
> > > > > Can you test the A B case? We can’t have a space right?
> > > > What's the rationale behind keeping `M(x)` in one case and not the 
> > > > other?
> > > > How can you decide?
> > > In the first one, we keep `M(x)` because we don't know that is `A` or 
> > > `M(x)` the name. 
> > > In the second one, because we see a `::`, so we know that's the name and 
> > > discard `M(x)`.
> > Added a test with `A B`. 
> > In that case, we will have `// namespace A B`, since we don't know which 
> > one is the real name. Either one could be a macro that expands to an 
> > attribute.
> In a different test case, could you add A to AttributeMacros and test that we 
> skip it like other attributes?
Euh, actually, it's out of scope of this patch. Please ignore.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121269

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


[PATCH] D121269: [clang-format] Fix namespace format when the name is followed by a macro

2022-03-09 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius added inline comments.



Comment at: clang/lib/Format/NamespaceEndCommentsFixer.cpp:72
 
-Tok = FirstNSTok;
-while (Tok && !Tok->is(tok::l_brace)) {
+bool IsPrevColoncolon = false;
+bool HasColoncolon = false;

Nit: Personally, I'd put these bools further down, closer to the place where 
they are used and after AddMacro lambda.



Comment at: clang/lib/Format/NamespaceEndCommentsFixer.cpp:85
+  Tok = Tok->getNextNonComment();
+  for (int NestLevel = 1; Tok && NestLevel > 0;) {
+if (Tok->is(tok::l_paren))

This loop seems very similar to the one that skips the attributes on lines 
45-53, could you please refactor?
A lambda taking a pair of token kinds (l_paren/r_paren, l_square/r_square) 
should be fine.



Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:192
 "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A M(x) {\n"

zequanwu wrote:
> zequanwu wrote:
> > curdeius wrote:
> > > MyDeveloperDay wrote:
> > > > Can you test the A B case? We can’t have a space right?
> > > What's the rationale behind keeping `M(x)` in one case and not the other?
> > > How can you decide?
> > In the first one, we keep `M(x)` because we don't know that is `A` or 
> > `M(x)` the name. 
> > In the second one, because we see a `::`, so we know that's the name and 
> > discard `M(x)`.
> Added a test with `A B`. 
> In that case, we will have `// namespace A B`, since we don't know which one 
> is the real name. Either one could be a macro that expands to an attribute.
In a different test case, could you add A to AttributeMacros and test that we 
skip it like other attributes?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121269

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


[PATCH] D121328: Disable -Wmissing-prototypes for internal linkage functions that aren't explicitly marked "static"""

2022-03-09 Thread David Blaikie via Phabricator via cfe-commits
dblaikie created this revision.
dblaikie added reviewers: aaron.ballman, rsmith, denik, deansturtevant.
Herald added a project: All.
dblaikie requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Some functions can end up non-externally visible despite not being
declared "static" or in an unnamed namespace in C++ - such as by having
parameters that are of non-external types.

Such functions aren't mistakenly intended to be defining some function
that needs a declaration. They could be maybe more legible (except for
the operator new example) with an explicit static, but that's a
stylistic thing outside what should be addressed by a warning.

This reapplies 275c56226d7fbd6a4d554807374f78d323aa0c1c 
 - once we 
figure
out what to do about the change in behavior for -Wnon-c-typedef-for-linkage
(this reverts the revert commit 85ee1d3ca1d06b6bd3477515b8d0c72c8df7c069 
)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121328

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaCXX/warn-missing-prototypes.cpp


Index: clang/test/SemaCXX/warn-missing-prototypes.cpp
===
--- clang/test/SemaCXX/warn-missing-prototypes.cpp
+++ clang/test/SemaCXX/warn-missing-prototypes.cpp
@@ -44,3 +44,16 @@
 extern void k() {} // expected-warning {{no previous prototype for function 
'k'}}
 // expected-note@-1{{declare 'static' if the function is not intended to be 
used outside of this translation unit}}
 // CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-2]]:{{.*}}-[[@LINE-2]]:{{.*}}}:"{{.*}}"
+
+namespace {
+struct anon { };
+}
+
+// No warning because this has internal linkage despite not being declared
+// explicitly 'static', owing to the internal linkage parameter.
+void l(anon) {
+}
+
+void *operator new(decltype(sizeof(3)) size, const anon &) throw() {
+  return nullptr;
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -14210,6 +14210,9 @@
   if (!FD->isGlobal())
 return false;
 
+  if (!FD->isExternallyVisible())
+return false;
+
   // Don't warn about C++ member functions.
   if (isa(FD))
 return false;


Index: clang/test/SemaCXX/warn-missing-prototypes.cpp
===
--- clang/test/SemaCXX/warn-missing-prototypes.cpp
+++ clang/test/SemaCXX/warn-missing-prototypes.cpp
@@ -44,3 +44,16 @@
 extern void k() {} // expected-warning {{no previous prototype for function 'k'}}
 // expected-note@-1{{declare 'static' if the function is not intended to be used outside of this translation unit}}
 // CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-2]]:{{.*}}-[[@LINE-2]]:{{.*}}}:"{{.*}}"
+
+namespace {
+struct anon { };
+}
+
+// No warning because this has internal linkage despite not being declared
+// explicitly 'static', owing to the internal linkage parameter.
+void l(anon) {
+}
+
+void *operator new(decltype(sizeof(3)) size, const anon &) throw() {
+  return nullptr;
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -14210,6 +14210,9 @@
   if (!FD->isGlobal())
 return false;
 
+  if (!FD->isExternallyVisible())
+return false;
+
   // Don't warn about C++ member functions.
   if (isa(FD))
 return false;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 85ee1d3 - Revert "Disable -Wmissing-prototypes for internal linkage functions that aren't explicitly marked "static""

2022-03-09 Thread David Blaikie via cfe-commits

Author: David Blaikie
Date: 2022-03-09T21:12:56Z
New Revision: 85ee1d3ca1d06b6bd3477515b8d0c72c8df7c069

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

LOG: Revert "Disable -Wmissing-prototypes for internal linkage functions that 
aren't explicitly marked "static""

Regresses:
typedef struct {
  static void  f() {
  }
} a_t;

Causing this to error instead of warn, because the linkage is computed
earlier/too early perhaps. I'll send out a review to see if there's some
other path forward or if this is an acceptable regression, etc.

This reverts commit 275c56226d7fbd6a4d554807374f78d323aa0c1c.

Added: 


Modified: 
clang/lib/Sema/SemaDecl.cpp
clang/test/SemaCXX/warn-missing-prototypes.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index b88d9f2f847fd..fa086ae0f6126 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -14210,9 +14210,6 @@ ShouldWarnAboutMissingPrototype(const FunctionDecl *FD,
   if (!FD->isGlobal())
 return false;
 
-  if (!FD->isExternallyVisible())
-return false;
-
   // Don't warn about C++ member functions.
   if (isa(FD))
 return false;

diff  --git a/clang/test/SemaCXX/warn-missing-prototypes.cpp 
b/clang/test/SemaCXX/warn-missing-prototypes.cpp
index 2880514ee02b7..e8637e5a90eab 100644
--- a/clang/test/SemaCXX/warn-missing-prototypes.cpp
+++ b/clang/test/SemaCXX/warn-missing-prototypes.cpp
@@ -44,16 +44,3 @@ void j() = delete;
 extern void k() {} // expected-warning {{no previous prototype for function 
'k'}}
 // expected-note@-1{{declare 'static' if the function is not intended to be 
used outside of this translation unit}}
 // CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-2]]:{{.*}}-[[@LINE-2]]:{{.*}}}:"{{.*}}"
-
-namespace {
-struct anon { };
-}
-
-// No warning because this has internal linkage despite not being declared
-// explicitly 'static', owing to the internal linkage parameter.
-void l(anon) {
-}
-
-void *operator new(decltype(sizeof(3)) size, const anon &) throw() {
-  return nullptr;
-}



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


[PATCH] D121233: [pseudo] Move pseudoparser from clang to clang-tools-extra

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

In D121233#3370821 , @sammccall wrote:

> In D121233#3370177 , @aaron.ballman 
> wrote:
>
>> I agreed based on the understanding that the new code would follow the 
>> existing conventions, so perhaps the agreement was a bit premature. But, I'm 
>> honestly pretty surprised at this significant of resistance to following the 
>> same patterns used by (basically) everything else in the project.
>
> I'm not sure I buy the premise ("everything else in the project"). 
> clang-tools-extra isn't really a project: it doesn't have coherent code, 
> goals, or developers.
> Each subproject in llvm-project **except** those under clang-tools-extra has 
> a root directory containing tests etc for the subproject, and makes good use 
> of this!

Yeah, I think we're converging on this point.

>> We're talking about a directory name and where we put tests; what are the 
>> technical challenges here? All of the arguments you've presented seem to be 
>> stylistic in nature (not that those kinds of issues aren't important to 
>> consider), so I feel like I must be missing something.
>
> Right, directory name is a stylistic concern either way AFAICT (redundancy 
> and consistency).

Agreed.

> Location of tests is more complicated, and more important. Experience from 
> clangd:
>
> - A root directory for build system config is important. IIRC the straw that 
> broke the camel's back for rearranging clangd was having a root CMakeLists 
> file to turn it off in one obvious place.
> - The most common development tools (editors, shells, grep, ...) are much 
> harder to use if your working set is several directories rather than one.
> - Linking strangers to the code 
>  
> leaves the tests essentially invisible.
> - It clearly defines the boundaries of the project. Before the move, I don't 
> think most contributors could have answered the question "which directories 
> are part of clangd" with confidence. (I couldn't!)
> - On multiple occasions contributors failed to find one of (unit|lit) tests, 
> because once you're looking in nonobvious places you stop when you find 
> anything. So they put tests in the wrong place.
> - The clang-tools-extra layout doesn't provide test targets for subprojects, 
> which is a dealbreaker; it seems people resort to guessing at llvm-lit 
> invocations instead. We were maintaining `check-clangd` in 
> clang-tools-extra/test/CMakeLists.txt as a special snowflake, which is 
> presumably also objectionable (it's 35 lines of CMake).

Thank you for the details here, this helps me understand the concerns a lot 
better.

>>> If consistency is to be the sine qua non, then I think we should probably 
>>> leave the code where it is until someone's willing to do the work you 
>>> described. clang/Tooling/Syntax is the most consistent location for the 
>>> code, and the one proposed in the original RFC last year.
>>
>> If you don't feel like updating the projects to do a consistent rename, 
>> that's totally fine; I didn't intend to imply that was expected of you or 
>> required for this to proceed.
>
> When you say it's fine, do you mean that it's acceptable to land this patch, 
> or to abandon it, or to land your preferred version that I'm not OK with? :-)

Sorry for the confusion, I mostly meant the last point, but without any 
additional work on your end after the patch lands.

> I think we are now is:
>
> - there was an RFC
> - several months later, code started landing, and there was new discussion 
> (on the RFC thread) including a proposal to move
> - we agreed that a move is OK with us, but are stuck on the details
>
> So if it makes a difference, it seems you're _requesting_ a change here, not 
> approving one.

A bit of both, really. I requested the move, you're doing the move, I didn't 
approve yet because the move did things I wasn't expecting.

>> The directory layout and naming structure has worked well enough thus far
>
> If people finding build/test setup weird and alienating, I think they're more 
> likely to not contribute than to offer clear feedback. I'm not sure how we 
> can tell it works well.
> Anecdotally, I do know that I was put off from contributing to clang-tidy by 
> how hard it was to maintain and debug tests, I've lost significant time when 
> I've needed to do this, and I've seen others struggle with it too.
> But while this has come up many times in conversation, I've never seen it 
> written down. Does open-source have a taboo about whining about stuff being 
> hard? :-)

My measurement for how well it works is how long it's existed without anyone 
proposing to change it, but that's not really "measuring" so much as "guessing".

>> I think part of the issue here is that clang-tools-extra is a dumping ground 
>> for projects, so it isn't itself a 

[PATCH] D118511: Add a warning for not packing non-POD members in packed structs

2022-03-09 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D118511#3369114 , @tbaeder wrote:

> Hey @dblaikie, seems like this has never been pushed?

Yeah, was holding off on this because it looked like maybe there was still 
outstanding work on the nuance/precise nature of the ABI change - turned out to 
be a known/outstanding issue: https://reviews.llvm.org/D119051 though it does 
have some impact on the warning and the layout change: If we get that POD ABI 
fix in, then the layout change/warning will fire on fewer places. So it seems 
sort of unfortunate to add the warning & end up having folks cleaning up things 
that don't need cleaning up once the POD ABI change happens.

But equally, bad to ship the layout change without teh associated warning.

Thoughts? Revert the layout change for now/in the release until the broader POD 
ABI issue is addressed? Then apply the layout change+warning?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118511

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


[PATCH] D121233: [pseudo] Move pseudoparser from clang to clang-tools-extra

2022-03-09 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

In D121233#3370177 , @aaron.ballman 
wrote:

> I agreed based on the understanding that the new code would follow the 
> existing conventions, so perhaps the agreement was a bit premature. But, I'm 
> honestly pretty surprised at this significant of resistance to following the 
> same patterns used by (basically) everything else in the project.

I'm not sure I buy the premise ("everything else in the project"). 
clang-tools-extra isn't really a project: it doesn't have coherent code, goals, 
or developers.
Each subproject in llvm-project **except** those under clang-tools-extra has a 
root directory containing tests etc for the subproject, and makes good use of 
this!

> We're talking about a directory name and where we put tests; what are the 
> technical challenges here? All of the arguments you've presented seem to be 
> stylistic in nature (not that those kinds of issues aren't important to 
> consider), so I feel like I must be missing something.

Right, directory name is a stylistic concern either way AFAICT (redundancy and 
consistency).

Location of tests is more complicated, and more important. Experience from 
clangd:

- A root directory for build system config is important. IIRC the straw that 
broke the camel's back for rearranging clangd was having a root CMakeLists file 
to turn it off in one obvious place.
- The most common development tools (editors, shells, grep, ...) are much 
harder to use if your working set is several directories rather than one.
- Linking strangers to the code 
 
leaves the tests essentially invisible.
- It clearly defines the boundaries of the project. Before the move, I don't 
think most contributors could have answered the question "which directories are 
part of clangd" with confidence. (I couldn't!)
- On multiple occasions contributors failed to find one of (unit|lit) tests, 
because once you're looking in nonobvious places you stop when you find 
anything. So they put tests in the wrong place.
- The clang-tools-extra layout doesn't provide test targets for subprojects, 
which is a dealbreaker; it seems people resort to guessing at llvm-lit 
invocations instead. We were maintaining `check-clangd` in 
clang-tools-extra/test/CMakeLists.txt as a special snowflake, which is 
presumably also objectionable (it's 35 lines of CMake).

>> If consistency is to be the sine qua non, then I think we should probably 
>> leave the code where it is until someone's willing to do the work you 
>> described. clang/Tooling/Syntax is the most consistent location for the 
>> code, and the one proposed in the original RFC last year.
>
> If you don't feel like updating the projects to do a consistent rename, 
> that's totally fine; I didn't intend to imply that was expected of you or 
> required for this to proceed.

When you say it's fine, do you mean that it's acceptable to land this patch, or 
to abandon it, or to land your preferred version that I'm not OK with? :-)

I think we are now is:

- there was an RFC
- several months later, code started landing, and there was new discussion (on 
the RFC thread) including a proposal to move
- we agreed that a move is OK with us, but are stuck on the details

So if it makes a difference, it seems you're _requesting_ a change here, not 
approving one.

> The directory layout and naming structure has worked well enough thus far

If people finding build/test setup weird and alienating, I think they're more 
likely to not contribute than to offer clear feedback. I'm not sure how we can 
tell it works well.
Anecdotally, I do know that I was put off from contributing to clang-tidy by 
how hard it was to maintain and debug tests, I've lost significant time when 
I've needed to do this, and I've seen others struggle with it too.
But while this has come up many times in conversation, I've never seen it 
written down. Does open-source have a taboo about whining about stuff being 
hard? :-)

> I think part of the issue here is that clang-tools-extra is a dumping ground 
> for projects, so it isn't itself a "project" (in the same sense of LLVM, 
> Clang, lldb, etc).

I do agree with this perspective, clang-tools-extra is "just a directory".
This is why it didn't seems like we were doing something wild with clangd: we 
were just treating it like a "real" subproject under the llvm-project umbrella.
(I'd be happy with moving clangd or clang-pseudo directly under llvm-project if 
that addresses the concerns, as long as I don't have to chase impossible 
consensus-via-RFC).

> I was originally concerned about the pseudo parser existing in the tree at 
> all because of maintenance burdens, but those concerns were mitigated by 
> moving the project here to clang-tools-extra. I don't think the directory 
> name being `pseudo` instead of `clang-pseudo` will add significant 
> maintenance burden; it'll just be the only 

[PATCH] D120132: [HIP] Fix HIP include path

2022-03-09 Thread Artem Belevich via Phabricator via cfe-commits
tra accepted this revision.
tra added a comment.
This revision is now accepted and ready to land.

I still don't quite understand your reluctance to use 
`AddClangSystemIncludeArgs` for adding HIP path, but if this change works for 
HIP, I'm fine with it.

Also, thank you for fixing the issue with inconsistent sub-compilation options 
for mixed-language compilations.


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

https://reviews.llvm.org/D120132

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


[PATCH] D121269: [clang-format] Fix namespace format when the name is followed by a macro

2022-03-09 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu added inline comments.



Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:192
 "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A M(x) {\n"

zequanwu wrote:
> curdeius wrote:
> > MyDeveloperDay wrote:
> > > Can you test the A B case? We can’t have a space right?
> > What's the rationale behind keeping `M(x)` in one case and not the other?
> > How can you decide?
> In the first one, we keep `M(x)` because we don't know that is `A` or `M(x)` 
> the name. 
> In the second one, because we see a `::`, so we know that's the name and 
> discard `M(x)`.
Added a test with `A B`. 
In that case, we will have `// namespace A B`, since we don't know which one is 
the real name. Either one could be a macro that expands to an attribute.



Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:192-211
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A M(x)",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A M(x) {\n"

curdeius wrote:
> MyDeveloperDay wrote:
> > Can you test the A B case? We can’t have a space right?
> What's the rationale behind keeping `M(x)` in one case and not the other?
> How can you decide?
In the first one, we keep `M(x)` because we don't know that is `A` or `M(x)` 
the name. 
In the second one, because we see a `::`, so we know that's the name and 
discard `M(x)`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121269

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


[PATCH] D121269: [clang-format] Fix namespace format when the name is followed by a macro

2022-03-09 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu updated this revision to Diff 414149.
zequanwu marked an inline comment as done.
zequanwu added a comment.

Add a test for `namespace A B {`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121269

Files:
  clang/lib/Format/NamespaceEndCommentsFixer.cpp
  clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp

Index: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
===
--- clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
+++ clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
@@ -189,6 +189,38 @@
 "int i;\n"
 "int j;\n"
 "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A M(x)",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ(
+  "#define B __attribute__((availability(macos, introduced=10.15)))\n"
+  "namespace A B {\n"
+  "int i;\n"
+  "int j;\n"
+  "}// namespace A B",
+  fixNamespaceEndComments(
+  "#define B __attribute__((availability(macos, introduced=10.15)))\n"
+  "namespace A B {\n"
+  "int i;\n"
+  "int j;\n"
+  "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A::B M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::B",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A::B M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
   EXPECT_EQ("inline namespace A {\n"
 "int i;\n"
 "int j;\n"
Index: clang/lib/Format/NamespaceEndCommentsFixer.cpp
===
--- clang/lib/Format/NamespaceEndCommentsFixer.cpp
+++ clang/lib/Format/NamespaceEndCommentsFixer.cpp
@@ -55,30 +55,72 @@
 Tok = Tok->getNextNonComment();
 }
 
-// Use the string after `namespace` as a name candidate until `{` or `::` or
-// `(`. If the name is empty, use the candicate.
 std::string FirstNSName;
 // For `namespace [[foo]] A::B::inline C {` or
 // `namespace MACRO1 MACRO2 A::B::inline C {`, returns "A::B::inline C".
 // Peek for the first '::' (or '{' or '(')) and then return all tokens from
 // one token before that up until the '{'. A '(' might be a macro with
 // arguments.
-const FormatToken *FirstNSTok = Tok;
+const FormatToken *FirstNSTok = nullptr;
 while (Tok && !Tok->isOneOf(tok::l_brace, tok::coloncolon, tok::l_paren)) {
-  FirstNSName += FirstNSTok->TokenText;
+  if (FirstNSTok)
+FirstNSName += FirstNSTok->TokenText;
   FirstNSTok = Tok;
   Tok = Tok->getNextNonComment();
 }
 
-Tok = FirstNSTok;
-while (Tok && !Tok->is(tok::l_brace)) {
+bool IsPrevColoncolon = false;
+bool HasColoncolon = false;
+bool IsPrevInline = false;
+bool NameFinished = false;
+if (FirstNSTok)
+  Tok = FirstNSTok;
+FirstNSTok = nullptr;
+// Add everything from '(' to ')'.
+auto AddMacro = [](const FormatToken *Tok) {
+  if (!Tok->is(tok::l_paren))
+return Tok;
   name += Tok->TokenText;
-  if (Tok->is(tok::kw_inline))
-name += " ";
+  Tok = Tok->getNextNonComment();
+  for (int NestLevel = 1; Tok && NestLevel > 0;) {
+if (Tok->is(tok::l_paren))
+  ++NestLevel;
+else if (Tok->is(tok::r_paren))
+  --NestLevel;
+name += Tok->TokenText;
+Tok = Tok->getNextNonComment();
+  }
+  return Tok;
+};
+// If we found '::' in name, then it's the name. Otherwise, we can't tell
+// which one is name. For example, `namespace A B {`.
+while (Tok && !Tok->is(tok::l_brace)) {
+  if (FirstNSTok) {
+if (!IsPrevInline && HasColoncolon && !IsPrevColoncolon) {
+  if (FirstNSTok->is(tok::l_paren)) {
+FirstNSTok = Tok = AddMacro(FirstNSTok);
+continue;
+  }
+  if (!FirstNSTok->is(tok::coloncolon)) {
+NameFinished = true;
+break;
+  }
+}
+name += FirstNSTok->TokenText;
+IsPrevColoncolon = FirstNSTok->is(tok::coloncolon);
+HasColoncolon |= IsPrevColoncolon;
+if (FirstNSTok->is(tok::kw_inline)) {
+  name += " ";
+  IsPrevInline = true;
+}
+  }
+  FirstNSTok = Tok;
   Tok = Tok->getNextNonComment();
 }
-if (name.empty())
-  name = FirstNSName;
+if (!NameFinished && 

[PATCH] D120573: [OpenMP] Support runtime user conditions in metadirective

2022-03-09 Thread Giorgis Georgakoudis via Phabricator via cfe-commits
ggeorgakoudis updated this revision to Diff 414139.
ggeorgakoudis added a comment.
Herald added subscribers: kbarton, nemanjai.

Fix tentative parsing reverting
Fix device codegen for metadirectives


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120573

Files:
  clang/include/clang/AST/OpenMPClause.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/StmtOpenMP.h
  clang/include/clang/Lex/Preprocessor.h
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/OpenMPClause.cpp
  clang/lib/AST/StmtOpenMP.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/Lex/PPCaching.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/tools/libclang/CIndex.cpp
  llvm/include/llvm/Frontend/OpenMP/OMP.td

Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -368,7 +368,9 @@
 def OMPC_Align : Clause<"align"> {
   let clangClass = "OMPAlignClause";
 }
-def OMPC_When: Clause<"when"> {}
+def OMPC_When: Clause<"when"> {
+  let clangClass = "OMPWhenClause";
+}
 
 def OMPC_Bind : Clause<"bind"> {
   let clangClass = "OMPBindClause";
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -2591,6 +2591,10 @@
 }
 void OMPClauseEnqueue::VisitOMPBindClause(const OMPBindClause *C) {}
 
+void OMPClauseEnqueue::VisitOMPWhenClause(const OMPWhenClause *C) {
+  Visitor->AddStmt(C->getDirective());
+}
+
 } // namespace
 
 void EnqueueVisitor::EnqueueChildren(const OMPClause *S) {
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -6864,6 +6864,12 @@
   Record.AddSourceLocation(C->getBindKindLoc());
 }
 
+void OMPClauseWriter::VisitOMPWhenClause(OMPWhenClause *C) {
+  // TODO: check, not familiar with this.
+  Record.writeOMPTraitInfo(>getTraitInfo());
+  Record.AddStmt(C->getDirective());
+}
+
 void ASTRecordWriter::writeOMPTraitInfo(const OMPTraitInfo *TI) {
   writeUInt32(TI->Sets.size());
   for (const auto  : TI->Sets) {
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -12994,6 +12994,12 @@
   C->setBindKindLoc(Record.readSourceLocation());
 }
 
+void OMPClauseReader::VisitOMPWhenClause(OMPWhenClause *C) {
+  // TODO: check, not familiar with this.
+  C->setTraitInfo(Record.readOMPTraitInfo());
+  C->setDirective(Record.readStmt());
+}
+
 void OMPClauseReader::VisitOMPAlignClause(OMPAlignClause *C) {
   C->setAlignment(Record.readExpr());
   C->setLParenLoc(Record.readSourceLocation());
Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -2284,6 +2284,18 @@
 return getSema().ActOnOpenMPAlignClause(A, StartLoc, LParenLoc, EndLoc);
   }
 
+  /// Build a new OpenMP 'when' clause.
+  ///
+  /// By default, performs semantic analysis to build the new OpenMP clause.
+  /// Subclasses may override this routine to provide different behavior.
+  OMPClause *RebuildOMPWhenClause(OMPTraitInfo , Stmt *Directive,
+  SourceLocation StartLoc,
+  SourceLocation LParenLoc,
+  SourceLocation EndLoc) {
+return getSema().ActOnOpenMPWhenClause(TI, Directive, StartLoc, LParenLoc,
+   EndLoc);
+  }
+
   /// Rebuild the operand to an Objective-C \@synchronized statement.
   ///
   /// By default, performs semantic analysis to build the new statement.
@@ -10323,6 +10335,13 @@
   C->getLParenLoc(), C->getEndLoc());
 }
 
+template 
+OMPClause *TreeTransform::TransformOMPWhenClause(OMPWhenClause *C) {
+  return getDerived().RebuildOMPWhenClause(C->getTraitInfo(), C->getDirective(),
+   C->getBeginLoc(), C->getLParenLoc(),
+   C->getEndLoc());
+}
+
 //===--===//
 // Expression transformation
 //===--===//
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ 

[PATCH] D121294: [AArch64][SVE][Clang] Fix crash for incorrect svptrue and svcnt parameters

2022-03-09 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen accepted this revision.
sdesmalen added a comment.
This revision is now accepted and ready to land.

In D121294#3370132 , @MattDevereau 
wrote:

> In D121294#3370085 , @sdesmalen 
> wrote:
>
>> This is missing tests for svundef, svrdffr, svsetffr and svpfalse?
>
> @sdesmalen Only svcnt and svptrue cause the crash. This might be because of 
> extra values added by the `[IsAppendSVALL]` TypeFlag in `arm_sve.td`. We 
> decided to change other intrinsics with 0 parameters as there seems to be no 
> drawbacks to doing so and it might catch further future errors.

Fair enough. Since you're adding the `void` to the prototype for a reason (the 
diagnostic behaviour now changes), I figured you may as well want to test it.




Comment at: 
clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_svptrue.c:2
+// REQUIRES: aarch64-registered-target
+
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-fallow-half-arguments-and-returns -fsyntax-only -verify %s

MattDevereau wrote:
> sdesmalen wrote:
> > Is it possible to use the `update_cc_test_checks.py` script for these tests?
> Deleting `// expected-error-re@+1...` and running `update_cc_test_checks.py` 
> did not generate anything in its place in either of the tests
Okay I wasn't sure, so thanks for confirming.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121294

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


[PATCH] D119479: [clang][extract-api] Add global record support

2022-03-09 Thread Juergen Ributzka via Phabricator via cfe-commits
ributzka added inline comments.



Comment at: clang/include/clang/SymbolGraph/AvailabilityInfo.h:31
+  bool Unavailable{false};
+  bool UnconditionallyDeprecated{false};
+

We also need unconditionally unavailable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119479

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


[PATCH] D118352: [clang][ABI] New c++20 modules mangling scheme

2022-03-09 Thread Steven Wu via Phabricator via cfe-commits
steven_wu added a comment.

In D118352#3368922 , @ChuanqiXu wrote:

> In D118352#3368919 , @phosek wrote:
>
>> We're also seeing this issue on our Mac bots, is it possible to revert it?
>
> I've reverted it. Since this is the new feature, I think it wouldn't so hurry 
> to land it. BTW, I think it would be helpful to provide more information to 
> fix it.

It breaks the macOS bot for LLVM, you can click the test case for its output: 
https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/27745/testReport/

You can see the error output. The problem might be that `dso_local` does not 
get codegen for macho targets.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118352

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


[PATCH] D121303: [clang][deps] Don't prune search paths used by dependencies

2022-03-09 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 created this revision.
jansvoboda11 added reviewers: Bigcheese, dexonsmith.
Herald added a project: All.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

When pruning header search paths (to reduce the number of modules we need to 
build explicitly), we can't prune the search paths used in (transitive) 
dependencies of a module. Otherwise, we could end up with either of the 
following dependency graphs:

  X: -> Y:
  X: -> Y:

depending on the search paths of the translation unit we discovered `X` and `Y` 
from.

This patch fixes that.

Depends on D121295 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121303

Files:
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
  clang/test/ClangScanDeps/header-search-pruning-transitive.c

Index: clang/test/ClangScanDeps/header-search-pruning-transitive.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/header-search-pruning-transitive.c
@@ -0,0 +1,169 @@
+// This test checks that pruning of header search paths produces consistent dependency graphs.
+//
+// When pruning header search paths for a module, we can't remove any paths its dependencies use.
+// Otherwise, we could get either of the following dependency graphs depending on the search path
+// configuration of the particular TU that first discovered the module:
+//   X: -> Y:
+//   X: -> Y:
+// We can't have the same version of module X depend on multiple different versions of Y based on
+// the TU configuration.
+//
+// Keeping all header search paths (transitive) dependencies use will ensure we get consistent
+// dependency graphs:
+//   X: -> Y:
+//   X: -> Y:
+
+// RUN: rm -rf %t && mkdir %t
+// RUN: split-file %s %t
+
+//--- a/a.h
+//--- b/b.h
+//--- begin/begin.h
+//--- end/end.h
+//--- Y.h
+#include "begin.h"
+#if __has_include("a.h")
+#include "a.h"
+#endif
+#include "end.h"
+
+//--- X.h
+#include "Y.h"
+
+//--- module.modulemap
+module Y { header "Y.h" }
+module X { header "X.h" }
+
+//--- test.c
+#include "X.h"
+
+//--- cdb_with_a.json.template
+[{
+  "file": "DIR/test.c",
+  "directory": "DIR",
+  "command": "clang -c test.c -o DIR/test.o -fmodules -fimplicit-modules -fmodules-cache-path=DIR/module-cache -fimplicit-module-maps -Ibegin -Ia -Ib -Iend"
+}]
+
+//--- cdb_without_a.json.template
+[{
+  "file": "DIR/test.c",
+  "directory": "DIR",
+  "command": "clang -c test.c -o DIR/test.o -fmodules -fimplicit-modules -fmodules-cache-path=DIR/module-cache -fimplicit-module-maps -Ibegin -Ib -Iend"
+}]
+
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb_with_a.json.template> %t/cdb_with_a.json
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb_without_a.json.template > %t/cdb_without_a.json
+
+// RUN: echo -%t > %t/results.json
+// RUN: clang-scan-deps -compilation-database %t/cdb_with_a.json-format experimental-full -optimize-args >> %t/results.json
+// RUN: clang-scan-deps -compilation-database %t/cdb_without_a.json -format experimental-full -optimize-args >> %t/results.json
+// RUN: cat %t/results.json | sed 's/\\/\//g' | FileCheck %s
+
+// CHECK:  -[[PREFIX:.*]]
+// CHECK-NEXT: {
+// CHECK-NEXT:   "modules": [
+// CHECK-NEXT: {
+// CHECK-NEXT:   "clang-module-deps": [
+// CHECK-NEXT: {
+// CHECK-NEXT:   "context-hash": "[[HASH_Y_WITH_A:.*]]",
+// CHECK-NEXT:   "module-name": "Y"
+// CHECK-NEXT: }
+// CHECK-NEXT:   ],
+// CHECK-NEXT:   "clang-modulemap-file": "[[PREFIX]]/module.modulemap",
+// CHECK-NEXT:   "command-line": [
+// CHECK:],
+// CHECK-NEXT:   "context-hash": "[[HASH_X:.*]]",
+// CHECK-NEXT:   "file-deps": [
+// CHECK-NEXT: "[[PREFIX]]/./X.h",
+// CHECK-NEXT: "[[PREFIX]]/./module.modulemap"
+// CHECK-NEXT:   ],
+// CHECK-NEXT:   "name": "X"
+// CHECK-NEXT: },
+// CHECK-NEXT: {
+// CHECK-NEXT:   "clang-module-deps": [],
+// CHECK-NEXT:   "clang-modulemap-file": "[[PREFIX]]/module.modulemap",
+// CHECK-NEXT:   "command-line": [
+// CHECK:],
+// CHECK-NEXT:   "context-hash": "[[HASH_Y_WITH_A]]",
+// CHECK-NEXT:   "file-deps": [
+// CHECK-NEXT: "[[PREFIX]]/./Y.h",
+// CHECK-NEXT: "[[PREFIX]]/./a/a.h",
+// CHECK-NEXT: "[[PREFIX]]/./begin/begin.h",
+// CHECK-NEXT: "[[PREFIX]]/./end/end.h",
+// CHECK-NEXT: "[[PREFIX]]/./module.modulemap"
+// CHECK-NEXT:   ],
+// CHECK-NEXT:   "name": "Y"
+// CHECK-NEXT: }
+// CHECK-NEXT:   ],
+// CHECK-NEXT:   "translation-units": [
+// CHECK-NEXT: {
+// CHECK-NEXT:   "clang-context-hash": "{{.*}}",
+// CHECK-NEXT:   "clang-module-deps": [
+// CHECK-NEXT: {
+// CHECK-NEXT:   "context-hash": "[[HASH_X]]",
+// CHECK-NEXT:   "module-name": "X"
+// CHECK-NEXT: }
+// CHECK-NEXT:   ],
+// CHECK-NEXT:   "command-line": [
+// CHECK:   

[PATCH] D121302: [HIP] Fix -fno-gpu-sanitize

2022-03-09 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl created this revision.
yaxunl added a reviewer: tra.
Herald added a project: All.
yaxunl requested review of this revision.

Fix a typo about -fno-gpu-sanitize handling and disable warnings when
-fno-gpu-sanitize is specified.


https://reviews.llvm.org/D121302

Files:
  clang/lib/Driver/ToolChains/HIPAMD.cpp
  clang/test/Driver/hip-sanitize-options.hip


Index: clang/test/Driver/hip-sanitize-options.hip
===
--- clang/test/Driver/hip-sanitize-options.hip
+++ clang/test/Driver/hip-sanitize-options.hip
@@ -35,6 +35,20 @@
 // RUN:   -fsanitize=leak -nogpuinc --rocm-path=%S/Inputs/rocm \
 // RUN:   %s 2>&1 | FileCheck -check-prefixes=XNACKNEG %s
 
+// Check -fno-gpu-sanitize with supported and unsupported GPU.
+// Sanitizer should be disabled for all GPU's and there should be no warnings 
about unsupported
+// GPU.
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu 
--offload-arch=gfx900:xnack- \
+// RUN:   --offload-arch=gfx900:xnack+ --offload-arch=gfx906 
-fsanitize=address -fno-gpu-sanitize \
+// RUN:   -fsanitize=leak -nogpuinc --rocm-path=%S/Inputs/rocm \
+// RUN:   %s 2>&1 | FileCheck -check-prefixes=NOGPU %s
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu 
--offload-arch=gfx900:xnack- \
+// RUN:   --offload-arch=gfx900:xnack+ --offload-arch=gfx906 
-fsanitize=address -fno-gpu-sanitize \
+// RUN:   -fsanitize=leak -nogpuinc --rocm-path=%S/Inputs/rocm \
+// RUN:   %s 2>&1 | FileCheck -check-prefixes=NOGPUNEG %s
+
 // CHECK-NOT: {{"[^"]*clang[^"]*".* "-fcuda-is-device".* "-fsanitize=address"}}
 // CHECK-NOT: {{"[^"]*clang[^"]*".* "-fcuda-is-device".* "-mlink-bitcode-file" 
".*asanrtl.bc"}}
 // CHECK-NOT: {{"[^"]*lld(\.exe){0,1}".* ".*hip.bc"}}
@@ -65,3 +79,22 @@
 // XNACKNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx900".* "-target-feature" "-xnack"}}
 // XNACKNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx906"}}
 // XNACKNEG-NOT: {{"[^"]*lld(\.exe){0,1}".* ".*hip.bc"}}
+
+// NOGPU-DAG: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* "-target-feature" 
"\+xnack"}}
+// NOGPU-DAG: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* "-target-feature" 
"-xnack"}}
+// NOGPU-DAG: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx906"}}
+// NOGPU-DAG: {{"[^"]*clang[^"]*".* "-triple" "x86_64-unknown-linux-gnu".* 
"-fsanitize=address,leak"}}
+// NOGPUNEG-NOT: warning: ignoring '-fsanitize=leak' option as it is not 
currently supported for target 'amdgcn-amd-amdhsa'
+// NOGPUNEG-NOT: warning: ignoring '-fsanitize=address' option as it is not 
currently supported for offload arch 'gfx900:xnack-'. Use it with an offload 
arch containing 'xnack+' instead
+// NOGPUNEG-NOT: warning: ignoring '-fsanitize=address' option as it is not 
currently supported for offload arch 'gfx906'. Use it with an offload arch 
containing 'xnack+' instead
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx900".* "-target-feature" "\+xnack".* "-fsanitize=address"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* 
"-target-feature" "\+xnack".* "-fsanitize=address,leak"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* 
"-target-feature" "-xnack".* "-fsanitize=address,leak"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx906".* 
"-fsanitize=address,leak"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* 
"-target-feature" "\+xnack".* "-fsanitize=address"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* 
"-target-feature" "-xnack".* "-fsanitize=address"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx906".* 
"-fsanitize=address"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx900".* "-target-feature" "\+xnack"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx900".* "-target-feature" "-xnack"}}
+// NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx906"}}
+// NOGPUNEG-NOT: {{"[^"]*lld(\.exe){0,1}".* ".*hip.bc"}}
Index: clang/lib/Driver/ToolChains/HIPAMD.cpp
===
--- clang/lib/Driver/ToolChains/HIPAMD.cpp
+++ clang/lib/Driver/ToolChains/HIPAMD.cpp
@@ -47,7 +47,7 @@
 return false;
 
   if (!DriverArgs.hasFlag(options::OPT_fgpu_sanitize,
-  -options::OPT_fno_gpu_sanitize))
+  options::OPT_fno_gpu_sanitize))
 return true;
 
   auto  = TC.getDriver().getDiags();
@@ -162,6 +162,8 @@
   getProgramPaths().push_back(getDriver().Dir);
 
   // Diagnose unsupported sanitizer options only once.
+  if (!Args.hasFlag(options::OPT_fgpu_sanitize, options::OPT_fno_gpu_sanitize))
+return;
   for (auto A : Args.filtered(options::OPT_fsanitize_EQ)) {
 SanitizerMask K = parseSanitizerValue(A->getValue(), 

[PATCH] D121233: [pseudo] Move pseudoparser from clang to clang-tools-extra

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

In D121233#3370110 , @sammccall wrote:

> I understand where you're coming from. But I think agreeing to move the code 
> was premature if it means either:
>
> - following all the precedents in clang-tools-extra, or
> - taking on the political burden of getting these changed for all projects.

I agreed based on the understanding that the new code would follow the existing 
conventions, so perhaps the agreement was a bit premature. But, I'm honestly 
pretty surprised at this significant of resistance to following the same 
patterns used by (basically) everything else in the project. We're talking 
about a directory name and where we put tests; what are the technical 
challenges here? All of the arguments you've presented seem to be stylistic in 
nature (not that those kinds of issues aren't important to consider), so I feel 
like I must be missing something.

> Based on previous interactions, I think we differ on the relative value we 
> place on consistency vs local quality vs burden on development, and our 
> ability to make consensus-based changes on a timeline that feels acceptable.
> (This isn't a criticism, I admire your patience and dedication to 
> consistency, I just don't share it).
> If consistency is to be the sine qua non, then I think we should probably 
> leave the code where it is until someone's willing to do the work you 
> described. clang/Tooling/Syntax is the most consistent location for the code, 
> and the one proposed in the original RFC last year.

If you don't feel like updating the projects to do a consistent rename, that's 
totally fine; I didn't intend to imply that was expected of you or required for 
this to proceed.

>> The status quo is that we try to be consistent unless there's a compelling 
>> reason not to, so I disagree; the onus is on you as to why this is a special 
>> snowflake that deserves to be inconsistent with everything else in the 
>> project.
>
> If I understand, you're saying that LLVM in general, or clang-tools-extra in 
> particular values consistency over quality.

You've not convinced me there's a quality issue here, just a difference in 
stylistic preference. The directory layout and naming structure has worked well 
enough thus far (excepting perhaps the test directory for clangd, but I'll be 
frank: I don't get why that change was needed and it's made my life worse since 
it was made, so I regret not paying closer attention to that review).

If there's a quality concern here that I'm not yet seeing, I'd like to know 
more about it. I definitely don't want to prefer consistency over quality.

> Is this a documented policy (where?), consensus (among who?), or historical 
> practice (which would beg the question somewhat).
> This is a genuine question - I suspect that you're right, but it's hard to 
> know how to challenge this if it's unclear where it comes from.

Not clearly documented anywhere (but sort of is documented; it's how we handle 
everything else in the coding style guidelines; stick with the conventions used 
locally as best you can). I would call it a mixture of historical practice and 
general common practice in the industry. Consistency in interfaces is generally 
easier on newcomers to a project because it reduces the amount of mental burden 
to understand the project's architecture. I think part of the issue here is 
that clang-tools-extra is a dumping ground for projects, so it isn't itself a 
"project" (in the same sense of LLVM, Clang, lldb, etc). I think that adds some 
natural tension here because the needs for a random group of projects is hard 
to get consistency out of as we add more and more projects. It's probably good 
that we're having this discussion, but I'd prefer if the finer points on policy 
didn't hold up your patch either.

I was originally concerned about the pseudo parser existing in the tree at all 
because of maintenance burdens, but those concerns were mitigated by moving the 
project here to clang-tools-extra. I don't think the directory name being 
`pseudo` instead of `clang-pseudo` will add significant maintenance burden; 
it'll just be the only project we can't figure out the executable name of from 
the base directory name (across the entire monorepo, perhaps? I can't find 
other examples with a quick look). That's.. silly, but not the end of the world 
or worth holding this patch up over if you insist on not having the `clang-` 
prefix that the executable has. But the test directory being in a novel 
location really does add maintenance burden in the form of making it trivially 
easy to think you've run tests when you haven't actually done so. This is has 
already caused me pain with clangd and I don't want to see that being used as 
precedent to make things worse here.

Can you help me understand the quality concerns you mentioned?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  

[PATCH] D121294: [AArch64][SVE][Clang] Fix crash for incorrect svptrue and svcnt parameters

2022-03-09 Thread Matt Devereau via Phabricator via cfe-commits
MattDevereau added a comment.

In D121294#3370085 , @sdesmalen wrote:

> This is missing tests for svundef, svrdffr, svsetffr and svpfalse?

@sdesmalen Only svcnt and svptrue cause the crash. This might be because of 
extra values added by the `[IsAppendSVALL]` TypeFlag in `arm_sve.td`




Comment at: 
clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_svptrue.c:2
+// REQUIRES: aarch64-registered-target
+
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-fallow-half-arguments-and-returns -fsyntax-only -verify %s

sdesmalen wrote:
> Is it possible to use the `update_cc_test_checks.py` script for these tests?
Deleting `// expected-error-re@+1...` and running `update_cc_test_checks.py` 
did not generate anything in its place in either of the tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121294

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


[PATCH] D107141: [Inline-asm] Add diagnosts for unsupported inline assembly arguments

2022-03-09 Thread Jennifer Yu via Phabricator via cfe-commits
jyu2 added inline comments.



Comment at: clang/lib/Sema/SemaStmtAsm.cpp:679
+  !llvm::isPowerOf2_32(OutSize))
+targetDiag(OutputExpr->getExprLoc(), diag::err_store_value_to_reg);
+

Error message is not very clear to me.  I think we should create more specified 
error message there.  Like power of two, or size <  8 or > pointer size?

Using error message selector.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107141

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


[PATCH] D120296: [Attr] Fix a btf_type_tag AST generation bug

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

Thanks for this! One thing I noticed is that we seem to be lacking a lot of 
Sema tests for the changes now that this is a type attribute. Of particular 
interest to me would be cases using `_Generic` and 
`__attribute__((overloadable))` to demonstrate what kind of type system effects 
there are. Same for redeclaration behavior or other type system situations.




Comment at: clang/include/clang/AST/ASTContext.h:1596
 
+  QualType getBTFTagAttributedType(BTFTypeTagAttr *Attr, QualType Wrapped);
+





Comment at: clang/include/clang/AST/Type.h:4797
+
+  BTFTagAttributedType(QualType canon, QualType wrapped,
+   BTFTypeTagAttr *attr)

You should fix the formatting issue, but also, the parameter names don't match 
the usual naming conventions (please don't replace `attr` with `Attr` though; 
that's a type name, so go with something else like `BTFAttr`).



Comment at: clang/include/clang/AST/Type.h:4804
+  QualType getWrappedType() const { return WrappedType; }
+  BTFTypeTagAttr *getAttr() const { return Attr; }
+

Should this be returning a `const BTFTypeTagAttr *` instead?



Comment at: clang/include/clang/AST/Type.h:4809
+
+  void Profile(llvm::FoldingSetNodeID ) {
+Profile(ID, WrappedType, Attr);

You should fix the formatting issue (here and everywhere in the file, I'll stop 
commenting on them).



Comment at: clang/include/clang/AST/TypeLoc.h:904-917
+struct BTFTagAttributedLocInfo {
+  const Attr *TypeAttr;
+};
+
+/// Type source information for an btf_tag attributed type.
+class BTFTagAttributedTypeLoc
+: public ConcreteTypeLoc Annots;
+  auto BTFTagAttrTy = dyn_cast(PointeeTy);
+  while (BTFTagAttrTy) {





Comment at: clang/lib/Sema/TreeTransform.h:6872
+  const BTFTagAttributedType *oldType = TL.getTypePtr();
+  StringRef Tag = oldType->getTag();
+  QualType modifiedType = getDerived().TransformType(TLB, TL.getModifiedLoc());

yonghong-song wrote:
> erichkeane wrote:
> > Most of this tree-transform doesn't really do much, since this is a 'C' 
> > only type, but otherwise we'd probably want to allow the tag itself to be 
> > dependent.  
> > 
> > We still need this though, since there are other non-template 
> > tree-transforms.
> > 
> > You also might need to make this not contain a `StringRef` based on the 
> > serialization issues above.
> I will try to do some experiment and simplify this. Indeed this is C and non 
> templates are involved.
> We still need this though, since there are other non-template tree-transforms.

Are we sure any of them can be hit for this new type? It'd be nice to keep this 
out of the template instantiation bits if possible.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120296

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


[PATCH] D121233: [pseudo] Move pseudoparser from clang to clang-tools-extra

2022-03-09 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

I understand where you're coming from. But I think agreeing to move the code 
was premature if it means either:

- following all the precedents in clang-tools-extra, or
- taking on the political burden of getting these changed for all projects.

Based on previous interactions, I think we differ on the relative value we 
place on consistency vs local quality vs burden on development, and our ability 
to make consensus-based changes on a timeline that feels acceptable.
(This isn't a criticism, I admire your patience and dedication to consistency, 
I just don't share it).
If consistency is to be the sine qua non, then I think we should probably leave 
the code where it is until someone's willing to do the work you described. 
clang/Tooling/Syntax is the most consistent location for the code, and the one 
proposed in the original RFC last year.

> The status quo is that we try to be consistent unless there's a compelling 
> reason not to, so I disagree; the onus is on you as to why this is a special 
> snowflake that deserves to be inconsistent with everything else in the 
> project.

If I understand, you're saying that LLVM in general, or clang-tools-extra in 
particular values consistency over quality.
Is this a documented policy (where?), consensus (among who?), or historical 
practice (which would beg the question somewhat).
This is a genuine question - I suspect that you're right, but it's hard to know 
how to challenge this if it's unclear where it comes from.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121233

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


[PATCH] D121294: [AArch64][SVE][Clang] Fix crash for incorrect svptrue and svcnt parameters

2022-03-09 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen added a comment.

This is missing tests for svundef, svrdffr, svsetffr and svpfalse?




Comment at: 
clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_svptrue.c:2
+// REQUIRES: aarch64-registered-target
+
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-fallow-half-arguments-and-returns -fsyntax-only -verify %s

Is it possible to use the `update_cc_test_checks.py` script for these tests?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121294

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


[PATCH] D121295: [clang][deps] Modules don't contribute to search path usage

2022-03-09 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 created this revision.
jansvoboda11 added reviewers: Bigcheese, dexonsmith.
Herald added a project: All.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

To reduce the number of modules we build in explicit builds (which use strict 
context hash), we prune unused header search paths. This essentially merges 
parts of the dependency graph.

Determining whether a search path was used to discover a module (through 
implicit module maps) proved to be somewhat complicated. Initial support landed 
in D102923 , while D113676 
 attempts to fix some bugs.

However, now that we don't use implicit module maps in explicit builds (since 
D120465 ), we don't need to consider such 
search paths as used anymore. Modules are no longer discovered through the 
header search mechanism, so we can drop such search paths (provided they are 
not needed for other reasons).

This patch removes whatever support for detecting such usage we had, since it's 
buggy and not required anymore.

Depends on D120465 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121295

Files:
  clang/lib/Lex/HeaderSearch.cpp
  clang/test/Preprocessor/search-path-usage.m


Index: clang/test/Preprocessor/search-path-usage.m
===
--- clang/test/Preprocessor/search-path-usage.m
+++ clang/test/Preprocessor/search-path-usage.m
@@ -129,7 +129,7 @@
 #endif
 #endif
 
-// Check that search paths with module maps are reported.
+// Check that search paths with module maps are NOT reported.
 //
 // RUN: mkdir %t/modulemap_abs
 // RUN: sed "s|DIR|%/S/Inputs/search-path-usage|g"\
@@ -142,5 +142,5 @@
 // RUN:   -DMODMAP_ABS -verify
 #ifdef MODMAP_ABS
 @import b; // \
-// expected-remark-re {{search path used: '{{.*}}/modulemap_abs'}}
+// expected-no-diagnostics
 #endif
Index: clang/lib/Lex/HeaderSearch.cpp
===
--- clang/lib/Lex/HeaderSearch.cpp
+++ clang/lib/Lex/HeaderSearch.cpp
@@ -299,20 +299,19 @@
SourceLocation ImportLoc,
bool AllowExtraModuleMapSearch) {
   Module *Module = nullptr;
-  SearchDirIterator It = nullptr;
 
   // Look through the various header search paths to load any available module
   // maps, searching for a module map that describes this module.
-  for (It = search_dir_begin(); It != search_dir_end(); ++It) {
-if (It->isFramework()) {
+  for (DirectoryLookup Dir : search_dir_range()) {
+if (Dir.isFramework()) {
   // Search for or infer a module map for a framework. Here we use
   // SearchName rather than ModuleName, to permit finding private modules
   // named FooPrivate in buggy frameworks named Foo.
   SmallString<128> FrameworkDirName;
-  FrameworkDirName += It->getFrameworkDir()->getName();
+  FrameworkDirName += Dir.getFrameworkDir()->getName();
   llvm::sys::path::append(FrameworkDirName, SearchName + ".framework");
   if (auto FrameworkDir = FileMgr.getDirectory(FrameworkDirName)) {
-bool IsSystem = It->getDirCharacteristic() != SrcMgr::C_User;
+bool IsSystem = Dir.getDirCharacteristic() != SrcMgr::C_User;
 Module = loadFrameworkModule(ModuleName, *FrameworkDir, IsSystem);
 if (Module)
   break;
@@ -322,12 +321,12 @@
 // FIXME: Figure out how header maps and module maps will work together.
 
 // Only deal with normal search directories.
-if (!It->isNormalDir())
+if (!Dir.isNormalDir())
   continue;
 
-bool IsSystem = It->isSystemHeaderDirectory();
+bool IsSystem = Dir.isSystemHeaderDirectory();
 // Search for a module map file in this directory.
-if (loadModuleMapFile(It->getDir(), IsSystem,
+if (loadModuleMapFile(Dir.getDir(), IsSystem,
   /*IsFramework*/false) == LMM_NewlyLoaded) {
   // We just loaded a module map file; check whether the module is
   // available now.
@@ -339,7 +338,7 @@
 // Search for a module map in a subdirectory with the same name as the
 // module.
 SmallString<128> NestedModuleMapDirName;
-NestedModuleMapDirName = It->getDir()->getName();
+NestedModuleMapDirName = Dir.getDir()->getName();
 llvm::sys::path::append(NestedModuleMapDirName, ModuleName);
 if (loadModuleMapFile(NestedModuleMapDirName, IsSystem,
   /*IsFramework*/false) == LMM_NewlyLoaded){
@@ -351,13 +350,13 @@
 
 // If we've already performed the exhaustive search for module maps in this
 // search directory, don't do it again.
-if (It->haveSearchedAllModuleMaps())
+if (Dir.haveSearchedAllModuleMaps())
   continue;
 
 // Load all module maps in the immediate 

[PATCH] D121294: [AArch64][SVE][Clang] Fix crash for incorrect svptrue and svcnt parameters

2022-03-09 Thread Matt Devereau via Phabricator via cfe-commits
MattDevereau created this revision.
MattDevereau added reviewers: peterwaller-arm, paulwalker-arm, DavidTruby.
Herald added subscribers: ctetreau, psnobl, kristof.beyls, tschuett.
Herald added a reviewer: efriedma.
Herald added a project: All.
MattDevereau requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Giving an int parameter to SVE intrinsics svptrue and svcnt caused Clang to 
crash on compilation. Changing their parameter types to void instead of 
omitting args results in a diagnostic error message instead.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121294

Files:
  clang/include/clang/Basic/arm_sve.td
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_svcnt.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_svptrue.c

Index: clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_svptrue.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_svptrue.c
@@ -0,0 +1,33 @@
+// REQUIRES: aarch64-registered-target
+
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify %s
+// RUN: %clang_cc1 -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify %s
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1, A2_UNUSED, A3, A4_UNUSED) A1##A3
+#else
+#define SVE_ACLE_FUNC(A1, A2, A3, A4) A1##A2##A3##A4
+#endif
+
+#include 
+
+svbool_t test_svptrue_b8() {
+  // expected-error-re@+1 {{too many arguments to function call, expected {{0}}, have {{1
+  return SVE_ACLE_FUNC(svptrue, , _b8, )(1);
+}
+
+svbool_t test_svptrue_b32() {
+  // expected-error-re@+1 {{too many arguments to function call, expected {{0}}, have {{1
+  return SVE_ACLE_FUNC(svptrue, , _b32, )(2);
+}
+
+svbool_t test_svptrue_b64() {
+  // expected-error-re@+1 {{too many arguments to function call, expected {{0}}, have {{1
+  return SVE_ACLE_FUNC(svptrue, , _b64, )(3);
+}
+
+svbool_t test_svptrue_b16() {
+  // expected-error-re@+1 {{too many arguments to function call, expected {{0}}, have {{1
+  return SVE_ACLE_FUNC(svptrue, , _b16, )(4);
+}
Index: clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_svcnt.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_svcnt.c
@@ -0,0 +1,33 @@
+// REQUIRES: aarch64-registered-target
+
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify %s
+// RUN: %clang_cc1 -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify %s
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1, A2_UNUSED, A3, A4_UNUSED) A1##A3
+#else
+#define SVE_ACLE_FUNC(A1, A2, A3, A4) A1##A2##A3##A4
+#endif
+
+#include 
+
+uint64_t test_svcntb() {
+  // expected-error-re@+1 {{too many arguments to function call, expected {{0}}, have {{1
+  return SVE_ACLE_FUNC(svcnt, , b, )(1);
+}
+
+uint64_t test_svcnth() {
+  // expected-error-re@+1 {{too many arguments to function call, expected {{0}}, have {{1
+  return SVE_ACLE_FUNC(svcnt, , h, )(2);
+}
+
+uint64_t test_svcntw() {
+  // expected-error-re@+1 {{too many arguments to function call, expected {{0}}, have {{1
+  return SVE_ACLE_FUNC(svcnt, , w, )(3);
+}
+
+uint64_t test_svcntd() {
+  // expected-error-re@+1 {{too many arguments to function call, expected {{0}}, have {{1
+  return SVE_ACLE_FUNC(svcnt, , d, )(4);
+}
Index: clang/include/clang/Basic/arm_sve.td
===
--- clang/include/clang/Basic/arm_sve.td
+++ clang/include/clang/Basic/arm_sve.td
@@ -1263,10 +1263,10 @@
 
 // Predicate creation
 
-def SVPFALSE : SInst<"svpfalse[_b]", "P", "", MergeNone, "", [IsOverloadNone]>;
+def SVPFALSE : SInst<"svpfalse[_b]", "Pv", "", MergeNone, "", [IsOverloadNone]>;
 
 def SVPTRUE_PAT : SInst<"svptrue_pat_{d}", "PI", "PcPsPiPl", MergeNone, "aarch64_sve_ptrue">;
-def SVPTRUE : SInst<"svptrue_{d}", "P",  "PcPsPiPl", MergeNone, "aarch64_sve_ptrue", [IsAppendSVALL]>;
+def SVPTRUE : SInst<"svptrue_{d}", "Pv",  "PcPsPiPl", MergeNone, "aarch64_sve_ptrue", [IsAppendSVALL]>;
 
 def SVDUPQ_B8  : SInst<"svdupq[_n]_{d}",  "P",  "Pc", MergeNone>;
 def SVDUPQ_B16 : SInst<"svdupq[_n]_{d}", "P",  "Ps", MergeNone>;
@@ -1309,9 +1309,9 @@
 
 // FFR manipulation
 
-def SVRDFFR   : 

[PATCH] D120568: [flang][driver] Add support for -S and implement -c/-emit-obj

2022-03-09 Thread Andrzej Warzynski via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG38101b4e95aa: [flang][driver] Add support for -S and 
implement -c/-emit-obj (authored by awarzynski).

Changed prior to commit:
  https://reviews.llvm.org/D120568?vs=414043=414102#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120568

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/FrontendActions.h
  flang/include/flang/Frontend/FrontendOptions.h
  flang/lib/Frontend/CMakeLists.txt
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/lib/Optimizer/Support/FIRContext.cpp
  flang/test/CMakeLists.txt
  flang/test/Driver/code-gen-aarch64.f90
  flang/test/Driver/code-gen-x86.f90
  flang/test/Driver/code-gen.f90
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/emit-asm-aarch64.f90
  flang/test/Driver/emit-asm-x86.f90
  flang/test/Driver/syntax-only.f90
  flang/test/Fir/target-rewrite-triple.fir
  flang/test/lit.cfg.py
  flang/test/lit.site.cfg.py.in
  flang/tools/flang-driver/fc1_main.cpp
  flang/unittests/Frontend/CMakeLists.txt
  flang/unittests/Frontend/FrontendActionTest.cpp

Index: flang/unittests/Frontend/FrontendActionTest.cpp
===
--- flang/unittests/Frontend/FrontendActionTest.cpp
+++ flang/unittests/Frontend/FrontendActionTest.cpp
@@ -11,6 +11,7 @@
 #include "flang/Frontend/FrontendOptions.h"
 #include "flang/FrontendTool/Utils.h"
 #include "llvm/Support/FileSystem.h"
+#include "llvm/Support/TargetSelect.h"
 #include "llvm/Support/raw_ostream.h"
 
 #include "gtest/gtest.h"
@@ -188,4 +189,35 @@
   EXPECT_TRUE(llvm::StringRef(outputFileBuffer.data())
   .contains("define void @_QQmain()"));
 }
+
+TEST_F(FrontendActionTest, EmitAsm) {
+  // Populate the input file with the pre-defined input and flush it.
+  *(inputFileOs_) << "end program";
+  inputFileOs_.reset();
+
+  // Set-up the action kind.
+  compInst_.invocation().frontendOpts().programAction = EmitAssembly;
+  compInst_.invocation().preprocessorOpts().noReformat = true;
+
+  // Initialise LLVM backend
+  llvm::InitializeAllTargets();
+  llvm::InitializeAllTargetMCs();
+  llvm::InitializeAllAsmPrinters();
+
+  // Set-up the output stream. We are using output buffer wrapped as an output
+  // stream, as opposed to an actual file (or a file descriptor).
+  llvm::SmallVector outputFileBuffer;
+  std::unique_ptr outputFileStream(
+  new llvm::raw_svector_ostream(outputFileBuffer));
+  compInst_.set_outputStream(std::move(outputFileStream));
+
+  // Execute the action.
+  bool success = ExecuteCompilerInvocation(_);
+
+  // Validate the expected output.
+  EXPECT_TRUE(success);
+  EXPECT_TRUE(!outputFileBuffer.empty());
+
+  EXPECT_TRUE(llvm::StringRef(outputFileBuffer.data()).contains("_QQmain"));
+}
 } // namespace
Index: flang/unittests/Frontend/CMakeLists.txt
===
--- flang/unittests/Frontend/CMakeLists.txt
+++ flang/unittests/Frontend/CMakeLists.txt
@@ -1,3 +1,7 @@
+set(LLVM_LINK_COMPONENTS
+  ${LLVM_TARGETS_TO_BUILD}
+)
+
 add_flang_unittest(FlangFrontendTests
   CompilerInstanceTest.cpp
   FrontendActionTest.cpp
Index: flang/tools/flang-driver/fc1_main.cpp
===
--- flang/tools/flang-driver/fc1_main.cpp
+++ flang/tools/flang-driver/fc1_main.cpp
@@ -20,6 +20,7 @@
 #include "llvm/Option/Arg.h"
 #include "llvm/Option/ArgList.h"
 #include "llvm/Option/OptTable.h"
+#include "llvm/Support/TargetSelect.h"
 
 #include 
 
@@ -48,6 +49,11 @@
   bool success =
   CompilerInvocation::CreateFromArgs(flang->invocation(), argv, diags);
 
+  // Initialize targets first, so that --version shows registered targets.
+  llvm::InitializeAllTargets();
+  llvm::InitializeAllTargetMCs();
+  llvm::InitializeAllAsmPrinters();
+
   diagsBuffer->FlushDiagnostics(flang->diagnostics());
 
   if (!success)
Index: flang/test/lit.site.cfg.py.in
===
--- flang/test/lit.site.cfg.py.in
+++ flang/test/lit.site.cfg.py.in
@@ -18,6 +18,7 @@
 config.flang_standalone_build = @FLANG_STANDALONE_BUILD@
 config.has_plugins = @LLVM_ENABLE_PLUGINS@
 config.cc = "@CMAKE_C_COMPILER@"
+config.targets_to_build = "@TARGETS_TO_BUILD@"
 
 # Support substitution of the tools_dir with user parameters. This is
 # used when we can't determine the tool dir at configuration time.
Index: flang/test/lit.cfg.py
===
--- flang/test/lit.cfg.py
+++ flang/test/lit.cfg.py
@@ -39,6 +39,11 @@
 

[clang] 38101b4 - [flang][driver] Add support for -S and implement -c/-emit-obj

2022-03-09 Thread Andrzej Warzynski via cfe-commits

Author: Andrzej Warzynski
Date: 2022-03-09T15:48:09Z
New Revision: 38101b4e95aa4983b7acf1e6351309db9ce5761b

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

LOG: [flang][driver] Add support for -S and implement -c/-emit-obj

This patch adds support for:
  * `-S` in Flang's compiler and frontend drivers,
and implements:
  * `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler
driver (this is consistent with Clang).
(these options were already available before, but only as placeholders).
The semantics of these options in Clang and Flang are identical.

The `EmitObjAction` frontend action is renamed as `BackendAction`. This
new name more accurately reflects the fact that this action will
primarily run the code-gen/backend pipeline in LLVM. It also makes more
sense as an action implementing both `-emit-obj` and `-S` (originally,
it was just `-emit-obj`).

`tripleName` from FirContext.cpp is deleted and, when a target triple is
required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used
instead. In practice, this means that `fir.triple` is replaced with
`llvm.target_triple`. The former was effectively ignored. The latter is
used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's
embedded in the generated LLVM IR module). The driver can then re-use
it when configuring the backend. With this change, the LLVM IR files
generated by e.g. `tco` will from now on contain the correct target
triple.

The code-gen.f90 test is replaced with code-gen-x86.f90 and
code-gen-aarch64.f90. With 2 seperate files we can verify that
`--target` is correctly taken into account. LIT configuration is updated
to enable e.g.:
```
! REQUIRES: aarch64-registered-target
```

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

Added: 
flang/test/Driver/code-gen-aarch64.f90
flang/test/Driver/code-gen-x86.f90
flang/test/Driver/emit-asm-aarch64.f90
flang/test/Driver/emit-asm-x86.f90

Modified: 
clang/include/clang/Driver/Options.td
flang/include/flang/Frontend/FrontendActions.h
flang/include/flang/Frontend/FrontendOptions.h
flang/lib/Frontend/CMakeLists.txt
flang/lib/Frontend/CompilerInvocation.cpp
flang/lib/Frontend/FrontendActions.cpp
flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
flang/lib/Optimizer/Support/FIRContext.cpp
flang/test/CMakeLists.txt
flang/test/Driver/driver-help-hidden.f90
flang/test/Driver/driver-help.f90
flang/test/Driver/syntax-only.f90
flang/test/Fir/target-rewrite-triple.fir
flang/test/lit.cfg.py
flang/test/lit.site.cfg.py.in
flang/tools/flang-driver/fc1_main.cpp
flang/unittests/Frontend/CMakeLists.txt
flang/unittests/Frontend/FrontendActionTest.cpp

Removed: 
flang/test/Driver/code-gen.f90



diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 3d49e6b165b38..fa54d4a7689cd 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -750,7 +750,7 @@ def Rpass_analysis_EQ : Joined<["-"], "Rpass-analysis=">, 
Group,
"name matches the given POSIX regular expression">;
 def R_Joined : Joined<["-"], "R">, Group, Flags<[CC1Option, 
CoreOption]>,
   MetaVarName<"">, HelpText<"Enable the specified remark">;
-def S : Flag<["-"], "S">, Flags<[NoXarchOption,CC1Option]>, 
Group,
+def S : Flag<["-"], "S">, 
Flags<[NoXarchOption,CC1Option,FlangOption,FC1Option]>, Group,
   HelpText<"Only run preprocess and compilation steps">;
 def Tbss : JoinedOrSeparate<["-"], "Tbss">, Group,
   MetaVarName<"">, HelpText<"Set starting address of BSS to ">;

diff  --git a/flang/include/flang/Frontend/FrontendActions.h 
b/flang/include/flang/Frontend/FrontendActions.h
index 0cb6d6301c066..34cabea590485 100644
--- a/flang/include/flang/Frontend/FrontendActions.h
+++ b/flang/include/flang/Frontend/FrontendActions.h
@@ -192,8 +192,19 @@ class EmitLLVMAction : public CodeGenAction {
   void ExecuteAction() override;
 };
 
-class EmitObjAction : public CodeGenAction {
+class BackendAction : public CodeGenAction {
+public:
+  enum class BackendActionTy {
+Backend_EmitAssembly, ///< Emit native assembly files
+Backend_EmitObj ///< Emit native object files
+  };
+
+  BackendAction(BackendActionTy act) : action{act} {};
+
+private:
   void ExecuteAction() override;
+
+  BackendActionTy action;
 };
 
 } // namespace Fortran::frontend

diff  --git a/flang/include/flang/Frontend/FrontendOptions.h 
b/flang/include/flang/Frontend/FrontendOptions.h
index c396822819ac6..b299c87ef15f1 100644
--- a/flang/include/flang/Frontend/FrontendOptions.h
+++ b/flang/include/flang/Frontend/FrontendOptions.h
@@ -40,6 +40,9 @@ enum ActionKind {
   /// Emit a .o file.
   EmitObj,
 
+  /// Emit a .s file.
+  

[PATCH] D120132: [HIP] Fix HIP include path

2022-03-09 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

I found a simple fix. Use -idirafter instead of -isystem-internal. It is still 
system include path but will be added after all other system include paths.


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

https://reviews.llvm.org/D120132

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


[clang] 3dd7877 - Revert "[clang][dataflow] Move dataflow testing support out of unittests"

2022-03-09 Thread Stanislav Gatev via cfe-commits

Author: Stanislav Gatev
Date: 2022-03-09T15:38:51Z
New Revision: 3dd7877b27dcd0d2b8e0d3a3ac156390248fe612

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

LOG: Revert "[clang][dataflow] Move dataflow testing support out of unittests"

This reverts commit 26bbde2612b2042c3a8a31aed7f45e065c3dd413.

Added: 
clang/unittests/Analysis/FlowSensitive/NoopAnalysis.h
clang/unittests/Analysis/FlowSensitive/TestingSupport.cpp
clang/unittests/Analysis/FlowSensitive/TestingSupport.h
clang/unittests/Analysis/FlowSensitive/TestingSupportTest.cpp

Modified: 
clang/lib/Analysis/FlowSensitive/CMakeLists.txt
clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp
clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Removed: 
clang/include/clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h
clang/include/clang/Analysis/FlowSensitive/Testing/NoopAnalysis.h
clang/lib/Analysis/FlowSensitive/Testing/CMakeLists.txt
clang/lib/Analysis/FlowSensitive/Testing/DataflowAnalysis.cpp
clang/unittests/Analysis/FlowSensitive/Testing/CMakeLists.txt
clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp



diff  --git a/clang/lib/Analysis/FlowSensitive/CMakeLists.txt 
b/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
index 58c3df47745cb..cfe3c8e77b4fd 100644
--- a/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
+++ b/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
@@ -12,5 +12,3 @@ add_clang_library(clangAnalysisFlowSensitive
   clangAST
   clangBasic
   )
-
-add_subdirectory(Testing)

diff  --git a/clang/lib/Analysis/FlowSensitive/Testing/CMakeLists.txt 
b/clang/lib/Analysis/FlowSensitive/Testing/CMakeLists.txt
deleted file mode 100644
index 513bcbf5ecc7a..0
--- a/clang/lib/Analysis/FlowSensitive/Testing/CMakeLists.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-add_clang_library(clangAnalysisFlowSensitiveTesting
-  DataflowAnalysis.cpp
-
-  LINK_LIBS
-  clangAnalysis
-  clangAnalysisFlowSensitive
-  clangAST
-  clangBasic
-  clangFrontend
-  clangLex
-  clangSerialization
-  clangTesting
-  clangTooling
-  )

diff  --git a/clang/unittests/Analysis/FlowSensitive/CMakeLists.txt 
b/clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
index f59024c8e78a7..d2608503a5396 100644
--- a/clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
+++ b/clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
@@ -11,6 +11,8 @@ add_clang_unittest(ClangAnalysisFlowSensitiveTests
   MultiVarConstantPropagationTest.cpp
   SingleVarConstantPropagationTest.cpp
   SourceLocationsLatticeTest.cpp
+  TestingSupport.cpp
+  TestingSupportTest.cpp
   TransferTest.cpp
   TypeErasedDataflowAnalysisTest.cpp
   SolverTest.cpp
@@ -20,7 +22,6 @@ clang_target_link_libraries(ClangAnalysisFlowSensitiveTests
   PRIVATE
   clangAnalysis
   clangAnalysisFlowSensitive
-  clangAnalysisFlowSensitiveTesting
   clangAST
   clangASTMatchers
   clangBasic
@@ -35,5 +36,3 @@ target_link_libraries(ClangAnalysisFlowSensitiveTests
   PRIVATE
   LLVMTestingSupport
   )
-
-add_subdirectory(Testing)

diff  --git 
a/clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp
index 738af8d9c97ca..51b40f2319878 100644
--- a/clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp
@@ -7,9 +7,9 @@
 
//===--===//
 
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
+#include "NoopAnalysis.h"
+#include "TestingSupport.h"
 #include "clang/Analysis/FlowSensitive/DataflowAnalysisContext.h"
-#include "clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h"
-#include "clang/Analysis/FlowSensitive/Testing/NoopAnalysis.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
 #include "clang/Analysis/FlowSensitive/WatchedLiteralsSolver.h"
 #include "gmock/gmock.h"

diff  --git a/clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
index b04d2b7e9105a..b99e5c6e1c0b0 100644
--- a/clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
@@ -13,6 +13,7 @@
 
//===--===//
 
 #include "clang/Analysis/FlowSensitive/MatchSwitch.h"

[PATCH] D120132: [HIP] Fix HIP include path

2022-03-09 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl updated this revision to Diff 414100.
yaxunl added a comment.

use -idirafter to include HIP include path


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

https://reviews.llvm.org/D120132

Files:
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/test/Driver/hip-include-path.hip
  clang/test/Driver/rocm-detect.hip


Index: clang/test/Driver/rocm-detect.hip
===
--- clang/test/Driver/rocm-detect.hip
+++ clang/test/Driver/rocm-detect.hip
@@ -90,7 +90,7 @@
 // SPACK: Found HIP installation: 
[[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5, version 4.0.20214-a2917cd
 // SPACK: "-triple" "amdgcn-amd-amdhsa"
 // SPACK-SAME: "-mlink-builtin-bitcode" 
"[[DIR]]/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/hip.bc"
-// SPACK-SAME: "-internal-isystem" 
"[[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5/include"
+// SPACK-SAME: "-idirafter" 
"[[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5/include"
 
 // SPACK-MULT: InstalledDir: 
[[DIR:.*]]/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/bin
 // SPACK-MULT-DAG: Cannot use SPACK package hip-4.0.0 at [[DIR]] due to 
multiple installations for the same version
@@ -101,12 +101,12 @@
 // SPACK-SET: Found HIP installation: [[DIR]]/hip-4.0.0-abcd, version 
4.0.20214-a2917cd
 // SPACK-SET: "-triple" "amdgcn-amd-amdhsa"
 // SPACK-SET-SAME: "-mlink-builtin-bitcode" 
"[[DIR]]/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/hip.bc"
-// SPACK-SET-SAME: "-internal-isystem" "[[DIR]]/hip-4.0.0-abcd/include"
+// SPACK-SET-SAME: "-idirafter" "[[DIR]]/hip-4.0.0-abcd/include"
 
 // SPACK-MISS: InstalledDir: 
[[DIR:.*]]/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/bin
 // SPACK-MISS-DAG: SPACK package hip-4.0.0 not found at [[DIR]]
 // SPACK-MISS-NOT: Found HIP installation: 
[[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5, version 4.0.20214-a2917cd
-// SPACK-MISS-NOT: "-internal-isystem" 
"[[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5/include"
+// SPACK-MISS-NOT: "-idirafter" 
"[[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5/include"
 
 // SPACK-MISS-SILENT-NOT: SPACK package hip-{{.*}} not found at
 // SPACK-MISS-SILENT-NOT: Found HIP installation
Index: clang/test/Driver/hip-include-path.hip
===
--- clang/test/Driver/hip-include-path.hip
+++ clang/test/Driver/hip-include-path.hip
@@ -19,24 +19,24 @@
 // COMMON-LABEL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
 // CLANG-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
 // NOCLANG-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
-// HIP-SAME: "-internal-isystem" "{{[^"]*}}Inputs/rocm/include"
-// NOHIP-NOT: "{{.*}}Inputs/rocm/include"
+// HIP-SAME: "-idirafter" "{{[^"]*}}Inputs/rocm/include"
 // HIP-SAME: "-include" "__clang_hip_runtime_wrapper.h"
 // NOHIP-NOT: "-include" "__clang_hip_runtime_wrapper.h"
 // skip check of standard C++ include path
 // CLANG-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"
 // NOCLANG-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"
+// NOHIP-NOT: "{{.*}}Inputs/rocm/include"
 
 // COMMON-LABEL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
 // CLANG-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
 // NOCLANG-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
-// HIP-SAME: "-internal-isystem" "{{[^"]*}}Inputs/rocm/include"
-// NOHIP-NOT: "{{.*}}Inputs/rocm/include"
+// HIP-SAME: "-idirafter" "{{[^"]*}}Inputs/rocm/include"
 // HIP-SAME: "-include" "__clang_hip_runtime_wrapper.h"
 // NOHIP-NOT: "-include" "__clang_hip_runtime_wrapper.h"
 // skip check of standard C++ include path
 // CLANG-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"
 // NOCLANG-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"
+// NOHIP-NOT: "{{.*}}Inputs/rocm/include"
 
 // RUN: %clang -c -### -target x86_64-unknown-linux-gnu --cuda-gpu-arch=gfx900 
\
 // RUN:   -std=c++11 --rocm-path=%S/Inputs/rocm -nogpulib %s 2>&1 \
@@ -45,7 +45,7 @@
 // ROCM35-LABEL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
 // ROCM35-NOT: "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include/cuda_wrappers"
 // ROCM35-SAME: "-internal-isystem" "{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}"
-// ROCM35-SAME: "-internal-isystem" "{{[^"]*}}Inputs/rocm/include"
+// ROCM35-SAME: "-idirafter" "{{[^"]*}}Inputs/rocm/include"
 // ROCM35-NOT: "-include" "__clang_hip_runtime_wrapper.h"
 // skip check of standard C++ include path
 // ROCM35-SAME: "-internal-isystem" 
"{{[^"]*}}/lib{{[^"]*}}/clang/{{[^"]*}}/include"
Index: clang/lib/Driver/ToolChains/AMDGPU.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -517,7 +517,7 @@
 return;
   }
 
-  CC1Args.push_back("-internal-isystem");
+  

[PATCH] D121285: [clang][dataflow] Move dataflow testing support out of unittests

2022-03-09 Thread Stanislav Gatev via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG26bbde2612b2: [clang][dataflow] Move dataflow testing 
support out of unittests (authored by sgatev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121285

Files:
  clang/include/clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/Testing/NoopAnalysis.h
  clang/lib/Analysis/FlowSensitive/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/Testing/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/Testing/DataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp
  clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
  clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
  clang/unittests/Analysis/FlowSensitive/NoopAnalysis.h
  clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
  clang/unittests/Analysis/FlowSensitive/Testing/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
  clang/unittests/Analysis/FlowSensitive/TestingSupport.cpp
  clang/unittests/Analysis/FlowSensitive/TestingSupport.h
  clang/unittests/Analysis/FlowSensitive/TestingSupportTest.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
  clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -6,8 +6,6 @@
 //
 //===--===//
 
-#include "NoopAnalysis.h"
-#include "TestingSupport.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/ExprCXX.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
@@ -17,6 +15,8 @@
 #include "clang/Analysis/FlowSensitive/DataflowAnalysisContext.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h"
+#include "clang/Analysis/FlowSensitive/Testing/NoopAnalysis.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
 #include "clang/Analysis/FlowSensitive/WatchedLiteralsSolver.h"
 #include "clang/Tooling/Tooling.h"
Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -6,14 +6,14 @@
 //
 //===--===//
 
-#include "NoopAnalysis.h"
-#include "TestingSupport.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/StorageLocation.h"
+#include "clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h"
+#include "clang/Analysis/FlowSensitive/Testing/NoopAnalysis.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
 #include "clang/Basic/LangStandard.h"
 #include "llvm/ADT/ArrayRef.h"
Index: clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
@@ -1,8 +1,16 @@
-#include "TestingSupport.h"
-#include "NoopAnalysis.h"
+//===- DataflowAnalysisTest.cpp ---===//
+//
+// 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 "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h"
+#include "clang/Analysis/FlowSensitive/Testing/NoopAnalysis.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/Testing/Support/Error.h"
 #include "gmock/gmock.h"
Index: clang/unittests/Analysis/FlowSensitive/Testing/CMakeLists.txt
===
--- /dev/null
+++ clang/unittests/Analysis/FlowSensitive/Testing/CMakeLists.txt
@@ -0,0 +1,28 @@
+set(LLVM_LINK_COMPONENTS
+  FrontendOpenMP
+  Support
+  )
+

[clang] 26bbde2 - [clang][dataflow] Move dataflow testing support out of unittests

2022-03-09 Thread Stanislav Gatev via cfe-commits

Author: Stanislav Gatev
Date: 2022-03-09T15:31:02Z
New Revision: 26bbde2612b2042c3a8a31aed7f45e065c3dd413

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

LOG: [clang][dataflow] Move dataflow testing support out of unittests

This enables tests out of clang/unittests/Analysis/FlowSensitive to
use the testing support utilities.

Reviewed-by: ymandel, gribozavr2

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

Added: 
clang/include/clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h
clang/include/clang/Analysis/FlowSensitive/Testing/NoopAnalysis.h
clang/lib/Analysis/FlowSensitive/Testing/CMakeLists.txt
clang/lib/Analysis/FlowSensitive/Testing/DataflowAnalysis.cpp
clang/unittests/Analysis/FlowSensitive/Testing/CMakeLists.txt
clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp

Modified: 
clang/lib/Analysis/FlowSensitive/CMakeLists.txt
clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp
clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Removed: 
clang/unittests/Analysis/FlowSensitive/NoopAnalysis.h
clang/unittests/Analysis/FlowSensitive/TestingSupport.cpp
clang/unittests/Analysis/FlowSensitive/TestingSupport.h
clang/unittests/Analysis/FlowSensitive/TestingSupportTest.cpp



diff  --git a/clang/unittests/Analysis/FlowSensitive/TestingSupport.h 
b/clang/include/clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h
similarity index 95%
rename from clang/unittests/Analysis/FlowSensitive/TestingSupport.h
rename to clang/include/clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h
index 957d73fd6d0c4..df9fdcb215eb4 100644
--- a/clang/unittests/Analysis/FlowSensitive/TestingSupport.h
+++ b/clang/include/clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h
@@ -1,4 +1,4 @@
-//===--- TestingSupport.h - Testing utils for dataflow analyses -*- C++ 
-*-===//
+//===--- DataflowAnalysis.h - Testing utils for dataflow analyses * C++ 
-*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -10,8 +10,8 @@
 //
 
//===--===//
 
-#ifndef LLVM_CLANG_ANALYSIS_FLOW_SENSITIVE_TESTING_SUPPORT_H_
-#define LLVM_CLANG_ANALYSIS_FLOW_SENSITIVE_TESTING_SUPPORT_H_
+#ifndef LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_TESTING_DATAFLOWANALYSIS_H
+#define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_TESTING_DATAFLOWANALYSIS_H
 
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
@@ -179,4 +179,4 @@ const ValueDecl *findValueDecl(ASTContext , 
llvm::StringRef Name);
 } // namespace dataflow
 } // namespace clang
 
-#endif // LLVM_CLANG_ANALYSIS_FLOW_SENSITIVE_TESTING_SUPPORT_H_
+#endif // LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_TESTING_DATAFLOWANALYSIS_H

diff  --git a/clang/unittests/Analysis/FlowSensitive/NoopAnalysis.h 
b/clang/include/clang/Analysis/FlowSensitive/Testing/NoopAnalysis.h
similarity index 90%
rename from clang/unittests/Analysis/FlowSensitive/NoopAnalysis.h
rename to clang/include/clang/Analysis/FlowSensitive/Testing/NoopAnalysis.h
index eab5782095bbc..18f5e87765487 100644
--- a/clang/unittests/Analysis/FlowSensitive/NoopAnalysis.h
+++ b/clang/include/clang/Analysis/FlowSensitive/Testing/NoopAnalysis.h
@@ -11,8 +11,8 @@
 //
 
//===--===//
 
-#ifndef LLVM_CLANG_UNITTESTS_ANALYSIS_FLOWSENSITIVE_NOOPANALYSIS_H
-#define LLVM_CLANG_UNITTESTS_ANALYSIS_FLOWSENSITIVE_NOOPANALYSIS_H
+#ifndef LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_TESTING_NOOPANALYSIS_H
+#define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_TESTING_NOOPANALYSIS_H
 
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Stmt.h"
@@ -55,4 +55,4 @@ class NoopAnalysis : public DataflowAnalysis {
 } // namespace dataflow
 } // namespace clang
 
-#endif // LLVM_CLANG_UNITTESTS_ANALYSIS_FLOWSENSITIVE_NOOPANALYSIS_H
+#endif // LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_TESTING_NOOPANALYSIS_H

diff  --git a/clang/lib/Analysis/FlowSensitive/CMakeLists.txt 
b/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
index cfe3c8e77b4fd..58c3df47745cb 100644
--- a/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
+++ b/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
@@ -12,3 +12,5 @@ add_clang_library(clangAnalysisFlowSensitive
   clangAST
   clangBasic
   )
+
+add_subdirectory(Testing)

diff  --git 

[PATCH] D120568: [flang][driver] Add support for -S and implement -c/-emit-obj

2022-03-09 Thread Eric Schweitz via Phabricator via cfe-commits
schweitz added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120568

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


[PATCH] D121285: [clang][dataflow] Move dataflow testing support out of unittests

2022-03-09 Thread Stanislav Gatev via Phabricator via cfe-commits
sgatev updated this revision to Diff 414094.
sgatev added a comment.

Move NoopAnalysis.h to clang/include/clang/Analysis/FlowSensitive/Testing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121285

Files:
  clang/include/clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/Testing/NoopAnalysis.h
  clang/lib/Analysis/FlowSensitive/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/Testing/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/Testing/DataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp
  clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
  clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
  clang/unittests/Analysis/FlowSensitive/NoopAnalysis.h
  clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
  clang/unittests/Analysis/FlowSensitive/Testing/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
  clang/unittests/Analysis/FlowSensitive/TestingSupport.cpp
  clang/unittests/Analysis/FlowSensitive/TestingSupport.h
  clang/unittests/Analysis/FlowSensitive/TestingSupportTest.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
  clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -6,8 +6,6 @@
 //
 //===--===//
 
-#include "NoopAnalysis.h"
-#include "TestingSupport.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/ExprCXX.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
@@ -17,6 +15,8 @@
 #include "clang/Analysis/FlowSensitive/DataflowAnalysisContext.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h"
+#include "clang/Analysis/FlowSensitive/Testing/NoopAnalysis.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
 #include "clang/Analysis/FlowSensitive/WatchedLiteralsSolver.h"
 #include "clang/Tooling/Tooling.h"
Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -6,14 +6,14 @@
 //
 //===--===//
 
-#include "NoopAnalysis.h"
-#include "TestingSupport.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/StorageLocation.h"
+#include "clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h"
+#include "clang/Analysis/FlowSensitive/Testing/NoopAnalysis.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
 #include "clang/Basic/LangStandard.h"
 #include "llvm/ADT/ArrayRef.h"
Index: clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
@@ -1,8 +1,16 @@
-#include "TestingSupport.h"
-#include "NoopAnalysis.h"
+//===- DataflowAnalysisTest.cpp ---===//
+//
+// 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 "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h"
+#include "clang/Analysis/FlowSensitive/Testing/NoopAnalysis.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/Testing/Support/Error.h"
 #include "gmock/gmock.h"
Index: clang/unittests/Analysis/FlowSensitive/Testing/CMakeLists.txt
===
--- /dev/null
+++ clang/unittests/Analysis/FlowSensitive/Testing/CMakeLists.txt
@@ -0,0 +1,28 @@
+set(LLVM_LINK_COMPONENTS
+  FrontendOpenMP
+  Support
+  )
+
+add_clang_unittest(ClangAnalysisFlowSensitiveTestingTests
+  DataflowCheckerTest.cpp
+  )
+

[PATCH] D121286: [clangd] Test against path insensitivity

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



Comment at: clang-tools-extra/clangd/unittests/TestFS.cpp:76
 #ifdef _WIN32
-  return "C:\\clangd-test";
+  // On windows paths are insensitive, simulate that behaviour by toggling
+  // capitalization for drive-letter on each call.

This is clever, but I don't think it's a good idea.

It's very surprising given the contract and historical behavior of this 
function, and can lead to spurious test failures in some legitimate uses, e.g 
in IncludeCleanerTests:
```
  // Note we deduped the names as _number_ of s is uninteresting.
  EXPECT_THAT(ReferencedFileNames.keys(),
  UnorderedElementsAre("", "",
   testPath("macros.h")));
```
(Not sure why this isn't failing, luck? Maybe you'll get more failures by 
adding more possible case variations?)
I don't think the extra verbosity to make such tests resilient to case changes 
is an improvement.

The paths coming from testRoot get propagated around a lot, so lots of strings 
start having unpredictable case (which is the point!). Nevertheless I'm not 
confident many of them will be effectively tested, because the paths compared 
need to originate through independent calls to testRoot() rather than e.g. both 
resulting from relative paths resolved against a CWD set to testRoot() called 
once.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121286

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


[PATCH] D119609: [Clang][Sema] Prohibit expression statement in lambda default argument

2022-03-09 Thread Jun Zhang via Phabricator via cfe-commits
junaire added a comment.

In D119609#3369816 , @erichkeane 
wrote:

> The commit message isn't quite accurate, we're prohibiting it in ALL default 
> arguments.

Yeah, I just realize this issue after changing the message.

>>> I just realized that something is not very clear here. Should we prohibit 
>>> expression statements in all default arguments or just in lambda and 
>>> templates? I wonder how gcc folks think about it as well.
>
> The latest patch was to prohibit it ONLY in the lambda default parameters, 
> but I though the discussion on the GCC bug had the patch author show 
> preference for all cases.  Can you please ping the thread to see what they 
> plan to do so we can align?

OK, done. let's wait the feedback before we continue the patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119609

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


[PATCH] D121269: [clang-format] Fix namespace format when the name is followed by a macro

2022-03-09 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius added inline comments.



Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:192-211
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A M(x)",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A M(x) {\n"

MyDeveloperDay wrote:
> Can you test the A B case? We can’t have a space right?
What's the rationale behind keeping `M(x)` in one case and not the other?
How can you decide?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121269

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


[PATCH] D121214: [clang-tidy][docs][NFC] Add alias cert-mem51-cpp to bugprone-shared-ptr-array-mismatch

2022-03-09 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

What I wanted is to highlight the relationship between the 
`bugprone-shared-ptr-array-mismatch` check and the `cert-mem51` rule.
I thought these aliases are the _programmatic_ way of encoding this 
relationship, but I understand that it might be a false advertisement given 
that only 1 out of 9 cases are caught by the related check.

What do you recommend?
Drop the alias-related changes and preserve the note in the 
`bugprone-shared-ptr-array-mismatch.rst` stating this relationship with the 
cert rule?
If we do it like that, then this will be again NFC.

How shall I proceed?


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

https://reviews.llvm.org/D121214

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


[PATCH] D121269: [clang-format] Fix namespace format when the name is followed by a macro

2022-03-09 Thread Nico Weber via Phabricator via cfe-commits
thakis resigned from this revision.
thakis added a comment.

(deferring to MyDeveloperDay and curdeius)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121269

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


[PATCH] D120244: [clang][sema] Enable first-class bool support for C2x

2022-03-09 Thread Timm Bäder via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe5ccd6680198: [clang][sema] Enable first-class bool support 
for C2x (authored by tbaeder).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120244

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Headers/stdbool.h
  clang/test/Headers/stdbool.c
  clang/test/Sema/c2x-bool.c

Index: clang/test/Sema/c2x-bool.c
===
--- /dev/null
+++ clang/test/Sema/c2x-bool.c
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -std=c2x -fsyntax-only -verify %s
+
+_Static_assert(_Generic(true, _Bool : 1, default: 0));
+_Static_assert(_Generic(false, _Bool : 1, default: 0));
+
+_Static_assert(_Generic(true, bool : 1, default: 0));
+_Static_assert(_Generic(false, bool : 1, default: 0));
+
+_Static_assert(_Generic(true, bool : true, default: false));
+_Static_assert(_Generic(false, bool : true, default: false));
+
+_Static_assert(true == (bool)+1);
+_Static_assert(false == (bool)+0);
+
+_Static_assert(_Generic(+true, bool : 0, unsigned int : 0, signed int : 1, default : 0));
+
+struct S {
+  bool b : 1;
+} s;
+_Static_assert(_Generic(+s.b, bool : 0, unsigned int : 0, signed int : 1, default : 0));
+
+static void *f = false; // expected-warning {{to null from a constant boolean expression}}
+static int one = true;
+static int zero = false;
+
+static void do_work() {
+  char *str = "Foo";
+  str[false] = 'f';
+  str[true] = 'f';
+
+  char c1[true];
+  char c2[false];
+}
+
+#if true != 1
+#error true should be 1 in the preprocessor
+#endif
+
+#if false != 0
+#error false should be 0 in the preprocessor
+#endif
Index: clang/test/Headers/stdbool.c
===
--- /dev/null
+++ clang/test/Headers/stdbool.c
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -fgnuc-version=4.2.1 -std=c11 -E -dM %s 2>&1 | FileCheck --check-prefix=CHECK-C11 %s
+// RUN: %clang_cc1 -fgnuc-version=4.2.1 -std=c2x -E -dM %s 2>&1 | FileCheck --check-prefix=CHECK-C2X %s
+// RUN: %clang_cc1 -fgnuc-version=4.2.1 -std=c2x -E -dM -D_CLANG_DISABLE_CRT_DEPRECATION_WARNINGS %s 2>&1 | FileCheck --check-prefix=CHECK-C2X-CRT %s
+
+#include 
+
+// CHECK-C11: #define bool _Bool
+// CHECK-C11: #define false 0
+// CHECK-C11: #define true 1
+
+// CHECK-C2X: warning "the  header is deprecated
+// CHECK-C2X-NOT: #define bool
+// CHECK-C2X-NOT: #define true
+// CHECK-C2X-NOT: #define falsea
+
+// CHECK-C2X-CRT-NOT: warning "the  header is deprecated
+// CHECK-C2X-CRT-NOT: #define bool
+// CHECK-C2X-CRT-NOT: #define true
+// CHECK-C2X-CRT-NOT: #define false
Index: clang/lib/Headers/stdbool.h
===
--- clang/lib/Headers/stdbool.h
+++ clang/lib/Headers/stdbool.h
@@ -10,8 +10,13 @@
 #ifndef __STDBOOL_H
 #define __STDBOOL_H
 
-/* Don't define bool, true, and false in C++, except as a GNU extension. */
-#ifndef __cplusplus
+#define __bool_true_false_are_defined 1
+
+#if __STDC_VERSION__ > 201710L
+#if !defined(_CLANG_DISABLE_CRT_DEPRECATION_WARNINGS)
+#warning "the  header is deprecated in C2x"
+#endif /* !defined(_CLANG_DISABLE_CRT_DEPRECATION_WARNINGS) */
+#elif !defined(__cplusplus)
 #define bool _Bool
 #define true 1
 #define false 0
@@ -20,12 +25,10 @@
 #define _Bool bool
 #if __cplusplus < 201103L
 /* For C++98, define bool, false, true as a GNU extension. */
-#define bool  bool
+#define bool bool
 #define false false
-#define true  true
+#define true true
 #endif
 #endif
 
-#define __bool_true_false_are_defined 1
-
 #endif /* __STDBOOL_H */
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3249,8 +3249,8 @@
 
   Opts.RenderScript = IK.getLanguage() == Language::RenderScript;
 
-  // OpenCL and C++ both have bool, true, false keywords.
-  Opts.Bool = Opts.OpenCL || Opts.CPlusPlus;
+  // OpenCL, C++ and C2x have bool, true, false keywords.
+  Opts.Bool = Opts.OpenCL || Opts.CPlusPlus || Opts.C2x;
 
   // OpenCL has half keyword
   Opts.Half = Opts.OpenCL;
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -110,6 +110,7 @@
 ---
 
 - Implemented `WG14 N2674 The noreturn attribute `_.
+- Implemented `WG14 N2935 Make false and true first-class language features `_.
 
 C++ Language Changes in Clang
 -
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] e5ccd66 - [clang][sema] Enable first-class bool support for C2x

2022-03-09 Thread Timm Bäder via cfe-commits

Author: Timm Bäder
Date: 2022-03-09T15:04:24+01:00
New Revision: e5ccd668019888de2704ae670da88a7be8cf7e0f

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

LOG: [clang][sema] Enable first-class bool support for C2x

Implement N2395 for C2x.

This also covers adding "bool", which is part of N2394.

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

Added: 
clang/test/Headers/stdbool.c
clang/test/Sema/c2x-bool.c

Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Frontend/CompilerInvocation.cpp
clang/lib/Headers/stdbool.h

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 662d4b1b2443e..53d07c03af0f9 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -110,6 +110,7 @@ C2x Feature Support
 ---
 
 - Implemented `WG14 N2674 The noreturn attribute 
`_.
+- Implemented `WG14 N2935 Make false and true first-class language features 
`_.
 
 C++ Language Changes in Clang
 -

diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 5d7c999b0143a..cac443de75dae 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -3249,8 +3249,8 @@ void CompilerInvocation::setLangDefaults(LangOptions 
, InputKind IK,
 
   Opts.RenderScript = IK.getLanguage() == Language::RenderScript;
 
-  // OpenCL and C++ both have bool, true, false keywords.
-  Opts.Bool = Opts.OpenCL || Opts.CPlusPlus;
+  // OpenCL, C++ and C2x have bool, true, false keywords.
+  Opts.Bool = Opts.OpenCL || Opts.CPlusPlus || Opts.C2x;
 
   // OpenCL has half keyword
   Opts.Half = Opts.OpenCL;

diff  --git a/clang/lib/Headers/stdbool.h b/clang/lib/Headers/stdbool.h
index 2525363dd02a5..ecf560218c3b5 100644
--- a/clang/lib/Headers/stdbool.h
+++ b/clang/lib/Headers/stdbool.h
@@ -10,8 +10,13 @@
 #ifndef __STDBOOL_H
 #define __STDBOOL_H
 
-/* Don't define bool, true, and false in C++, except as a GNU extension. */
-#ifndef __cplusplus
+#define __bool_true_false_are_defined 1
+
+#if __STDC_VERSION__ > 201710L
+#if !defined(_CLANG_DISABLE_CRT_DEPRECATION_WARNINGS)
+#warning "the  header is deprecated in C2x"
+#endif /* !defined(_CLANG_DISABLE_CRT_DEPRECATION_WARNINGS) */
+#elif !defined(__cplusplus)
 #define bool _Bool
 #define true 1
 #define false 0
@@ -20,12 +25,10 @@
 #define _Bool bool
 #if __cplusplus < 201103L
 /* For C++98, define bool, false, true as a GNU extension. */
-#define bool  bool
+#define bool bool
 #define false false
-#define true  true
+#define true true
 #endif
 #endif
 
-#define __bool_true_false_are_defined 1
-
 #endif /* __STDBOOL_H */

diff  --git a/clang/test/Headers/stdbool.c b/clang/test/Headers/stdbool.c
new file mode 100644
index 0..1ac94dc67a28f
--- /dev/null
+++ b/clang/test/Headers/stdbool.c
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -fgnuc-version=4.2.1 -std=c11 -E -dM %s 2>&1 | FileCheck 
--check-prefix=CHECK-C11 %s
+// RUN: %clang_cc1 -fgnuc-version=4.2.1 -std=c2x -E -dM %s 2>&1 | FileCheck 
--check-prefix=CHECK-C2X %s
+// RUN: %clang_cc1 -fgnuc-version=4.2.1 -std=c2x -E -dM 
-D_CLANG_DISABLE_CRT_DEPRECATION_WARNINGS %s 2>&1 | FileCheck 
--check-prefix=CHECK-C2X-CRT %s
+
+#include 
+
+// CHECK-C11: #define bool _Bool
+// CHECK-C11: #define false 0
+// CHECK-C11: #define true 1
+
+// CHECK-C2X: warning "the  header is deprecated
+// CHECK-C2X-NOT: #define bool
+// CHECK-C2X-NOT: #define true
+// CHECK-C2X-NOT: #define falsea
+
+// CHECK-C2X-CRT-NOT: warning "the  header is deprecated
+// CHECK-C2X-CRT-NOT: #define bool
+// CHECK-C2X-CRT-NOT: #define true
+// CHECK-C2X-CRT-NOT: #define false

diff  --git a/clang/test/Sema/c2x-bool.c b/clang/test/Sema/c2x-bool.c
new file mode 100644
index 0..0bc147228fda4
--- /dev/null
+++ b/clang/test/Sema/c2x-bool.c
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -std=c2x -fsyntax-only -verify %s
+
+_Static_assert(_Generic(true, _Bool : 1, default: 0));
+_Static_assert(_Generic(false, _Bool : 1, default: 0));
+
+_Static_assert(_Generic(true, bool : 1, default: 0));
+_Static_assert(_Generic(false, bool : 1, default: 0));
+
+_Static_assert(_Generic(true, bool : true, default: false));
+_Static_assert(_Generic(false, bool : true, default: false));
+
+_Static_assert(true == (bool)+1);
+_Static_assert(false == (bool)+0);
+
+_Static_assert(_Generic(+true, bool : 0, unsigned int : 0, signed int : 1, 
default : 0));
+
+struct S {
+  bool b : 1;
+} s;
+_Static_assert(_Generic(+s.b, bool : 0, unsigned int : 0, signed int : 1, 
default : 0));
+
+static void *f = false; // expected-warning {{to null from a constant boolean 
expression}}

[PATCH] D119609: [Clang][Sema] Prohibit expression statement in lambda default argument

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

The commit message isn't quite accurate, we're prohibiting it in ALL default 
arguments.

>> I just realized that something is not very clear here. Should we prohibit 
>> expression statements in all default arguments or just in lambda and 
>> templates? I wonder how gcc folks think about it as well.

The latest patch was to prohibit it ONLY in the lambda default parameters, but 
I though the discussion on the GCC bug had the patch author show preference for 
all cases.  Can you please ping the thread to see what they plan to do so we 
can align?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119609

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


[PATCH] D120296: [Attr] Fix a btf_type_tag AST generation bug

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

1 comment, otherwise LGTM.  I'd like @aaron.ballman to take a look once you've 
got the attribute transforming as well though.




Comment at: clang/lib/Sema/TreeTransform.h:6876
+
+  BTFTypeTagAttr *Attr = oldType->getAttr();
+  QualType result = TL.getType();

The attribute needs to be transformed as well.  This should basically be a 'no 
op', but we need to do so in case we end up using 'treetransform' for something 
like a 'clone a node' type thing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120296

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


[PATCH] D121286: [clangd] Test against path insensitivity

2022-03-09 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet created this revision.
Herald added subscribers: usaxena95, arphaman.
Herald added a project: All.
kadircet requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121286

Files:
  clang-tools-extra/clangd/HeaderSourceSwitch.cpp
  clang-tools-extra/clangd/unittests/TestFS.cpp


Index: clang-tools-extra/clangd/unittests/TestFS.cpp
===
--- clang-tools-extra/clangd/unittests/TestFS.cpp
+++ clang-tools-extra/clangd/unittests/TestFS.cpp
@@ -73,7 +73,11 @@
 
 const char *testRoot() {
 #ifdef _WIN32
-  return "C:\\clangd-test";
+  // On windows paths are insensitive, simulate that behaviour by toggling
+  // capitalization for drive-letter on each call.
+  static bool CallParity = false;
+  CallParity = !CallParity;
+  return CallParity ? "C:\\clangd-test" : "c:\\clangd-test";
 #else
   return "/clangd-test";
 #endif
Index: clang-tools-extra/clangd/HeaderSourceSwitch.cpp
===
--- clang-tools-extra/clangd/HeaderSourceSwitch.cpp
+++ clang-tools-extra/clangd/HeaderSourceSwitch.cpp
@@ -11,6 +11,7 @@
 #include "SourceCode.h"
 #include "index/SymbolCollector.h"
 #include "support/Logger.h"
+#include "support/Path.h"
 #include "clang/AST/Decl.h"
 
 namespace clang {
@@ -82,7 +83,7 @@
   llvm::StringMap Candidates; // Target path => score.
   auto AwardTarget = [&](const char *TargetURI) {
 if (auto TargetPath = URI::resolve(TargetURI, OriginalFile)) {
-  if (*TargetPath != OriginalFile) // exclude the original file.
+  if (!pathEqual(*TargetPath, OriginalFile)) // exclude the original file.
 ++Candidates[*TargetPath];
 } else {
   elog("Failed to resolve URI {0}: {1}", TargetURI, 
TargetPath.takeError());


Index: clang-tools-extra/clangd/unittests/TestFS.cpp
===
--- clang-tools-extra/clangd/unittests/TestFS.cpp
+++ clang-tools-extra/clangd/unittests/TestFS.cpp
@@ -73,7 +73,11 @@
 
 const char *testRoot() {
 #ifdef _WIN32
-  return "C:\\clangd-test";
+  // On windows paths are insensitive, simulate that behaviour by toggling
+  // capitalization for drive-letter on each call.
+  static bool CallParity = false;
+  CallParity = !CallParity;
+  return CallParity ? "C:\\clangd-test" : "c:\\clangd-test";
 #else
   return "/clangd-test";
 #endif
Index: clang-tools-extra/clangd/HeaderSourceSwitch.cpp
===
--- clang-tools-extra/clangd/HeaderSourceSwitch.cpp
+++ clang-tools-extra/clangd/HeaderSourceSwitch.cpp
@@ -11,6 +11,7 @@
 #include "SourceCode.h"
 #include "index/SymbolCollector.h"
 #include "support/Logger.h"
+#include "support/Path.h"
 #include "clang/AST/Decl.h"
 
 namespace clang {
@@ -82,7 +83,7 @@
   llvm::StringMap Candidates; // Target path => score.
   auto AwardTarget = [&](const char *TargetURI) {
 if (auto TargetPath = URI::resolve(TargetURI, OriginalFile)) {
-  if (*TargetPath != OriginalFile) // exclude the original file.
+  if (!pathEqual(*TargetPath, OriginalFile)) // exclude the original file.
 ++Candidates[*TargetPath];
 } else {
   elog("Failed to resolve URI {0}: {1}", TargetURI, TargetPath.takeError());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D120936: [Sema][Windows] Don't special-case void* in __unaligned conversions.

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

This looks fine to me, though we should wait for @rnk to decide whether the 
warning is sufficient for him.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120936

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


[PATCH] D121119: [clang][SVE] Add support for bitwise operators on SVE types

2022-03-09 Thread Peter Waller via Phabricator via cfe-commits
peterwaller-arm added a comment.

Looking reasonable to me, one comment.




Comment at: clang/lib/Sema/SemaExpr.cpp:10404
+   SourceLocation Loc,
+   bool IsArithmetic) {
   QualType LHSType = LHS.get()->getType().getUnqualifiedType();

There is a saying that booleans are often inferior to enums in arguments. I 
think this might be one of those cases, could you use the `enum ArithConvKind` 
instead?

As a side effect call sites will be clear without the need for a comment string:
```
CheckSizelessVectorOperands(LHS, RHS, Loc, ACK_Arithmetic);
```

... and it will be extensible to other kinds, which I presume are likely to 
creep in here as more operators are added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121119

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


[PATCH] D121233: [pseudo] Move pseudoparser from clang to clang-tools-extra

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

In D121233#3369736 , @sammccall wrote:

> In D121233#3369657 , @aaron.ballman 
> wrote:
>
>> Thank you for working on this! I have a few thoughts on the renaming, but 
>> otherwise strongly support the direction here.
>>
>>> clang/lib/Tooling/Syntax/Pseudo/*   => 
>>> clang-tools-extra/pseudo/lib/*
>>
>> The usual naming conventions in clang-tools-extra is to use the tool name as 
>> the folder it goes in. Based on that, should the folders be 
>> `clang-tools-extra/clang-pseudo/` instead of `clang-tools-extra/pseudo/`?
>
> I don't think it's a good naming convention, and am not convinced consistency 
> here is important enough to propagate a bad idea further.

It's the convention we currently use and I don't think we should deviate from 
it as a one-off; that only adds confusion, especially once others go to add 
another project and try to use existing projects as a pattern.

> We're in a directory called "clang-tools-extra", so the clang- prefix is 
> redundant in the path (not in the binary name).
> It seems like a small thing, but it adds up: the `clang-tools-extra` 
> directory is ugly, so are `lib` and `include/clang-pseudo`, so is having both 
> `llvm` and `llvm-project` because of the monorepo.
> We have a file named 
> `llvm/llvm-project/llvm/include/llvm/Support/InitLLVM.h`! People working with 
> this code type these paths often.

I don't disagree with these points, FWIW. :-)

> (If it helps, I'd be happy to prepare changes to drop the `clang-` prefixes 
> from any of the directories where they seem obviously redundant - everything 
> except `clang-doc` and `clangd`. But I think the much larger burden of 
> establishing consensus needs to fall on people who think that consistency is 
> worth enforcing here).

The status quo is that we try to be consistent unless there's a compelling 
reason not to, so I disagree; the onus is on you as to why this is a special 
snowflake that deserves to be inconsistent with everything else in the project. 
My suggestion to move forward is: rename to be consistent in this patch so we 
can land it, then put up an RFC to rename all of the directories in 
clang-tools-extra at once so that we stay consistent (there's a wee bit extra 
churn from that, but it means we don't hold up this patch debating directory 
names). I'd support such an RFC, but I wouldn't support introducing 
inconsistency here; the rationale for deviation isn't nearly compelling enough 
to me. Also, because it's an NFC change, I think the RFC is effectively "does 
someone have a blocking concern that I need to address first, otherwise the NFC 
change will go in now". It's not so much an RFC as a heads up that the change 
is coming in case downstreams need to react to it early.

>>> clang/include/clang/Tooling/Syntax/Pseudo/* => 
>>> clang-tools-extra/pseudo/include/clang-pseudo/*
>>> clang/tools/clang/pseudo/*  => 
>>> clang-tools-extra/pseudo/tool/*
>>> clang/test/Syntax/* => 
>>> clang-tools-extra/pseudo/test/*
>>
>> The convention are for clang-tools-extra tests to live in 
>> `clang-tools-extra/test/` (clangd is using the style you propose here 
>> when it probably should have followed the existing conventions).
>
> We used this layout for several years, and it was painful to navigate and 
> maintain, so it was deliberately changed in 
> b804eef09052cf40e79aa2ed8a23f2f39e2dda1b at which point all the pain went 
> away.

And introduced new pain for others when you did so -- I went looking for the 
clangd tests and it took me a while to figure out that project deviated.

> Again, I'd be willing to work on improving this, but I don't want to spend 
> weeks arguing with people about it. My experience is that these conversations 
> are exhausting, negative because people are grumpy about dealing with churn, 
> and in the end there's nobody empowered to say "OK, this is a good idea". See 
> also the idea of using a separate bugtracker, website infra etc for clangd, 
> where all the feedback was extremely negative, it was very difficult to 
> decide to proceed anyway, and these turned out to be large improvements and 
> none of the warnings came true.

Understandable. FWIW, I'd also be fine switching things around so that the test 
directory is with the tool for all tools (I'd see this as the same kind of NFC 
change as above). What I'm not fine with is one tool deciding they're special 
and don't need to be consistent with the rest of the project. These sorts of 
inconsistencies rarely cause pain for the people who introduce them, but they 
do cause pain for others who are working on the project as a whole instead of 
just one tool. As an example of the pain caused by clangd -- not everyone runs 
tests using a check target. Some folks use python to execute tests directly, 
and they expect that `python llvm-lit.sv -sv 

[PATCH] D121214: [clang-tidy][docs][NFC] Add alias cert-mem51-cpp to bugprone-shared-ptr-array-mismatch

2022-03-09 Thread Whisperity via Phabricator via cfe-commits
whisperity added a comment.

I have some concerns about this. While it is now clear to me that the 
//partial//ness refers to partial coverage of the guideline rule, it is indeed 
very, very partial. **MEM51-CPP** as of now lists **9** cases of non-compliant 
examples, from which `std::shared_ptr = new S[8];` is just //one//. 
`bugprone-shared-ptr-array-mismatch` (D117306 
) in itself is a check that inherits from a 
"more generic" smart pointer check.

Right now, there is no check for the exact same `unique_ptr` case, which the 
linked CERT site explicitly phrases:

> As with std::unique_ptr, when the std::shared_ptr is destroyed [...]

Let's suppose a `bugprone-unique-ptr-array-mismatch` check is also created 
(even though that would mean immediately that the naming of the `shared_ptr` 
one is kind of bad and that we should rename or deprecate the check... which is 
its own can of worms with regards to support of clients...). What will this 
alias become, then?

At first re-read my recent comment of

In D121214#3367609 , @whisperity 
wrote:

> Is "partial aliasing" a new notion?

sounded weird to me too, but thinking this through again, I think I know what I 
was thinking yesterday.

Please correct me if I'm wrong, but the "name" of a check (alias or not) is a 
**unique** property. We lack the infrastructure support for `1:N` aliasing. 
While there are certainly cases where we only managed to partially cover a 
rule, and made an alias for it, missing a small chunk of the guideline (e.g. 
because static analyses can't catch such) looks less intrusive than -- 
essentially -- //"trying to sell 1/9 coverage as **the** alias"//.




Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-mem51-cpp.rst:12
+
+Please note that the check only partially covers the corresponding CERT rule.

//Maybe// this warning could be emphasised with the appropriate RST entity, but 
a quick grep of Tidy docs turned up no such similar constructs so maybe it is 
better if we do not break form here...




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

https://reviews.llvm.org/D121214

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


[PATCH] D121285: [clang][dataflow] Move dataflow testing support out of unittests

2022-03-09 Thread Stanislav Gatev via Phabricator via cfe-commits
sgatev updated this revision to Diff 414074.
sgatev added a comment.

Update top level comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121285

Files:
  clang/include/clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h
  clang/lib/Analysis/FlowSensitive/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/Testing/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/Testing/DataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp
  clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
  clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
  clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
  clang/unittests/Analysis/FlowSensitive/Testing/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
  clang/unittests/Analysis/FlowSensitive/TestingSupport.cpp
  clang/unittests/Analysis/FlowSensitive/TestingSupport.h
  clang/unittests/Analysis/FlowSensitive/TestingSupportTest.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
  clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -7,7 +7,6 @@
 //===--===//
 
 #include "NoopAnalysis.h"
-#include "TestingSupport.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/ExprCXX.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
@@ -17,6 +16,7 @@
 #include "clang/Analysis/FlowSensitive/DataflowAnalysisContext.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
 #include "clang/Analysis/FlowSensitive/WatchedLiteralsSolver.h"
 #include "clang/Tooling/Tooling.h"
Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -7,13 +7,13 @@
 //===--===//
 
 #include "NoopAnalysis.h"
-#include "TestingSupport.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/StorageLocation.h"
+#include "clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
 #include "clang/Basic/LangStandard.h"
 #include "llvm/ADT/ArrayRef.h"
Index: clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
@@ -1,4 +1,12 @@
-#include "TestingSupport.h"
+//===- DataflowAnalysisTest.cpp ---===//
+//
+// 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 "clang/Analysis/FlowSensitive/Testing/DataflowChecker.h"
 #include "NoopAnalysis.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
Index: clang/unittests/Analysis/FlowSensitive/Testing/CMakeLists.txt
===
--- /dev/null
+++ clang/unittests/Analysis/FlowSensitive/Testing/CMakeLists.txt
@@ -0,0 +1,28 @@
+set(LLVM_LINK_COMPONENTS
+  FrontendOpenMP
+  Support
+  )
+
+add_clang_unittest(ClangAnalysisFlowSensitiveTestingTests
+  DataflowCheckerTest.cpp
+  )
+
+clang_target_link_libraries(ClangAnalysisFlowSensitiveTestingTests
+  PRIVATE
+  clangAnalysis
+  clangAnalysisFlowSensitive
+  clangAnalysisFlowSensitiveTesting
+  clangAST
+  clangASTMatchers
+  clangBasic
+  clangFrontend
+  clangLex
+  clangSerialization
+  clangTesting
+  clangTooling
+  )
+
+target_link_libraries(ClangAnalysisFlowSensitiveTestingTests
+  PRIVATE
+  LLVMTestingSupport
+  )
Index: clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
===
--- 

[PATCH] D121285: [clang][dataflow] Move dataflow testing support out of unittests

2022-03-09 Thread Stanislav Gatev via Phabricator via cfe-commits
sgatev created this revision.
sgatev added reviewers: ymandel, xazax.hun, gribozavr2.
Herald added subscribers: tschuett, steakhal, rnkovacs, mgorny.
Herald added a project: All.
sgatev requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added a subscriber: sstefan1.
Herald added a project: clang.

This enables tests out of clang/unittests/Analysis/FlowSensitive to
use the testing support utilities.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121285

Files:
  clang/include/clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h
  clang/lib/Analysis/FlowSensitive/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/Testing/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/Testing/DataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp
  clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
  clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
  clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
  clang/unittests/Analysis/FlowSensitive/Testing/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
  clang/unittests/Analysis/FlowSensitive/TestingSupport.cpp
  clang/unittests/Analysis/FlowSensitive/TestingSupport.h
  clang/unittests/Analysis/FlowSensitive/TestingSupportTest.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
  clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -7,7 +7,6 @@
 //===--===//
 
 #include "NoopAnalysis.h"
-#include "TestingSupport.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/ExprCXX.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
@@ -17,6 +16,7 @@
 #include "clang/Analysis/FlowSensitive/DataflowAnalysisContext.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
 #include "clang/Analysis/FlowSensitive/WatchedLiteralsSolver.h"
 #include "clang/Tooling/Tooling.h"
Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -7,13 +7,13 @@
 //===--===//
 
 #include "NoopAnalysis.h"
-#include "TestingSupport.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/StorageLocation.h"
+#include "clang/Analysis/FlowSensitive/Testing/DataflowAnalysis.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
 #include "clang/Basic/LangStandard.h"
 #include "llvm/ADT/ArrayRef.h"
Index: clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
@@ -1,4 +1,13 @@
-#include "TestingSupport.h"
+//===- unittests/Analysis/FlowSensitive/Testing/DataflowCheckerTest.cpp
+//---===//
+//
+// 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 "clang/Analysis/FlowSensitive/Testing/DataflowChecker.h"
 #include "NoopAnalysis.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
Index: clang/unittests/Analysis/FlowSensitive/Testing/CMakeLists.txt
===
--- /dev/null
+++ clang/unittests/Analysis/FlowSensitive/Testing/CMakeLists.txt
@@ -0,0 +1,28 @@
+set(LLVM_LINK_COMPONENTS
+  FrontendOpenMP
+  Support
+  )
+
+add_clang_unittest(ClangAnalysisFlowSensitiveTestingTests
+  DataflowCheckerTest.cpp
+  )
+
+clang_target_link_libraries(ClangAnalysisFlowSensitiveTestingTests
+  PRIVATE
+  clangAnalysis
+  clangAnalysisFlowSensitive
+  clangAnalysisFlowSensitiveTesting
+  clangAST
+  clangASTMatchers
+  clangBasic
+  clangFrontend
+  clangLex
+  clangSerialization
+  clangTesting
+  

[PATCH] D121233: [pseudo] Move pseudoparser from clang to clang-tools-extra

2022-03-09 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

In D121233#3369657 , @aaron.ballman 
wrote:

> Thank you for working on this! I have a few thoughts on the renaming, but 
> otherwise strongly support the direction here.
>
>> clang/lib/Tooling/Syntax/Pseudo/*   => clang-tools-extra/pseudo/lib/*
>
> The usual naming conventions in clang-tools-extra is to use the tool name as 
> the folder it goes in. Based on that, should the folders be 
> `clang-tools-extra/clang-pseudo/` instead of `clang-tools-extra/pseudo/`?

I don't think it's a good naming convention, and am not convinced consistency 
here is important enough to propagate a bad idea further.
We're in a directory called "clang-tools-extra", so the clang- prefix is 
redundant in the path (not in the binary name).
It seems like a small thing, but it adds up: the `clang-tools-extra` directory 
is ugly, so are `lib` and `include/clang-pseudo`, so is having both `llvm` and 
`llvm-project` because of the monorepo.
We have a file named `llvm/llvm-project/llvm/include/llvm/Support/InitLLVM.h`! 
People working with this code type these paths often.

(If it helps, I'd be happy to prepare changes to drop the `clang-` prefixes 
from any of the directories where they seem obviously redundant - everything 
except `clang-doc` and `clangd`. But I think the much larger burden of 
establishing consensus needs to fall on people who think that consistency is 
worth enforcing here).

>> clang/include/clang/Tooling/Syntax/Pseudo/* => 
>> clang-tools-extra/pseudo/include/clang-pseudo/*
>> clang/tools/clang/pseudo/*  => 
>> clang-tools-extra/pseudo/tool/*
>> clang/test/Syntax/* => 
>> clang-tools-extra/pseudo/test/*
>
> The convention are for clang-tools-extra tests to live in 
> `clang-tools-extra/test/` (clangd is using the style you propose here 
> when it probably should have followed the existing conventions).

We used this layout for several years, and it was painful to navigate and 
maintain, so it was deliberately changed in 
b804eef09052cf40e79aa2ed8a23f2f39e2dda1b at which point all the pain went away.

Again, I'd be willing to work on improving this, but I don't want to spend 
weeks arguing with people about it. My experience is that these conversations 
are exhausting, negative because people are grumpy about dealing with churn, 
and in the end there's nobody empowered to say "OK, this is a good idea". See 
also the idea of using a separate bugtracker, website infra etc for clangd, 
where all the feedback was extremely negative, it was very difficult to decide 
to proceed anyway, and these turned out to be large improvements and none of 
the warnings came true.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121233

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


[PATCH] D121214: [clang-tidy][docs][NFC] Add alias cert-mem51-cpp to bugprone-shared-ptr-array-mismatch

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

Nit: This is not an NFC change


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

https://reviews.llvm.org/D121214

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


[PATCH] D120824: [clang][ASTImporter] Fix a bug when importing CXXDefaultInitExpr.

2022-03-09 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

In D120824#3369563 , @balazske wrote:

> 



> I think that the problem may be related to the fact that the in-class 
> initializer is not used by the code in the "To" AST (in 
> //ctu-cxxdefaultinitexpr.cpp// the problem is with `QMultiHash::d` field). 
> Probably the expression node in the field is set only if it is used by any 
> `CXXDefaultInitExpr`, but the `hasInClassInitializer` value is set always if 
> the code contains in-class initializer. I can try to make a unit test for 
> this case ...

Thanks, that'd be great.

> ... (but the lit test is good to have because it is more complex and can 
> reveal other problems).

I agree.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120824

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


[PATCH] D107141: [Inline-asm] Add diagnosts for unsupported inline assembly arguments

2022-03-09 Thread Phoebe Wang via Phabricator via cfe-commits
pengfei added a comment.

Ping @jyu2


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107141

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


[PATCH] D121283: [Clang] Support multiple attributes in a single pragma

2022-03-09 Thread Egor Zhdan via Phabricator via cfe-commits
egorzhdan updated this revision to Diff 414068.
egorzhdan added a comment.

Remove unused include


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121283

Files:
  clang/include/clang/Basic/AttrSubjectMatchRules.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParsePragma.cpp
  clang/test/AST/pragma-multiple-attributes-declspec.cpp
  clang/test/AST/pragma-multiple-attributes.cpp
  clang/test/FixIt/fixit-pragma-attribute.c
  clang/test/FixIt/fixit-pragma-attribute.cpp
  clang/test/Parser/pragma-attribute-declspec.cpp
  clang/test/Parser/pragma-attribute.cpp
  clang/test/Parser/pragma-multiple-attributes.cpp

Index: clang/test/Parser/pragma-multiple-attributes.cpp
===
--- /dev/null
+++ clang/test/Parser/pragma-multiple-attributes.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -Wno-pragma-clang-attribute -verify %s
+
+#pragma clang attribute push ([[clang::disable_tail_calls, noreturn]], apply_to = function)
+#pragma clang attribute pop
+
+#pragma clang attribute push ([[clang::disable_tail_calls]] __attribute__((annotate("test"))), apply_to = function)
+#pragma clang attribute pop
+
+#pragma clang attribute push (__attribute__((disable_tail_calls)) __attribute__((annotate("test"))), apply_to = function)
+#pragma clang attribute pop
+
+#pragma clang attribute push ([[clang::disable_tail_calls, noreturn]]) // expected-error {{expected ','}}
+
+#pragma clang attribute push (test [[noreturn]]) // expected-error {{expected an attribute that is specified using the GNU, C++11 or '__declspec' syntax}}
+
+#pragma clang attribute push ([[noreturn]] test) // expected-error {{expected ',' or an attribute that is specified using the GNU, C++11 or '__declspec' syntax}}
Index: clang/test/Parser/pragma-attribute.cpp
===
--- clang/test/Parser/pragma-attribute.cpp
+++ clang/test/Parser/pragma-attribute.cpp
@@ -154,9 +154,6 @@
 #pragma clang attribute push ([[gnu::abi_tag]], apply_to=any(function))
 #pragma clang attribute pop
 
-#pragma clang attribute push ([[clang::disable_tail_calls, noreturn]], apply_to = function) // expected-error {{more than one attribute specified in '#pragma clang attribute push'}}
-#pragma clang attribute push ([[clang::disable_tail_calls, noreturn]]) // expected-error {{more than one attribute specified in '#pragma clang attribute push'}}
-
 #pragma clang attribute push ([[gnu::abi_tag]], apply_to=namespace)
 #pragma clang attribute pop
 
Index: clang/test/Parser/pragma-attribute-declspec.cpp
===
--- clang/test/Parser/pragma-attribute-declspec.cpp
+++ clang/test/Parser/pragma-attribute-declspec.cpp
@@ -6,7 +6,8 @@
 
 #pragma clang attribute pop
 
-#pragma clang attribute push(__declspec(dllexport, dllimport), apply_to = function) // expected-error {{more than one attribute specified in '#pragma clang attribute push'}}
+#pragma clang attribute push(__declspec(dllexport, dllimport), apply_to = function)
+#pragma clang attribute pop
 
 #pragma clang attribute push(__declspec(align), apply_to = variable) // expected-error {{attribute 'align' is not supported by '#pragma clang attribute'}}
 
Index: clang/test/FixIt/fixit-pragma-attribute.cpp
===
--- clang/test/FixIt/fixit-pragma-attribute.cpp
+++ clang/test/FixIt/fixit-pragma-attribute.cpp
@@ -39,7 +39,7 @@
 #pragma clang attribute pop
 
 #pragma clang attribute push (__attribute__((abi_tag("a"
-// CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:60}:", apply_to = any(record(unless(is_union)), variable, function, namespace)"
+// CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:60}:", apply_to = any(function, namespace, record(unless(is_union)), variable)"
 #pragma clang attribute push (__attribute__((abi_tag("a"))) apply_to=function)
 // CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:60}:", "
 #pragma clang attribute push (__attribute__((abi_tag("a"))) = function)
@@ -48,35 +48,33 @@
 // CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:60}:", apply_to = "
 
 #pragma clang attribute push (__attribute__((abi_tag("a"))) 22)
-// CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:63}:", apply_to = any(record(unless(is_union)), variable, function, namespace)"
-#pragma clang attribute push (__attribute__((abi_tag("a"))) function)
-// CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:69}:", apply_to = any(record(unless(is_union)), variable, function, namespace)"
+// CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:63}:", apply_to = any(function, namespace, record(unless(is_union)), variable)"
 #pragma clang attribute push (__attribute__((abi_tag("a"))) (function))
-// CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:71}:", apply_to = any(record(unless(is_union)), variable, 

[PATCH] D121283: [Clang] Support multiple attributes in a single pragma

2022-03-09 Thread Egor Zhdan via Phabricator via cfe-commits
egorzhdan created this revision.
egorzhdan added a reviewer: arphaman.
Herald added a subscriber: jdoerfert.
Herald added a project: All.
egorzhdan requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This adds support for multiple attributes in `#pragma clang attribute push`, 
for example:

  #pragma clang attribute push 
(__attribute__((disable_sanitizer_instrumentation)) 
__attribute__((section("S"))), apply_to=variable(is_global))

or

  #pragma clang attribute push ([[clang::disable_tail_calls, noreturn]], 
apply_to = function)

Related attributes can now be applied with a single pragma, which makes it 
harder for developers to make an accidental error later when editing the code.

rdar://78269653


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121283

Files:
  clang/include/clang/Basic/AttrSubjectMatchRules.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParsePragma.cpp
  clang/test/AST/pragma-multiple-attributes-declspec.cpp
  clang/test/AST/pragma-multiple-attributes.cpp
  clang/test/FixIt/fixit-pragma-attribute.c
  clang/test/FixIt/fixit-pragma-attribute.cpp
  clang/test/Parser/pragma-attribute-declspec.cpp
  clang/test/Parser/pragma-attribute.cpp
  clang/test/Parser/pragma-multiple-attributes.cpp

Index: clang/test/Parser/pragma-multiple-attributes.cpp
===
--- /dev/null
+++ clang/test/Parser/pragma-multiple-attributes.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -Wno-pragma-clang-attribute -verify %s
+
+#pragma clang attribute push ([[clang::disable_tail_calls, noreturn]], apply_to = function)
+#pragma clang attribute pop
+
+#pragma clang attribute push ([[clang::disable_tail_calls]] __attribute__((annotate("test"))), apply_to = function)
+#pragma clang attribute pop
+
+#pragma clang attribute push (__attribute__((disable_tail_calls)) __attribute__((annotate("test"))), apply_to = function)
+#pragma clang attribute pop
+
+#pragma clang attribute push ([[clang::disable_tail_calls, noreturn]]) // expected-error {{expected ','}}
+
+#pragma clang attribute push (test [[noreturn]]) // expected-error {{expected an attribute that is specified using the GNU, C++11 or '__declspec' syntax}}
+
+#pragma clang attribute push ([[noreturn]] test) // expected-error {{expected ',' or an attribute that is specified using the GNU, C++11 or '__declspec' syntax}}
Index: clang/test/Parser/pragma-attribute.cpp
===
--- clang/test/Parser/pragma-attribute.cpp
+++ clang/test/Parser/pragma-attribute.cpp
@@ -154,9 +154,6 @@
 #pragma clang attribute push ([[gnu::abi_tag]], apply_to=any(function))
 #pragma clang attribute pop
 
-#pragma clang attribute push ([[clang::disable_tail_calls, noreturn]], apply_to = function) // expected-error {{more than one attribute specified in '#pragma clang attribute push'}}
-#pragma clang attribute push ([[clang::disable_tail_calls, noreturn]]) // expected-error {{more than one attribute specified in '#pragma clang attribute push'}}
-
 #pragma clang attribute push ([[gnu::abi_tag]], apply_to=namespace)
 #pragma clang attribute pop
 
Index: clang/test/Parser/pragma-attribute-declspec.cpp
===
--- clang/test/Parser/pragma-attribute-declspec.cpp
+++ clang/test/Parser/pragma-attribute-declspec.cpp
@@ -6,7 +6,8 @@
 
 #pragma clang attribute pop
 
-#pragma clang attribute push(__declspec(dllexport, dllimport), apply_to = function) // expected-error {{more than one attribute specified in '#pragma clang attribute push'}}
+#pragma clang attribute push(__declspec(dllexport, dllimport), apply_to = function)
+#pragma clang attribute pop
 
 #pragma clang attribute push(__declspec(align), apply_to = variable) // expected-error {{attribute 'align' is not supported by '#pragma clang attribute'}}
 
Index: clang/test/FixIt/fixit-pragma-attribute.cpp
===
--- clang/test/FixIt/fixit-pragma-attribute.cpp
+++ clang/test/FixIt/fixit-pragma-attribute.cpp
@@ -39,7 +39,7 @@
 #pragma clang attribute pop
 
 #pragma clang attribute push (__attribute__((abi_tag("a"
-// CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:60}:", apply_to = any(record(unless(is_union)), variable, function, namespace)"
+// CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:60}:", apply_to = any(function, namespace, record(unless(is_union)), variable)"
 #pragma clang attribute push (__attribute__((abi_tag("a"))) apply_to=function)
 // CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:60}:", "
 #pragma clang attribute push (__attribute__((abi_tag("a"))) = function)
@@ -48,35 +48,33 @@
 // CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:60}:", apply_to = "
 
 #pragma clang attribute push (__attribute__((abi_tag("a"))) 22)
-// CHECK: 

[PATCH] D121214: [clang-tidy][docs][NFC] Add alias cert-mem51-cpp to bugprone-shared-ptr-array-mismatch

2022-03-09 Thread Balázs Benics via Phabricator via cfe-commits
steakhal updated this revision to Diff 414065.
steakhal added a comment.
Herald added a subscriber: carlosgalvezp.

Register the checker with the alias name :D


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

https://reviews.llvm.org/D121214

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-shared-ptr-array-mismatch.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-mem51-cpp.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst


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
@@ -350,6 +350,7 @@
`cert-exp42-c `_, `bugprone-suspicious-memory-comparison 
`_,
`cert-fio38-c `_, `misc-non-copyable-objects 
`_,
`cert-flp37-c `_, `bugprone-suspicious-memory-comparison 
`_,
+   `cert-mem51-cpp `_, 
`bugprone-shared-ptr-array-mismatch 
`_, "Yes"
`cert-msc30-c `_, `cert-msc50-cpp 
`_,
`cert-msc32-c `_, `cert-msc51-cpp 
`_,
`cert-oop11-cpp `_, `performance-move-constructor-init 
`_,
Index: clang-tools-extra/docs/clang-tidy/checks/cert-mem51-cpp.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/cert-mem51-cpp.rst
@@ -0,0 +1,12 @@
+.. title:: clang-tidy - cert-mem51-cpp
+.. meta::
+   :http-equiv=refresh: 5;URL=bugprone-shared-ptr-array-mismatch.html
+
+cert-mem51-cpp
+==
+
+The cert-mem51-cpp check is an alias, please see
+`bugprone-shared-ptr-array-mismatch `_
+for more information.
+
+Please note that the check only partially covers the corresponding CERT rule.
Index: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-shared-ptr-array-mismatch.rst
===
--- 
clang-tools-extra/docs/clang-tidy/checks/bugprone-shared-ptr-array-mismatch.rst
+++ 
clang-tools-extra/docs/clang-tidy/checks/bugprone-shared-ptr-array-mismatch.rst
@@ -29,3 +29,8 @@
 std::shared_ptr x(new Foo[10]); // no replacement in this case
 // ^ warning: shared pointer to non-array is 
initialized with array [bugprone-shared-ptr-array-mismatch]
   };
+
+This check corresponds to the CERT C++ Coding Standard rule
+`MEM51-CPP. Properly deallocate dynamically allocated resources
+`_
+rule, but only partially implements it.
Index: clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
===
--- clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
+++ clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
@@ -11,6 +11,7 @@
 #include "../ClangTidyModuleRegistry.h"
 #include "../bugprone/BadSignalToKillThreadCheck.h"
 #include "../bugprone/ReservedIdentifierCheck.h"
+#include "../bugprone/SharedPtrArrayMismatchCheck.h"
 #include "../bugprone/SignalHandlerCheck.h"
 #include "../bugprone/SignedCharMisuseCheck.h"
 #include "../bugprone/SpuriouslyWakeUpFunctionsCheck.h"
@@ -300,6 +301,9 @@
 "cert-flp37-c");
 // FIO
 
CheckFactories.registerCheck("cert-fio38-c");
+// MEM
+CheckFactories.registerCheck(
+"cert-mem51-cpp");
 // MSC
 CheckFactories.registerCheck("cert-msc30-c");
 CheckFactories.registerCheck(


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
@@ -350,6 +350,7 @@
`cert-exp42-c `_, `bugprone-suspicious-memory-comparison `_,
`cert-fio38-c `_, `misc-non-copyable-objects `_,
`cert-flp37-c `_, `bugprone-suspicious-memory-comparison `_,
+   `cert-mem51-cpp `_, `bugprone-shared-ptr-array-mismatch `_, "Yes"
`cert-msc30-c `_, `cert-msc50-cpp `_,
`cert-msc32-c `_, `cert-msc51-cpp `_,
`cert-oop11-cpp `_, `performance-move-constructor-init `_,
Index: clang-tools-extra/docs/clang-tidy/checks/cert-mem51-cpp.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/cert-mem51-cpp.rst
@@ -0,0 +1,12 @@
+.. title:: clang-tidy - cert-mem51-cpp
+.. meta::
+   :http-equiv=refresh: 5;URL=bugprone-shared-ptr-array-mismatch.html
+
+cert-mem51-cpp
+==
+
+The cert-mem51-cpp check is an alias, please see
+`bugprone-shared-ptr-array-mismatch `_
+for more information.
+
+Please note that the check only partially covers the corresponding CERT rule.
Index: clang-tools-extra/docs/clang-tidy/checks/bugprone-shared-ptr-array-mismatch.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone-shared-ptr-array-mismatch.rst
+++ 

[PATCH] D120244: [clang][sema] Enable first-class bool support for C2x

2022-03-09 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!




Comment at: clang/test/Headers/stdbool.c:2
+// RUN: %clang_cc1 -fgnuc-version=4.2.1 -std=c11 -E -dM %s 2>&1 | FileCheck 
--check-prefix=CHECK-C11 %s
+// RUN: %clang_cc1 -fgnuc-version=4.2.1 -std=c2x -E -dM %s 2>&1 | FileCheck 
--check-prefix=CHECK-C2X %s
+

tbaeder wrote:
> aaron.ballman wrote:
> > If you're playing along at home, `stdbool.cpp` tests the C++ behavior, so 
> > we don't need an additional RUN line here for that.
> > 
> > However, I'd appreciate a RUN line that defines 
> > `_CLANG_DISABLE_CRT_DEPRECATION_WARNINGS` to demonstrate we don't emit the 
> > warning or the defines in that case.
> I don't understand, both of the `RUN` lines are for C.
> I don't understand, both of the RUN lines are for C.

An earlier form of your patch broke the behavior in C++ and I didn't recall if 
the precommit CI pipeline caught the failure or not. So I thought "hmm, should 
we have a C++ RUN line here to catch that break or do we already have test 
coverage?" It turns out we have existing coverage, so I was reporting that so 
other reviewers (including drive-by reviews) knew we already thought about that.

Thanks for adding the other RUN line for the macro definition!


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

https://reviews.llvm.org/D120244

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


[PATCH] D121233: [pseudo] Move pseudoparser from clang to clang-tools-extra

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

Thank you for working on this! I have a few thoughts on the renaming, but 
otherwise strongly support the direction here.

> clang/lib/Tooling/Syntax/Pseudo/*   => clang-tools-extra/pseudo/lib/*

The usual naming conventions in clang-tools-extra is to use the tool name as 
the folder it goes in. Based on that, should the folders be 
`clang-tools-extra/clang-pseudo/` instead of `clang-tools-extra/pseudo/`?

> clang/include/clang/Tooling/Syntax/Pseudo/* => 
> clang-tools-extra/pseudo/include/clang-pseudo/*
> clang/tools/clang/pseudo/*  => clang-tools-extra/pseudo/tool/*
> clang/test/Syntax/* => clang-tools-extra/pseudo/test/*

The convention are for clang-tools-extra tests to live in 
`clang-tools-extra/test/` (clangd is using the style you propose here 
when it probably should have followed the existing conventions).

> clang/unittests/Tooling/Syntax/Pseudo/* => 
> clang-tools-extra/pseudo/unittests/*
> #include "clang/Tooling/Syntax/Pseudo/*"=> #include "clang-pseudo/*"
> namespace clang::syntax::pseudo => namespace clang::pseudo
> check-clang => check-clang-pseudo
> clangToolingSyntaxPseudo=> clangPseudo




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121233

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


[PATCH] D121078: Replace links to archived mailing lists by links to Discourse forums

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

In D121078#3368424 , @tonic wrote:

> In D121078#3367950 , @aaron.ballman 
> wrote:
>
>> I've added comments to the few places I'd like to see a change, which 
>> hopefully makes my request more clear. I am carefully trying to avoid adding 
>> this extra information to the places we're documenting people to go for 
>> discussion; I think those should continue to only point to Discourse. But 
>> the places where we have quick links for more useful information are where I 
>> think we should retain some unobtrusive mention of the complete archives.
>
> Without going through every single comment here (which is not to dismiss 
> them, but I am not sure its helpful to respond to each one as I think we both 
> want to work towards a resolution), I will propose an alternative solution 
> that I hope has some common ground and addresses both of our concerns.
>
> I hear you are concerned about is:
>
> - The archives may be missing information and therefore someone will not find 
> the information they are looking for. You would like some reference to the 
> archives to exist.
>
> (You can correct me of I am wrong)

You have the gist of it -- I'd like some "official" place where we make it 
clear that these archives exist and are "ours" (as opposed to some third-party 
scraping service that exposes the messages while extracting ad revenue and 
perhaps modifying link targets for tracking, etc).

> I am concerned about:
>
> - Where communication happens and where to find past communication to be 
> confusing to newcomers
> - Creating more work in the future to remove more references to the mailing 
> lists that have moved to discourse.  It is a lot of work to keep 
> documentation up to date, so the fewer spots we have outdated information, 
> the better.
> - Creating new patterns of behavior to use Discourse as the first reference 
> versus the mailing list archives

I think all of these are important concerns.

> I would propose that we add information to Discourse that informs users of 
> the migration issue we are working through and that *if* they encounter a 
> topic that seems incomplete, that they can cross reference with the mailing 
> list archives. This can be added to the banner that is displayed when users 
> join Discourse until we decide it is no longer needed or it can be added in 
> the FAQ/About or as an stand alone announcement on the forum itself.
>
> I believe this solution will meet both our needs. Please let me know what you 
> think.

Thank you for suggesting this!

This adds an extra level of indirection from putting the information in our 
docs, but I think that's a reasonable compromise. I'd like to avoid adding it 
to the FAQ if possible because I'm not certain people will think to look there 
if they find something that looks incomplete on Discourse. Adding it to the 
banner would certainly work, but might feel like we're advertising it a bit TOO 
much at that point. Perhaps a pinned post in just the forums that replace a 
mailing list? That is a bit more work when we decide the information is no 
longer needed, but maybe it strikes a reasonable balance?

Either way, I'm happy enough with *something* along the lines you propose here. 
Based on that, I don't think further changes are needed on this patch, so it 
LGTM. Thank you for your patience @SimplyDanny while we worked these details 
out, and thank you again for updating the docs!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121078

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


[clang] d258196 - [clang] ScalarExprEmitter::VisitCastExpr - use castAs<> instead of getAs<> to avoid dereference of nullptr

2022-03-09 Thread Simon Pilgrim via cfe-commits

Author: Simon Pilgrim
Date: 2022-03-09T11:40:37Z
New Revision: d258196f5fddf510e785be68da803d5feae56855

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

LOG: [clang] ScalarExprEmitter::VisitCastExpr - use castAs<> instead of getAs<> 
to avoid dereference of nullptr

The pointers are always dereferenced, so assert the cast is correct instead of 
returning nullptr

Added: 


Modified: 
clang/lib/CodeGen/CGExprScalar.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGExprScalar.cpp 
b/clang/lib/CodeGen/CGExprScalar.cpp
index 93fb7d37c3445..f0692a2266b74 100644
--- a/clang/lib/CodeGen/CGExprScalar.cpp
+++ b/clang/lib/CodeGen/CGExprScalar.cpp
@@ -2039,12 +2039,12 @@ Value *ScalarExprEmitter::VisitCastExpr(CastExpr *CE) {
 }
 
 if (CGF.SanOpts.has(SanitizerKind::CFIUnrelatedCast)) {
-  if (auto PT = DestTy->getAs()) {
+  if (auto *PT = DestTy->getAs()) {
 CGF.EmitVTablePtrCheckForCast(
 PT->getPointeeType(),
 Address(Src,
 CGF.ConvertTypeForMem(
-E->getType()->getAs()->getPointeeType()),
+E->getType()->castAs()->getPointeeType()),
 CGF.getPointerAlign()),
 /*MayBeNull=*/true, CodeGenFunction::CFITCK_UnrelatedCast,
 CE->getBeginLoc());
@@ -2948,8 +2948,8 @@ Value *ScalarExprEmitter::VisitOffsetOfExpr(OffsetOfExpr 
*E) {
   CurrentType = ON.getBase()->getType();
 
   // Compute the offset to the base.
-  const RecordType *BaseRT = CurrentType->getAs();
-  CXXRecordDecl *BaseRD = cast(BaseRT->getDecl());
+  auto *BaseRT = CurrentType->castAs();
+  auto *BaseRD = cast(BaseRT->getDecl());
   CharUnits OffsetInt = RL.getBaseClassOffset(BaseRD);
   Offset = llvm::ConstantInt::get(ResultType, OffsetInt.getQuantity());
   break;



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


[clang] a157d83 - [clang] Environment::createValueUnlessSelfReferential - use castAs<> instead of getAs<> to avoid dereference of nullptr

2022-03-09 Thread Simon Pilgrim via cfe-commits

Author: Simon Pilgrim
Date: 2022-03-09T11:40:37Z
New Revision: a157d839c52077001f234ce5c8b0cbc05fbb429c

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

LOG: [clang] Environment::createValueUnlessSelfReferential - use castAs<> 
instead of getAs<> to avoid dereference of nullptr

The pointer is always dereferenced, so assert the cast is correct instead of 
returning nullptr

Added: 


Modified: 
clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp

Removed: 




diff  --git a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp 
b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
index ec945bac09863..23e905fc5138c 100644
--- a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -439,7 +439,7 @@ Value *Environment::createValueUnlessSelfReferential(
 
   if (Type->isReferenceType()) {
 CreatedValuesCount++;
-QualType PointeeType = Type->getAs()->getPointeeType();
+QualType PointeeType = Type->castAs()->getPointeeType();
 auto  = createStorageLocation(PointeeType);
 
 if (!Visited.contains(PointeeType.getCanonicalType())) {
@@ -457,7 +457,7 @@ Value *Environment::createValueUnlessSelfReferential(
 
   if (Type->isPointerType()) {
 CreatedValuesCount++;
-QualType PointeeType = Type->getAs()->getPointeeType();
+QualType PointeeType = Type->castAs()->getPointeeType();
 auto  = createStorageLocation(PointeeType);
 
 if (!Visited.contains(PointeeType.getCanonicalType())) {



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


[clang] 8d09311 - [clang] Sema::ActOnModuleImport - remove superfluous nullptr test

2022-03-09 Thread Simon Pilgrim via cfe-commits

Author: Simon Pilgrim
Date: 2022-03-09T11:40:36Z
New Revision: 8d0931114f2df30c23b4eb1380185063f4684851

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

LOG: [clang] Sema::ActOnModuleImport - remove superfluous nullptr test

Mod has already been dereferenced

Added: 


Modified: 
clang/lib/Sema/SemaModule.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaModule.cpp b/clang/lib/Sema/SemaModule.cpp
index d12de22241f2c..9de95e2e6087a 100644
--- a/clang/lib/Sema/SemaModule.cpp
+++ b/clang/lib/Sema/SemaModule.cpp
@@ -476,7 +476,7 @@ DeclResult Sema::ActOnModuleImport(SourceLocation StartLoc,
 Context.addModuleInitializer(ModuleScopes.back().Module, Import);
 
   // A module (partition) implementation unit shall not be exported.
-  if (getLangOpts().CPlusPlusModules && Mod && ExportLoc.isValid() &&
+  if (getLangOpts().CPlusPlusModules && ExportLoc.isValid() &&
   Mod->Kind == Module::ModuleKind::ModulePartitionImplementation) {
 Diag(ExportLoc, diag::err_export_partition_impl)
 << SourceRange(ExportLoc, Path.back().second);



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


[PATCH] D120824: [clang][ASTImporter] Fix a bug when importing CXXDefaultInitExpr.

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

I think that the problem may be related to the fact that the in-class 
initializer is not used by the code in the "To" AST (in 
//ctu-cxxdefaultinitexpr.cpp// the problem is with `QMultiHash::d` field). 
Probably the expression node in the field is set only if it is used by any 
`CXXDefaultInitExpr`, but the `hasInClassInitializer` value is set always if 
the code contains in-class initializer. I can try to make a unit test for this 
case (but the lit test is good to have because it is more complex and can 
reveal other problems).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120824

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


  1   2   >