[PATCH] D126324: [clang] Allow const variables with weak attribute to be overridden

[Chris Lattner via Phabricator via cfe-commits]

lattner added a comment.

I'm not a competent reviewer for the patch, but +1 on aligning with GCC 
behavior here.  I don't recall the motivation for the original patch (apologies 
again for the terrible commit message).  This approach makes a lot of sense to 
me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126324

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

[PATCH] D123286: [Clang][OpenMP] Support for omp nothing

[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 rGca27f3e3b26e: [Clang][OpenMP] Support for omp nothing 
(authored by koops, committed by Chi-Chun, Chen 
chichunchen...@gmail.com).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123286

Files:
  clang/lib/Basic/OpenMPKinds.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/test/OpenMP/nothing_messages.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
@@ -629,6 +629,7 @@
 VersionedClause
   ];
 }
+def OMP_Nothing : Directive<"nothing"> {}
 def OMP_TargetData : Directive<"target data"> {
   let allowedClauses = [
 VersionedClause,
Index: clang/test/OpenMP/nothing_messages.cpp
===
--- /dev/null
+++ clang/test/OpenMP/nothing_messages.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -verify=expected -fopenmp -ferror-limit 100 %s 
-Wuninitialized
+
+int mixed() {
+  int x = 0;
+  int d = 4;
+
+#pragma omp nothing
+  x=d;
+
+  if(!x) {
+#pragma omp nothing
+x=d;
+  }
+
+// expected-error@+2 {{#pragma omp nothing' cannot be an immediate 
substatement}}
+  if(!x)
+#pragma omp nothing
+x=d;
+
+// expected-warning@+2 {{extra tokens at the end of '#pragma omp nothing' are 
ignored}}
+  if(!x) {
+#pragma omp nothing seq_cst
+x=d;
+  }
+
+  return 0;
+}
Index: clang/lib/Parse/ParseOpenMP.cpp
===
--- clang/lib/Parse/ParseOpenMP.cpp
+++ clang/lib/Parse/ParseOpenMP.cpp
@@ -2488,6 +2488,16 @@
   bool HasAssociatedStatement = true;
 
   switch (DKind) {
+  case OMPD_nothing:
+if ((StmtCtx & ParsedStmtContext::AllowStandaloneOpenMPDirectives) ==
+ParsedStmtContext())
+  Diag(Tok, diag::err_omp_immediate_directive)
+<< getOpenMPDirectiveName(DKind) << 0;
+ConsumeToken();
+skipUntilPragmaOpenMPEnd(DKind);
+if (Tok.is(tok::annot_pragma_openmp_end))
+  ConsumeAnnotationToken();
+break;
   case OMPD_metadirective: {
 ConsumeToken();
 SmallVector VMIs;
Index: clang/lib/Basic/OpenMPKinds.cpp
===
--- clang/lib/Basic/OpenMPKinds.cpp
+++ clang/lib/Basic/OpenMPKinds.cpp
@@ -730,6 +730,9 @@
   case OMPD_teams_loop:
 CaptureRegions.push_back(OMPD_teams);
 break;
+  case OMPD_nothing:
+CaptureRegions.push_back(OMPD_nothing);
+break;
   case OMPD_loop:
 // TODO: 'loop' may require different capture regions depending on the bind
 // clause or the parent directive when there is no bind clause. Use


Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -629,6 +629,7 @@
 VersionedClause
   ];
 }
+def OMP_Nothing : Directive<"nothing"> {}
 def OMP_TargetData : Directive<"target data"> {
   let allowedClauses = [
 VersionedClause,
Index: clang/test/OpenMP/nothing_messages.cpp
===
--- /dev/null
+++ clang/test/OpenMP/nothing_messages.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -verify=expected -fopenmp -ferror-limit 100 %s -Wuninitialized
+
+int mixed() {
+  int x = 0;
+  int d = 4;
+
+#pragma omp nothing
+  x=d;
+
+  if(!x) {
+#pragma omp nothing
+x=d;
+  }
+
+// expected-error@+2 {{#pragma omp nothing' cannot be an immediate substatement}}
+  if(!x)
+#pragma omp nothing
+x=d;
+
+// expected-warning@+2 {{extra tokens at the end of '#pragma omp nothing' are ignored}}
+  if(!x) {
+#pragma omp nothing seq_cst
+x=d;
+  }
+
+  return 0;
+}
Index: clang/lib/Parse/ParseOpenMP.cpp
===
--- clang/lib/Parse/ParseOpenMP.cpp
+++ clang/lib/Parse/ParseOpenMP.cpp
@@ -2488,6 +2488,16 @@
   bool HasAssociatedStatement = true;
 
   switch (DKind) {
+  case OMPD_nothing:
+if ((StmtCtx & ParsedStmtContext::AllowStandaloneOpenMPDirectives) ==
+ParsedStmtContext())
+  Diag(Tok, diag::err_omp_immediate_directive)
+<< getOpenMPDirectiveName(DKind) << 0;
+ConsumeToken();
+skipUntilPragmaOpenMPEnd(DKind);
+if (Tok.is(tok::annot_pragma_openmp_end))
+  ConsumeAnnotationToken();
+break;
   case OMPD_metadirective: {
 ConsumeToken();
 SmallVector VMIs;
Index: clang/lib/Basic/OpenMPKinds.cpp
===
--- clang/lib/Basic/OpenMPKinds.cpp
+++ clang/lib/Basic/OpenMPKinds.cpp
@@ -730,6 +730,9 @@
   case OMPD_teams_loop:
 CaptureRegions.push_back(OMPD_teams);
 break;
+  

[clang] ca27f3e - [Clang][OpenMP] Support for omp nothing

[via cfe-commits]

Author: Sunil Kuravinakop
Date: 2022-05-24T23:59:31-05:00
New Revision: ca27f3e3b26ed5389d4a361f274e3be516eb282d

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

LOG: [Clang][OpenMP] Support for omp nothing

Patch to support "#pragma omp nothing"

Reviewed By: tianshilei1992

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

Added: 
clang/test/OpenMP/nothing_messages.cpp

Modified: 
clang/lib/Basic/OpenMPKinds.cpp
clang/lib/Parse/ParseOpenMP.cpp
llvm/include/llvm/Frontend/OpenMP/OMP.td

Removed: 




diff  --git a/clang/lib/Basic/OpenMPKinds.cpp b/clang/lib/Basic/OpenMPKinds.cpp
index 5ff4e023fb3c1..dbfe2117b00a6 100644
--- a/clang/lib/Basic/OpenMPKinds.cpp
+++ b/clang/lib/Basic/OpenMPKinds.cpp
@@ -730,6 +730,9 @@ void clang::getOpenMPCaptureRegions(
   case OMPD_teams_loop:
 CaptureRegions.push_back(OMPD_teams);
 break;
+  case OMPD_nothing:
+CaptureRegions.push_back(OMPD_nothing);
+break;
   case OMPD_loop:
 // TODO: 'loop' may require 
diff erent capture regions depending on the bind
 // clause or the parent directive when there is no bind clause. Use

diff  --git a/clang/lib/Parse/ParseOpenMP.cpp b/clang/lib/Parse/ParseOpenMP.cpp
index 3d5c9c949760b..1e484f5644170 100644
--- a/clang/lib/Parse/ParseOpenMP.cpp
+++ b/clang/lib/Parse/ParseOpenMP.cpp
@@ -2488,6 +2488,16 @@ StmtResult 
Parser::ParseOpenMPDeclarativeOrExecutableDirective(
   bool HasAssociatedStatement = true;
 
   switch (DKind) {
+  case OMPD_nothing:
+if ((StmtCtx & ParsedStmtContext::AllowStandaloneOpenMPDirectives) ==
+ParsedStmtContext())
+  Diag(Tok, diag::err_omp_immediate_directive)
+<< getOpenMPDirectiveName(DKind) << 0;
+ConsumeToken();
+skipUntilPragmaOpenMPEnd(DKind);
+if (Tok.is(tok::annot_pragma_openmp_end))
+  ConsumeAnnotationToken();
+break;
   case OMPD_metadirective: {
 ConsumeToken();
 SmallVector VMIs;

diff  --git a/clang/test/OpenMP/nothing_messages.cpp 
b/clang/test/OpenMP/nothing_messages.cpp
new file mode 100644
index 0..cd6d0defe492f
--- /dev/null
+++ b/clang/test/OpenMP/nothing_messages.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -verify=expected -fopenmp -ferror-limit 100 %s 
-Wuninitialized
+
+int mixed() {
+  int x = 0;
+  int d = 4;
+
+#pragma omp nothing
+  x=d;
+
+  if(!x) {
+#pragma omp nothing
+x=d;
+  }
+
+// expected-error@+2 {{#pragma omp nothing' cannot be an immediate 
substatement}}
+  if(!x)
+#pragma omp nothing
+x=d;
+
+// expected-warning@+2 {{extra tokens at the end of '#pragma omp nothing' are 
ignored}}
+  if(!x) {
+#pragma omp nothing seq_cst
+x=d;
+  }
+
+  return 0;
+}

diff  --git a/llvm/include/llvm/Frontend/OpenMP/OMP.td 
b/llvm/include/llvm/Frontend/OpenMP/OMP.td
index 8218be1f966bf..b4abc64bc2118 100644
--- a/llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ b/llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -629,6 +629,7 @@ def OMP_Requires : Directive<"requires"> {
 VersionedClause
   ];
 }
+def OMP_Nothing : Directive<"nothing"> {}
 def OMP_TargetData : Directive<"target data"> {
   let allowedClauses = [
 VersionedClause,



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

[PATCH] D123235: [OpenMP] atomic compare fail : Parser & AST support

[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 rG232bf8189ef7: [OpenMP] atomic compare fail : Parser  
AST support (authored by koops, committed by Chi-Chun, Chen 
chichunchen...@gmail.com).
Herald added a project: Flang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123235

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

Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -199,6 +199,7 @@
 def OMPC_Update : Clause<"update"> { let clangClass = "OMPUpdateClause"; }
 def OMPC_Capture : Clause<"capture"> { let clangClass = "OMPCaptureClause"; }
 def OMPC_Compare : Clause<"compare"> { let clangClass = "OMPCompareClause"; }
+def OMPC_Fail : Clause<"fail"> { let clangClass = "OMPFailClause"; }
 def OMPC_SeqCst : Clause<"seq_cst"> { let clangClass = "OMPSeqCstClause"; }
 def OMPC_AcqRel : Clause<"acq_rel"> { let clangClass = "OMPAcqRelClause"; }
 def OMPC_Acquire : Clause<"acquire"> { let clangClass = "OMPAcquireClause"; }
@@ -569,7 +570,8 @@
 VersionedClause,
 VersionedClause,
 VersionedClause,
-VersionedClause
+VersionedClause,
+VersionedClause
   ];
 }
 def OMP_Target : Directive<"target"> {
Index: flang/lib/Semantics/check-omp-structure.cpp
===
--- flang/lib/Semantics/check-omp-structure.cpp
+++ flang/lib/Semantics/check-omp-structure.cpp
@@ -1807,6 +1807,7 @@
 CHECK_SIMPLE_CLAUSE(Align, OMPC_align)
 CHECK_SIMPLE_CLAUSE(Compare, OMPC_compare)
 CHECK_SIMPLE_CLAUSE(CancellationConstructType, OMPC_cancellation_construct_type)
+CHECK_SIMPLE_CLAUSE(Fail, OMPC_fail)
 
 CHECK_REQ_SCALAR_INT_CLAUSE(Grainsize, OMPC_grainsize)
 CHECK_REQ_SCALAR_INT_CLAUSE(NumTasks, OMPC_num_tasks)
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -2368,6 +2368,8 @@
 
 void OMPClauseEnqueue::VisitOMPCompareClause(const OMPCompareClause *) {}
 
+void OMPClauseEnqueue::VisitOMPFailClause(const OMPFailClause *) {}
+
 void OMPClauseEnqueue::VisitOMPSeqCstClause(const OMPSeqCstClause *) {}
 
 void OMPClauseEnqueue::VisitOMPAcqRelClause(const OMPAcqRelClause *) {}
Index: clang/test/OpenMP/atomic_messages.cpp
===
--- clang/test/OpenMP/atomic_messages.cpp
+++ clang/test/OpenMP/atomic_messages.cpp
@@ -958,6 +958,24 @@
 // expected-error@+1 {{directive '#pragma omp atomic' cannot contain more than one 'capture' clause}}
 #pragma omp atomic compare compare capture capture
   { v = a; if (a > b) a = b; }
+// expected-error@+1 {{expected 'compare' clause with the 'fail' modifier}}
+#pragma omp atomic fail(seq_cst)
+  if(v == a) { v = a; }
+// expected-error@+1 {{expected '(' after 'fail'}}
+#pragma omp atomic compare fail
+  if(v < a) { v = a; }
+// expected-error@+1 {{expected a memory order clause}}
+#pragma omp atomic compare fail(capture)
+  if(v < a) { v = a; }
+ // expected-error@+2 {{expected ')' after 'atomic compare fail'}}
+ // expected-warning@+1 {{extra tokens at the end of '#pragma omp atomic' are ignored}}
+#pragma omp atomic compare fail(seq_cst | acquire)
+  if(v < a) { v = a; }
+// expected-error@+1 {{directive '#pragma omp atomic' cannot contain more than one 'fail' clause}}
+#pragma omp atomic compare fail(relaxed) fail(seq_cst)
+  if(v < a) { v = a; }
+
+
 #endif
   // expected-note@+1 {{in instantiation of function template specialization 'mixed' requested here}}
   return mixed();
Index: clang/test/OpenMP/atomic_ast_print.cpp
===
--- clang/test/OpenMP/atomic_ast_print.cpp
+++ clang/test/OpenMP/atomic_ast_print.cpp
@@ -226,6 +226,16 @@
   { v = a; if (a < b) { a = b; } }
 #pragma omp atomic compare capture hint(6)
   { v = a == b; if (v) a = c; }
+#pragma omp atomic compare fail(acq_rel)
+  { if (a < c) { a = c; } }
+#pragma omp atomic compare fail(acquire)
+  { if 

[clang] 232bf81 - [OpenMP] atomic compare fail : Parser & AST support

[via cfe-commits]

Author: Sunil Kuravinakop
Date: 2022-05-24T23:56:42-05:00
New Revision: 232bf8189ef7d574a468bd5bfd1e84e962f7f16e

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

LOG: [OpenMP] atomic compare fail : Parser & AST support

This is a support for " #pragma omp atomic compare fail ". It has Parser & AST 
support for now.

Reviewed By: tianshilei1992

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

Added: 


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

Removed: 




diff  --git a/clang/include/clang/AST/ASTNodeTraverser.h 
b/clang/include/clang/AST/ASTNodeTraverser.h
index f2c5c01ac88de..cb5bbeb644812 100644
--- a/clang/include/clang/AST/ASTNodeTraverser.h
+++ b/clang/include/clang/AST/ASTNodeTraverser.h
@@ -214,6 +214,10 @@ class ASTNodeTraverser
   }
 
   void Visit(const OMPClause *C) {
+if (OMPFailClause::classof(C)) {
+  Visit(static_cast(C));
+  return;
+}
 getNodeDelegate().AddChild([=] {
   getNodeDelegate().Visit(C);
   for (const auto *S : C->children())
@@ -221,6 +225,13 @@ class ASTNodeTraverser
 });
   }
 
+  void Visit(const OMPFailClause *C) {
+getNodeDelegate().AddChild([=] {
+  getNodeDelegate().Visit(C);
+  const OMPClause *MOC = C->const_getMemoryOrderClause();
+  Visit(MOC);
+});
+  }
   void Visit(const GenericSelectionExpr::ConstAssociation ) {
 getNodeDelegate().AddChild([=] {
   getNodeDelegate().Visit(A);

diff  --git a/clang/include/clang/AST/OpenMPClause.h 
b/clang/include/clang/AST/OpenMPClause.h
index a745df1143468..aa9503c565779 100644
--- a/clang/include/clang/AST/OpenMPClause.h
+++ b/clang/include/clang/AST/OpenMPClause.h
@@ -2266,6 +2266,133 @@ class OMPCompareClause final : public OMPClause {
   }
 };
 
+/// This represents 'fail' clause in the '#pragma omp atomic'
+/// directive.
+///
+/// \code
+/// #pragma omp atomic compare fail
+/// \endcode
+/// In this example directive '#pragma omp atomic compare' has 'fail' clause.
+class OMPFailClause final
+: public OMPClause,
+  private llvm::TrailingObjects {
+  OMPClause *MemoryOrderClause;
+
+  friend class OMPClauseReader;
+  friend TrailingObjects;
+
+  /// Define the sizes of each trailing object array except the last one. This
+  /// is required for TrailingObjects to work properly.
+  size_t numTrailingObjects(OverloadToken) const {
+// 2 locations: for '(' and argument location.
+return 2;
+  }
+
+  /// Sets the location of '(' in fail clause.
+  void setLParenLoc(SourceLocation Loc) {
+*getTrailingObjects() = Loc;
+  }
+
+  /// Sets the location of memoryOrder clause argument in fail clause.
+  void setArgumentLoc(SourceLocation Loc) {
+*std::next(getTrailingObjects(), 1) = Loc;
+  }
+
+  /// Sets the mem_order clause for 'atomic compare fail' directive.
+  void setMemOrderClauseKind(OpenMPClauseKind MemOrder) {
+OpenMPClauseKind *MOCK = getTrailingObjects();
+*MOCK = MemOrder;
+  }
+
+  /// Sets the mem_order clause for 'atomic compare fail' directive.
+  void setMemOrderClause(OMPClause *MemoryOrderClauseParam) {
+MemoryOrderClause = MemoryOrderClauseParam;
+  }
+public:
+  /// Build 'fail' clause.
+  ///
+  /// \param StartLoc Starting location of the clause.
+  /// \param EndLoc Ending location of the clause.
+  OMPFailClause(SourceLocation StartLoc, SourceLocation EndLoc)
+  : OMPClause(llvm::omp::OMPC_fail, StartLoc, EndLoc) {}
+
+  /// Build an empty clause.
+  OMPFailClause()
+  : OMPClause(llvm::omp::OMPC_fail, SourceLocation(), SourceLocation()) {}
+
+  static OMPFailClause *CreateEmpty(const ASTContext );
+  static OMPFailClause *Create(const ASTContext , SourceLocation StartLoc,
+   SourceLocation EndLoc);
+
+  child_range children() {
+return child_range(child_iterator(), child_iterator());
+  }
+
+
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
+
+  child_range used_children() {
+return child_range(child_iterator(), child_iterator());

[PATCH] D117616: GCC ABI Compatibility: Preserve alignment of non-pod members in packed structs

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:239-243
+- GCC doesn't pack non-POD members in packed structs unless the packed
+  attribute is also specified on the member. Clang historically did perform
+  such packing. Clang now matches the gcc behavior (except on Darwin and PS4).
+  You can switch back to the old ABI behavior with the flag:
+  ``-fclang-abi-compat=13.0``.

dblaikie wrote:
> tstellar wrote:
> > dblaikie wrote:
> > > MatzeB wrote:
> > > > Ugh... The release notes went missing in `main` now:
> > > > 
> > > > * We had them in clang-14, but then reverted in the release process of 
> > > > clang-14 so they never showed for clang-14.
> > > > * In `main` we removed all release nodes when going from 14->15.
> > > > 
> > > > So this notice is effectively lost now...
> > > Ah, thanks - readded it in 0b903ef6aa0976a60d3f448837f3c43adaf09cc1
> > > 
> > > Anyone have feelings about whether we should move the old ABI under 
> > > Ver14, instead of Ver13, since the break was never released in Ver14?
> > That seems fine to me.
> Sent D126334
Done in D126334 (posted, reviewed, and committed)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117616

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

[PATCH] D102122: Support warn_unused_result on typedefs

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.
Herald added a project: All.

In D102122#3344317 , @dblaikie wrote:

> I don't recall all the context, but did try discussing this with the 
> committee folks and got a variety of strong opinions/wasn't sure whether 
> there was a path forward: 
> https://lists.isocpp.org/ext/2021/05/index.php#msg16554 (for those with 
> access to that). What's your take on the discussion there? Worth pushing 
> forward?

Ping on this


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102122

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

[PATCH] D119051: Extend the C++03 definition of POD to include defaulted functions

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119051

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

[PATCH] D119051: Extend the C++03 definition of POD to include defaulted functions

[David Blaikie via Phabricator via cfe-commits]

dblaikie updated this revision to Diff 431871.
dblaikie added a comment.
Herald added a subscriber: MaskRay.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119051

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/AST/DeclCXX.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/AST/ast-dump-record-definition-data-json.cpp
  clang/test/Driver/clang_f_opts.c
  clang/test/SemaCXX/class-layout.cpp

Index: clang/test/SemaCXX/class-layout.cpp
===
--- clang/test/SemaCXX/class-layout.cpp
+++ clang/test/SemaCXX/class-layout.cpp
@@ -1,9 +1,9 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify -std=c++98 -Wno-inaccessible-base
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify -std=c++11 -Wno-inaccessible-base
-// RUN: %clang_cc1 -triple x86_64-apple-darwin%s -fsyntax-only -verify -std=c++11 -Wno-inaccessible-base -DCLANG_ABI_COMPAT=14
-// RUN: %clang_cc1 -triple x86_64-scei-ps4%s -fsyntax-only -verify -std=c++11 -Wno-inaccessible-base -DCLANG_ABI_COMPAT=6
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify -std=c++11 -Wno-inaccessible-base -fclang-abi-compat=6 -DCLANG_ABI_COMPAT=6
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify -std=c++11 -Wno-inaccessible-base -fclang-abi-compat=14 -DCLANG_ABI_COMPAT=14
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify -std=c++98 -Wno-inaccessible-base -Wno-c++11-extensions
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify -std=c++11 -Wno-inaccessible-base -Wno-c++11-extensions
+// RUN: %clang_cc1 -triple x86_64-apple-darwin%s -fsyntax-only -verify -std=c++11 -Wno-inaccessible-base -Wno-c++11-extensions -DCLANG_ABI_COMPAT=14
+// RUN: %clang_cc1 -triple x86_64-scei-ps4%s -fsyntax-only -verify -std=c++11 -Wno-inaccessible-base -Wno-c++11-extensions -DCLANG_ABI_COMPAT=6
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify -std=c++11 -Wno-inaccessible-base -Wno-c++11-extensions -fclang-abi-compat=6 -DCLANG_ABI_COMPAT=6
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify -std=c++11 -Wno-inaccessible-base -Wno-c++11-extensions -fclang-abi-compat=14 -DCLANG_ABI_COMPAT=14
 // expected-no-diagnostics
 
 #define SA(n, p) int a##n[(p) ? 1 : -1]
@@ -641,3 +641,21 @@
 _Static_assert(_Alignof(t1) == 1, "");
 _Static_assert(_Alignof(t2) == 1, "");
 } // namespace non_pod_packed
+
+namespace cxx11_pod {
+struct t1 {
+  t1() = default;
+  t1(const t1&) = delete;
+  ~t1() = delete;
+  t1(t1&&) = default;
+  int a;
+};
+struct t2 {
+  t1 v1;
+} __attribute__((packed));
+#ifdef NO_DEFAULTED_SMF_ARE_POD
+_Static_assert(_Alignof(t2) == 4, "");
+#else
+_Static_assert(_Alignof(t2) == 1, "");
+#endif
+}
Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -597,6 +597,15 @@
 // CHECK_DISABLE_DIRECT: -fobjc-disable-direct-methods-for-testing
 // CHECK_NO_DISABLE_DIRECT-NOT: -fobjc-disable-direct-methods-for-testing
 
+// RUN: %clang -### %s -fno-defaulted-smf-are-pod 2>&1 | FileCheck --check-prefix=CHECK-NO-DEFAULTED-SMF-ARE-POD %s
+// RUN: %clang -### %s 2>&1 | FileCheck --check-prefix=CHECK-DEFAULTED-SMF-ARE-POD %s
+// RUN: %clang -### %s -target x86_64-scei-ps4 2>&1 | FileCheck --check-prefix=CHECK-NO-DEFAULTED-SMF-ARE-POD %s
+// RUN: %clang -### %s -target x86_64-scei-ps4 -fdefaulted-smf-are-pod 2>&1 | FileCheck --check-prefix=CHECK-DEFAULTED-SMF-ARE-POD %s
+// RUN: %clang -### %s -target x86_64-unknown-darwin 2>&1 | FileCheck --check-prefix=CHECK-NO-DEFAULTED-SMF-ARE-POD %s
+// RUN: %clang -### %s -target x86_64-unknown-darwin -fdefaulted-smf-are-pod 2>&1 | FileCheck --check-prefix=CHECK-DEFAULTED-SMF-ARE-POD %s
+// CHECK-NO-DEFAULTED-SMF-ARE-POD-NOT: defaulted-smf-are-pod
+// CHECK-DEFAULTED-SMF-ARE-POD: -fdefaulted-smf-are-pod
+
 // RUN: %clang -### -S -fjmc -target x86_64-unknown-linux %s 2>&1 | FileCheck -check-prefixes=CHECK_JMC_WARN,CHECK_NOJMC %s
 // RUN: %clang -### -S -fjmc -target x86_64-pc-windows-msvc %s 2>&1 | FileCheck -check-prefixes=CHECK_JMC_WARN_NOT_ELF,CHECK_NOJMC %s
 // RUN: %clang -### -S -fjmc -g -target x86_64-unknown-linux %s 2>&1 | FileCheck -check-prefix=CHECK_JMC %s
Index: clang/test/AST/ast-dump-record-definition-data-json.cpp
===
--- clang/test/AST/ast-dump-record-definition-data-json.cpp
+++ clang/test/AST/ast-dump-record-definition-data-json.cpp
@@ -772,6 +772,7 @@
 // CHECK-NEXT:   "isAggregate": true,
 // CHECK-NEXT:   "isEmpty": true,
 // CHECK-NEXT:   "isLiteral": true,
+// CHECK-NEXT:   "isPOD": true,
 // CHECK-NEXT:   "isStandardLayout": 

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

[David Blaikie via Phabricator via cfe-commits]

dblaikie updated this revision to Diff 431869.
dblaikie added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118511

Files:
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/lib/AST/RecordLayoutBuilder.cpp
  clang/test/CodeGenCXX/warn-padded-packed.cpp

Index: clang/test/CodeGenCXX/warn-padded-packed.cpp
===
--- clang/test/CodeGenCXX/warn-padded-packed.cpp
+++ clang/test/CodeGenCXX/warn-padded-packed.cpp
@@ -146,8 +146,28 @@
   unsigned char b : 8;
 } __attribute__((packed));
 
+struct S28_non_pod {
+ protected:
+  int i;
+};
+struct S28 {
+  char c1;
+  short s1;
+  char c2;
+  S28_non_pod p1; // expected-warning {{not packing field 'p1' as it is non-POD}}
+} __attribute__((packed));
+
+struct S29_non_pod_align_1 {
+ protected:
+  char c;
+};
+struct S29 {
+  S29_non_pod_align_1 p1;
+  int i;
+} __attribute__((packed)); // no warning
+static_assert(alignof(S29) == 1, "");
 
 // The warnings are emitted when the layout of the structs is computed, so we have to use them.
 void f(S1*, S2*, S3*, S4*, S5*, S6*, S7*, S8*, S9*, S10*, S11*, S12*, S13*,
S14*, S15*, S16*, S17*, S18*, S19*, S20*, S21*, S22*, S23*, S24*, S25*,
-   S26*, S27*){}
+   S26*, S27*, S28*, S29*){}
Index: clang/lib/AST/RecordLayoutBuilder.cpp
===
--- clang/lib/AST/RecordLayoutBuilder.cpp
+++ clang/lib/AST/RecordLayoutBuilder.cpp
@@ -1888,11 +1888,6 @@
   LastBitfieldStorageUnitSize = 0;
 
   llvm::Triple Target = Context.getTargetInfo().getTriple();
-  bool FieldPacked = (Packed && (!FieldClass || FieldClass->isPOD() ||
- Context.getLangOpts().getClangABICompat() <=
- LangOptions::ClangABI::Ver14 ||
- Target.isPS4() || Target.isOSDarwin())) ||
- D->hasAttr();
 
   AlignRequirementKind AlignRequirement = AlignRequirementKind::None;
   CharUnits FieldSize;
@@ -1973,6 +1968,12 @@
 }
   }
 
+  bool FieldPacked = (Packed && (!FieldClass || FieldClass->isPOD() ||
+ Context.getLangOpts().getClangABICompat() <=
+ LangOptions::ClangABI::Ver14 ||
+ Target.isPS4() || Target.isOSDarwin())) ||
+ D->hasAttr();
+
   // When used as part of a typedef, or together with a 'packed' attribute, the
   // 'aligned' attribute can be used to decrease alignment. In that case, it
   // overrides any computed alignment we have, and there is no need to upgrade
@@ -2023,28 +2024,34 @@
 
   // The align if the field is not packed. This is to check if the attribute
   // was unnecessary (-Wpacked).
-  CharUnits UnpackedFieldAlign =
-  !DefaultsToAIXPowerAlignment ? FieldAlign : PreferredAlign;
+  CharUnits UnpackedFieldAlign = FieldAlign; 
+  CharUnits PackedFieldAlign = CharUnits::One();
   CharUnits UnpackedFieldOffset = FieldOffset;
   CharUnits OriginalFieldAlign = UnpackedFieldAlign;
 
-  if (FieldPacked) {
-FieldAlign = CharUnits::One();
-PreferredAlign = CharUnits::One();
-  }
   CharUnits MaxAlignmentInChars =
   Context.toCharUnitsFromBits(D->getMaxAlignment());
-  FieldAlign = std::max(FieldAlign, MaxAlignmentInChars);
+  PackedFieldAlign = std::max(PackedFieldAlign, MaxAlignmentInChars);
   PreferredAlign = std::max(PreferredAlign, MaxAlignmentInChars);
   UnpackedFieldAlign = std::max(UnpackedFieldAlign, MaxAlignmentInChars);
 
   // The maximum field alignment overrides the aligned attribute.
   if (!MaxFieldAlignment.isZero()) {
-FieldAlign = std::min(FieldAlign, MaxFieldAlignment);
+PackedFieldAlign = std::min(PackedFieldAlign, MaxFieldAlignment);
 PreferredAlign = std::min(PreferredAlign, MaxFieldAlignment);
 UnpackedFieldAlign = std::min(UnpackedFieldAlign, MaxFieldAlignment);
   }
 
+
+  if (!FieldPacked)
+FieldAlign = UnpackedFieldAlign;
+  if (DefaultsToAIXPowerAlignment)
+UnpackedFieldAlign = PreferredAlign;
+  if (FieldPacked) {
+PreferredAlign = PackedFieldAlign;
+FieldAlign = PackedFieldAlign;
+  }
+
   CharUnits AlignTo =
   !DefaultsToAIXPowerAlignment ? FieldAlign : PreferredAlign;
   // Round up the current record size to the field's alignment boundary.
@@ -2127,6 +2134,9 @@
 << Context.getTypeDeclType(RD) << D->getName() << D->getType();
 }
   }
+
+  if (Packed && !FieldPacked && PackedFieldAlign < FieldAlign)
+Diag(D->getLocation(), diag::warn_unpacked_field) << D;
 }
 
 void ItaniumRecordLayoutBuilder::FinishLayout(const NamedDecl *D) {
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/DiagnosticGroups.td
+++ 

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

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

@rsmith I had a few responses to your last round of review here - could you 
have a look through them/see if this is the right way to go, or if more 
refactoring would be suitable?


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] D126334: Move GCC-compatible pod-packing change to v15/old behavior available at v14 and below

[David Blaikie via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe59f648d698e: Move GCC-compatible pod-packing change to 
v15/old behavior available at v14 and… (authored by dblaikie).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126334

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/LangOptions.h
  clang/lib/AST/RecordLayoutBuilder.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/SemaCXX/class-layout.cpp


Index: clang/test/SemaCXX/class-layout.cpp
===
--- clang/test/SemaCXX/class-layout.cpp
+++ clang/test/SemaCXX/class-layout.cpp
@@ -1,9 +1,9 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify 
-std=c++98 -Wno-inaccessible-base
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base
-// RUN: %clang_cc1 -triple x86_64-apple-darwin%s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base -DCLANG_ABI_COMPAT=13
+// RUN: %clang_cc1 -triple x86_64-apple-darwin%s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base -DCLANG_ABI_COMPAT=14
 // RUN: %clang_cc1 -triple x86_64-scei-ps4%s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base -DCLANG_ABI_COMPAT=6
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base -fclang-abi-compat=6 -DCLANG_ABI_COMPAT=6
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base -fclang-abi-compat=13 -DCLANG_ABI_COMPAT=13
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base -fclang-abi-compat=14 -DCLANG_ABI_COMPAT=14
 // expected-no-diagnostics
 
 #define SA(n, p) int a##n[(p) ? 1 : -1]
@@ -620,7 +620,7 @@
   char c2;
   t1 v1;
 } __attribute__((packed));
-#if defined(CLANG_ABI_COMPAT) && CLANG_ABI_COMPAT <= 13
+#if defined(CLANG_ABI_COMPAT) && CLANG_ABI_COMPAT <= 14
 _Static_assert(_Alignof(t1) == 4, "");
 _Static_assert(_Alignof(t2) == 1, "");
 #else
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3516,8 +3516,6 @@
 GenerateArg(Args, OPT_fclang_abi_compat_EQ, "11.0", SA);
   else if (Opts.getClangABICompat() == LangOptions::ClangABI::Ver12)
 GenerateArg(Args, OPT_fclang_abi_compat_EQ, "12.0", SA);
-  else if (Opts.getClangABICompat() == LangOptions::ClangABI::Ver13)
-GenerateArg(Args, OPT_fclang_abi_compat_EQ, "13.0", SA);
   else if (Opts.getClangABICompat() == LangOptions::ClangABI::Ver14)
 GenerateArg(Args, OPT_fclang_abi_compat_EQ, "14.0", SA);
 
@@ -4010,8 +4008,6 @@
 Opts.setClangABICompat(LangOptions::ClangABI::Ver11);
   else if (Major <= 12)
 Opts.setClangABICompat(LangOptions::ClangABI::Ver12);
-  else if (Major <= 13)
-Opts.setClangABICompat(LangOptions::ClangABI::Ver13);
   else if (Major <= 14)
 Opts.setClangABICompat(LangOptions::ClangABI::Ver14);
 } else if (Ver != "latest") {
Index: clang/lib/AST/RecordLayoutBuilder.cpp
===
--- clang/lib/AST/RecordLayoutBuilder.cpp
+++ clang/lib/AST/RecordLayoutBuilder.cpp
@@ -1890,7 +1890,7 @@
   llvm::Triple Target = Context.getTargetInfo().getTriple();
   bool FieldPacked = (Packed && (!FieldClass || FieldClass->isPOD() ||
  Context.getLangOpts().getClangABICompat() <=
- LangOptions::ClangABI::Ver13 ||
+ LangOptions::ClangABI::Ver14 ||
  Target.isPS4() || Target.isOSDarwin())) ||
  D->hasAttr();
 
Index: clang/include/clang/Basic/LangOptions.h
===
--- clang/include/clang/Basic/LangOptions.h
+++ clang/include/clang/Basic/LangOptions.h
@@ -214,12 +214,9 @@
 /// global-scope inline variables incorrectly.
 Ver12,
 
-/// Attempt to be ABI-compatible with code generated by Clang 13.0.x.
-/// This causes clang to not pack non-POD members of packed structs.
-Ver13,
-
 /// Attempt to be ABI-compatible with code generated by Clang 14.0.x.
 /// This causes clang to mangle dependent nested names incorrectly.
+/// This causes clang to pack non-POD members of packed structs.
 Ver14,
 
 /// Conform to the underlying platform's C and C++ ABIs as closely
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -431,7 +431,7 @@
   attribute is also specified on the member. Clang historically did perform
   such 

[clang] e59f648 - Move GCC-compatible pod-packing change to v15/old behavior available at v14 and below

[David Blaikie via cfe-commits]

Author: David Blaikie
Date: 2022-05-25T03:03:27Z
New Revision: e59f648d698efe58b96e9b6224449b2b8cfa872a

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

LOG: Move GCC-compatible pod-packing change to v15/old behavior available at 
v14 and below

Since this didn't make it into the v14 release - anyone requesting the
v14 ABI shouldn't get this GCC-compatible change that isn't backwards
compatible with v14 Clang.

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/LangOptions.h
clang/lib/AST/RecordLayoutBuilder.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/test/SemaCXX/class-layout.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 7a54a3368547..a457a8fb2efe 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -431,7 +431,7 @@ ABI Changes in Clang
   attribute is also specified on the member. Clang historically did perform
   such packing. Clang now matches the gcc behavior (except on Darwin and PS4).
   You can switch back to the old ABI behavior with the flag:
-  ``-fclang-abi-compat=13.0``.
+  ``-fclang-abi-compat=14.0``.
 
 OpenMP Support in Clang
 ---

diff  --git a/clang/include/clang/Basic/LangOptions.h 
b/clang/include/clang/Basic/LangOptions.h
index d442b4d96e76..6e7763a4a2b4 100644
--- a/clang/include/clang/Basic/LangOptions.h
+++ b/clang/include/clang/Basic/LangOptions.h
@@ -214,12 +214,9 @@ class LangOptions : public LangOptionsBase {
 /// global-scope inline variables incorrectly.
 Ver12,
 
-/// Attempt to be ABI-compatible with code generated by Clang 13.0.x.
-/// This causes clang to not pack non-POD members of packed structs.
-Ver13,
-
 /// Attempt to be ABI-compatible with code generated by Clang 14.0.x.
 /// This causes clang to mangle dependent nested names incorrectly.
+/// This causes clang to pack non-POD members of packed structs.
 Ver14,
 
 /// Conform to the underlying platform's C and C++ ABIs as closely

diff  --git a/clang/lib/AST/RecordLayoutBuilder.cpp 
b/clang/lib/AST/RecordLayoutBuilder.cpp
index 202823da7baa..8827e956fc2f 100644
--- a/clang/lib/AST/RecordLayoutBuilder.cpp
+++ b/clang/lib/AST/RecordLayoutBuilder.cpp
@@ -1890,7 +1890,7 @@ void ItaniumRecordLayoutBuilder::LayoutField(const 
FieldDecl *D,
   llvm::Triple Target = Context.getTargetInfo().getTriple();
   bool FieldPacked = (Packed && (!FieldClass || FieldClass->isPOD() ||
  Context.getLangOpts().getClangABICompat() <=
- LangOptions::ClangABI::Ver13 ||
+ LangOptions::ClangABI::Ver14 ||
  Target.isPS4() || Target.isOSDarwin())) ||
  D->hasAttr();
 

diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 88125dad8a92..32b084dfedec 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -3516,8 +3516,6 @@ void CompilerInvocation::GenerateLangArgs(const 
LangOptions ,
 GenerateArg(Args, OPT_fclang_abi_compat_EQ, "11.0", SA);
   else if (Opts.getClangABICompat() == LangOptions::ClangABI::Ver12)
 GenerateArg(Args, OPT_fclang_abi_compat_EQ, "12.0", SA);
-  else if (Opts.getClangABICompat() == LangOptions::ClangABI::Ver13)
-GenerateArg(Args, OPT_fclang_abi_compat_EQ, "13.0", SA);
   else if (Opts.getClangABICompat() == LangOptions::ClangABI::Ver14)
 GenerateArg(Args, OPT_fclang_abi_compat_EQ, "14.0", SA);
 
@@ -4010,8 +4008,6 @@ bool CompilerInvocation::ParseLangArgs(LangOptions , 
ArgList ,
 Opts.setClangABICompat(LangOptions::ClangABI::Ver11);
   else if (Major <= 12)
 Opts.setClangABICompat(LangOptions::ClangABI::Ver12);
-  else if (Major <= 13)
-Opts.setClangABICompat(LangOptions::ClangABI::Ver13);
   else if (Major <= 14)
 Opts.setClangABICompat(LangOptions::ClangABI::Ver14);
 } else if (Ver != "latest") {

diff  --git a/clang/test/SemaCXX/class-layout.cpp 
b/clang/test/SemaCXX/class-layout.cpp
index 79fa67707110..940966950d8b 100644
--- a/clang/test/SemaCXX/class-layout.cpp
+++ b/clang/test/SemaCXX/class-layout.cpp
@@ -1,9 +1,9 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify 
-std=c++98 -Wno-inaccessible-base
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base
-// RUN: %clang_cc1 -triple x86_64-apple-darwin%s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base -DCLANG_ABI_COMPAT=13
+// RUN: %clang_cc1 -triple x86_64-apple-darwin%s 

[PATCH] D126187: [C++20] [Coroutines] Conform the updates for CWG issue 2585

[Chuanqi Xu 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 rGa1ffba8d5286: [C++20] [Coroutines] Conform the updates for 
CWG issue 2585 (authored by ChuanqiXu).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126187

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Sema/SemaCoroutine.cpp
  clang/test/CodeGenCoroutines/coro-alloc-2.cpp

Index: clang/test/CodeGenCoroutines/coro-alloc-2.cpp
===
--- /dev/null
+++ clang/test/CodeGenCoroutines/coro-alloc-2.cpp
@@ -0,0 +1,30 @@
+// Tests that we wouldn't generate an allocation call in global scope with (std::size_t, p0, ..., pn)
+// RUN: %clang_cc1 %s -std=c++20 -S -triple x86_64-unknown-linux-gnu -emit-llvm -disable-llvm-passes %s -o - | FileCheck %s
+#include "Inputs/coroutine.h"
+
+namespace std {
+typedef decltype(sizeof(int)) size_t;
+}
+
+struct Allocator {};
+
+struct resumable {
+  struct promise_type {
+
+resumable get_return_object() { return {}; }
+auto initial_suspend() { return std::suspend_always(); }
+auto final_suspend() noexcept { return std::suspend_always(); }
+void unhandled_exception() {}
+void return_void(){};
+  };
+};
+
+void *operator new(std::size_t, void *);
+
+resumable f1(void *) {
+  co_return;
+}
+
+// CHECK: coro.alloc:
+// CHECK-NEXT: [[SIZE:%.+]] = call [[BITWIDTH:.+]] @llvm.coro.size.[[BITWIDTH]]()
+// CHECK-NEXT: call {{.*}} ptr @_Znwm([[BITWIDTH]] noundef [[SIZE]])
Index: clang/lib/Sema/SemaCoroutine.cpp
===
--- clang/lib/Sema/SemaCoroutine.cpp
+++ clang/lib/Sema/SemaCoroutine.cpp
@@ -1239,6 +1239,41 @@
   return true;
 }
 
+// Collect placement arguments for allocation function of coroutine FD.
+// Return true if we collect placement arguments succesfully. Return false,
+// otherwise.
+static bool collectPlacementArgs(Sema , FunctionDecl , SourceLocation Loc,
+ SmallVectorImpl ) {
+  if (auto *MD = dyn_cast()) {
+if (MD->isInstance() && !isLambdaCallOperator(MD)) {
+  ExprResult ThisExpr = S.ActOnCXXThis(Loc);
+  if (ThisExpr.isInvalid())
+return false;
+  ThisExpr = S.CreateBuiltinUnaryOp(Loc, UO_Deref, ThisExpr.get());
+  if (ThisExpr.isInvalid())
+return false;
+  PlacementArgs.push_back(ThisExpr.get());
+}
+  }
+
+  for (auto *PD : FD.parameters()) {
+if (PD->getType()->isDependentType())
+  continue;
+
+// Build a reference to the parameter.
+auto PDLoc = PD->getLocation();
+ExprResult PDRefExpr =
+S.BuildDeclRefExpr(PD, PD->getOriginalType().getNonReferenceType(),
+   ExprValueKind::VK_LValue, PDLoc);
+if (PDRefExpr.isInvalid())
+  return false;
+
+PlacementArgs.push_back(PDRefExpr.get());
+  }
+
+  return true;
+}
+
 bool CoroutineStmtBuilder::makeNewAndDeleteExpr() {
   // Form and check allocation and deallocation calls.
   assert(!IsPromiseDependentType &&
@@ -1255,13 +1290,7 @@
   // allocated, followed by the coroutine function's arguments. If a matching
   // allocation function exists, use it. Otherwise, use an allocation function
   // that just takes the requested size.
-
-  FunctionDecl *OperatorNew = nullptr;
-  FunctionDecl *OperatorDelete = nullptr;
-  FunctionDecl *UnusedResult = nullptr;
-  bool PassAlignment = false;
-  SmallVector PlacementArgs;
-
+  //
   // [dcl.fct.def.coroutine]p9
   //   An implementation may need to allocate additional storage for a
   //   coroutine.
@@ -1288,31 +1317,12 @@
   // and p_i denotes the i-th function parameter otherwise. For a non-static
   // member function, q_1 is an lvalue that denotes *this; any other q_i is an
   // lvalue that denotes the parameter copy corresponding to p_i.
-  if (auto *MD = dyn_cast()) {
-if (MD->isInstance() && !isLambdaCallOperator(MD)) {
-  ExprResult ThisExpr = S.ActOnCXXThis(Loc);
-  if (ThisExpr.isInvalid())
-return false;
-  ThisExpr = S.CreateBuiltinUnaryOp(Loc, UO_Deref, ThisExpr.get());
-  if (ThisExpr.isInvalid())
-return false;
-  PlacementArgs.push_back(ThisExpr.get());
-}
-  }
-  for (auto *PD : FD.parameters()) {
-if (PD->getType()->isDependentType())
-  continue;
 
-// Build a reference to the parameter.
-auto PDLoc = PD->getLocation();
-ExprResult PDRefExpr =
-S.BuildDeclRefExpr(PD, PD->getOriginalType().getNonReferenceType(),
-   ExprValueKind::VK_LValue, PDLoc);
-if (PDRefExpr.isInvalid())
-  return false;
-
-PlacementArgs.push_back(PDRefExpr.get());
-  }
+  FunctionDecl *OperatorNew = nullptr;
+  FunctionDecl *OperatorDelete = nullptr;
+  FunctionDecl *UnusedResult = nullptr;
+  bool PassAlignment = false;
+  SmallVector PlacementArgs;
 
   bool 

[clang] a1ffba8 - [C++20] [Coroutines] Conform the updates for CWG issue 2585

[Chuanqi Xu via cfe-commits]

Author: Chuanqi Xu
Date: 2022-05-25T10:31:26+08:00
New Revision: a1ffba8d528681d55c901a997beedbc69946eb90

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

LOG: [C++20] [Coroutines] Conform the updates for CWG issue 2585

According to the updates in CWG issue 2585
https://cplusplus.github.io/CWG/issues/2585.html, we shouldn't find an
allocation function with (size, p0, …, pn) in global scope.

Reviewed By: erichkeane

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

Added: 
clang/test/CodeGenCoroutines/coro-alloc-2.cpp

Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Sema/SemaCoroutine.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index a889c74a5523..7a54a3368547 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -149,8 +149,11 @@ Bug Fixes
   because there is no way to fully qualify the enumerator name, so this
   "extension" was unintentional and useless. This fixes
   `Issue 42372 `_.
-- Clang shouldn't lookup allocation function in global scope for coroutines
-  in case it found the allocation function name in the promise_type body.
+- Clang will now find and emit a call to an allocation function in a 
+  promise_type body for coroutines if there is any allocation function 
+  declaration in the scope of promise_type. Additionally, to implement CWG2585,
+  a coroutine will no longer generate a call to a global allocation function
+  with the signature (std::size_t, p0, ..., pn).
   This fixes Issue `Issue 54881 
`_.
 
 Improvements to Clang's diagnostics

diff  --git a/clang/lib/Sema/SemaCoroutine.cpp 
b/clang/lib/Sema/SemaCoroutine.cpp
index b43b0b3eb957..55f1c2989578 100644
--- a/clang/lib/Sema/SemaCoroutine.cpp
+++ b/clang/lib/Sema/SemaCoroutine.cpp
@@ -1239,6 +1239,41 @@ bool CoroutineStmtBuilder::makeReturnOnAllocFailure() {
   return true;
 }
 
+// Collect placement arguments for allocation function of coroutine FD.
+// Return true if we collect placement arguments succesfully. Return false,
+// otherwise.
+static bool collectPlacementArgs(Sema , FunctionDecl , SourceLocation Loc,
+ SmallVectorImpl ) {
+  if (auto *MD = dyn_cast()) {
+if (MD->isInstance() && !isLambdaCallOperator(MD)) {
+  ExprResult ThisExpr = S.ActOnCXXThis(Loc);
+  if (ThisExpr.isInvalid())
+return false;
+  ThisExpr = S.CreateBuiltinUnaryOp(Loc, UO_Deref, ThisExpr.get());
+  if (ThisExpr.isInvalid())
+return false;
+  PlacementArgs.push_back(ThisExpr.get());
+}
+  }
+
+  for (auto *PD : FD.parameters()) {
+if (PD->getType()->isDependentType())
+  continue;
+
+// Build a reference to the parameter.
+auto PDLoc = PD->getLocation();
+ExprResult PDRefExpr =
+S.BuildDeclRefExpr(PD, PD->getOriginalType().getNonReferenceType(),
+   ExprValueKind::VK_LValue, PDLoc);
+if (PDRefExpr.isInvalid())
+  return false;
+
+PlacementArgs.push_back(PDRefExpr.get());
+  }
+
+  return true;
+}
+
 bool CoroutineStmtBuilder::makeNewAndDeleteExpr() {
   // Form and check allocation and deallocation calls.
   assert(!IsPromiseDependentType &&
@@ -1255,13 +1290,7 @@ bool CoroutineStmtBuilder::makeNewAndDeleteExpr() {
   // allocated, followed by the coroutine function's arguments. If a matching
   // allocation function exists, use it. Otherwise, use an allocation function
   // that just takes the requested size.
-
-  FunctionDecl *OperatorNew = nullptr;
-  FunctionDecl *OperatorDelete = nullptr;
-  FunctionDecl *UnusedResult = nullptr;
-  bool PassAlignment = false;
-  SmallVector PlacementArgs;
-
+  //
   // [dcl.fct.def.coroutine]p9
   //   An implementation may need to allocate additional storage for a
   //   coroutine.
@@ -1288,31 +1317,12 @@ bool CoroutineStmtBuilder::makeNewAndDeleteExpr() {
   // and p_i denotes the i-th function parameter otherwise. For a non-static
   // member function, q_1 is an lvalue that denotes *this; any other q_i is an
   // lvalue that denotes the parameter copy corresponding to p_i.
-  if (auto *MD = dyn_cast()) {
-if (MD->isInstance() && !isLambdaCallOperator(MD)) {
-  ExprResult ThisExpr = S.ActOnCXXThis(Loc);
-  if (ThisExpr.isInvalid())
-return false;
-  ThisExpr = S.CreateBuiltinUnaryOp(Loc, UO_Deref, ThisExpr.get());
-  if (ThisExpr.isInvalid())
-return false;
-  PlacementArgs.push_back(ThisExpr.get());
-}
-  }
-  for (auto *PD : FD.parameters()) {
-if (PD->getType()->isDependentType())
-  continue;
 
-// Build a reference to the parameter.
-auto PDLoc = PD->getLocation();
-ExprResult PDRefExpr 

[PATCH] D126187: [C++20] [Coroutines] Conform the updates for CWG issue 2585

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

> I think I have a preference to move it to CodeGenCXX anyway however, since 
> we're actually testing the code-generated output (this is not novel, we DO 
> often use CodeGen tests to make sure proper overloads/etc get called).

It makes sense. Done.

Thanks for reviewing!




Comment at: clang/docs/ReleaseNotes.rst:152
   `Issue 42372 `_.
 - Clang shouldn't lookup allocation function in global scope for coroutines
   in case it found the allocation function name in the promise_type body.

erichkeane wrote:
> I realize it isn't part of this patch, but this release note reads 
> awkwardly... How about:
> 
> 
> 
> > Clang will now find and emit a call to an allocation function in a 
> > promise_type body for coroutines.  Additionally, to implement CWG2585, a 
> > coroutine will no longer generate a call to a global allocation function 
> > with the signature (std::size_t, p0, ..., pn).
> > This fixes Issue `Issue 54881 
> > `_.
> 
> 
The suggested wording lacks a condition that we generate a call to allocation 
function in promise_type only if there is an allocation function name in the 
scope of promise_type. I try to add a condition based on your suggestions.


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

https://reviews.llvm.org/D126187

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

[PATCH] D126187: [C++20] [Coroutines] Conform the updates for CWG issue 2585

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu updated this revision to Diff 431861.
ChuanqiXu added a comment.

Address comments.


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

https://reviews.llvm.org/D126187

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Sema/SemaCoroutine.cpp
  clang/test/CodeGenCoroutines/coro-alloc-2.cpp

Index: clang/test/CodeGenCoroutines/coro-alloc-2.cpp
===
--- /dev/null
+++ clang/test/CodeGenCoroutines/coro-alloc-2.cpp
@@ -0,0 +1,30 @@
+// Tests that we wouldn't generate an allocation call in global scope with (std::size_t, p0, ..., pn)
+// RUN: %clang_cc1 %s -std=c++20 -S -triple x86_64-unknown-linux-gnu -emit-llvm -disable-llvm-passes %s -o - | FileCheck %s
+#include "Inputs/coroutine.h"
+
+namespace std {
+typedef decltype(sizeof(int)) size_t;
+}
+
+struct Allocator {};
+
+struct resumable {
+  struct promise_type {
+
+resumable get_return_object() { return {}; }
+auto initial_suspend() { return std::suspend_always(); }
+auto final_suspend() noexcept { return std::suspend_always(); }
+void unhandled_exception() {}
+void return_void(){};
+  };
+};
+
+void *operator new(std::size_t, void *);
+
+resumable f1(void *) {
+  co_return;
+}
+
+// CHECK: coro.alloc:
+// CHECK-NEXT: [[SIZE:%.+]] = call [[BITWIDTH:.+]] @llvm.coro.size.[[BITWIDTH]]()
+// CHECK-NEXT: call {{.*}} ptr @_Znwm([[BITWIDTH]] noundef [[SIZE]])
Index: clang/lib/Sema/SemaCoroutine.cpp
===
--- clang/lib/Sema/SemaCoroutine.cpp
+++ clang/lib/Sema/SemaCoroutine.cpp
@@ -1239,6 +1239,41 @@
   return true;
 }
 
+// Collect placement arguments for allocation function of coroutine FD.
+// Return true if we collect placement arguments succesfully. Return false,
+// otherwise.
+static bool collectPlacementArgs(Sema , FunctionDecl , SourceLocation Loc,
+ SmallVectorImpl ) {
+  if (auto *MD = dyn_cast()) {
+if (MD->isInstance() && !isLambdaCallOperator(MD)) {
+  ExprResult ThisExpr = S.ActOnCXXThis(Loc);
+  if (ThisExpr.isInvalid())
+return false;
+  ThisExpr = S.CreateBuiltinUnaryOp(Loc, UO_Deref, ThisExpr.get());
+  if (ThisExpr.isInvalid())
+return false;
+  PlacementArgs.push_back(ThisExpr.get());
+}
+  }
+
+  for (auto *PD : FD.parameters()) {
+if (PD->getType()->isDependentType())
+  continue;
+
+// Build a reference to the parameter.
+auto PDLoc = PD->getLocation();
+ExprResult PDRefExpr =
+S.BuildDeclRefExpr(PD, PD->getOriginalType().getNonReferenceType(),
+   ExprValueKind::VK_LValue, PDLoc);
+if (PDRefExpr.isInvalid())
+  return false;
+
+PlacementArgs.push_back(PDRefExpr.get());
+  }
+
+  return true;
+}
+
 bool CoroutineStmtBuilder::makeNewAndDeleteExpr() {
   // Form and check allocation and deallocation calls.
   assert(!IsPromiseDependentType &&
@@ -1255,13 +1290,7 @@
   // allocated, followed by the coroutine function's arguments. If a matching
   // allocation function exists, use it. Otherwise, use an allocation function
   // that just takes the requested size.
-
-  FunctionDecl *OperatorNew = nullptr;
-  FunctionDecl *OperatorDelete = nullptr;
-  FunctionDecl *UnusedResult = nullptr;
-  bool PassAlignment = false;
-  SmallVector PlacementArgs;
-
+  //
   // [dcl.fct.def.coroutine]p9
   //   An implementation may need to allocate additional storage for a
   //   coroutine.
@@ -1288,31 +1317,12 @@
   // and p_i denotes the i-th function parameter otherwise. For a non-static
   // member function, q_1 is an lvalue that denotes *this; any other q_i is an
   // lvalue that denotes the parameter copy corresponding to p_i.
-  if (auto *MD = dyn_cast()) {
-if (MD->isInstance() && !isLambdaCallOperator(MD)) {
-  ExprResult ThisExpr = S.ActOnCXXThis(Loc);
-  if (ThisExpr.isInvalid())
-return false;
-  ThisExpr = S.CreateBuiltinUnaryOp(Loc, UO_Deref, ThisExpr.get());
-  if (ThisExpr.isInvalid())
-return false;
-  PlacementArgs.push_back(ThisExpr.get());
-}
-  }
-  for (auto *PD : FD.parameters()) {
-if (PD->getType()->isDependentType())
-  continue;
 
-// Build a reference to the parameter.
-auto PDLoc = PD->getLocation();
-ExprResult PDRefExpr =
-S.BuildDeclRefExpr(PD, PD->getOriginalType().getNonReferenceType(),
-   ExprValueKind::VK_LValue, PDLoc);
-if (PDRefExpr.isInvalid())
-  return false;
-
-PlacementArgs.push_back(PDRefExpr.get());
-  }
+  FunctionDecl *OperatorNew = nullptr;
+  FunctionDecl *OperatorDelete = nullptr;
+  FunctionDecl *UnusedResult = nullptr;
+  bool PassAlignment = false;
+  SmallVector PlacementArgs;
 
   bool PromiseContainNew = [this, ]() -> bool {
 DeclarationName NewName =
@@ -1330,8 +1340,10 @@
 //   The allocation function's name is looked up by searching for it in the
 // scope of the promise 

[PATCH] D125788: [flang][driver] Rename `flang-new` as `flang`

[Peixin Qiao via Phabricator via cfe-commits]

peixin added a comment.

In D125788#3535199 , @sscalpone wrote:

> My proposal is:
>
> If the compiler compiles it, it ought to run.
> If the compiler can't compile it, it ought to clearly say why.
>
> 1. All tests of legal Fortran that compile & link must also execute correctly 
> (which excludes tests that expect to catch a problem at runtime)
> 2. For all tests with unsupported features, the compiler must issues an error 
> message and the message references the source-location of the unsupported 
> feature
>
> My preference is to use the NAG test suite.   It is not freely available.

I tested a lot of test cases (mostly Fortran 95 code) and have several detailed 
questions about the reasonable quality bar.

1. Should some incorrect execution results be changed into one TODO if there is 
no plan to support it soon? One example is derived type array in forall 
(https://github.com/flang-compiler/f18-llvm-project/issues/1598).

2. What if the case fails in lowering with a "fatal internal error", but the 
real reason is the incorrect semantic analysis? Should it either be supported, 
or be turned from the "fatal internal error" into TODO?

3. What about the edge cases? For those with incorrect execution results, turn 
them into TODO? One example is D125632 .

4. What about some dangerous usage? Usually, gfortran can report a lot of 
warnings for the dangerous scenarios such as string length mismatch, external 
procedure type kind mismatch, the test case in D125891 
, etc. Maybe this is not in priority.

5. Are the rules also applied to Fortran 2003, 2008 and 2018 code, or only 
restricted to Fortran 95 code?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125788

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

[PATCH] D125847: LTO: Decide upfront whether to use opaque/non-opaque pointer types

[Matthias Braun via Phabricator via cfe-commits]

MatzeB updated this revision to Diff 431853.
MatzeB marked an inline comment as done.
MatzeB added a comment.

Enable LTO by default and fix a whole bunch of LTO tests because of it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125847

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/CodeGen/thinlto-inline-asm2.c
  clang/test/Driver/arm-float-abi-lto.c
  clang/test/Driver/lto-no-opaque-pointers.c
  clang/test/Driver/lto-opaque-pointers.c
  clang/test/Driver/memtag_lto.c
  lld/ELF/Config.h
  lld/ELF/Driver.cpp
  lld/ELF/LTO.cpp
  lld/ELF/Options.td
  lld/test/ELF/lto/discard-value-names.ll
  lld/test/ELF/lto/ltopasses-basic.ll
  lld/test/ELF/lto/type-merge.ll
  lld/test/ELF/lto/type-merge2.ll
  lld/test/ELF/lto/wrap-unreferenced-before-codegen.test
  llvm/docs/OpaquePointers.rst
  llvm/include/llvm/LTO/Config.h
  llvm/test/Analysis/StackSafetyAnalysis/ipa-alias.ll
  llvm/test/Analysis/StackSafetyAnalysis/ipa.ll
  llvm/test/LTO/Resolution/X86/alias-alias.ll
  llvm/test/LTO/Resolution/X86/comdat.ll
  llvm/test/LTO/Resolution/X86/ifunc2.ll
  llvm/test/LTO/Resolution/X86/local-def-dllimport.ll
  llvm/test/LTO/X86/Inputs/opaque-pointers.ll
  llvm/test/LTO/X86/cfi_jt_aliases.ll
  llvm/test/LTO/X86/mix-opaque-typed.ll
  llvm/test/LTO/X86/type-mapping-bug4.ll
  llvm/test/ThinLTO/X86/Inputs/import-constant.ll
  llvm/test/ThinLTO/X86/cfi-devirt.ll
  llvm/test/ThinLTO/X86/cfi-unsat.ll
  llvm/test/ThinLTO/X86/devirt-after-icp.ll
  llvm/test/ThinLTO/X86/devirt2.ll
  llvm/test/ThinLTO/X86/devirt_check.ll
  llvm/test/ThinLTO/X86/devirt_promote.ll
  llvm/test/ThinLTO/X86/devirt_single_hybrid.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-unknown.ll
  llvm/test/ThinLTO/X86/globals-import-blockaddr.ll
  llvm/test/ThinLTO/X86/import-constant.ll
  llvm/test/ThinLTO/X86/import-dsolocal.ll
  llvm/test/ThinLTO/X86/index-const-prop-gvref-pie.ll
  llvm/test/ThinLTO/X86/index-const-prop-gvref.ll
  llvm/test/ThinLTO/X86/index-const-prop-linkage.ll
  llvm/test/ThinLTO/X86/reference_non_importable.ll
  llvm/test/ThinLTO/X86/weak_externals.ll
  llvm/tools/gold/gold-plugin.cpp
  llvm/tools/llvm-lto2/llvm-lto2.cpp

Index: llvm/tools/llvm-lto2/llvm-lto2.cpp
===
--- llvm/tools/llvm-lto2/llvm-lto2.cpp
+++ llvm/tools/llvm-lto2/llvm-lto2.cpp
@@ -143,6 +143,10 @@
  cl::desc("Run PGO context sensitive IR instrumentation"),
  cl::init(false), cl::Hidden);
 
+static cl::opt LtoOpaquePointers("lto-opaque-pointers",
+   cl::desc("Enable opaque pointer types"),
+   cl::init(true), cl::Hidden);
+
 static cl::opt
 DebugPassManager("debug-pass-manager", cl::init(false), cl::Hidden,
  cl::desc("Print pass management debugging information"));
@@ -291,6 +295,7 @@
   Conf.StatsFile = StatsFile;
   Conf.PTO.LoopVectorization = Conf.OptLevel > 1;
   Conf.PTO.SLPVectorization = Conf.OptLevel > 1;
+  Conf.OpaquePointers = LtoOpaquePointers;
 
   ThinBackend Backend;
   if (ThinLTODistributedIndexes)
Index: llvm/tools/gold/gold-plugin.cpp
===
--- llvm/tools/gold/gold-plugin.cpp
+++ llvm/tools/gold/gold-plugin.cpp
@@ -208,6 +208,8 @@
   static std::string stats_file;
   // Asserts that LTO link has whole program visibility
   static bool whole_program_visibility = false;
+  // Use opaque pointer types.
+  static bool opaque_pointers = true;
 
   // Optimization remarks filename, accepted passes and hotness options
   static std::string RemarksFilename;
@@ -308,6 +310,10 @@
   RemarksFormat = std::string(opt);
 } else if (opt.consume_front("stats-file=")) {
   stats_file = std::string(opt);
+} else if (opt == "opaque-pointers") {
+  opaque_pointers = true;
+} else if (opt == "no-opaque-pointers") {
+  opaque_pointers = false;
 } else {
   // Save this option to pass to the code generator.
   // ParseCommandLineOptions() expects argv[0] to be program name. Lazily
@@ -957,6 +963,8 @@
 
   Conf.HasWholeProgramVisibility = options::whole_program_visibility;
 
+  Config.OpaquePointers = options.opaque_pointers;
+
   Conf.StatsFile = options::stats_file;
   return std::make_unique(std::move(Conf), Backend,
 options::ParallelCodeGenParallelismLevel);
Index: llvm/test/ThinLTO/X86/weak_externals.ll
===
--- llvm/test/ThinLTO/X86/weak_externals.ll
+++ llvm/test/ThinLTO/X86/weak_externals.ll
@@ -10,9 +10,9 @@
 ; RUN: llvm-dis %t.out.1.2.internalize.bc -o - | FileCheck %s --check-prefix=INTERNALIZE
 
 ; CHECK: @_ZZN9SingletonI1SE11getInstanceEvE8instance = available_externally dso_local global %struct.S zeroinitializer
-; CHECK: @_ZZN9SingletonI1SE11getInstanceEvE13instance_weak = 

[PATCH] D125904: [Cuda] Use fallback method to mangle externalized decls if no CUID given

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

In D125904#3535905 , @jhuber6 wrote:

> I can't think of a way to generate these new symbols, we'd need to somehow 
> have a list of all the static entries that need new symbols and then modify 
> the object file after its been made. Not sure if this is possible in general 
> considering the vendor linkers might not behave. I'm definitely open to 
> discussion though, I'd love to have a solution for this.

Thinking further, we could theoretically read all the offloading entries via 
the object files, since we already scan for the `.llvm.offloading` section, we 
would just need to look in the same files for all the `omp_offload_entries`. It 
would be somewhat difficult to extract the strings, it's theoretically 
possible. Then we could do a sort of device-side registration where we create a 
new `.ll` file containing some new symbols to hook up to those offloading 
entries. The problem at this point, is even if we had this device glue, how 
would we register the static variable's pointer? The CUDA runtime looks up 
symbols by name, so we'd need a symbol with some arbitrary name, whose pointer 
somehow maps to an existing static variable. Another problem is we'd have 
duplicate names in the offloading entry, so we'd need to change those somehow 
to match up with the ones on the device.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125904

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

[PATCH] D126282: [Driver] Add more options for target AVR when linking with lld

[Ben Shi via Phabricator via cfe-commits]

benshi001 added inline comments.



Comment at: clang/lib/Driver/ToolChains/AVR.cpp:395
+
+unsigned GetMCUEEPROMSize(StringRef MCUName) {
+  for (const auto  : MCUInfo)

Add three helper functions for the newly added fields.


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

https://reviews.llvm.org/D126282

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

[PATCH] D126192: [Driver] Support linking with lld for target AVR

[Ben Shi via Phabricator via cfe-commits]

benshi001 added inline comments.



Comment at: clang/lib/Driver/ToolChains/AVR.cpp:441
+if (!llvm::sys::fs::can_execute(FullPath))
+  D.Diag(diag::err_drv_invalid_linker_name) << Linker;
+else

We report an error if the linker specified via `-fuse-ld` is not executable.



Comment at: clang/lib/Driver/ToolChains/AVR.cpp:526
+  CmdArgs.push_back(Args.MakeArgString("__vectors"));
+  // We must explicitly spefify the linker script (for lld), which has
+  // already been integrated into avr-libc, and whose full path is

benshi001 wrote:
> I am not familiar with avr-ld internal, but it will implicitly:
> 
> 1. Use `__vectors` as the entry;
> 2. Use `$AVR-LIBC/lib/ldscripts/$FamilyName.xn` as the linker script;
>  
Use `$AVR-LIBC/lib/ldscripts/$FamilyName.x` as the default linker script.


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

https://reviews.llvm.org/D126192

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

[PATCH] D126031: [libclang] add supporting for indexing/visiting C++ concepts

[Jake Egan via Phabricator via cfe-commits]

Jake-Egan added a comment.

@arphaman Thanks for the quick action. The tests pass on a clean build 
https://lab.llvm.org/buildbot/#/builders/214/builds/1493, so that's probably 
why there was trouble reproducing. I think we could revert 
1b34f1e996565bc5e4f2be14b89f881f8fe0f3b9 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126031

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

[PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

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

rsmith added a comment.
Herald added a project: All.

I've not looked at the test changes in any detail; please let me know if 
there's anything in there that deserves special attention.




Comment at: clang-tools-extra/clang-change-namespace/ChangeNamespace.cpp:567-577
-if (Loc.getTypeLocClass() == TypeLoc::Elaborated) {
-  NestedNameSpecifierLoc NestedNameSpecifier =
-  Loc.castAs().getQualifierLoc();
-  // This happens for friend declaration of a base class with injected 
class
-  // name.
-  if (!NestedNameSpecifier.getNestedNameSpecifier())
-return;

Can we keep at least the second check here?



Comment at: 
clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.h:28
 NameSpecifierNestingThreshold(
-Options.get("NameSpecifierNestingThreshold", 3U)) {}
+Options.get("NameSpecifierNestingThreshold", 2U)) {}
 

If this is an externally-visible option that might be in someone's config file, 
can we keep it meaning the same thing? Eg, start with a `NestingLevel` of `1`, 
not `0`, so it counts the number of name components rather than the number of 
`::`s.



Comment at: clang/include/clang/AST/TypeLoc.h:2255-2257
+  unsigned getExtraLocalDataSize() const {
+return !isEmpty() ? sizeof(ElaboratedLocInfo) : 0;
+  }

Instead of using a `LocalData` type of `void` and adding `llvm::SizeOf` etc, 
how about using a local data type of `ElaboratedLocInfo` and overriding 
`getLocalDataSize` to sometimes return 0 if you don't actually want to store 
local data? `AdjustedTypeLoc` does something similar already.



Comment at: clang/lib/AST/FormatString.cpp:979-983
+  for (const TypedefNameDecl *Typedef;; QT = Typedef->getUnderlyingType()) {
+const auto *TT = QT->getAs();
+if (!TT)
+  return false;
+Typedef = TT->getDecl();

Optional, but I think this is a bit clearer. (You'd need to re-add the `return 
false;` after the loop too.)



Comment at: clang/lib/CodeGen/CGCall.cpp:2790
   if (!AVAttr)
-if (const auto *TOTy = dyn_cast(OTy))
+if (const auto *TOTy = OTy->getAs())
   AVAttr = TOTy->getDecl()->getAttr();

Hm, this and the checks for this attribute in CGExprScalar.cpp aren't fully 
fixed: if we don't find the attribute on a typedef we should look inside that 
typedef to see if its target is another typedef. See `TypeHasMayAlias` for an 
example of code doing it correctly. Might make sense to land that as a separate 
change since it's a pre-existing bug?



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:2210
 case Type::ExtInt:
   llvm_unreachable("type class is never variably-modified!");
 

Hm, this seems to already be reachable for an `ElaboratedType`, even without 
this change:

```
void f(int n) {
  using T = int[n];
  struct A {
using U = T;
  };
  A::U au;
}
```

... but I think that's actually a bug. Bad things are going to happen if the 
members of `A` mention `U`.

Filed that as https://github.com/llvm/llvm-project/issues/55686.



Comment at: clang/lib/Sema/SemaTemplate.cpp:3982
+  // Create an elaborated-type-specifier containing the nested-name-specifier.
+  QualType ElTy = getElaboratedType(ETK_None, SS, SpecTy);
+  ElaboratedTypeLoc ElabTL = TLB.push(ElTy);

I think in the case we have a constructor or destructor name, we should pass in 
an empty scope specifier here, so that pretty-printing 
`Namespace::Class::Class() {}` produces just that instead of 
`Namespace::Class::Namespace::Class) {}`. (The first name specifier comes from 
printing the declaration's qualified name, and the second one would come from 
printing the constructor type.)



Comment at: llvm/include/llvm/Support/SizeOf.h:20-23
+/// A sizeof operator stand-in which supports `sizeof(void) == 0`.
+///
+template  struct SizeOf { static constexpr size_t value = sizeof(T); 
};
+template <> struct SizeOf { static constexpr size_t value = 0; };

I think it's too surprising to call this simply `SizeOf`, especially given that 
under https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0146r1.html we 
might eventually see C++ defining `sizeof(void)` as some non-zero value.



Comment at: llvm/include/llvm/Support/SizeOf.h:25-32
+/// An alignof operator stand-in which supports `alignof(void) == 1`.
+///
+template  struct AlignOf {
+  static constexpr size_t value = alignof(T);
+};
+template <> struct AlignOf { static constexpr size_t value = 1; };
+

There's already a (different!) `llvm::AlignOf` in `llvm/Support/AlignOf.h`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112374

[PATCH] D125052: [HLSL] Enable vector types for hlsl.

[Xiang Li via Phabricator via cfe-commits]

python3kgae added inline comments.



Comment at: clang/lib/Basic/LangOptions.cpp:122
+  if (Opts.HLSL)
+Includes.push_back("hlsl.h");
 

Anastasia wrote:
> Is this header expected to be large? You might want to flag up in the 
> description of the review and the comments in the header itself what content 
> is expected to be there.
> 
> If the file is expected to be large it might make sense to add a flag that 
> would disable this include. You can then for example use bare clang without 
> this header for all the tests that don't require functionality from the 
> header to reduce the testing time.
It might be large when more things are added.
I'll add an option to disable the include.



Comment at: clang/test/CodeGenHLSL/basic_types.hlsl:1
+// RUN: %clang_dxc  -Tlib_6_7 -Fo - %s | FileCheck %s
+

Anastasia wrote:
> Technically mapping into IR types might be target specific, so passing the 
> triple is necessary for this test to work correctly. Alternatively you can 
> switch to AST dump checking, however even that might be target specific in 
> some cases.
The option -T lib_6_7 decides the triple.

"-Tlib_6_7 -Fo -" will be translated into
"-cc1" "-triple" "dxil--shadermodel6.7-library"  "-o" "-" "-x" "hlsl" for cc1.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125052

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

[PATCH] D126302: [PowerPC] Diagnose invalid combination with Altivec, VSX and soft-float

[Laurentiu Tertan via Phabricator via cfe-commits]

ltertan added inline comments.



Comment at: clang/lib/Basic/Targets/PPC.cpp:455
+   << "-maltivec";
+
+  // Cannot allow soft-float with Altivec.

Do we also need to return from here?



Comment at: clang/lib/Basic/Targets/PPC.cpp:461
+   << "-mno-altivec";
+
   // vsx was not explicitly turned off.

Do we also need to return from here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126302

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

[PATCH] D126347: [pseudo] WIP: GSS Node refcount (smart pointers)

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: hokein.
Herald added a subscriber: mgrang.
Herald added a project: All.
sammccall requested review of this revision.
Herald added subscribers: cfe-commits, alextsao1999.
Herald added a project: clang-tools-extra.

Here is the version where ownership is managed by smart-pointers.
It uses some thread_local magic but it's not hairy, and it seems much easier to
reason about to me.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126347

Files:
  clang-tools-extra/pseudo/include/clang-pseudo/GLR.h
  clang-tools-extra/pseudo/lib/GLR.cpp
  clang-tools-extra/pseudo/unittests/GLRTest.cpp

Index: clang-tools-extra/pseudo/unittests/GLRTest.cpp
===
--- clang-tools-extra/pseudo/unittests/GLRTest.cpp
+++ clang-tools-extra/pseudo/unittests/GLRTest.cpp
@@ -36,10 +36,10 @@
 MATCHER_P(parsedSymbol, FNode, "") { return arg->Payload == FNode; }
 MATCHER_P(parsedSymbolID, SID, "") { return arg->Payload->symbol() == SID; }
 
-testing::Matcher
-parents(llvm::ArrayRef Parents) {
-  return testing::Property(::Node::parents,
-   testing::UnorderedElementsAreArray(Parents));
+testing::Matcher
+parents(llvm::ArrayRef Parents) {
+  return testing::Pointee(testing::Property(
+  ::Node::parents, testing::UnorderedElementsAreArray(Parents)));
 }
 
 class GLRTest : public ::testing::Test {
@@ -84,22 +84,14 @@
   }
 
   NewHeadCallback captureNewHeads() {
-return [this](const GSS::Node *NewHead) {
-  GSStack.ref(NewHead);
-  NewHeadResults.push_back(NewHead);
-};
+return [this](GSS::NodePtr P) { NewHeadResults.push_back(std::move(P)); };
   };
 
 protected:
-  ~GLRTest() {
-for (auto *N : NewHeadResults)
-  GSStack.unref(N);
-  }
-
   std::unique_ptr G;
   ForestArena Arena;
   GSS GSStack;
-  std::vector NewHeadResults;
+  std::vector NewHeadResults;
 };
 
 TEST_F(GLRTest, ShiftMergingHeads) {
@@ -113,15 +105,14 @@
   //   0---1---4
   //   └---2---┘
   //   └---3---5
-  auto *GSSNode0 =
+  auto GSSNode0 =
   GSStack.addNode(/*State=*/0, /*ForestNode=*/nullptr, /*Parents=*/{});
-  auto *GSSNode1 = GSStack.addNode(/*State=*/0, /*ForestNode=*/nullptr,
+  auto GSSNode1 = GSStack.addNode(/*State=*/0, /*ForestNode=*/nullptr,
/*Parents=*/{GSSNode0});
-  auto *GSSNode2 = GSStack.addNode(/*State=*/0, /*ForestNode=*/nullptr,
+  auto GSSNode2 = GSStack.addNode(/*State=*/0, /*ForestNode=*/nullptr,
/*Parents=*/{GSSNode0});
-  auto *GSSNode3 = GSStack.addNode(/*State=*/0, /*ForestNode=*/nullptr,
-   /*Parents=*/{GSSNode0});
-  GSStack.unref(GSSNode0);
+  auto GSSNode3 = GSStack.addNode(/*State=*/0, /*ForestNode=*/nullptr,
+  /*Parents=*/{GSSNode0});
 
   buildGrammar({}, {}); // Create a fake empty grammar.
   LRTable T = LRTable::buildForTests(G->table(), /*Entries=*/{});
@@ -139,8 +130,7 @@
   AllOf(state(4), parsedSymbol(),
 parents({GSSNode1, GSSNode2})),
   AllOf(state(5), parsedSymbol(),
-parents({GSSNode3}
-  << NewHeadResults;
+parents({GSSNode3};
 }
 
 TEST_F(GLRTest, ReduceConflictsSplitting) {
@@ -157,24 +147,21 @@
   G->table(), {{/*State=*/0, id("class-name"), Action::goTo(2)},
{/*State=*/0, id("enum-name"), Action::goTo(3)}});
 
-  const auto *GSSNode0 =
+  auto GSSNode0 =
   GSStack.addNode(/*State=*/0, /*ForestNode=*/nullptr, /*Parents=*/{});
-  const auto *GSSNode1 =
+  auto GSSNode1 =
   GSStack.addNode(3, (tok::identifier, 0), {GSSNode0});
-  GSStack.unref(GSSNode0);
-  GSStack.ref(GSSNode1);
 
   std::vector PendingReduce = {
   {GSSNode1, Action::reduce(ruleFor("class-name"))},
   {GSSNode1, Action::reduce(ruleFor("enum-name"))}};
-  glrReduce(PendingReduce, {*G, Table, Arena, GSStack},
-captureNewHeads());
+  glrReduce(PendingReduce, {*G, Table, Arena, GSStack}, captureNewHeads());
   EXPECT_THAT(NewHeadResults,
   testing::UnorderedElementsAre(
   AllOf(state(2), parsedSymbolID(id("class-name")),
 parents({GSSNode0})),
   AllOf(state(3), parsedSymbolID(id("enum-name")),
-parents({GSSNode0} << NewHeadResults;
+parents({GSSNode0};
 }
 
 TEST_F(GLRTest, ReduceSplittingDueToMultipleBases) {
@@ -190,15 +177,13 @@
   auto *ClassNameNode = (id("class-name"), /*TokenIndex=*/0);
   auto *EnumNameNode = (id("enum-name"), /*TokenIndex=*/0);
 
-  const auto *GSSNode2 =
+  auto GSSNode2 =
   GSStack.addNode(/*State=*/2, /*ForestNode=*/ClassNameNode, /*Parents=*/{});
-  const auto *GSSNode3 =
+  auto GSSNode3 =
   

[PATCH] D125904: [Cuda] Use fallback method to mangle externalized decls if no CUID given

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

In D125904#3535830 , @tra wrote:

> I'm still itching to figure out a way to avoid CUID altogether and with the 
> new driver it may be possible.

I would be 100% in favor of working around this if possible, it's proving to be 
one of the most painful parts of the process.

> CUID serves two purposes:
> a) avoid name conflicts during device-side linking ("must be globally unique" 
> part)
> b) allow host to refer to something in the GPU executable ("stable within TU" 
> part)
>
> My understanding that we already collect the data about all offloading 
> entities and that include those we have to externalize. We also postpone 
> generation of the registration glue to the final linking step.

Yes, we would have all those entries see here 
. The final linker just gets a pointer to 
`__start_omp_offloading_entries` so we can iterate this at runtime.

> Let's suppose that we do not externalize those normally-internal symbols. The 
> offloading table would still have entries for them, but there will be no 
> issue with name conflicts during linking, as they do remain internal.

We would also need to make sure that they're used so they don't get optimized 
out.

> During the final linking, if an an offloading entity uses a pointer w/o a 
> public symbol, we would be in position to generate a unique one, using the 
> pointer value in the offload table entry. Linker can just use a free-running 
> counter for the suffix, or could just generate a completely new symbol. It 
> does not matter.

This is the part I'm not sure about, how would we generate new symbols during 
the linking stage? We can only iterate the offloading entry table after the 
final linking, which is when we're already supposed to have a fully linked and 
registered module. We could potentially generate the same kind of table for the 
device, but I don't think `nvlink` would perform the same linker magic to merge 
those entries.

> When we generate the host-side registration glue, we'll use the name of that 
> generated symbol.

When we make the registration glue we haven't created the final executable, so 
I don't think we could modify existing entries, only create new ones.

> In the end linking will work exactly as it would for C++ (modulo having 
> offloading tables) and host/device registration will be ensured by telling 
> host side which symbols to use, instead of assuming that we've happened to 
> generate exactly the same unique suffix on both sides.
>
> @yaxunl -- do you see any holes in this approach?

I can't think of a way to generate these new symbols, we'd need to somehow have 
a list of all the static entries that need new symbols and then modify the 
object file after its been made. Not sure if this is possible in general 
considering the vendor linkers might not behave. I'm definitely open to 
discussion though, I'd love to have a solution for this.




Comment at: clang/lib/CodeGen/CodeGenModule.cpp:6836
+
+  // If the CUID is not specified we try to generate a unique postfix.
+  if (getLangOpts().CUID.empty()) {

tra wrote:
> jhuber6 wrote:
> > jhuber6 wrote:
> > > tra wrote:
> > > > jhuber6 wrote:
> > > > > tra wrote:
> > > > > > > However, [CUID] is not always availible. 
> > > > > > 
> > > > > > The question is -- when and why is it not available? I'm getting 
> > > > > > the feeling that we're fixing the consequence here, not the root 
> > > > > > cause.
> > > > > > 
> > > > > > Is there a reason we can't make sure that the driver always 
> > > > > > generates a cuid for offload subcompilations and error out if it's 
> > > > > > needed but is not provided?
> > > > > > That would make this fallback unnecessary and would be a more 
> > > > > > robust approach in general.
> > > > > > 
> > > > > So, I'm more in favor of this approach because it doesn't require 
> > > > > extra intervention from the compiler driver, this makes it less 
> > > > > convoluted to do split compilation since we don't have an extra 
> > > > > arguments. The way I would prefer it, is that we do this implicitly 
> > > > > by default without requiring extra thought from the driver, but if 
> > > > > it's not good enough we can support the manual `CUID` approach to let 
> > > > > the user override it. I think this is a cleaner implementation, and 
> > > > > is mostly coming from my support for CUDA in the new driver which 
> > > > > currently doesn't implement the CUID as we do with the old driver. 
> > > > > Generally I'd prefer things to behave independent of the driver, so 
> > > > > we can consider host and device compilation more separately.
> > > > > So, I'm more in favor of this approach because it doesn't require 
> > > > > extra intervention from the compiler driver
> > > > 
> > > > We need the driver intervention for any cc1 compilations anyways, so 
> > > > this does not buy us anything.  While you can run a 

[PATCH] D126346: [Clang] Make PIC check comprehensive with respect to relocation models.

[Zhiyao Ma via Phabricator via cfe-commits]

ZhiyaoMa98 created this revision.
ZhiyaoMa98 added reviewers: rsmith, llvm-commits.
Herald added a project: All.
ZhiyaoMa98 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Add missing if branch for "ropi", "rwpi" and "ropi-rwpi" relocation model when 
initializing the PIC boolean variable.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126346

Files:
  clang/tools/driver/cc1as_main.cpp


Index: clang/tools/driver/cc1as_main.cpp
===
--- clang/tools/driver/cc1as_main.cpp
+++ clang/tools/driver/cc1as_main.cpp
@@ -403,6 +403,12 @@
 PIC = false;
   } else if (Opts.RelocationModel == "pic") {
 PIC = true;
+  } else if (Opts.RelocationModel == "ropi-rwpi") {
+PIC = true;
+  } else if (Opts.RelocationModel == "ropi") {
+PIC = false;
+  } else if (Opts.RelocationModel == "rwpi") {
+PIC = false;
   } else {
 assert(Opts.RelocationModel == "dynamic-no-pic" &&
"Invalid PIC model!");


Index: clang/tools/driver/cc1as_main.cpp
===
--- clang/tools/driver/cc1as_main.cpp
+++ clang/tools/driver/cc1as_main.cpp
@@ -403,6 +403,12 @@
 PIC = false;
   } else if (Opts.RelocationModel == "pic") {
 PIC = true;
+  } else if (Opts.RelocationModel == "ropi-rwpi") {
+PIC = true;
+  } else if (Opts.RelocationModel == "ropi") {
+PIC = false;
+  } else if (Opts.RelocationModel == "rwpi") {
+PIC = false;
   } else {
 assert(Opts.RelocationModel == "dynamic-no-pic" &&
"Invalid PIC model!");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126345: [Clang][CoverageMapping] Fix switch case counter compile time explosion

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

bruno created this revision.
bruno added reviewers: alanphipps, vsk, zequanwu.
Herald added subscribers: hoy, modimo, wenlei, hiraditya.
Herald added a project: All.
bruno requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

After D84467 , C++ generated code with huge 
number of switch cases chokes badly while emitting
coverage mapping, in our specific testcase (~72k cases), it won't stop after 
hours.

This patch makes the frontend job to finish in 4.5s and shrinks down 
`@__covrec_`
by 288k when compared to disabling simplification altogether.

There's probably no good way to create a testcase for this, but it's easy to
reproduce, just add thousands of cases in the below switch, and build with
`-fprofile-instr-generate -fcoverage-mapping`.

  enum type : int {
   FEATURE_INVALID = 0,
   FEATURE_A = 1,
   ...
  };
  
  const char *to_string(type e) {
switch (e) {
case type::FEATURE_INVALID: return "FEATURE_INVALID";
case type::FEATURE_A: return "FEATURE_A";}
...
}


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126345

Files:
  clang/lib/CodeGen/CoverageMappingGen.cpp
  llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h
  llvm/lib/ProfileData/Coverage/CoverageMapping.cpp


Index: llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
===
--- llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
+++ llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
@@ -123,13 +123,15 @@
   return C;
 }
 
-Counter CounterExpressionBuilder::add(Counter LHS, Counter RHS) {
-  return simplify(get(CounterExpression(CounterExpression::Add, LHS, RHS)));
+Counter CounterExpressionBuilder::add(Counter LHS, Counter RHS, bool Simplify) 
{
+  auto Cnt = get(CounterExpression(CounterExpression::Add, LHS, RHS));
+  return Simplify ? simplify(Cnt) : Cnt;
 }
 
-Counter CounterExpressionBuilder::subtract(Counter LHS, Counter RHS) {
-  return simplify(
-  get(CounterExpression(CounterExpression::Subtract, LHS, RHS)));
+Counter CounterExpressionBuilder::subtract(Counter LHS, Counter RHS,
+   bool Simplify) {
+  auto Cnt = get(CounterExpression(CounterExpression::Subtract, LHS, RHS));
+  return Simplify ? simplify(Cnt) : Cnt;
 }
 
 void CounterMappingContext::dump(const Counter , raw_ostream ) const {
Index: llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h
===
--- llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h
+++ llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h
@@ -195,11 +195,11 @@
   ArrayRef getExpressions() const { return Expressions; }
 
   /// Return a counter that represents the expression that adds LHS and RHS.
-  Counter add(Counter LHS, Counter RHS);
+  Counter add(Counter LHS, Counter RHS, bool Simplify = true);
 
   /// Return a counter that represents the expression that subtracts RHS from
   /// LHS.
-  Counter subtract(Counter LHS, Counter RHS);
+  Counter subtract(Counter LHS, Counter RHS, bool Simplify = true);
 };
 
 using LineColPair = std::pair;
Index: clang/lib/CodeGen/CoverageMappingGen.cpp
===
--- clang/lib/CodeGen/CoverageMappingGen.cpp
+++ clang/lib/CodeGen/CoverageMappingGen.cpp
@@ -550,17 +550,18 @@
   Counter GapRegionCounter;
 
   /// Return a counter for the subtraction of \c RHS from \c LHS
-  Counter subtractCounters(Counter LHS, Counter RHS) {
-return Builder.subtract(LHS, RHS);
+  Counter subtractCounters(Counter LHS, Counter RHS, bool Simplify = true) {
+return Builder.subtract(LHS, RHS, Simplify);
   }
 
   /// Return a counter for the sum of \c LHS and \c RHS.
-  Counter addCounters(Counter LHS, Counter RHS) {
-return Builder.add(LHS, RHS);
+  Counter addCounters(Counter LHS, Counter RHS, bool Simplify = true) {
+return Builder.add(LHS, RHS, Simplify);
   }
 
-  Counter addCounters(Counter C1, Counter C2, Counter C3) {
-return addCounters(addCounters(C1, C2), C3);
+  Counter addCounters(Counter C1, Counter C2, Counter C3,
+  bool Simplify = true) {
+return addCounters(addCounters(C1, C2, Simplify), C3, Simplify);
   }
 
   /// Return the region counter for the given statement.
@@ -1317,11 +1318,16 @@
 const SwitchCase *Case = S->getSwitchCaseList();
 for (; Case; Case = Case->getNextSwitchCase()) {
   HasDefaultCase = HasDefaultCase || isa(Case);
-  CaseCountSum = addCounters(CaseCountSum, getRegionCounter(Case));
+  CaseCountSum =
+  addCounters(CaseCountSum, getRegionCounter(Case), 
/*Simplify=*/false);
   createSwitchCaseRegion(
   Case, getRegionCounter(Case),
   subtractCounters(ParentCount, getRegionCounter(Case)));
 }
+// Simplify is skipped while building the counters above: it can get really
+// 

[PATCH] D124751: [HLSL] Support -E option for HLSL.

[Xiang Li via Phabricator via cfe-commits]

python3kgae added a comment.

In D124751#3529652 , @MaskRay wrote:

> In D124751#3513513 , @python3kgae 
> wrote:
>
>> In D124751#3513283 , @MaskRay 
>> wrote:
>>
>>> Is there a specification or reference implementation stating that -E is 
>>> used?
>>>
 Option<["--", "/", "-"], "E",
>>>
>>> Do you need the prefix `--`? You may define something like `CLFlag`. I have 
>>> missed previous patches, but if `/` options are not necessary, removing 
>>> them will be the best to avoid collision with filenames starting with `/`.
>>
>> Unfortunately, '/' is necessary. dxc allow both '-' and '/' like 'CLFlag'.
>> Remove '/' means existing customers may need to change their command line to 
>> compile hlsl.
>> And add '--' feels not hurt anyone, that's why I choose to add '--' to 
>> work-around the conflict.
>
> OK. I guess you have a pre-existing implementation using `-E` and the 
> upstreaming implementation wants to be compatible.
> I wonder why the new tool needs to reuse 
> `clang/include/clang/Driver/Options.td`. ISTM it would be cleaner to use a 
> new .td file.

I tried to create a DxcOptions.td which only have dxc options and core options. 
Then create OptTable from DxcOptions.td and use the Dxc OptTable when ParseArgs 
in Driver::ParseArgStrings. It works fine.

But after ParseArgs, there're lots of code in Driver::BuildCompilation use 
options::OPT_* enum which depends on Options.td.  Cannot find a clean solution 
to switch to DxcOptions while share code about core options in 
Driver::BuildCompilation. Do you have any suggestions about how to update 
options::OPT_* enum after switch to new .td file?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124751

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

[PATCH] D125904: [Cuda] Use fallback method to mangle externalized decls if no CUID given

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

I'm still itching to figure out a way to avoid CUID altogether and with the new 
driver it may be possible.
CUID serves two purposes:
a) avoid name conflicts during device-side linking ("must be globally unique" 
part)
b) allow host to refer to something in the GPU executable ("stable within TU" 
part)

My understanding that we already collect the data about all offloading entities 
and that include those we have to externalize. We also postpone generation of 
the registration glue to the final linking step.

Let's suppose that we do not externalize those normally-internal symbols. The 
offloading table would still have entries for them, but there will be no issue 
with name conflicts during linking, as they do remain internal.
During the final linking, if an an offloading entity uses a pointer w/o a 
public symbol, we would be in position to generate a unique one, using the 
pointer value in the offload table entry. Linker can just use a free-running 
counter for the suffix, or could just generate a completely new symbol. It does 
not matter.
When we generate the host-side registration glue, we'll use the name of that 
generated symbol.

In the end linking will work exactly as it would for C++ (modulo having 
offloading tables) and host/device registration will be ensured by telling host 
side which symbols to use, instead of assuming that we've happened to generate 
exactly the same unique suffix on both sides.

@yaxunl -- do you see any holes in this approach?




Comment at: clang/lib/CodeGen/CodeGenModule.cpp:6836
+
+  // If the CUID is not specified we try to generate a unique postfix.
+  if (getLangOpts().CUID.empty()) {

jhuber6 wrote:
> jhuber6 wrote:
> > tra wrote:
> > > jhuber6 wrote:
> > > > tra wrote:
> > > > > > However, [CUID] is not always availible. 
> > > > > 
> > > > > The question is -- when and why is it not available? I'm getting the 
> > > > > feeling that we're fixing the consequence here, not the root cause.
> > > > > 
> > > > > Is there a reason we can't make sure that the driver always generates 
> > > > > a cuid for offload subcompilations and error out if it's needed but 
> > > > > is not provided?
> > > > > That would make this fallback unnecessary and would be a more robust 
> > > > > approach in general.
> > > > > 
> > > > So, I'm more in favor of this approach because it doesn't require extra 
> > > > intervention from the compiler driver, this makes it less convoluted to 
> > > > do split compilation since we don't have an extra arguments. The way I 
> > > > would prefer it, is that we do this implicitly by default without 
> > > > requiring extra thought from the driver, but if it's not good enough we 
> > > > can support the manual `CUID` approach to let the user override it. I 
> > > > think this is a cleaner implementation, and is mostly coming from my 
> > > > support for CUDA in the new driver which currently doesn't implement 
> > > > the CUID as we do with the old driver. Generally I'd prefer things to 
> > > > behave independent of the driver, so we can consider host and device 
> > > > compilation more separately.
> > > > So, I'm more in favor of this approach because it doesn't require extra 
> > > > intervention from the compiler driver
> > > 
> > > We need the driver intervention for any cc1 compilations anyways, so this 
> > > does not buy us anything.  While you can run a sub-compilation manually 
> > > with handcrafted cc1 flags, that's not a practical use case. The driver 
> > > is the ultimate source of cc1 flags.
> > > 
> > > > this makes it less convoluted to do split compilation since we don't 
> > > > have an extra arguments.
> > > 
> > > For CUDA/HIP sub-compilation should be done with clang 
> > > --cuda-host-only/--cuda-device-only.  Whether the driver supplies yet 
> > > another cc1 option, --cuid=... makes no difference to the user launching 
> > > such sub-compilation. 
> > > 
> > > > The way I would prefer it, is that we do this implicitly by default 
> > > > without requiring extra thought from the driver, but if it's not good 
> > > > enough we can support the manual CUID approach to let the user override 
> > > > it.
> > > 
> > > I agree that we can come up with something that will almost always work. 
> > > Possibly even good enough for all practical purposes. However, if a 
> > > better solution would take comparable effort, it would make sense to do 
> > > things right and avoid adding technical debt. 
> > > 
> > > On the other hand, requiring the driver to supply identical cuid to all 
> > > sub-compilations appears to be a better approach to me:
> > > * Driver is the best place to do it, functionally. Driver has access to 
> > > all user-provided inputs and is in position to guarantee that all 
> > > subcompilations get the same cuid.
> > > * Calculating CUID in the driver keeps relevant logic in one place. Doing 
> > > it in the driver *and* in the codegen 
> > > * Figuring out 

[PATCH] D126138: [clang-tidy] Fix #55134 (regression introduced by 5da7c04)

[Salman Javed 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 rG9ff4f2dfea63: [clang-tidy] Fix #55134 (regression introduced 
by 5da7c04) (authored by salman-javed-nz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126138

Files:
  clang-tools-extra/clang-tidy/NoLintDirectiveHandler.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp


Index: clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
+++ clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
@@ -1,5 +1,5 @@
 // REQUIRES: static-analyzer
-// RUN: %check_clang_tidy %s 
google-explicit-constructor,clang-diagnostic-unused-variable,clang-analyzer-core.UndefinedBinaryOperatorResult,modernize-avoid-c-arrays,cppcoreguidelines-avoid-c-arrays
 %t -- -extra-arg=-Wunused-variable -- -I%S/Inputs/nolint
+// RUN: %check_clang_tidy %s 
google-explicit-constructor,clang-diagnostic-unused-variable,clang-analyzer-core.UndefinedBinaryOperatorResult,modernize-avoid-c-arrays,cppcoreguidelines-avoid-c-arrays,cppcoreguidelines-pro-type-member-init
 %t -- -extra-arg=-Wunused-variable -- -I%S/Inputs/nolint
 
 #include "trigger_warning.h"
 void I(int& Out) {
@@ -96,6 +96,23 @@
 #define MACRO_NOLINT class G { G(int i); }; // NOLINT
 MACRO_NOLINT
 
+// Check that we can suppress diagnostics about macro arguments (as opposed to
+// diagnostics about the macro contents itself).
+#define MACRO_SUPPRESS_DIAG_FOR_ARG_1(X)\
+  class X { \
+X(int i); /* NOLINT(google-explicit-constructor) */ \
+  };
+
+MACRO_SUPPRESS_DIAG_FOR_ARG_1(G1)
+
+#define MACRO_SUPPRESS_DIAG_FOR_ARG_2(X)  \
+  struct X { /* NOLINT(cppcoreguidelines-pro-type-member-init) */ \
+int a = 0;\
+int b;\
+  };
+
+MACRO_SUPPRESS_DIAG_FOR_ARG_2(G2)
+
 #define DOUBLE_MACRO MACRO(H) // NOLINT
 DOUBLE_MACRO
 
@@ -116,4 +133,4 @@
 int array3[10];  // 
NOLINT(cppcoreguidelines-avoid-c-arrays,modernize-avoid-c-arrays)
 int array4[10];  // NOLINT(*-avoid-c-arrays)
 
-// CHECK-MESSAGES: Suppressed 34 warnings (34 NOLINT)
+// CHECK-MESSAGES: Suppressed 36 warnings (36 NOLINT)
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -106,6 +106,10 @@
   means it is advised to use YAML's block style initiated by the pipe 
character `|` for the `Checks`
   section in order to benefit from the easier syntax that works without commas.
 
+- Fixed a regression introduced in clang-tidy 14.0.0, which prevented NOLINTs
+  from suppressing diagnostics associated with macro arguments. This fixes
+  `Issue 55134 `_.
+
 New checks
 ^^
 
Index: clang-tools-extra/clang-tidy/NoLintDirectiveHandler.cpp
===
--- clang-tools-extra/clang-tidy/NoLintDirectiveHandler.cpp
+++ clang-tools-extra/clang-tidy/NoLintDirectiveHandler.cpp
@@ -266,7 +266,7 @@
   return true;
 if (!DiagLoc.isMacroID())
   return false;
-DiagLoc = SrcMgr.getImmediateMacroCallerLoc(DiagLoc);
+DiagLoc = SrcMgr.getImmediateExpansionRange(DiagLoc).getBegin();
   }
   return false;
 }


Index: clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
+++ clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
@@ -1,5 +1,5 @@
 // REQUIRES: static-analyzer
-// RUN: %check_clang_tidy %s google-explicit-constructor,clang-diagnostic-unused-variable,clang-analyzer-core.UndefinedBinaryOperatorResult,modernize-avoid-c-arrays,cppcoreguidelines-avoid-c-arrays %t -- -extra-arg=-Wunused-variable -- -I%S/Inputs/nolint
+// RUN: %check_clang_tidy %s google-explicit-constructor,clang-diagnostic-unused-variable,clang-analyzer-core.UndefinedBinaryOperatorResult,modernize-avoid-c-arrays,cppcoreguidelines-avoid-c-arrays,cppcoreguidelines-pro-type-member-init %t -- -extra-arg=-Wunused-variable -- -I%S/Inputs/nolint
 
 #include "trigger_warning.h"
 void I(int& Out) {
@@ -96,6 +96,23 @@
 #define MACRO_NOLINT class G { G(int i); }; // NOLINT
 MACRO_NOLINT
 
+// Check that we can suppress diagnostics about macro arguments (as opposed to
+// diagnostics about the macro contents itself).
+#define MACRO_SUPPRESS_DIAG_FOR_ARG_1(X)\
+  class X { \
+X(int i); /* 

[clang-tools-extra] 9ff4f2d - [clang-tidy] Fix #55134 (regression introduced by 5da7c04)

[Salman Javed via cfe-commits]

Author: Salman Javed
Date: 2022-05-25T11:30:58+12:00
New Revision: 9ff4f2dfea632d63e3a57a88a2faa634aae5c772

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

LOG: [clang-tidy] Fix #55134 (regression introduced by 5da7c04)

5da7c04 introduced a regression in the NOLINT macro checking loop, replacing the
call to `getImmediateExpansionRange().getBegin()` with
`getImmediateMacroCallerLoc()`, which has similar but subtly different
behaviour.

The consequence is that NOLINTs cannot suppress diagnostics when they are
attached to a token that came from a macro **argument**, rather than elsewhere
in the macro expansion.

Revert to pre-patch behaviour and add test cases to cover this issue.

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/NoLintDirectiveHandler.cpp
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/NoLintDirectiveHandler.cpp 
b/clang-tools-extra/clang-tidy/NoLintDirectiveHandler.cpp
index 667ffdb5fab60..d482e49e0f6d9 100644
--- a/clang-tools-extra/clang-tidy/NoLintDirectiveHandler.cpp
+++ b/clang-tools-extra/clang-tidy/NoLintDirectiveHandler.cpp
@@ -266,7 +266,7 @@ bool NoLintDirectiveHandler::Impl::diagHasNoLintInMacro(
   return true;
 if (!DiagLoc.isMacroID())
   return false;
-DiagLoc = SrcMgr.getImmediateMacroCallerLoc(DiagLoc);
+DiagLoc = SrcMgr.getImmediateExpansionRange(DiagLoc).getBegin();
   }
   return false;
 }

diff  --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index 74e77f4a7de11..787f535dedb64 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -106,6 +106,10 @@ Improvements to clang-tidy
   means it is advised to use YAML's block style initiated by the pipe 
character `|` for the `Checks`
   section in order to benefit from the easier syntax that works without commas.
 
+- Fixed a regression introduced in clang-tidy 14.0.0, which prevented NOLINTs
+  from suppressing diagnostics associated with macro arguments. This fixes
+  `Issue 55134 `_.
+
 New checks
 ^^
 

diff  --git a/clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp 
b/clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
index 9ef194232b6b7..bc952ee03b5ad 100644
--- a/clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
+++ b/clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
@@ -1,5 +1,5 @@
 // REQUIRES: static-analyzer
-// RUN: %check_clang_tidy %s 
google-explicit-constructor,clang-diagnostic-unused-variable,clang-analyzer-core.UndefinedBinaryOperatorResult,modernize-avoid-c-arrays,cppcoreguidelines-avoid-c-arrays
 %t -- -extra-arg=-Wunused-variable -- -I%S/Inputs/nolint
+// RUN: %check_clang_tidy %s 
google-explicit-constructor,clang-diagnostic-unused-variable,clang-analyzer-core.UndefinedBinaryOperatorResult,modernize-avoid-c-arrays,cppcoreguidelines-avoid-c-arrays,cppcoreguidelines-pro-type-member-init
 %t -- -extra-arg=-Wunused-variable -- -I%S/Inputs/nolint
 
 #include "trigger_warning.h"
 void I(int& Out) {
@@ -96,6 +96,23 @@ MACRO_NOARG // NOLINT
 #define MACRO_NOLINT class G { G(int i); }; // NOLINT
 MACRO_NOLINT
 
+// Check that we can suppress diagnostics about macro arguments (as opposed to
+// diagnostics about the macro contents itself).
+#define MACRO_SUPPRESS_DIAG_FOR_ARG_1(X)\
+  class X { \
+X(int i); /* NOLINT(google-explicit-constructor) */ \
+  };
+
+MACRO_SUPPRESS_DIAG_FOR_ARG_1(G1)
+
+#define MACRO_SUPPRESS_DIAG_FOR_ARG_2(X)  \
+  struct X { /* NOLINT(cppcoreguidelines-pro-type-member-init) */ \
+int a = 0;\
+int b;\
+  };
+
+MACRO_SUPPRESS_DIAG_FOR_ARG_2(G2)
+
 #define DOUBLE_MACRO MACRO(H) // NOLINT
 DOUBLE_MACRO
 
@@ -116,4 +133,4 @@ int array2[10];  // NOLINT(cppcoreguidelines-avoid-c-arrays)
 int array3[10];  // 
NOLINT(cppcoreguidelines-avoid-c-arrays,modernize-avoid-c-arrays)
 int array4[10];  // NOLINT(*-avoid-c-arrays)
 
-// CHECK-MESSAGES: Suppressed 34 warnings (34 NOLINT)
+// CHECK-MESSAGES: Suppressed 36 warnings (36 NOLINT)



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

[PATCH] D126341: Order implicitly instantiated global variable's initializer by the reverse instantiation order

[Yuanfang Chen via Phabricator via cfe-commits]

ychen updated this revision to Diff 431825.
ychen added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126341

Files:
  clang/lib/CodeGen/CGDeclCXX.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/test/CodeGenCXX/aix-static-init-temp-spec-and-inline-var.cpp
  clang/test/CodeGenCXX/microsoft-abi-static-initializers.cpp
  clang/test/CodeGenCXX/static-member-variable-explicit-specialization.cpp
  clang/test/Modules/initializers.cpp

Index: clang/test/Modules/initializers.cpp
===
--- clang/test/Modules/initializers.cpp
+++ clang/test/Modules/initializers.cpp
@@ -154,12 +154,12 @@
 
 // It's OK if the order of the first 6 of these changes.
 // CHECK: @llvm.global_ctors = appending global
-// CHECK-SAME: @[[E_INIT:[^,]*]], {{[^@]*}} @[[E]]
-// CHECK-SAME: @[[F_INIT:[^,]*]], {{[^@]*}} @[[F]]
-// CHECK-SAME: @[[XA_INIT:[^,]*]], {{[^@]*}} @[[XA]]
-// CHECK-SAME: @[[XE_INIT:[^,]*]], {{[^@]*}} @[[XE]]
-// CHECK-SAME: @[[XF_INIT:[^,]*]], {{[^@]*}} @[[XF]]
 // CHECK-SAME: @[[XB_INIT:[^,]*]], {{[^@]*}} @[[XB]]
+// CHECK-SAME: @[[XF_INIT:[^,]*]], {{[^@]*}} @[[XF]]
+// CHECK-SAME: @[[XE_INIT:[^,]*]], {{[^@]*}} @[[XE]]
+// CHECK-SAME: @[[XA_INIT:[^,]*]], {{[^@]*}} @[[XA]]
+// CHECK-SAME: @[[F_INIT:[^,]*]], {{[^@]*}} @[[F]]
+// CHECK-SAME: @[[E_INIT:[^,]*]], {{[^@]*}} @[[E]]
 // CHECK-IMPORT-SAME: @[[TU_INIT:[^,]*]], i8* null }]
 
 // FIXME: Should this use __cxa_guard_acquire?
Index: clang/test/CodeGenCXX/static-member-variable-explicit-specialization.cpp
===
--- clang/test/CodeGenCXX/static-member-variable-explicit-specialization.cpp
+++ clang/test/CodeGenCXX/static-member-variable-explicit-specialization.cpp
@@ -29,32 +29,41 @@
 // ALL: @_ZN1AIbE1aE ={{.*}} global i32 10
 template<> int A::a = 10;
 
-// ALL: @llvm.global_ctors = appending global [8 x { i32, void ()*, i8* }]
+// ALL: @llvm.global_ctors = appending global [11 x { i32, void ()*, i8* }]
 
-// ELF: [{ i32, void ()*, i8* } { i32 65535, void ()* @[[unordered1:[^,]*]], i8* bitcast (i32* @_ZN1AIsE1aE to i8*) },
-// MACHO: [{ i32, void ()*, i8* } { i32 65535, void ()* @[[unordered1:[^,]*]], i8* null },
+// ELF:  [{ i32, void ()*, i8* } { i32 65535, void ()* @[[unordered10:[^,]*]], i8* bitcast (i32* @_ZN1RILi1EE1aE to i8*) },
+// MACHO: [{ i32, void ()*, i8* } { i32 65535, void ()* @[[unordered10:[^,]*]], i8* null },
 
-// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered2:[^,]*]], i8* bitcast (i16* @_Z1xIsE to i8*) },
-// MACHO:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered2:[^,]*]], i8* null },
+// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered9:[^,]*]], i8* bitcast (i32* @_ZN1RILi2EE1aE to i8*) },
+// MACHO: { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered9:[^,]*]], i8* null },
 
-// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered3:[^,]*]], i8* bitcast (i32* @_ZN2ns1aIiE1iE to i8*) },
-// MACHO:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered3:[^,]*]], i8* null },
+// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered8:[^,]*]], i8* bitcast (i32* @_ZN1RILi3EE1aE to i8*) },
+// MACHO: { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered8:[^,]*]], i8* null },
 
-// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered4:[^,]*]], i8* bitcast (i32* @_ZN2ns1b1iIiEE to i8*) },
-// MACHO:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered4:[^,]*]], i8* null },
+// ALL:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered7:[^,]*]], i8* null },
+
+// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered6:[^,]*]], i8* @_Z1xIcE },
+// MACHO:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered6:[^,]*]], i8* null },
 
 // ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered5:[^,]*]], i8* bitcast (i32* @_ZN1AIvE1aE to i8*) },
 // MACHO:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered5:[^,]*]], i8* null },
 
-// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered6:[^,]*]], i8* @_Z1xIcE },
-// MACHO:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered6:[^,]*]], i8* null },
+// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered4:[^,]*]], i8* bitcast (i32* @_ZN2ns1b1iIiEE to i8*) },
+// MACHO:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered4:[^,]*]], i8* null },
 
-// ALL:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered7:[^,]*]], i8* null },
+// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered3:[^,]*]], i8* bitcast (i32* @_ZN2ns1aIiE1iE to i8*) },
+// MACHO:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered3:[^,]*]], i8* null },
+
+// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered2:[^,]*]], i8* bitcast (i16* @_Z1xIsE to i8*) },
+// MACHO:  { i32, void ()*, i8* } { 

[PATCH] D126341: Order implicitly instantiated global variable's initializer by the reverse instantiation order

[Yuanfang Chen via Phabricator via cfe-commits]

ychen created this revision.
ychen added reviewers: rnk, rsmith, aaron.ballman.
Herald added a project: All.
ychen requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

By the standard https://eel.is/c++draft/basic.start#dynamic-1, implicitly 
instantiated global variable's initializer has no order. However GCC has 
the *intuitive behavior* for the two test cases in 
https://clang.godbolt.org/z/MPdhYTqhK.

The underlying problem is basically wg21.link/cwg362 which has no concensus yet.

I wish both cases could work, like GCC. However, to make the original cwg362 
test case work,
I needs an extra data structure to track the instantiation order for implicitly 
instantiated global variable. So the current patch only work for the first test 
case.

Will the reviewers be supportive if I make the original cwg362 test case work 
too?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126341

Files:
  clang/test/CodeGenCXX/aix-static-init-temp-spec-and-inline-var.cpp
  clang/test/CodeGenCXX/microsoft-abi-static-initializers.cpp
  clang/test/CodeGenCXX/static-member-variable-explicit-specialization.cpp
  clang/test/Modules/initializers.cpp

Index: clang/test/Modules/initializers.cpp
===
--- clang/test/Modules/initializers.cpp
+++ clang/test/Modules/initializers.cpp
@@ -154,12 +154,12 @@
 
 // It's OK if the order of the first 6 of these changes.
 // CHECK: @llvm.global_ctors = appending global
-// CHECK-SAME: @[[E_INIT:[^,]*]], {{[^@]*}} @[[E]]
-// CHECK-SAME: @[[F_INIT:[^,]*]], {{[^@]*}} @[[F]]
-// CHECK-SAME: @[[XA_INIT:[^,]*]], {{[^@]*}} @[[XA]]
-// CHECK-SAME: @[[XE_INIT:[^,]*]], {{[^@]*}} @[[XE]]
-// CHECK-SAME: @[[XF_INIT:[^,]*]], {{[^@]*}} @[[XF]]
 // CHECK-SAME: @[[XB_INIT:[^,]*]], {{[^@]*}} @[[XB]]
+// CHECK-SAME: @[[XF_INIT:[^,]*]], {{[^@]*}} @[[XF]]
+// CHECK-SAME: @[[XE_INIT:[^,]*]], {{[^@]*}} @[[XE]]
+// CHECK-SAME: @[[XA_INIT:[^,]*]], {{[^@]*}} @[[XA]]
+// CHECK-SAME: @[[F_INIT:[^,]*]], {{[^@]*}} @[[F]]
+// CHECK-SAME: @[[E_INIT:[^,]*]], {{[^@]*}} @[[E]]
 // CHECK-IMPORT-SAME: @[[TU_INIT:[^,]*]], i8* null }]
 
 // FIXME: Should this use __cxa_guard_acquire?
Index: clang/test/CodeGenCXX/static-member-variable-explicit-specialization.cpp
===
--- clang/test/CodeGenCXX/static-member-variable-explicit-specialization.cpp
+++ clang/test/CodeGenCXX/static-member-variable-explicit-specialization.cpp
@@ -29,32 +29,41 @@
 // ALL: @_ZN1AIbE1aE ={{.*}} global i32 10
 template<> int A::a = 10;
 
-// ALL: @llvm.global_ctors = appending global [8 x { i32, void ()*, i8* }]
+// ALL: @llvm.global_ctors = appending global [11 x { i32, void ()*, i8* }]
 
-// ELF: [{ i32, void ()*, i8* } { i32 65535, void ()* @[[unordered1:[^,]*]], i8* bitcast (i32* @_ZN1AIsE1aE to i8*) },
-// MACHO: [{ i32, void ()*, i8* } { i32 65535, void ()* @[[unordered1:[^,]*]], i8* null },
+// ELF:  [{ i32, void ()*, i8* } { i32 65535, void ()* @[[unordered10:[^,]*]], i8* bitcast (i32* @_ZN1RILi1EE1aE to i8*) },
+// MACHO: [{ i32, void ()*, i8* } { i32 65535, void ()* @[[unordered10:[^,]*]], i8* null },
 
-// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered2:[^,]*]], i8* bitcast (i16* @_Z1xIsE to i8*) },
-// MACHO:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered2:[^,]*]], i8* null },
+// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered9:[^,]*]], i8* bitcast (i32* @_ZN1RILi2EE1aE to i8*) },
+// MACHO: { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered9:[^,]*]], i8* null },
 
-// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered3:[^,]*]], i8* bitcast (i32* @_ZN2ns1aIiE1iE to i8*) },
-// MACHO:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered3:[^,]*]], i8* null },
+// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered8:[^,]*]], i8* bitcast (i32* @_ZN1RILi3EE1aE to i8*) },
+// MACHO: { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered8:[^,]*]], i8* null },
 
-// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered4:[^,]*]], i8* bitcast (i32* @_ZN2ns1b1iIiEE to i8*) },
-// MACHO:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered4:[^,]*]], i8* null },
+// ALL:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered7:[^,]*]], i8* null },
+
+// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered6:[^,]*]], i8* @_Z1xIcE },
+// MACHO:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered6:[^,]*]], i8* null },
 
 // ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered5:[^,]*]], i8* bitcast (i32* @_ZN1AIvE1aE to i8*) },
 // MACHO:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered5:[^,]*]], i8* null },
 
-// ELF:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered6:[^,]*]], i8* @_Z1xIcE },
-// MACHO:  { i32, void ()*, i8* } { i32 65535, void ()* @[[unordered6:[^,]*]], i8* null },
+// ELF:  { i32, void ()*, i8* } { 

[PATCH] D126334: Move GCC-compatible pod-packing change to v15/old behavior available at v14 and below

[Matthias Braun via Phabricator via cfe-commits]

MatzeB accepted this revision.
MatzeB 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/D126334/new/

https://reviews.llvm.org/D126334

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

[PATCH] D126337: [pseudo] WIP: GSS node refcounting (dumb pointers)

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: hokein.
Herald added a subscriber: mgrang.
Herald added a project: All.
sammccall requested review of this revision.
Herald added subscribers: cfe-commits, alextsao1999.
Herald added a project: clang-tools-extra.

This adds a refcount to GSS::Node, and uses a freelist to reuse nodes rather
than reallocating.

The freelist works well (on AST.cpp, 35K nodes created but only 74 allocated),
but it's not the only point here. Tracking the lifetime of GSS nodes is going to
be useful for error handling: when a node dies having never been successfully
reduced, we can capture it to run recovery on it.

This version of the patch continues to use Node*, with calls to GSS::ref() and
GSS::unref() to manipulate the count. I don't think this is workable - it
took me a depressingly long time to track down the bugs, and the code is hard
to reason about.
I think we want a smart pointer here to make the code clearer. Unfortunately
this is a bit tricky: the destructor needs the GSS to do the destruction, but
we don't want to pay the cost of storing an extra pointer to the GSS everywhere.
I can't think of a better alternative than (ick) thread-local storage.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126337

Files:
  clang-tools-extra/pseudo/include/clang-pseudo/GLR.h
  clang-tools-extra/pseudo/lib/GLR.cpp
  clang-tools-extra/pseudo/unittests/GLRTest.cpp

Index: clang-tools-extra/pseudo/unittests/GLRTest.cpp
===
--- clang-tools-extra/pseudo/unittests/GLRTest.cpp
+++ clang-tools-extra/pseudo/unittests/GLRTest.cpp
@@ -85,11 +85,17 @@
 
   NewHeadCallback captureNewHeads() {
 return [this](const GSS::Node *NewHead) {
+  GSStack.ref(NewHead);
   NewHeadResults.push_back(NewHead);
 };
   };
 
 protected:
+  ~GLRTest() {
+for (auto *N : NewHeadResults)
+  GSStack.unref(N);
+  }
+
   std::unique_ptr G;
   ForestArena Arena;
   GSS GSStack;
@@ -115,6 +121,7 @@
/*Parents=*/{GSSNode0});
   auto *GSSNode3 = GSStack.addNode(/*State=*/0, /*ForestNode=*/nullptr,
/*Parents=*/{GSSNode0});
+  GSStack.unref(GSSNode0);
 
   buildGrammar({}, {}); // Create a fake empty grammar.
   LRTable T = LRTable::buildForTests(G->table(), /*Entries=*/{});
@@ -154,6 +161,8 @@
   GSStack.addNode(/*State=*/0, /*ForestNode=*/nullptr, /*Parents=*/{});
   const auto *GSSNode1 =
   GSStack.addNode(3, (tok::identifier, 0), {GSSNode0});
+  GSStack.unref(GSSNode0);
+  GSStack.ref(GSSNode1);
 
   std::vector PendingReduce = {
   {GSSNode1, Action::reduce(ruleFor("class-name"))},
@@ -188,6 +197,8 @@
   const auto *GSSNode4 = GSStack.addNode(
   /*State=*/4, (tok::star, /*TokenIndex=*/1),
   /*Parents=*/{GSSNode2, GSSNode3});
+  GSStack.unref(GSSNode2);
+  GSStack.unref(GSSNode3);
 
   LRTable Table = LRTable::buildForTests(
   G->table(),
@@ -237,6 +248,9 @@
   const auto *GSSNode4 =
   GSStack.addNode(/*State=*/4, /*ForestNode=*/EnumNameNode,
   /*Parents=*/{GSSNode2});
+  GSStack.unref(GSSNode0);
+  GSStack.unref(GSSNode1);
+  GSStack.unref(GSSNode2);
 
   LRTable Table = LRTable::buildForTests(
   G->table(),
@@ -295,6 +309,9 @@
   const auto *GSSNode4 =
   GSStack.addNode(/*State=*/4, /*ForestNode=*/StartTerminal,
   /*Parents=*/{GSSNode2});
+  GSStack.unref(GSSNode0);
+  GSStack.unref(GSSNode1);
+  GSStack.unref(GSSNode2);
 
   LRTable Table = LRTable::buildForTests(
   G->table(), {{/*State=*/0, id("pointer"), Action::goTo(5)}});
Index: clang-tools-extra/pseudo/lib/GLR.cpp
===
--- clang-tools-extra/pseudo/lib/GLR.cpp
+++ clang-tools-extra/pseudo/lib/GLR.cpp
@@ -31,11 +31,43 @@
   std::vector ParentStates;
   for (const auto *Parent : N.parents())
 ParentStates.push_back(llvm::formatv("{0}", Parent->State));
-  OS << llvm::formatv("state {0}, parsed symbol {1}, parents {2}", N.State,
-  N.Payload->symbol(), llvm::join(ParentStates, ", "));
+  OS << llvm::formatv("state {0}, parsed symbol {1}, parents {{{2}}, refcount={3}",
+  N.State, N.Payload ? N.Payload->symbol() : 0,
+  llvm::join(ParentStates, ", "), N.RefCount);
   return OS;
 }
 
+#ifndef NDEBUG
+static void checkRefcounts(std::vector Queue) {
+  llvm::DenseSet Seen;
+  llvm::DenseMap Expected;
+  for (const auto *N : Queue)
+++Expected[N];
+  while (!Queue.empty()) {
+const GSS::Node *N = Queue.back();
+Queue.pop_back();
+if (!Seen.insert(N).second)
+  continue;
+for (const auto *P : N->parents()) {
+  ++Expected[P];
+  Queue.push_back(P);
+}
+  }
+  bool AnyWrong = false;
+  llvm::dbgs() << "Checking refcounts:\n";
+  for (const auto& E : Expected) {
+llvm::dbgs() << E.first << " " << *E.first << "\n";
+if (E.second != 

[PATCH] D117616: GCC ABI Compatibility: Preserve alignment of non-pod members in packed structs

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:239-243
+- GCC doesn't pack non-POD members in packed structs unless the packed
+  attribute is also specified on the member. Clang historically did perform
+  such packing. Clang now matches the gcc behavior (except on Darwin and PS4).
+  You can switch back to the old ABI behavior with the flag:
+  ``-fclang-abi-compat=13.0``.

tstellar wrote:
> dblaikie wrote:
> > MatzeB wrote:
> > > Ugh... The release notes went missing in `main` now:
> > > 
> > > * We had them in clang-14, but then reverted in the release process of 
> > > clang-14 so they never showed for clang-14.
> > > * In `main` we removed all release nodes when going from 14->15.
> > > 
> > > So this notice is effectively lost now...
> > Ah, thanks - readded it in 0b903ef6aa0976a60d3f448837f3c43adaf09cc1
> > 
> > Anyone have feelings about whether we should move the old ABI under Ver14, 
> > instead of Ver13, since the break was never released in Ver14?
> That seems fine to me.
Sent D126334


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117616

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

[PATCH] D126334: Move GCC-compatible pod-packing change to v15/old behavior available at v14 and below

[David Blaikie via Phabricator via cfe-commits]

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

Since this didn't make it into the v14 release - anyone requesting the
v14 ABI shouldn't get this GCC-compatible change that isn't backwards
compatible with v14 Clang.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126334

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/LangOptions.h
  clang/lib/AST/RecordLayoutBuilder.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/SemaCXX/class-layout.cpp


Index: clang/test/SemaCXX/class-layout.cpp
===
--- clang/test/SemaCXX/class-layout.cpp
+++ clang/test/SemaCXX/class-layout.cpp
@@ -1,9 +1,9 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify 
-std=c++98 -Wno-inaccessible-base
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base
-// RUN: %clang_cc1 -triple x86_64-apple-darwin%s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base -DCLANG_ABI_COMPAT=13
+// RUN: %clang_cc1 -triple x86_64-apple-darwin%s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base -DCLANG_ABI_COMPAT=14
 // RUN: %clang_cc1 -triple x86_64-scei-ps4%s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base -DCLANG_ABI_COMPAT=6
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base -fclang-abi-compat=6 -DCLANG_ABI_COMPAT=6
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base -fclang-abi-compat=13 -DCLANG_ABI_COMPAT=13
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify 
-std=c++11 -Wno-inaccessible-base -fclang-abi-compat=14 -DCLANG_ABI_COMPAT=14
 // expected-no-diagnostics
 
 #define SA(n, p) int a##n[(p) ? 1 : -1]
@@ -620,7 +620,7 @@
   char c2;
   t1 v1;
 } __attribute__((packed));
-#if defined(CLANG_ABI_COMPAT) && CLANG_ABI_COMPAT <= 13
+#if defined(CLANG_ABI_COMPAT) && CLANG_ABI_COMPAT <= 14
 _Static_assert(_Alignof(t1) == 4, "");
 _Static_assert(_Alignof(t2) == 1, "");
 #else
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3516,8 +3516,6 @@
 GenerateArg(Args, OPT_fclang_abi_compat_EQ, "11.0", SA);
   else if (Opts.getClangABICompat() == LangOptions::ClangABI::Ver12)
 GenerateArg(Args, OPT_fclang_abi_compat_EQ, "12.0", SA);
-  else if (Opts.getClangABICompat() == LangOptions::ClangABI::Ver13)
-GenerateArg(Args, OPT_fclang_abi_compat_EQ, "13.0", SA);
   else if (Opts.getClangABICompat() == LangOptions::ClangABI::Ver14)
 GenerateArg(Args, OPT_fclang_abi_compat_EQ, "14.0", SA);
 
@@ -4010,8 +4008,6 @@
 Opts.setClangABICompat(LangOptions::ClangABI::Ver11);
   else if (Major <= 12)
 Opts.setClangABICompat(LangOptions::ClangABI::Ver12);
-  else if (Major <= 13)
-Opts.setClangABICompat(LangOptions::ClangABI::Ver13);
   else if (Major <= 14)
 Opts.setClangABICompat(LangOptions::ClangABI::Ver14);
 } else if (Ver != "latest") {
Index: clang/lib/AST/RecordLayoutBuilder.cpp
===
--- clang/lib/AST/RecordLayoutBuilder.cpp
+++ clang/lib/AST/RecordLayoutBuilder.cpp
@@ -1890,7 +1890,7 @@
   llvm::Triple Target = Context.getTargetInfo().getTriple();
   bool FieldPacked = (Packed && (!FieldClass || FieldClass->isPOD() ||
  Context.getLangOpts().getClangABICompat() <=
- LangOptions::ClangABI::Ver13 ||
+ LangOptions::ClangABI::Ver14 ||
  Target.isPS4() || Target.isOSDarwin())) ||
  D->hasAttr();
 
Index: clang/include/clang/Basic/LangOptions.h
===
--- clang/include/clang/Basic/LangOptions.h
+++ clang/include/clang/Basic/LangOptions.h
@@ -214,12 +214,9 @@
 /// global-scope inline variables incorrectly.
 Ver12,
 
-/// Attempt to be ABI-compatible with code generated by Clang 13.0.x.
-/// This causes clang to not pack non-POD members of packed structs.
-Ver13,
-
 /// Attempt to be ABI-compatible with code generated by Clang 14.0.x.
 /// This causes clang to mangle dependent nested names incorrectly.
+/// This causes clang to pack non-POD members of packed structs.
 Ver14,
 
 /// Conform to the underlying platform's C and C++ ABIs as closely
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ 

[PATCH] D124752: [HLSL] clang codeGen for HLSLShaderAttr.

[Xiang Li via Phabricator via cfe-commits]

python3kgae updated this revision to Diff 431812.
python3kgae added a comment.

Treat entry functions as in extern C scope.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124752

Files:
  clang/lib/AST/Decl.cpp
  clang/lib/CodeGen/CGHLSLRuntime.cpp
  clang/lib/CodeGen/CGHLSLRuntime.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGenHLSL/entry.hlsl
  clang/test/CodeGenHLSL/shader_type_attr.hlsl

Index: clang/test/CodeGenHLSL/shader_type_attr.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/shader_type_attr.hlsl
@@ -0,0 +1,11 @@
+// RUN: %clang --driver-mode=dxc -Tlib_6_x -fcgl -Fo - %s | FileCheck %s
+
+// Make sure not mangle entry.
+// CHECK:define void @foo()
+// Make sure add function attribute.
+// CHECK:"dx.shader"="compute"
+[shader("compute")]
+[numthreads(1,1,1)]
+void foo() {
+
+}
Index: clang/test/CodeGenHLSL/entry.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/entry.hlsl
@@ -0,0 +1,10 @@
+// RUN: %clang --driver-mode=dxc -Tcs_6_1 -Efoo -fcgl -Fo - %s | FileCheck %s
+
+// Make sure not mangle entry.
+// CHECK:define void @foo()
+// Make sure add function attribute.
+// CHECK:"dx.shader"="compute"
+[numthreads(1,1,1)]
+void foo() {
+
+}
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -1650,6 +1650,10 @@
  /*AttrOnCallSite=*/false, IsThunk);
   F->setAttributes(PAL);
   F->setCallingConv(static_cast(CallingConv));
+  if (getLangOpts().HLSL) {
+if (const FunctionDecl *FD = dyn_cast_or_null(GD.getDecl()))
+  getHLSLRuntime().setHLSLFnuctionAttributes(F, FD);
+  }
 }
 
 static void removeImageAccessQualifier(std::string& TyName) {
Index: clang/lib/CodeGen/CGHLSLRuntime.h
===
--- clang/lib/CodeGen/CGHLSLRuntime.h
+++ clang/lib/CodeGen/CGHLSLRuntime.h
@@ -15,8 +15,13 @@
 #ifndef LLVM_CLANG_LIB_CODEGEN_CGHLSLRUNTIME_H
 #define LLVM_CLANG_LIB_CODEGEN_CGHLSLRUNTIME_H
 
+namespace llvm {
+class Function;
+}
 namespace clang {
 
+class FunctionDecl;
+
 namespace CodeGen {
 
 class CodeGenModule;
@@ -30,6 +35,8 @@
   virtual ~CGHLSLRuntime() {}
 
   void finishCodeGen();
+
+  void setHLSLFnuctionAttributes(llvm::Function *, const FunctionDecl *);
 };
 
 } // namespace CodeGen
Index: clang/lib/CodeGen/CGHLSLRuntime.cpp
===
--- clang/lib/CodeGen/CGHLSLRuntime.cpp
+++ clang/lib/CodeGen/CGHLSLRuntime.cpp
@@ -50,3 +50,12 @@
   llvm::Module  = CGM.getModule();
   addDxilValVersion(TargetOpts.DxilValidatorVersion, M);
 }
+
+void clang::CodeGen::CGHLSLRuntime::setHLSLFnuctionAttributes(
+llvm::Function *F, const FunctionDecl *FD) {
+  if (HLSLShaderAttr *ShaderAttr = FD->getAttr()) {
+const StringRef ShaderAttrKindStr = "dx.shader";
+F->addFnAttr(ShaderAttrKindStr,
+ ShaderAttr->ConvertShaderTypeToStr(ShaderAttr->getType()));
+  }
+}
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -3281,7 +3281,7 @@
 }
 
 bool FunctionDecl::isInExternCContext() const {
-  if (hasAttr())
+  if (hasAttr() || hasAttr())
 return true;
   return getLexicalDeclContext()->isExternCContext();
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D125904: [Cuda] Use fallback method to mangle externalized decls if no CUID given

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

A




Comment at: clang/lib/CodeGen/CodeGenModule.cpp:6836
+
+  // If the CUID is not specified we try to generate a unique postfix.
+  if (getLangOpts().CUID.empty()) {

jhuber6 wrote:
> tra wrote:
> > jhuber6 wrote:
> > > tra wrote:
> > > > > However, [CUID] is not always availible. 
> > > > 
> > > > The question is -- when and why is it not available? I'm getting the 
> > > > feeling that we're fixing the consequence here, not the root cause.
> > > > 
> > > > Is there a reason we can't make sure that the driver always generates a 
> > > > cuid for offload subcompilations and error out if it's needed but is 
> > > > not provided?
> > > > That would make this fallback unnecessary and would be a more robust 
> > > > approach in general.
> > > > 
> > > So, I'm more in favor of this approach because it doesn't require extra 
> > > intervention from the compiler driver, this makes it less convoluted to 
> > > do split compilation since we don't have an extra arguments. The way I 
> > > would prefer it, is that we do this implicitly by default without 
> > > requiring extra thought from the driver, but if it's not good enough we 
> > > can support the manual `CUID` approach to let the user override it. I 
> > > think this is a cleaner implementation, and is mostly coming from my 
> > > support for CUDA in the new driver which currently doesn't implement the 
> > > CUID as we do with the old driver. Generally I'd prefer things to behave 
> > > independent of the driver, so we can consider host and device compilation 
> > > more separately.
> > > So, I'm more in favor of this approach because it doesn't require extra 
> > > intervention from the compiler driver
> > 
> > We need the driver intervention for any cc1 compilations anyways, so this 
> > does not buy us anything.  While you can run a sub-compilation manually 
> > with handcrafted cc1 flags, that's not a practical use case. The driver is 
> > the ultimate source of cc1 flags.
> > 
> > > this makes it less convoluted to do split compilation since we don't have 
> > > an extra arguments.
> > 
> > For CUDA/HIP sub-compilation should be done with clang 
> > --cuda-host-only/--cuda-device-only.  Whether the driver supplies yet 
> > another cc1 option, --cuid=... makes no difference to the user launching 
> > such sub-compilation. 
> > 
> > > The way I would prefer it, is that we do this implicitly by default 
> > > without requiring extra thought from the driver, but if it's not good 
> > > enough we can support the manual CUID approach to let the user override 
> > > it.
> > 
> > I agree that we can come up with something that will almost always work. 
> > Possibly even good enough for all practical purposes. However, if a better 
> > solution would take comparable effort, it would make sense to do things 
> > right and avoid adding technical debt. 
> > 
> > On the other hand, requiring the driver to supply identical cuid to all 
> > sub-compilations appears to be a better approach to me:
> > * Driver is the best place to do it, functionally. Driver has access to all 
> > user-provided inputs and is in position to guarantee that all 
> > subcompilations get the same cuid.
> > * Calculating CUID in the driver keeps relevant logic in one place. Doing 
> > it in the driver *and* in the codegen 
> > * Figuring out what inputs are relevant for calculation of CUID in cc1 
> > invocation is error prone. E.g. we have to guess which cc1 options are 
> > relevant or not and is the driver would pass a macro to one subcompilation 
> > but not to another, we would end up generating mismatching CUID and would 
> > not have any way to notice that. Even when that's not the case, we would 
> > need to guess which flags, supplied by the driver, are relevant. At CC1 
> > level that may be somewhat complicated as top-level options may expand to 
> > quite a few more cc1 options. E.g. we'll need to take into account 
> > `-std=...`, `--cuda-path=`, `-include ...`, `-I` (and other include 
> > paths)... All of that does not belong to the codegen.
> > 
> > The driver is already doing CUID computation, so I do not see any downsides 
> > to just letting it do its job, and I do believe it will be a better, and 
> > likely less complicated, solution.
> > 
> > > ... mostly coming from my support for CUDA in the new driver which 
> > > currently doesn't implement the CUID as we do with the old driver
> > 
> > Right. That appears to be the key missing piece.
> > 
> > What are the obstacles for having CUID calculation done in the new driver. 
> > It should have all the info it needs. What am I missing?
> > 
> > For CUDA/HIP sub-compilation should be done with clang 
> > --cuda-host-only/--cuda-device-only. Whether the driver supplies yet 
> > another cc1 option, --cuid=... makes no difference to the user launching 
> > such sub-compilation.
> The problem I have with this is that we use the command line to generate the 
> value, 

[PATCH] D126100: Add sanitizer-specific GlobalValue attributes.

[Mitch Phillips via Phabricator via cfe-commits]

hctim updated this revision to Diff 431810.
hctim added a comment.

Remove extra creation path, turns out it's a duplicate of elsewhere.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126100

Files:
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/SanitizerMetadata.cpp
  clang/lib/CodeGen/SanitizerMetadata.h
  clang/test/CodeGen/asan-globals-alias.cpp
  clang/test/CodeGen/asan-globals-odr.cpp
  clang/test/CodeGen/asan-static-odr.cpp
  clang/test/CodeGen/asan-strings.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/AsmParser/LLParser.h
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/IR/GlobalValue.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/Globals.cpp
  llvm/lib/IR/LLVMContextImpl.h

Index: llvm/lib/IR/LLVMContextImpl.h
===
--- llvm/lib/IR/LLVMContextImpl.h
+++ llvm/lib/IR/LLVMContextImpl.h
@@ -1503,6 +1503,9 @@
   /// Collection of per-GlobalValue partitions used in this context.
   DenseMap GlobalValuePartitions;
 
+  DenseMap
+  GlobalValueSanitizerMetadata;
+
   /// DiscriminatorTable - This table maps file:line locations to an
   /// integer representing the next DWARF path discriminator to assign to
   /// instructions in different blocks at the same location.
Index: llvm/lib/IR/Globals.cpp
===
--- llvm/lib/IR/Globals.cpp
+++ llvm/lib/IR/Globals.cpp
@@ -67,6 +67,8 @@
   setDLLStorageClass(Src->getDLLStorageClass());
   setDSOLocal(Src->isDSOLocal());
   setPartition(Src->getPartition());
+  if (Src->hasSanitizerMetadata())
+setSanitizerMetadata(Src->getSanitizerMetadata());
 }
 
 void GlobalValue::removeFromParent() {
@@ -217,6 +219,18 @@
   HasPartition = !S.empty();
 }
 
+using SanitizerMetadata = GlobalValue::SanitizerMetadata;
+using GlobalSanitizer = GlobalValue::SanitizerMetadata::GlobalSanitizer;
+const SanitizerMetadata ::getSanitizerMetadata() const {
+  assert(hasSanitizerMetadata());
+  return getContext().pImpl->GlobalValueSanitizerMetadata[this];
+}
+
+void GlobalValue::setSanitizerMetadata(const SanitizerMetadata ) {
+  getContext().pImpl->GlobalValueSanitizerMetadata[this] = Meta;
+  HasSanitizerMetadata = true;
+}
+
 StringRef GlobalObject::getSectionImpl() const {
   assert(hasSection());
   return getContext().pImpl->GlobalObjectSections[this];
Index: llvm/lib/IR/AsmWriter.cpp
===
--- llvm/lib/IR/AsmWriter.cpp
+++ llvm/lib/IR/AsmWriter.cpp
@@ -100,6 +100,9 @@
 using UseListOrderMap =
 DenseMap>>;
 
+using SanitizerMetadata = llvm::GlobalValue::SanitizerMetadata;
+using GlobalSanitizer = SanitizerMetadata::GlobalSanitizer;
+
 /// Look for a value that might be wrapped as metadata, e.g. a value in a
 /// metadata operand. Returns the input value as-is if it is not wrapped.
 static const Value *skipMetadataWrapper(const Value *V) {
@@ -3537,6 +3540,28 @@
 Out << '"';
   }
 
+  if (GV->hasSanitizerMetadata()) {
+SanitizerMetadata MD = GV->getSanitizerMetadata();
+if (MD.HasSanitizer(SanitizerMetadata::NoSanitize)) {
+  Out << ", no_sanitize";
+} else {
+  if (MD.HasSanitizer(SanitizerMetadata::Address))
+Out << ", sanitize_address";
+  if (MD.HasSanitizer(SanitizerMetadata::HWAddress))
+Out << ", sanitize_hwaddress";
+  if (MD.HasSanitizer(SanitizerMetadata::Memtag))
+Out << ", sanitize_address";
+  if (MD.HasSanitizer(SanitizerMetadata::NoAddress))
+Out << ", no_sanitize_address";
+  if (MD.HasSanitizer(SanitizerMetadata::NoHWAddress))
+Out << ", no_sanitize_hwaddress";
+  if (MD.HasSanitizer(SanitizerMetadata::NoMemtag))
+Out << ", no_sanitize_memtag";
+  if (MD.HasSanitizer(GlobalSanitizer::Address) && MD.IsDynInit)
+Out << ", sanitize_address_dyninit";
+}
+  }
+
   maybePrintComdat(Out, *GV);
   if (MaybeAlign A = GV->getAlign())
 Out << ", align " << A->value();
Index: llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
===
--- llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
+++ llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
@@ -1344,7 +1344,8 @@
 // GLOBALVAR: [strtab offset, strtab size, type, isconst, initid,
 // linkage, alignment, section, visibility, threadlocal,
 // unnamed_addr, externally_initialized, dllstorageclass,
-// comdat, attributes, DSO_Local]
+// comdat, attributes, DSO_Local, GlobalSanitizer::Sanitizer,
+// GlobalSanitizer::IsDynInit]
 Vals.push_back(addToStrtab(GV.getName()));
 Vals.push_back(GV.getName().size());
 

[PATCH] D125904: [Cuda] Use fallback method to mangle externalized decls if no CUID given

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:6836
+
+  // If the CUID is not specified we try to generate a unique postfix.
+  if (getLangOpts().CUID.empty()) {

tra wrote:
> jhuber6 wrote:
> > tra wrote:
> > > > However, [CUID] is not always availible. 
> > > 
> > > The question is -- when and why is it not available? I'm getting the 
> > > feeling that we're fixing the consequence here, not the root cause.
> > > 
> > > Is there a reason we can't make sure that the driver always generates a 
> > > cuid for offload subcompilations and error out if it's needed but is not 
> > > provided?
> > > That would make this fallback unnecessary and would be a more robust 
> > > approach in general.
> > > 
> > So, I'm more in favor of this approach because it doesn't require extra 
> > intervention from the compiler driver, this makes it less convoluted to do 
> > split compilation since we don't have an extra arguments. The way I would 
> > prefer it, is that we do this implicitly by default without requiring extra 
> > thought from the driver, but if it's not good enough we can support the 
> > manual `CUID` approach to let the user override it. I think this is a 
> > cleaner implementation, and is mostly coming from my support for CUDA in 
> > the new driver which currently doesn't implement the CUID as we do with the 
> > old driver. Generally I'd prefer things to behave independent of the 
> > driver, so we can consider host and device compilation more separately.
> > So, I'm more in favor of this approach because it doesn't require extra 
> > intervention from the compiler driver
> 
> We need the driver intervention for any cc1 compilations anyways, so this 
> does not buy us anything.  While you can run a sub-compilation manually with 
> handcrafted cc1 flags, that's not a practical use case. The driver is the 
> ultimate source of cc1 flags.
> 
> > this makes it less convoluted to do split compilation since we don't have 
> > an extra arguments.
> 
> For CUDA/HIP sub-compilation should be done with clang 
> --cuda-host-only/--cuda-device-only.  Whether the driver supplies yet another 
> cc1 option, --cuid=... makes no difference to the user launching such 
> sub-compilation. 
> 
> > The way I would prefer it, is that we do this implicitly by default without 
> > requiring extra thought from the driver, but if it's not good enough we can 
> > support the manual CUID approach to let the user override it.
> 
> I agree that we can come up with something that will almost always work. 
> Possibly even good enough for all practical purposes. However, if a better 
> solution would take comparable effort, it would make sense to do things right 
> and avoid adding technical debt. 
> 
> On the other hand, requiring the driver to supply identical cuid to all 
> sub-compilations appears to be a better approach to me:
> * Driver is the best place to do it, functionally. Driver has access to all 
> user-provided inputs and is in position to guarantee that all subcompilations 
> get the same cuid.
> * Calculating CUID in the driver keeps relevant logic in one place. Doing it 
> in the driver *and* in the codegen 
> * Figuring out what inputs are relevant for calculation of CUID in cc1 
> invocation is error prone. E.g. we have to guess which cc1 options are 
> relevant or not and is the driver would pass a macro to one subcompilation 
> but not to another, we would end up generating mismatching CUID and would not 
> have any way to notice that. Even when that's not the case, we would need to 
> guess which flags, supplied by the driver, are relevant. At CC1 level that 
> may be somewhat complicated as top-level options may expand to quite a few 
> more cc1 options. E.g. we'll need to take into account `-std=...`, 
> `--cuda-path=`, `-include ...`, `-I` (and other include paths)... All of that 
> does not belong to the codegen.
> 
> The driver is already doing CUID computation, so I do not see any downsides 
> to just letting it do its job, and I do believe it will be a better, and 
> likely less complicated, solution.
> 
> > ... mostly coming from my support for CUDA in the new driver which 
> > currently doesn't implement the CUID as we do with the old driver
> 
> Right. That appears to be the key missing piece.
> 
> What are the obstacles for having CUID calculation done in the new driver. It 
> should have all the info it needs. What am I missing?
> 
> For CUDA/HIP sub-compilation should be done with clang 
> --cuda-host-only/--cuda-device-only. Whether the driver supplies yet another 
> cc1 option, --cuid=... makes no difference to the user launching such 
> sub-compilation.
The problem I have with this is that we use the command line to generate the 
value, so they aren't going to be the same without the user manually specifying 
it. I guess we could filter out only "relevant" command line flags, maybe 
that's an option. I just think it's not intuitive 

[PATCH] D126138: [clang-tidy] Fix #55134 (regression introduced by 5da7c04)

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz updated this revision to Diff 431805.
salman-javed-nz added a comment.

Added release note.

(Also taking the opportunity to run the patch through the pre-merge build bot 
one last time.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126138

Files:
  clang-tools-extra/clang-tidy/NoLintDirectiveHandler.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp


Index: clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
+++ clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
@@ -1,5 +1,5 @@
 // REQUIRES: static-analyzer
-// RUN: %check_clang_tidy %s 
google-explicit-constructor,clang-diagnostic-unused-variable,clang-analyzer-core.UndefinedBinaryOperatorResult,modernize-avoid-c-arrays,cppcoreguidelines-avoid-c-arrays
 %t -- -extra-arg=-Wunused-variable -- -I%S/Inputs/nolint
+// RUN: %check_clang_tidy %s 
google-explicit-constructor,clang-diagnostic-unused-variable,clang-analyzer-core.UndefinedBinaryOperatorResult,modernize-avoid-c-arrays,cppcoreguidelines-avoid-c-arrays,cppcoreguidelines-pro-type-member-init
 %t -- -extra-arg=-Wunused-variable -- -I%S/Inputs/nolint
 
 #include "trigger_warning.h"
 void I(int& Out) {
@@ -96,6 +96,23 @@
 #define MACRO_NOLINT class G { G(int i); }; // NOLINT
 MACRO_NOLINT
 
+// Check that we can suppress diagnostics about macro arguments (as opposed to
+// diagnostics about the macro contents itself).
+#define MACRO_SUPPRESS_DIAG_FOR_ARG_1(X)\
+  class X { \
+X(int i); /* NOLINT(google-explicit-constructor) */ \
+  };
+
+MACRO_SUPPRESS_DIAG_FOR_ARG_1(G1)
+
+#define MACRO_SUPPRESS_DIAG_FOR_ARG_2(X)  \
+  struct X { /* NOLINT(cppcoreguidelines-pro-type-member-init) */ \
+int a = 0;\
+int b;\
+  };
+
+MACRO_SUPPRESS_DIAG_FOR_ARG_2(G2)
+
 #define DOUBLE_MACRO MACRO(H) // NOLINT
 DOUBLE_MACRO
 
@@ -116,4 +133,4 @@
 int array3[10];  // 
NOLINT(cppcoreguidelines-avoid-c-arrays,modernize-avoid-c-arrays)
 int array4[10];  // NOLINT(*-avoid-c-arrays)
 
-// CHECK-MESSAGES: Suppressed 34 warnings (34 NOLINT)
+// CHECK-MESSAGES: Suppressed 36 warnings (36 NOLINT)
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -106,6 +106,10 @@
   means it is advised to use YAML's block style initiated by the pipe 
character `|` for the `Checks`
   section in order to benefit from the easier syntax that works without commas.
 
+- Fixed a regression introduced in clang-tidy 14.0.0, which prevented NOLINTs
+  from suppressing diagnostics associated with macro arguments. This fixes
+  `Issue 55134 `_.
+
 New checks
 ^^
 
Index: clang-tools-extra/clang-tidy/NoLintDirectiveHandler.cpp
===
--- clang-tools-extra/clang-tidy/NoLintDirectiveHandler.cpp
+++ clang-tools-extra/clang-tidy/NoLintDirectiveHandler.cpp
@@ -266,7 +266,7 @@
   return true;
 if (!DiagLoc.isMacroID())
   return false;
-DiagLoc = SrcMgr.getImmediateMacroCallerLoc(DiagLoc);
+DiagLoc = SrcMgr.getImmediateExpansionRange(DiagLoc).getBegin();
   }
   return false;
 }


Index: clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
+++ clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
@@ -1,5 +1,5 @@
 // REQUIRES: static-analyzer
-// RUN: %check_clang_tidy %s google-explicit-constructor,clang-diagnostic-unused-variable,clang-analyzer-core.UndefinedBinaryOperatorResult,modernize-avoid-c-arrays,cppcoreguidelines-avoid-c-arrays %t -- -extra-arg=-Wunused-variable -- -I%S/Inputs/nolint
+// RUN: %check_clang_tidy %s google-explicit-constructor,clang-diagnostic-unused-variable,clang-analyzer-core.UndefinedBinaryOperatorResult,modernize-avoid-c-arrays,cppcoreguidelines-avoid-c-arrays,cppcoreguidelines-pro-type-member-init %t -- -extra-arg=-Wunused-variable -- -I%S/Inputs/nolint
 
 #include "trigger_warning.h"
 void I(int& Out) {
@@ -96,6 +96,23 @@
 #define MACRO_NOLINT class G { G(int i); }; // NOLINT
 MACRO_NOLINT
 
+// Check that we can suppress diagnostics about macro arguments (as opposed to
+// diagnostics about the macro contents itself).
+#define MACRO_SUPPRESS_DIAG_FOR_ARG_1(X)\
+  class X { \
+X(int i); /* NOLINT(google-explicit-constructor) */ \
+  };
+

[PATCH] D126323: [OpenMP] Extend omp teams to permit nested omp atomic

[Joel E. Denny via Phabricator via cfe-commits]

jdenny marked 2 inline comments as done.
jdenny added a comment.

Thanks.  Will try to push tomorrow.


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

https://reviews.llvm.org/D126323

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

[PATCH] D126323: [OpenMP] Extend omp teams to permit nested omp atomic

[Joel E. Denny via Phabricator via cfe-commits]

jdenny updated this revision to Diff 431804.
jdenny added a comment.

Fixed a bug in the new tests.


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

https://reviews.llvm.org/D126323

Files:
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/nesting_of_regions.cpp
  openmp/libomptarget/test/offloading/target-teams-atomic.c
  openmp/runtime/test/teams/teams-atomic.c

Index: openmp/runtime/test/teams/teams-atomic.c
===
--- /dev/null
+++ openmp/runtime/test/teams/teams-atomic.c
@@ -0,0 +1,49 @@
+// Check that omp atomic is permitted and behaves when strictly nested within
+// omp teams.  This is an extension to OpenMP 5.2 and is enabled by default.
+
+// RUN: %libomp-compile-and-run | FileCheck %s
+
+#include 
+#include 
+#include 
+#include 
+
+// High parallelism increases our chances of detecting a lack of atomicity.
+#define NUM_TEAMS_TRY 256
+
+int main() {
+  //  CHECK: update: num_teams=[[#NUM_TEAMS:]]{{$}}
+  // CHECK-NEXT: update: x=[[#NUM_TEAMS]]{{$}}
+  int x = 0;
+  int numTeams;
+  #pragma omp teams num_teams(NUM_TEAMS_TRY)
+  {
+#pragma omp atomic update
+++x;
+if (omp_get_team_num() == 0)
+  numTeams = omp_get_num_teams();
+  }
+  printf("update: num_teams=%d\n", numTeams);
+  printf("update: x=%d\n", x);
+
+  // CHECK-NEXT: capture: x=[[#NUM_TEAMS]]{{$}}
+  // CHECK-NEXT: capture: xCapturedCount=[[#NUM_TEAMS]]{{$}}
+  bool xCaptured[numTeams];
+  memset(xCaptured, 0, sizeof xCaptured);
+  x = 0;
+  #pragma omp teams num_teams(NUM_TEAMS_TRY)
+  {
+int v;
+#pragma omp atomic capture
+v = x++;
+xCaptured[v] = true;
+  }
+  printf("capture: x=%d\n", x);
+  int xCapturedCount = 0;
+  for (int i = 0; i < numTeams; ++i) {
+if (xCaptured[i])
+  ++xCapturedCount;
+  }
+  printf("capture: xCapturedCount=%d\n", xCapturedCount);
+  return 0;
+}
Index: openmp/libomptarget/test/offloading/target-teams-atomic.c
===
--- /dev/null
+++ openmp/libomptarget/test/offloading/target-teams-atomic.c
@@ -0,0 +1,50 @@
+// Check that omp atomic is permitted and behaves when strictly nested within
+// omp target teams.  This is an extension to OpenMP 5.2 and is enabled by
+// default.
+
+// RUN: %libomptarget-compile-run-and-check-generic
+
+#include 
+#include 
+#include 
+#include 
+
+// High parallelism increases our chances of detecting a lack of atomicity.
+#define NUM_TEAMS_TRY 256
+
+int main() {
+  //  CHECK: update: num_teams=[[#NUM_TEAMS:]]{{$}}
+  // CHECK-NEXT: update: x=[[#NUM_TEAMS]]{{$}}
+  int x = 0;
+  int numTeams;
+  #pragma omp target teams num_teams(NUM_TEAMS_TRY) map(tofrom:x, numTeams)
+  {
+#pragma omp atomic update
+++x;
+if (omp_get_team_num() == 0)
+  numTeams = omp_get_num_teams();
+  }
+  printf("update: num_teams=%d\n", numTeams);
+  printf("update: x=%d\n", x);
+
+  // CHECK-NEXT: capture: x=[[#NUM_TEAMS]]{{$}}
+  // CHECK-NEXT: capture: xCapturedCount=[[#NUM_TEAMS]]{{$}}
+  bool xCaptured[numTeams];
+  memset(xCaptured, 0, sizeof xCaptured);
+  x = 0;
+  #pragma omp target teams num_teams(NUM_TEAMS_TRY) map(tofrom:x, numTeams)
+  {
+int v;
+#pragma omp atomic capture
+v = x++;
+xCaptured[v] = true;
+  }
+  printf("capture: x=%d\n", x);
+  int xCapturedCount = 0;
+  for (int i = 0; i < numTeams; ++i) {
+if (xCaptured[i])
+  ++xCapturedCount;
+  }
+  printf("capture: xCapturedCount=%d\n", xCapturedCount);
+  return 0;
+}
Index: clang/test/OpenMP/nesting_of_regions.cpp
===
--- clang/test/OpenMP/nesting_of_regions.cpp
+++ clang/test/OpenMP/nesting_of_regions.cpp
@@ -1,10 +1,11 @@
-// RUN: %clang_cc1 -fsyntax-only -fopenmp -fopenmp-version=45 -verify=expected,omp45,omp45warn %s
-// RUN: %clang_cc1 -fsyntax-only -fopenmp -verify=expected,omp50 %s
-// RUN: %clang_cc1 -fsyntax-only -fopenmp -fopenmp-version=45 -verify=expected,omp45 -Wno-openmp %s
-// RUN: %clang_cc1 -fsyntax-only -fopenmp -fopenmp-version=45 -verify=expected,omp45 -Wno-source-uses-openmp %s
+// RUN: %clang_cc1 -fsyntax-only -fopenmp -fopenmp-version=45 -fno-openmp-extensions -verify=expected,omp45,omp45warn,omp %s
+// RUN: %clang_cc1 -fsyntax-only -fopenmp -fno-openmp-extensions -verify=expected,omp50,omp %s
+// RUN: %clang_cc1 -fsyntax-only -fopenmp -fopenmp-extensions -verify=expected,omp50 %s
+// RUN: %clang_cc1 -fsyntax-only -fopenmp -fopenmp-version=45 -verify=expected,omp45,omp -fno-openmp-extensions -Wno-openmp %s
+// RUN: %clang_cc1 -fsyntax-only -fopenmp -fopenmp-version=45 -verify=expected,omp45,omp -fno-openmp-extensions -Wno-source-uses-openmp %s
 
-// RUN: %clang_cc1 -fsyntax-only -fopenmp-simd -fopenmp-version=45 -verify=expected,omp45,omp45warn %s
-// RUN: %clang_cc1 -fsyntax-only -fopenmp-simd -verify=expected,omp50 %s
+// RUN: %clang_cc1 -fsyntax-only -fopenmp-simd -fopenmp-version=45 -fno-openmp-extensions 

[PATCH] D126323: [OpenMP] Extend omp teams to permit nested omp atomic

[Alexey Bataev via Phabricator via cfe-commits]

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

LY


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126323

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

[PATCH] D125506: [PowerPC] Implement XL compat __fnabs and __fnabss builtins.

[Nathan Chancellor via Phabricator via cfe-commits]

nathanchance added a comment.

@amyk Thank you a lot for the fix! I'll pull it down and verify everything is 
fixed tonight.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125506

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

[PATCH] D125506: [PowerPC] Implement XL compat __fnabs and __fnabss builtins.

[Amy Kwan via Phabricator via cfe-commits]

amyk added a comment.

In D125506#3528380 , @nathanchance 
wrote:

> I bisected a crash when compiling the Linux kernel to this change.
>
> A reduced C reproducer:
>
>   enum {
> OP_CB_GETATTR = 3,
> OP_CB_RECALL,
> OP_CB_RECALL_ANY = 8,
> OP_CB_RECALL_SLOT = 10,
> OP_CB_NOTIFY_LOCK = 13,
> OP_CB_NOTIFY_DEVICEID,
> OP_CB_OFFLOAD
>   } static callback_ops_0;
>   int preprocess_nfs42_op_op_nr, preprocess_nfs42_op_op;
>   void preprocess_nfs42_op() {
> switch (preprocess_nfs42_op_op_nr)
> case OP_CB_GETATTR:
> case OP_CB_RECALL:
> case OP_CB_RECALL_ANY:
> case OP_CB_RECALL_SLOT:
> case OP_CB_NOTIFY_DEVICEID:
> case OP_CB_NOTIFY_LOCK:
>   preprocess_nfs42_op_op = preprocess_nfs42_op_op_nr;
> if (preprocess_nfs42_op_op_nr == OP_CB_OFFLOAD)
>   preprocess_nfs42_op_op = callback_ops_0;
>   }
>
>
>
>   $ clang --version | head -1
>   ClangBuiltLinux clang version 15.0.0 (https://github.com/llvm/llvm-project 
> 559b8fc17ef6f5a65ccf9a11fce5f91c0a011b00)
>   
>   $ clang --target=powerpc64le-linux-gnu -O2 -Wall -Wextra -c -o /dev/null 
> callback_xdr.i
>
>
>
>   $ clang --version | head -1
>   ClangBuiltLinux clang version 15.0.0 (https://github.com/llvm/llvm-project 
> c35ca3a1c78f693b749ad11742350b7fc6c5cd89)
>   
>   $ clang --target=powerpc64le-linux-gnu -O2 -Wall -Wextra -c -o /dev/null 
> callback_xdr.i
>   Impossible reg-to-reg copy
>   UNREACHABLE executed at 
> /home/nathan/cbl/src/llvm-project/llvm/lib/Target/PowerPC/PPCInstrInfo.cpp:1861!
>   PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
> and include the crash backtrace, preprocessed source, and associated run 
> script.
>   Stack dump:
>   0.  Program arguments: clang --target=powerpc64le-linux-gnu -O2 -Wall 
> -Wextra -c -o /dev/null callback_xdr.i
>   1.   parser at end of file
>   2.  Code generation
>   3.  Running pass 'Function Pass Manager' on module 'callback_xdr.i'.
>   4.  Running pass 'Post-RA pseudo instruction expansion pass' on 
> function '@preprocess_nfs42_op'
>#0 0x55a3bcb4e583 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
> (/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang-15+0x3351583)
>#1 0x55a3bcb4c50e llvm::sys::RunSignalHandlers() 
> (/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang-15+0x334f50e)
>#2 0x55a3bcad2923 (anonymous 
> namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) 
> CrashRecoveryContext.cpp:0:0
>#3 0x55a3bcad2a9e CrashRecoverySignalHandler(int) 
> CrashRecoveryContext.cpp:0:0
>#4 0x7f4af3152b00 __restore_rt (/lib64/libc.so.6+0x3eb00)
>#5 0x7f4af31a2d0c __pthread_kill_implementation 
> (/lib64/libc.so.6+0x8ed0c)
>#6 0x7f4af3152a56 gsignal (/lib64/libc.so.6+0x3ea56)
>#7 0x7f4af313c7f4 abort (/lib64/libc.so.6+0x287f4)
>#8 0x55a3bcad787f 
> (/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang-15+0x32da87f)
>#9 0x55a3bb83b308 
> llvm::PPCInstrInfo::copyPhysReg(llvm::MachineBasicBlock&, 
> llvm::MachineInstrBundleIterator, llvm::DebugLoc 
> const&, llvm::MCRegister, llvm::MCRegister, bool) const PPCInstrInfo.cpp:0:0
>   #10 0x55a3bc1242bb (anonymous 
> namespace)::ExpandPostRA::runOnMachineFunction(llvm::MachineFunction&) 
> ExpandPostRAPseudos.cpp:0:0
>   #11 0x55a3bbf62d4d 
> llvm::MachineFunctionPass::runOnFunction(llvm::Function&) 
> (/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang-15+0x2765d4d)
>   #12 0x55a3bc3fc107 llvm::FPPassManager::runOnFunction(llvm::Function&) 
> (/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang-15+0x2bff107)
>   #13 0x55a3bc403b81 llvm::FPPassManager::runOnModule(llvm::Module&) 
> (/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang-15+0x2c06b81)
>   #14 0x55a3bc3fcafc llvm::legacy::PassManagerImpl::run(llvm::Module&) 
> (/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang-15+0x2bffafc)
>   #15 0x55a3bd2fd16d clang::EmitBackendOutput(clang::DiagnosticsEngine&, 
> clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, 
> clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, 
> llvm::Module*, clang::BackendAction, std::unique_ptr std::default_delete>) 
> (/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang-15+0x3b0016d)
>   #16 0x55a3bd6a27ee 
> clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) 
> CodeGenAction.cpp:0:0
>   #17 0x55a3bdf46cb4 clang::ParseAST(clang::Sema&, bool, bool) 
> (/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang-15+0x4749cb4)
>   #18 0x55a3bd5f0f50 clang::FrontendAction::Execute() 
> (/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang-15+0x3df3f50)
>   #19 0x55a3bd565d1f 
> clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) 
> (/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang-15+0x3d68d1f)
>   #20 0x55a3bd69be92 
> clang::ExecuteCompilerInvocation(clang::CompilerInstance*) 
> 

[PATCH] D126323: [OpenMP] Extend omp teams to permit nested omp atomic

[Joel E. Denny via Phabricator via cfe-commits]

jdenny added inline comments.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:4983
+  CurrentRegion != OMPD_loop &&
+  !(SemaRef.getLangOpts().OpenMPExtensions &&
+CurrentRegion == OMPD_atomic);

ABataev wrote:
> jdenny wrote:
> > ABataev wrote:
> > > Can you add a check for 5.2?
> > This is an extension relative not only to 5.2 and but also to previous 
> > versions.  I quoted 5.2 just because it's the most recent.
> > 
> > Given that, I'm not sure why this should check for 5.2.  Am I 
> > misunderstanding your request?
> Just looks like it is allowed in 5.2. Am I missing something?
I'm not aware of any change in the 5.2 spec that would permit this.  The text I 
cited in the review summary does not include atomic in the list of regions 
"that may be strictly nested inside the teams region":

> distribute regions, including any distribute regions arising from composite 
> constructs,
> parallel regions, including any parallel regions arising from combined 
> constructs, loop
> regions, omp_get_num_teams() regions, and omp_get_team_num() regions are the
> only OpenMP regions that may be strictly nested inside the teams region.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126323

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

[PATCH] D125814: Improve the strict prototype diagnostic behavior

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith resigned from this revision.
dexonsmith added a comment.

(I’ll be happy with whatever you two sort out here!)


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

https://reviews.llvm.org/D125814

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

[PATCH] D126323: [OpenMP] Extend omp teams to permit nested omp atomic

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:4983
+  CurrentRegion != OMPD_loop &&
+  !(SemaRef.getLangOpts().OpenMPExtensions &&
+CurrentRegion == OMPD_atomic);

jdenny wrote:
> ABataev wrote:
> > Can you add a check for 5.2?
> This is an extension relative not only to 5.2 and but also to previous 
> versions.  I quoted 5.2 just because it's the most recent.
> 
> Given that, I'm not sure why this should check for 5.2.  Am I 
> misunderstanding your request?
Just looks like it is allowed in 5.2. Am I missing something?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126323

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

[PATCH] D125814: Improve the strict prototype diagnostic behavior

[James Y Knight via Phabricator via cfe-commits]

jyknight added a comment.

Good improvement, but an additional change to wording for just the zero-arg 
non-prototype function declaration case could help a lot. The fact that 
zero-arg it's only being warned about because of the "...because of" note isn't 
particularly clear -- especially when the "because of" isn't emitted.

So, suggestion for zero-arg-specific warning text:
`this function %select{declaration|definition}0 without a prototype is 
deprecated before C2x, and is treated as a zero-parameter prototype in C2x, 
conflicting with a %select{previous|subsequent}1 declaration`. Then, the 
note_func_decl_changes_behavior text can just be e.g.: `conflicting prototype 
is here`

That'd result in: `printf 'int f();\nint f(a) int a; {return 1;}' | 
build/bin/clang -c -fsyntax-only -xc -` showing:

  :2:5: warning: a function definition without a prototype is deprecated 
in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
  int f(a) int a; {return 1;}
  ^
  :1:5: warning: this function declaration without a prototype is 
deprecated before C2x, and is treated as a zero-parameter prototype in C2x, 
conflicting with a subsequent declaration [-Wdeprecated-non-prototype]
  int f();
  ^


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

https://reviews.llvm.org/D125814

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

[PATCH] D126323: [OpenMP] Extend omp teams to permit nested omp atomic

[Joel E. Denny via Phabricator via cfe-commits]

jdenny added inline comments.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:4983
+  CurrentRegion != OMPD_loop &&
+  !(SemaRef.getLangOpts().OpenMPExtensions &&
+CurrentRegion == OMPD_atomic);

ABataev wrote:
> Can you add a check for 5.2?
This is an extension relative not only to 5.2 and but also to previous 
versions.  I quoted 5.2 just because it's the most recent.

Given that, I'm not sure why this should check for 5.2.  Am I misunderstanding 
your request?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126323

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

[PATCH] D126314: [clang][dataflow] Relax `Environment` comparison operation.

[Yitzhak Mandelbaum 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 rG2f93bbb9cd7c: [clang][dataflow] Relax `Environment` 
comparison operation. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126314

Files:
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp


Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -3120,4 +3120,59 @@
   });
 }
 
+TEST_F(TransferTest, LoopWithStructReferenceAssignmentConverges) {
+  std::string Code = R"(
+struct Lookup {
+  int x;
+};
+
+void target(Lookup val, bool b) {
+  const Lookup* l = nullptr;
+  while (b) {
+l = 
+/*[[p-inner]]*/
+  }
+  (void)0;
+  /*[[p-outer]]*/
+}
+  )";
+  // The key property that we are verifying is implicit in `runDataflow` --
+  // namely, that the analysis succeeds, rather than hitting the maximum number
+  // of iterations.
+  runDataflow(
+  Code, [](llvm::ArrayRef<
+   std::pair>>
+   Results,
+   ASTContext ) {
+ASSERT_THAT(Results,
+ElementsAre(Pair("p-outer", _), Pair("p-inner", _)));
+const Environment  = Results[0].second.Env;
+const Environment  = Results[1].second.Env;
+
+const ValueDecl *ValDecl = findValueDecl(ASTCtx, "val");
+ASSERT_THAT(ValDecl, NotNull());
+
+const ValueDecl *LDecl = findValueDecl(ASTCtx, "l");
+ASSERT_THAT(LDecl, NotNull());
+
+// Inner.
+auto *LVal = dyn_cast(
+InnerEnv.getValue(*LDecl, SkipPast::None));
+ASSERT_THAT(LVal, NotNull());
+
+EXPECT_EQ(>getPointeeLoc(),
+  InnerEnv.getStorageLocation(*ValDecl, SkipPast::Reference));
+
+// Outer.
+LVal = dyn_cast(
+OuterEnv.getValue(*LDecl, SkipPast::None));
+ASSERT_THAT(LVal, NotNull());
+
+// The loop body may not have been executed, so we should not conclude
+// that `l` points to `val`.
+EXPECT_NE(>getPointeeLoc(),
+  OuterEnv.getStorageLocation(*ValDecl, SkipPast::Reference));
+});
+}
+
 } // namespace
Index: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
===
--- clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -239,9 +239,6 @@
   if (ExprToLoc != Other.ExprToLoc)
 return false;
 
-  if (MemberLocToStruct != Other.MemberLocToStruct)
-return false;
-
   // Compare the contents for the intersection of their domains.
   for (auto  : LocToVal) {
 const StorageLocation *Loc = Entry.first;


Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -3120,4 +3120,59 @@
   });
 }
 
+TEST_F(TransferTest, LoopWithStructReferenceAssignmentConverges) {
+  std::string Code = R"(
+struct Lookup {
+  int x;
+};
+
+void target(Lookup val, bool b) {
+  const Lookup* l = nullptr;
+  while (b) {
+l = 
+/*[[p-inner]]*/
+  }
+  (void)0;
+  /*[[p-outer]]*/
+}
+  )";
+  // The key property that we are verifying is implicit in `runDataflow` --
+  // namely, that the analysis succeeds, rather than hitting the maximum number
+  // of iterations.
+  runDataflow(
+  Code, [](llvm::ArrayRef<
+   std::pair>>
+   Results,
+   ASTContext ) {
+ASSERT_THAT(Results,
+ElementsAre(Pair("p-outer", _), Pair("p-inner", _)));
+const Environment  = Results[0].second.Env;
+const Environment  = Results[1].second.Env;
+
+const ValueDecl *ValDecl = findValueDecl(ASTCtx, "val");
+ASSERT_THAT(ValDecl, NotNull());
+
+const ValueDecl *LDecl = findValueDecl(ASTCtx, "l");
+ASSERT_THAT(LDecl, NotNull());
+
+// Inner.
+auto *LVal = dyn_cast(
+InnerEnv.getValue(*LDecl, SkipPast::None));
+ASSERT_THAT(LVal, NotNull());
+
+EXPECT_EQ(>getPointeeLoc(),
+  InnerEnv.getStorageLocation(*ValDecl, SkipPast::Reference));
+
+// Outer.
+LVal = dyn_cast(
+OuterEnv.getValue(*LDecl, SkipPast::None));
+ASSERT_THAT(LVal, NotNull());
+
+// The loop body may not have been executed, so we should not conclude
+// that `l` points to 

[clang] 2f93bbb - [clang][dataflow] Relax `Environment` comparison operation.

[Yitzhak Mandelbaum via cfe-commits]

Author: Yitzhak Mandelbaum
Date: 2022-05-24T20:58:18Z
New Revision: 2f93bbb9cd7c20ea1a273cf652d852d4b641f94a

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

LOG: [clang][dataflow] Relax `Environment` comparison operation.

Ignore `MemberLocToStruct` in environment comparison. As an ancillary data
structure, including it is redundant. We also can generate environments which
differ in their `MemberLocToStruct` but are otherwise equivalent.

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

Added: 


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

Removed: 




diff  --git a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp 
b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
index 51aea12cb271..e555bee0e8bf 100644
--- a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -239,9 +239,6 @@ bool Environment::equivalentTo(const Environment ,
   if (ExprToLoc != Other.ExprToLoc)
 return false;
 
-  if (MemberLocToStruct != Other.MemberLocToStruct)
-return false;
-
   // Compare the contents for the intersection of their domains.
   for (auto  : LocToVal) {
 const StorageLocation *Loc = Entry.first;

diff  --git a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
index 981940929104..b6d2940a98da 100644
--- a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -3120,4 +3120,59 @@ TEST_F(TransferTest, 
LoopWithReferenceAssignmentConverges) {
   });
 }
 
+TEST_F(TransferTest, LoopWithStructReferenceAssignmentConverges) {
+  std::string Code = R"(
+struct Lookup {
+  int x;
+};
+
+void target(Lookup val, bool b) {
+  const Lookup* l = nullptr;
+  while (b) {
+l = 
+/*[[p-inner]]*/
+  }
+  (void)0;
+  /*[[p-outer]]*/
+}
+  )";
+  // The key property that we are verifying is implicit in `runDataflow` --
+  // namely, that the analysis succeeds, rather than hitting the maximum number
+  // of iterations.
+  runDataflow(
+  Code, [](llvm::ArrayRef<
+   std::pair>>
+   Results,
+   ASTContext ) {
+ASSERT_THAT(Results,
+ElementsAre(Pair("p-outer", _), Pair("p-inner", _)));
+const Environment  = Results[0].second.Env;
+const Environment  = Results[1].second.Env;
+
+const ValueDecl *ValDecl = findValueDecl(ASTCtx, "val");
+ASSERT_THAT(ValDecl, NotNull());
+
+const ValueDecl *LDecl = findValueDecl(ASTCtx, "l");
+ASSERT_THAT(LDecl, NotNull());
+
+// Inner.
+auto *LVal = dyn_cast(
+InnerEnv.getValue(*LDecl, SkipPast::None));
+ASSERT_THAT(LVal, NotNull());
+
+EXPECT_EQ(>getPointeeLoc(),
+  InnerEnv.getStorageLocation(*ValDecl, SkipPast::Reference));
+
+// Outer.
+LVal = dyn_cast(
+OuterEnv.getValue(*LDecl, SkipPast::None));
+ASSERT_THAT(LVal, NotNull());
+
+// The loop body may not have been executed, so we should not conclude
+// that `l` points to `val`.
+EXPECT_NE(>getPointeeLoc(),
+  OuterEnv.getStorageLocation(*ValDecl, SkipPast::Reference));
+});
+}
+
 } // namespace



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

[PATCH] D126323: [OpenMP] Extend omp teams to permit nested omp atomic

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:4983
+  CurrentRegion != OMPD_loop &&
+  !(SemaRef.getLangOpts().OpenMPExtensions &&
+CurrentRegion == OMPD_atomic);

Can you add a check for 5.2?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126323

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

[PATCH] D126031: [libclang] add supporting for indexing/visiting C++ concepts

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added a comment.

Marked them as unsupported on AIX in 1b34f1e996565bc5e4f2be14b89f881f8fe0f3b9 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126031

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

[clang] 1b34f1e - [clang][test] mark tests added in ee8524087c78 as unsupported on AIX

[Alex Lorenz via cfe-commits]

Author: Alex Lorenz
Date: 2022-05-24T13:39:37-07:00
New Revision: 1b34f1e996565bc5e4f2be14b89f881f8fe0f3b9

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

LOG: [clang][test] mark tests added in ee8524087c78 as unsupported on AIX

These tests are failing on the PPC64 AIX CI bot, but it's unclear why,
as they pass on other CI jobs.
I marked them as unsupported on AIX for now while investigating the failure.

Added: 


Modified: 
clang/test/Index/index-concept-kind.cpp
clang/test/Index/index-concepts.cpp

Removed: 




diff  --git a/clang/test/Index/index-concept-kind.cpp 
b/clang/test/Index/index-concept-kind.cpp
index 7aaf814f5f989..f33fc6bc5cc0d 100644
--- a/clang/test/Index/index-concept-kind.cpp
+++ b/clang/test/Index/index-concept-kind.cpp
@@ -1,5 +1,5 @@
 // RUN: c-index-test -index-file %s -std=gnu++20 | FileCheck %s
-
+// UNSUPPORTED: aix
 template 
 concept LargeType = sizeof(T) > 8;
 // CHECK: [indexDeclaration]: kind: concept | name: LargeType | USR: 
c:@CT@LargeType | lang: C | cursor: ConceptDecl=LargeType:[[@LINE-1]]:9 
(Definition) | loc: [[@LINE-1]]:9 | semantic-container: [TU] | 
lexical-container: [TU] | isRedecl: 0 | isDef: 1 | isContainer: 0 | isImplicit: 0

diff  --git a/clang/test/Index/index-concepts.cpp 
b/clang/test/Index/index-concepts.cpp
index 9887e9fdc6541..ba4b87111ff48 100644
--- a/clang/test/Index/index-concepts.cpp
+++ b/clang/test/Index/index-concepts.cpp
@@ -1,5 +1,5 @@
 // RUN: c-index-test -test-load-source all %s -std=gnu++20 
-fno-delayed-template-parsing | FileCheck %s
-
+// UNSUPPORTED: aix
 template
 struct type_trait {
 const static bool value = false;



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

[PATCH] D126137: [X86] Add support for `-mharden-sls=all`

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added a comment.

Diff 431607 boots for me in QEMU (triple checked that CONFIG_CC_HAS_SLS=y AND 
CONFIG_SLS=y were set this time ;) ).




Comment at: clang/docs/ReleaseNotes.rst:371
 
+- Support ``-mharden-sls=all`` for X86.
+

pengfei wrote:
> nickdesaulniers wrote:
> > This should be updated if additional options are supported.
> > 
> > You should also update `clang/docs/ClangCommandLineReference.rst` I think.
> There's already introduction there.
We should expand the introduction there to state explicitly what options are 
supported for which targets.



Comment at: clang/lib/Driver/ToolChains/Arch/X86.cpp:252-254
+} else if (Scope == "none") {
+  Features.push_back("-harden-sls-ind");
+  Features.push_back("-harden-sls-ret");

I think if the `Scope` is `"none"`, we can simply do nothing.
@craig.topper is there a precedent for target features being "unset" like this? 
I guess it doesn't matter much either way...



Comment at: llvm/lib/Target/X86/X86AsmPrinter.cpp:345
+  const MCInstrDesc  = I->getDesc();
+  auto IsIndirectTailCall = [I, ]() {
+return Desc.isCall() && Desc.isReturn() && Desc.isBarrier() &&

How come you capture `Desc` by reference, and `I` by value? Might it be simpler 
to just have static functions defined above `X86AsmPrinter::emitBasicBlockEnd` 
that accepts an MCInstr by reference?



Comment at: llvm/lib/Target/X86/X86AsmPrinter.cpp:346
+  auto IsIndirectTailCall = [I, ]() {
+return Desc.isCall() && Desc.isReturn() && Desc.isBarrier() &&
+   !I->getOperand(0).isGlobal();

Why `isBarrier`? Maybe add a comment that mentions a specific TableGen record 
from llvm/lib/Target/X86/X86InstrControl.td?  That would help me verify that 
`isBarrier()` is correct here.

I'm guessing this is:

363 let isCall = 1, isTerminator = 1, isReturn = 1, isBarrier = 1,  

364 isCodeGenOnly = 1, Uses = [RSP, SSP] in {

block in llvm/lib/Target/X86/X86InstrControl.td.

Otherwise llvm/lib/Target/X86/X86FrameLowering.cpp has a static function that I 
think is precisely what we want here, called ` isTailCallOpcode`. Perhaps move 
that to a header shared between the two translation units then reuse it here?  
A few other backends have an `IsTailCall` method though they're inconsistent 
where they define it. It still would be good though to try to match existing 
conventions which makes jumping between backends easier.



Comment at: llvm/lib/Target/X86/X86AsmPrinter.cpp:347
+return Desc.isCall() && Desc.isReturn() && Desc.isBarrier() &&
+   !I->getOperand(0).isGlobal();
+  };

Rather than `!...isGlobal()`, would it be more precise to use 
`getOperand(0).isReg()`?  Looking at all of the values of `enum 
MachineOperandType`, I think it would be more precise if we check the operand 
is of one type, rather than "not one type."



Comment at: llvm/lib/Target/X86/X86AsmPrinter.cpp:349
+  };
+  if ((Subtarget->hardenSlsRet() && Desc.isReturn() && !Desc.isCall()) ||
+  (Subtarget->hardenSlsInd() &&

So this check is logically "isn't a tail call"?

I feel like we could have a helper or lamba for "is this a tail call" and "is 
this an indirect call" and compose our logic here out of those two.  Having 
descriptive names would make the code more readable, otherwise one has to think 
about which instruction is a return and not a call.



Comment at: llvm/test/CodeGen/X86/speculation-hardening-sls.ll:7
+; CHECK: jle
+; CEHCK-NOT: int3
+; CHECK: retq

typo



Comment at: llvm/test/CodeGen/X86/speculation-hardening-sls.ll:59
+; CHECK: jmp .L
+; CEHCK-NOT: int3
+; CHECK: retq

typo



Comment at: llvm/test/CodeGen/X86/speculation-hardening-sls.ll:83-94
+; CEHCK-NOT: ret
+  tail call void %0()
+  ret void
+}
+
+declare dso_local void @foo()
+

3 typos, s/CEHCK/CHECK/g


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126137

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

[PATCH] D126324: [clang] Allow const variables with weak attribute to be overridden

[Anders Waldenborg via Phabricator via cfe-commits]

wanders created this revision.
wanders added reviewers: lattner, jyknight, rsmith.
wanders added a project: clang.
Herald added a reviewer: aaron.ballman.
Herald added a project: All.
wanders requested review of this revision.
Herald added a subscriber: cfe-commits.

A variable with `weak` attribute signifies that it can be replaced with
a "strong" symbol link time. Therefore it must not emitted with
"weak_odr" linkage, as that allows the backend to use its value in
optimizations.

The frontend already considers weak const variables as
non-constant (note_constexpr_var_init_weak diagnostic) so this change
makes frontend and backend consistent.

This commit reverses the

  f49573d1 weak globals that are const should get weak_odr linkage.

commit from 2009-08-05 which introduced this behavior. Unfortunately
that commit doesn't provide any details on why the change was made.

This was discussed in
https://discourse.llvm.org/t/weak-attribute-semantics-on-const-variables/62311


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126324

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/global-init.c
  clang/test/CodeGen/weak_constant.c

Index: clang/test/CodeGen/weak_constant.c
===
--- clang/test/CodeGen/weak_constant.c
+++ clang/test/CodeGen/weak_constant.c
@@ -1,13 +1,31 @@
 // RUN: %clang_cc1 -w -emit-llvm %s -O1 -o - | FileCheck %s
-// Check for bug compatibility with gcc.
+// This used to "check for bug compatibility with gcc".
+// Now it checks that that the "weak" declaration makes the value
+// fully interposable whereas a "selectany" one is handled as constant
+// and propagated.
 
+// CHECK: @x = weak constant i32 123
 const int x __attribute((weak)) = 123;
 
+// CHECK: @y = weak_odr constant i32 234
+const int y __attribute((selectany)) = 234;
+
 int* f(void) {
   return 
 }
 
 int g(void) {
-  // CHECK: ret i32 123
+  // CHECK: load i32, ptr @x
+  // CHECK-NOT: ret i32 123
   return *f();
 }
+
+int* k(void) {
+  return 
+}
+
+int l(void) {
+  // CHECK-NOT: load i32, ptr @y
+  // CHECK: ret i32 234
+  return *k();
+}
Index: clang/test/CodeGen/global-init.c
===
--- clang/test/CodeGen/global-init.c
+++ clang/test/CodeGen/global-init.c
@@ -9,14 +9,22 @@
 
 // This should get normal weak linkage.
 int c __attribute__((weak))= 0;
-// CHECK: @c = weak{{.*}} global i32 0
+// CHECK: @c = weak global i32 0
 
 
-// Since this is marked const, it should get weak_odr linkage, since all
-// definitions have to be the same.
-// CHECK: @d = weak_odr constant i32 0
+// Even though is marked const, it should get still get "weak"
+// linkage, not "weak_odr" as the weak attribute makes it possible
+// that there is a strong definition that changes the value linktime,
+// so the value must not be considered constant.
+// CHECK: @d = weak constant i32 0
 const int d __attribute__((weak))= 0;
 
+// However, "selectany" is similar to "weak", but isn't interposable
+// by a strong definition, and should appear as weak_odr.
+// CHECK: @e = weak_odr constant i32 17
+const int e __attribute__((selectany)) = 17;
+
+
 // PR6168 "too many undefs"
 struct ManyFields {
   int a;
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -4893,12 +4893,8 @@
   if (Linkage == GVA_Internal)
 return llvm::Function::InternalLinkage;
 
-  if (D->hasAttr()) {
-if (IsConstantVariable)
-  return llvm::GlobalVariable::WeakODRLinkage;
-else
-  return llvm::GlobalVariable::WeakAnyLinkage;
-  }
+  if (D->hasAttr())
+return llvm::GlobalVariable::WeakAnyLinkage;
 
   if (const auto *FD = D->getAsFunction())
 if (FD->isMultiVersion() && Linkage == GVA_AvailableExternally)
Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -6477,3 +6477,69 @@
 The full documentation is available here: https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/sv-groupindex
   }];
 }
+
+def WeakDocs : Documentation {
+  let Category = DocCatDecl;
+  let Content = [{
+
+In supported output formats the ``weak`` attribute can be used to
+specify that a variable or function should be emitted as a symbol with
+``weak`` (if a definition) or ``extern_weak`` (if a declaration of an
+external symbol) `linkage
+`_.
+
+If there is a non-weak definition of the symbol the linker will select
+that over the weak. They must have same type and alignment (variables
+must also have the same size), but may have a different value.
+
+If there are multiple weak definitions of same symbol, but no 

[PATCH] D126031: [libclang] add supporting for indexing/visiting C++ concepts

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added a comment.

@Jake-Egan 
I'm going to disable these tests for `aix` for now to unblock the bot as 
they're still failing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126031

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

[PATCH] D126323: [OpenMP] Extend omp teams to permit nested omp atomic

[Joel E. Denny via Phabricator via cfe-commits]

jdenny created this revision.
jdenny added reviewers: jdoerfert, ABataev.
jdenny added a project: OpenMP.
Herald added subscribers: guansong, yaxunl.
Herald added a project: All.
jdenny requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

OpenMP 5.2, sec. 10.2 "teams Construct", p. 232, L9-12 restricts what
regions can be strictly nested within a `teams` construct.  This patch
relaxes Clang's enforcement of this restriction in the case of nested
`atomic` constructs unless `-fno-openmp-extensions` is specified.
Cases like the following then seem to work fine with no additional
implementation changes:

  #pragma omp target teams map(tofrom:x)
  #pragma omp atomic update
  x++;


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126323

Files:
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/nesting_of_regions.cpp
  openmp/libomptarget/test/offloading/target-teams-atomic.c
  openmp/runtime/test/teams/teams-atomic.c

Index: openmp/runtime/test/teams/teams-atomic.c
===
--- /dev/null
+++ openmp/runtime/test/teams/teams-atomic.c
@@ -0,0 +1,47 @@
+// Check that omp atomic is permitted and behaves when strictly nested within
+// omp teams.  This is an extension to OpenMP 5.2 and is enabled by default.
+
+// RUN: %libomp-compile-and-run | FileCheck %s
+
+#include 
+#include 
+#include 
+#include 
+
+// High parallelism increases our chances of detecting a lack of atomicity.
+#define NUM_TEAMS_TRY 256
+
+int main() {
+  //  CHECK: update: num_teams=[[#NUM_TEAMS:]]{{$}}
+  // CHECK-NEXT: update: x=[[#NUM_TEAMS]]{{$}}
+  int x = 0;
+  int numTeams;
+  #pragma omp teams num_teams(NUM_TEAMS_TRY)
+  {
+#pragma omp atomic update
+++x;
+if (omp_get_team_num() == 0)
+  numTeams = omp_get_num_teams();
+  }
+  printf("update: num_teams=%d\n", numTeams);
+  printf("update: x=%d\n", x);
+
+  // CHECK-NEXT: capture: x=[[#NUM_TEAMS]]{{$}}
+  // CHECK-NEXT: capture: xCapturedCount=[[#NUM_TEAMS]]{{$}}
+  bool xCaptured[numTeams];
+  memset(xCaptured, 0, sizeof xCaptured);
+  x = 0;
+  #pragma omp teams num_teams(NUM_TEAMS_TRY)
+  {
+int v;
+#pragma omp atomic capture
+v = x++;
+xCaptured[v] = true;
+  }
+  printf("capture: x=%d\n", x);
+  int xCapturedCount = 0;
+  for (int i = 0; i < numTeams; ++i)
+++xCapturedCount;
+  printf("capture: xCapturedCount=%d\n", xCapturedCount);
+  return 0;
+}
Index: openmp/libomptarget/test/offloading/target-teams-atomic.c
===
--- /dev/null
+++ openmp/libomptarget/test/offloading/target-teams-atomic.c
@@ -0,0 +1,48 @@
+// Check that omp atomic is permitted and behaves when strictly nested within
+// omp target teams.  This is an extension to OpenMP 5.2 and is enabled by
+// default.
+
+// RUN: %libomptarget-compile-run-and-check-generic
+
+#include 
+#include 
+#include 
+#include 
+
+// High parallelism increases our chances of detecting a lack of atomicity.
+#define NUM_TEAMS_TRY 256
+
+int main() {
+  //  CHECK: update: num_teams=[[#NUM_TEAMS:]]{{$}}
+  // CHECK-NEXT: update: x=[[#NUM_TEAMS]]{{$}}
+  int x = 0;
+  int numTeams;
+  #pragma omp target teams num_teams(NUM_TEAMS_TRY) map(tofrom:x, numTeams)
+  {
+#pragma omp atomic update
+++x;
+if (omp_get_team_num() == 0)
+  numTeams = omp_get_num_teams();
+  }
+  printf("update: num_teams=%d\n", numTeams);
+  printf("update: x=%d\n", x);
+
+  // CHECK-NEXT: capture: x=[[#NUM_TEAMS]]{{$}}
+  // CHECK-NEXT: capture: xCapturedCount=[[#NUM_TEAMS]]{{$}}
+  bool xCaptured[numTeams];
+  memset(xCaptured, 0, sizeof xCaptured);
+  x = 0;
+  #pragma omp target teams num_teams(NUM_TEAMS_TRY) map(tofrom:x, numTeams)
+  {
+int v;
+#pragma omp atomic capture
+v = x++;
+xCaptured[v] = true;
+  }
+  printf("capture: x=%d\n", x);
+  int xCapturedCount = 0;
+  for (int i = 0; i < numTeams; ++i)
+++xCapturedCount;
+  printf("capture: xCapturedCount=%d\n", xCapturedCount);
+  return 0;
+}
Index: clang/test/OpenMP/nesting_of_regions.cpp
===
--- clang/test/OpenMP/nesting_of_regions.cpp
+++ clang/test/OpenMP/nesting_of_regions.cpp
@@ -1,10 +1,11 @@
-// RUN: %clang_cc1 -fsyntax-only -fopenmp -fopenmp-version=45 -verify=expected,omp45,omp45warn %s
-// RUN: %clang_cc1 -fsyntax-only -fopenmp -verify=expected,omp50 %s
-// RUN: %clang_cc1 -fsyntax-only -fopenmp -fopenmp-version=45 -verify=expected,omp45 -Wno-openmp %s
-// RUN: %clang_cc1 -fsyntax-only -fopenmp -fopenmp-version=45 -verify=expected,omp45 -Wno-source-uses-openmp %s
+// RUN: %clang_cc1 -fsyntax-only -fopenmp -fopenmp-version=45 -fno-openmp-extensions -verify=expected,omp45,omp45warn,omp %s
+// RUN: %clang_cc1 -fsyntax-only -fopenmp -fno-openmp-extensions -verify=expected,omp50,omp %s
+// RUN: %clang_cc1 -fsyntax-only -fopenmp -fopenmp-extensions 

[PATCH] D126061: [clang] [WIP] Reject non-declaration C++11 attributes on declarations

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:9118
+  ProcessDeclAttributeOptions Options;
+  Options.IncludeCXX11Attributes = AL.isCXX11Attribute();
+  ProcessDeclAttribute(*this, nullptr, ASDecl, AL, Options);

rsmith wrote:
> aaron.ballman wrote:
> > rsmith wrote:
> > > This seems to be equivalent to setting `IncludeCXX11Attributes` to 
> > > `true`, which seems to be equivalent to not setting it at all.
> > Hmmm, not quite -- `AL.isCXX11Attribute()` may return `false` (like for the 
> > GNU spelling of this attribute).
> It might, but we only care about the value of `IncludeCXX11Attributes` when 
> processing a C++11 attribute, so it doesn't matter how this flag is set for a 
> non-C++11 attribute.
Oh, good observation, you're right!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126061

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

[PATCH] D126316: [clang][dataflow] Make limit on fixpoint-algorithm iterations proportional to size of CFG.

[Yitzhak Mandelbaum 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 rG6eb9e0f5ebb9: [clang][dataflow] Make limit on 
fixpoint-algorithm iterations proportional to… (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126316

Files:
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp


Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -11,6 +11,7 @@
 //
 
//===--===//
 
+#include 
 #include 
 #include 
 #include 
@@ -330,10 +331,17 @@
   // converging. To limit the damage (infinite loops) that these bugs can 
cause,
   // limit the number of iterations.
   // FIXME: Consider making the maximum number of iterations configurable.
+  // FIXME: Consider restricting the number of backedges followed, rather than
+  // iterations.
   // FIXME: Set up statistics (see llvm/ADT/Statistic.h) to count average 
number
   // of iterations, number of functions that time out, etc.
+  static constexpr uint32_t MaxAverageVisitsPerBlock = 4;
+  static constexpr uint32_t AbsoluteMaxIterations = 1 << 16;
+  const uint32_t RelativeMaxIterations =
+  MaxAverageVisitsPerBlock * BlockStates.size();
+  const uint32_t MaxIterations =
+  std::min(RelativeMaxIterations, AbsoluteMaxIterations);
   uint32_t Iterations = 0;
-  static constexpr uint32_t MaxIterations = 1 << 16;
   while (const CFGBlock *Block = Worklist.dequeue()) {
 if (++Iterations > MaxIterations) {
   return llvm::createStringError(std::errc::timed_out,


Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -11,6 +11,7 @@
 //
 //===--===//
 
+#include 
 #include 
 #include 
 #include 
@@ -330,10 +331,17 @@
   // converging. To limit the damage (infinite loops) that these bugs can cause,
   // limit the number of iterations.
   // FIXME: Consider making the maximum number of iterations configurable.
+  // FIXME: Consider restricting the number of backedges followed, rather than
+  // iterations.
   // FIXME: Set up statistics (see llvm/ADT/Statistic.h) to count average number
   // of iterations, number of functions that time out, etc.
+  static constexpr uint32_t MaxAverageVisitsPerBlock = 4;
+  static constexpr uint32_t AbsoluteMaxIterations = 1 << 16;
+  const uint32_t RelativeMaxIterations =
+  MaxAverageVisitsPerBlock * BlockStates.size();
+  const uint32_t MaxIterations =
+  std::min(RelativeMaxIterations, AbsoluteMaxIterations);
   uint32_t Iterations = 0;
-  static constexpr uint32_t MaxIterations = 1 << 16;
   while (const CFGBlock *Block = Worklist.dequeue()) {
 if (++Iterations > MaxIterations) {
   return llvm::createStringError(std::errc::timed_out,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 6eb9e0f - [clang][dataflow] Make limit on fixpoint-algorithm iterations proportional to size of CFG.

[Yitzhak Mandelbaum via cfe-commits]

Author: Yitzhak Mandelbaum
Date: 2022-05-24T20:13:55Z
New Revision: 6eb9e0f5ebb94cccf52ea27aa342001b84c1c8b1

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

LOG: [clang][dataflow] Make limit on fixpoint-algorithm iterations proportional 
to size of CFG.

Currently, the maximum number of iterations of the loop for finding the fixpoint
of the dataflow analysis is set at 2^16. When things go wrong in an analysis,
this can be far too large.  This patch changes the limit to be proportional to
the size of the CFG, which will generally be far smaller than 2^16 (while still
maintaining 2^16 as the absolute limit).

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

Added: 


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

Removed: 




diff  --git a/clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp 
b/clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
index aebc9dd6f6fac..ee1723dcd8cc8 100644
--- a/clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ b/clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -11,6 +11,7 @@
 //
 
//===--===//
 
+#include 
 #include 
 #include 
 #include 
@@ -330,10 +331,17 @@ runTypeErasedDataflowAnalysis(const ControlFlowContext 
,
   // converging. To limit the damage (infinite loops) that these bugs can 
cause,
   // limit the number of iterations.
   // FIXME: Consider making the maximum number of iterations configurable.
+  // FIXME: Consider restricting the number of backedges followed, rather than
+  // iterations.
   // FIXME: Set up statistics (see llvm/ADT/Statistic.h) to count average 
number
   // of iterations, number of functions that time out, etc.
+  static constexpr uint32_t MaxAverageVisitsPerBlock = 4;
+  static constexpr uint32_t AbsoluteMaxIterations = 1 << 16;
+  const uint32_t RelativeMaxIterations =
+  MaxAverageVisitsPerBlock * BlockStates.size();
+  const uint32_t MaxIterations =
+  std::min(RelativeMaxIterations, AbsoluteMaxIterations);
   uint32_t Iterations = 0;
-  static constexpr uint32_t MaxIterations = 1 << 16;
   while (const CFGBlock *Block = Worklist.dequeue()) {
 if (++Iterations > MaxIterations) {
   return llvm::createStringError(std::errc::timed_out,



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

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

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

rsmith added inline comments.
Herald added a project: All.



Comment at: clang/lib/AST/ASTContext.cpp:11551-11552
+if (Unqualified && !Ctx.hasSameType(X, Y)) {
+  assert(Ctx.hasSameUnqualifiedType(X, Y));
+  auto XQuals = X.getCVRQualifiers(), YQuals = Y.getCVRQualifiers();
+  X.addFastQualifiers(YQuals & ~XQuals);

What should happen if there's a qualifier difference other than a CVR 
qualifier? Eg, address space or ObjC lifetime.



Comment at: clang/lib/AST/ASTContext.cpp:11578
+  default:
+return X;
+  }

For `TemplateArgument::ArgKind::Declaration`, I think it'd make sense to take 
the common type of the `getParamTypeForDecl`s.



Comment at: clang/lib/AST/ASTContext.cpp:11603
+ ? X->getQualifier()
+ : Ctx.getCanonicalNestedNameSpecifier(X->getQualifier());
+}

Might be worth adding a `FIXME` to keep as much common NNS sugar as we can?



Comment at: clang/lib/AST/ASTContext.cpp:11632-11633
+
+static QualType getCommonCanonicalType(ASTContext , const Type *X,
+   const Type *Y) {
+  Type::TypeClass TC = X->getTypeClass();

I don't understand this function name: there's only one canonical 
representation of a type, so this seems paradoxical. I think 
`getCommonDesugaredType` is probably a clearer name for what this is doing.



Comment at: clang/lib/AST/ASTContext.cpp:11790-11801
+if (EPIX.ExceptionSpec.Exceptions.size() ==
+EPIY.ExceptionSpec.Exceptions.size()) {
+  auto E = getCommonTypeArray(Ctx, EPIX.ExceptionSpec.Exceptions,
+  EPIY.ExceptionSpec.Exceptions);
+  EPIX.ExceptionSpec.Exceptions = E;
+  return Ctx.getFunctionType(R, P, EPIX);
+} else {

This seems a bit suspicious: `getCommonTypeArray` assumes the two arrays 
contain the same types in the same order, but if the arrays can be different 
sizes, is it really correct to assume that they contain the same types if 
they're the same size?

Can we make this work the same way that the conditional expression handling 
deals with differing lists of exception types?



Comment at: clang/lib/AST/ASTContext.cpp:11861
+   *IY = cast(Y);
+assert(IX->getDecl() == IY->getDecl());
+return Ctx.getInjectedClassNameType(

I think this should probably be a `declaresSameEntity` check: we might be 
comparing injected class names from two different merged modules with two 
different declarations for the same class definition. The right declaration to 
use is the one that is chosen to be "the" definition.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111283

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

[PATCH] D125291: Introduce @llvm.threadlocal.address intrinsic to access TLS variable (1/3)

[Nicolai Hähnle via Phabricator via cfe-commits]

nhaehnle added inline comments.



Comment at: llvm/include/llvm/IR/Intrinsics.td:1393-1394
 
+def int_threadlocal_address : Intrinsic<[llvm_ptr_ty], [llvm_ptr_ty],
+[IntrNoMem, IntrWillReturn]>;
+

Whether IntrNoMem is truly correct here depends on the overall solution of the 
thread identification issue, i.e. it depends on whether readnone implies 
"doesn't read thread ID". We'd best discuss that separately.


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

https://reviews.llvm.org/D125291

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

[PATCH] D125904: [Cuda] Use fallback method to mangle externalized decls if no CUID given

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:6836
+
+  // If the CUID is not specified we try to generate a unique postfix.
+  if (getLangOpts().CUID.empty()) {

jhuber6 wrote:
> tra wrote:
> > > However, [CUID] is not always availible. 
> > 
> > The question is -- when and why is it not available? I'm getting the 
> > feeling that we're fixing the consequence here, not the root cause.
> > 
> > Is there a reason we can't make sure that the driver always generates a 
> > cuid for offload subcompilations and error out if it's needed but is not 
> > provided?
> > That would make this fallback unnecessary and would be a more robust 
> > approach in general.
> > 
> So, I'm more in favor of this approach because it doesn't require extra 
> intervention from the compiler driver, this makes it less convoluted to do 
> split compilation since we don't have an extra arguments. The way I would 
> prefer it, is that we do this implicitly by default without requiring extra 
> thought from the driver, but if it's not good enough we can support the 
> manual `CUID` approach to let the user override it. I think this is a cleaner 
> implementation, and is mostly coming from my support for CUDA in the new 
> driver which currently doesn't implement the CUID as we do with the old 
> driver. Generally I'd prefer things to behave independent of the driver, so 
> we can consider host and device compilation more separately.
> So, I'm more in favor of this approach because it doesn't require extra 
> intervention from the compiler driver

We need the driver intervention for any cc1 compilations anyways, so this does 
not buy us anything.  While you can run a sub-compilation manually with 
handcrafted cc1 flags, that's not a practical use case. The driver is the 
ultimate source of cc1 flags.

> this makes it less convoluted to do split compilation since we don't have an 
> extra arguments.

For CUDA/HIP sub-compilation should be done with clang 
--cuda-host-only/--cuda-device-only.  Whether the driver supplies yet another 
cc1 option, --cuid=... makes no difference to the user launching such 
sub-compilation. 

> The way I would prefer it, is that we do this implicitly by default without 
> requiring extra thought from the driver, but if it's not good enough we can 
> support the manual CUID approach to let the user override it.

I agree that we can come up with something that will almost always work. 
Possibly even good enough for all practical purposes. However, if a better 
solution would take comparable effort, it would make sense to do things right 
and avoid adding technical debt. 

On the other hand, requiring the driver to supply identical cuid to all 
sub-compilations appears to be a better approach to me:
* Driver is the best place to do it, functionally. Driver has access to all 
user-provided inputs and is in position to guarantee that all subcompilations 
get the same cuid.
* Calculating CUID in the driver keeps relevant logic in one place. Doing it in 
the driver *and* in the codegen 
* Figuring out what inputs are relevant for calculation of CUID in cc1 
invocation is error prone. E.g. we have to guess which cc1 options are relevant 
or not and is the driver would pass a macro to one subcompilation but not to 
another, we would end up generating mismatching CUID and would not have any way 
to notice that. Even when that's not the case, we would need to guess which 
flags, supplied by the driver, are relevant. At CC1 level that may be somewhat 
complicated as top-level options may expand to quite a few more cc1 options. 
E.g. we'll need to take into account `-std=...`, `--cuda-path=`, `-include 
...`, `-I` (and other include paths)... All of that does not belong to the 
codegen.

The driver is already doing CUID computation, so I do not see any downsides to 
just letting it do its job, and I do believe it will be a better, and likely 
less complicated, solution.

> ... mostly coming from my support for CUDA in the new driver which currently 
> doesn't implement the CUID as we do with the old driver

Right. That appears to be the key missing piece.

What are the obstacles for having CUID calculation done in the new driver. It 
should have all the info it needs. What am I missing?



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125904

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

[PATCH] D125788: [flang][driver] Rename `flang-new` as `flang`

[Steve Scalpone via Phabricator via cfe-commits]

sscalpone added a comment.

My proposal is:

If the compiler compiles it, it ought to run.
If the compiler can't compile it, it ought to clearly say why.

1. All tests of legal Fortran that compile & link must also execute correctly 
(which excludes tests that expect to catch a problem at runtime)
2. For all tests with unsupported features, the compiler must issues an error 
message and the message references the source-location of the unsupported 
feature

My preference is to use the NAG test suite.   It is not freely available.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125788

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

[PATCH] D125291: Introduce @llvm.threadlocal.address intrinsic to access TLS variable (1/3)

[Nicolai Hähnle via Phabricator via cfe-commits]

nhaehnle added a comment.

You can use the "Edit Related Revisions" option in the right-hand side menu of 
Phabricator to link this revision with the others of the series. I can't really 
speak for the Clang parts, but the LLVM parts looks reasonable to me modulo 
some detail comments.




Comment at: llvm/docs/LangRef.rst:24392-24403
+Overview:
+""
+
+The LLVM treated the address of thread local variable as a constant expression.
+But it is not true. The ``llvm.threadlocal.address`` intrinsic would represent
+the address of the thread local variable.
+

LangRef should be written in present tense. Something like:

> The address of a thread local variable is not a constant, since it depends on 
> the calling thread. The ``llvm.threadlocal.address`` intrinsic returns the 
> address of the given thread local variable in the calling thread.



Comment at: llvm/include/llvm/IR/IRBuilder.h:746-747
 
+  /// Create a call to llvm.threadlocal.address intrinsic.
+  CallInst *CreateThreadLocalAddress(Value *Ptr);
+

This could be a `GlobalValue*` operand to reduce the risk of misuse, right?


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

https://reviews.llvm.org/D125291

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

[PATCH] D125974: [clang] Limit bitcode option ignorelist to Darwin

[Michiel Derhaeg via Phabricator via cfe-commits]

MichielDerhaeg updated this revision to Diff 431768.
MichielDerhaeg marked an inline comment as done.
MichielDerhaeg added a comment.

- add target requirement to lit test
- move condition


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125974

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/embed-bitcode-elf.c

Index: clang/test/Driver/embed-bitcode-elf.c
===
--- /dev/null
+++ clang/test/Driver/embed-bitcode-elf.c
@@ -0,0 +1,16 @@
+// REQUIRES: aarch64-registered-target
+
+// RUN: %clang -c -target aarch64-linux-android21 %s -fembed-bitcode -o %t.o \
+// RUN: -ffunction-sections -fdata-sections -fstack-protector-strong
+
+// RUN: llvm-readobj -S %t.o | FileCheck --check-prefix=CHECK %s
+// CHECK:   Name: .text.foo
+// CHECK:   Name: .llvmbc
+// CHECK:   Name: .llvmcmd
+
+// RUN: llvm-objcopy %t.o --dump-section=.llvmcmd=%t.llvmcmd
+// RUN: FileCheck --check-prefix=CMD %s < %t.llvmcmd
+// CMD: ffunction-sections
+// CMD: fdata-sections
+
+int foo() { return 42; }
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4757,54 +4757,92 @@
 // Render target options.
 TC.addClangTargetOptions(Args, CmdArgs, JA.getOffloadingDeviceKind());
 
-// reject options that shouldn't be supported in bitcode
-// also reject kernel/kext
-static const constexpr unsigned kBitcodeOptionIgnorelist[] = {
-options::OPT_mkernel,
-options::OPT_fapple_kext,
-options::OPT_ffunction_sections,
-options::OPT_fno_function_sections,
-options::OPT_fdata_sections,
-options::OPT_fno_data_sections,
-options::OPT_fbasic_block_sections_EQ,
-options::OPT_funique_internal_linkage_names,
-options::OPT_fno_unique_internal_linkage_names,
-options::OPT_funique_section_names,
-options::OPT_fno_unique_section_names,
-options::OPT_funique_basic_block_section_names,
-options::OPT_fno_unique_basic_block_section_names,
-options::OPT_mrestrict_it,
-options::OPT_mno_restrict_it,
-options::OPT_mstackrealign,
-options::OPT_mno_stackrealign,
-options::OPT_mstack_alignment,
-options::OPT_mcmodel_EQ,
-options::OPT_mlong_calls,
-options::OPT_mno_long_calls,
-options::OPT_ggnu_pubnames,
-options::OPT_gdwarf_aranges,
-options::OPT_fdebug_types_section,
-options::OPT_fno_debug_types_section,
-options::OPT_fdwarf_directory_asm,
-options::OPT_fno_dwarf_directory_asm,
-options::OPT_mrelax_all,
-options::OPT_mno_relax_all,
-options::OPT_ftrap_function_EQ,
-options::OPT_ffixed_r9,
-options::OPT_mfix_cortex_a53_835769,
-options::OPT_mno_fix_cortex_a53_835769,
-options::OPT_ffixed_x18,
-options::OPT_mglobal_merge,
-options::OPT_mno_global_merge,
-options::OPT_mred_zone,
-options::OPT_mno_red_zone,
-options::OPT_Wa_COMMA,
-options::OPT_Xassembler,
-options::OPT_mllvm,
-};
-for (const auto  : Args)
-  if (llvm::is_contained(kBitcodeOptionIgnorelist, A->getOption().getID()))
-D.Diag(diag::err_drv_unsupported_embed_bitcode) << A->getSpelling();
+if (RawTriple.isOSDarwin())
+  for (const auto  : Args) {
+// For Apple platforms, the following options are disallowed to limit
+// the ability to change the backend behaviour and ABI. This is to
+// ensure the bitcode can be retargeted to certain architectures.
+static const constexpr unsigned kBitcodeOptionIgnorelist[] = {
+options::OPT_mkernel,
+options::OPT_fapple_kext,
+options::OPT_ffunction_sections,
+options::OPT_fno_function_sections,
+options::OPT_fdata_sections,
+options::OPT_fno_data_sections,
+options::OPT_fbasic_block_sections_EQ,
+options::OPT_funique_internal_linkage_names,
+options::OPT_fno_unique_internal_linkage_names,
+options::OPT_funique_section_names,
+options::OPT_fno_unique_section_names,
+options::OPT_funique_basic_block_section_names,
+options::OPT_fno_unique_basic_block_section_names,
+options::OPT_mrestrict_it,
+options::OPT_mno_restrict_it,
+options::OPT_mstackrealign,
+options::OPT_mno_stackrealign,
+options::OPT_mstack_alignment,
+options::OPT_mcmodel_EQ,
+options::OPT_mlong_calls,
+options::OPT_mno_long_calls,
+options::OPT_ggnu_pubnames,
+options::OPT_gdwarf_aranges,
+options::OPT_fdebug_types_section,
+  

[PATCH] D126031: [libclang] add supporting for indexing/visiting C++ concepts

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added a comment.

@Jake-Egan 
Do you happen to have suggestions for how to try to reproduce this? Looking at 
the failure it looks like this CI job somehow was unable to be affected by this 
change, for instance the CI output of `index-concept-kind.cpp` does not have 
any concepts output:

  + : 'RUN: at line 1'
  + 
/scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/build/bin/c-index-test
 -index-file 
/scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/llvm-project/clang/test/Index/index-concept-kind.cpp
 -std=gnu++20
  + 
/scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/build/bin/FileCheck 
/scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/llvm-project/clang/test/Index/index-concept-kind.cpp
  
/scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/llvm-project/clang/test/Index/index-concept-kind.cpp:5:11:
 error: CHECK: expected string not found in input
  // CHECK: [indexDeclaration]: kind: concept | name: LargeType | USR: 
c:@CT@LargeType | lang: C | cursor: ConceptDecl=LargeType:[[@LINE-1]]:9 
(Definition) | loc: [[@LINE-1]]:9 | semantic-container: [TU] | 
lexical-container: [TU] | isRedecl: 0 | isDef: 1 | isContainer: 0 | isImplicit: 0
^
  :1:1: note: scanning from here
  [startedTranslationUnit]
  ^
  :1:1: note: with "@LINE-1" equal to "4"
  [startedTranslationUnit]
  ^
  :1:1: note: with "@LINE-1" equal to "4"
  [startedTranslationUnit]
  ^
  Input file: 
  Check file: 
/scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/llvm-project/clang/test/Index/index-concept-kind.cpp
  -dump-input=help explains the following input dump.
  Input was:
  <<
 1: [startedTranslationUnit] 
  check:5'0 X error: no match found
  check:5'1   with "@LINE-1" equal to "4"
  check:5'2   with "@LINE-1" equal to "4"
 2: [enteredMainFile]: 
/scratch/powerllvm/powerllvm_env/aix-ppc64/clang-ppc64-aix/llvm-project/clang/test/Index/index-concept-kind.cpp
 
  check:5'0 
~~~
 3: [indexDeclaration]: kind: function-template | name: f | USR: 
c:@FT@>1#Tf#v# | lang: C++ | cursor: FunctionDecl=f:9:6 | loc: 9:6 | 
semantic-container: [TU] | lexical-container: [TU] | isRedecl: 0 | isDef: 0 | 
isContainer: 0 | isImplicit: 0 
  check:5'0 
~~~
  >>

So far I was unable to reproduce this locally, and all the other CI jobs seem 
to pass.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126031

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

[PATCH] D126316: [clang][dataflow] Make limit on fixpoint-algorithm iterations proportional to size of CFG.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added a comment.

In D126316#3535057 , @tschuett wrote:

> or `min(MaxAverageVisitsPerBlock * BlockStates.size(), 2^16);`

Good idea, thx.

In D126316#3535077 , @xazax.hun wrote:

> An alternative approach is to maintain separate counters for back edges and 
> bail if those reach a certain limit. But this global limit is way simpler, so 
> it looks good to me.

Agreed -- this seems a better approach. Added as a FIXME. We should revisit...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126316

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

[PATCH] D126316: [clang][dataflow] Make limit on fixpoint-algorithm iterations proportional to size of CFG.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel updated this revision to Diff 431761.
ymandel added a comment.

Reinstated absolute limit of 2^16.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126316

Files:
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp


Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -11,6 +11,7 @@
 //
 
//===--===//
 
+#include 
 #include 
 #include 
 #include 
@@ -330,10 +331,17 @@
   // converging. To limit the damage (infinite loops) that these bugs can 
cause,
   // limit the number of iterations.
   // FIXME: Consider making the maximum number of iterations configurable.
+  // FIXME: Consider restricting the number of backedges followed, rather than
+  // iterations.
   // FIXME: Set up statistics (see llvm/ADT/Statistic.h) to count average 
number
   // of iterations, number of functions that time out, etc.
+  static constexpr uint32_t MaxAverageVisitsPerBlock = 4;
+  static constexpr uint32_t AbsoluteMaxIterations = 1 << 16;
+  const uint32_t RelativeMaxIterations =
+  MaxAverageVisitsPerBlock * BlockStates.size();
+  const uint32_t MaxIterations =
+  std::min(RelativeMaxIterations, AbsoluteMaxIterations);
   uint32_t Iterations = 0;
-  static constexpr uint32_t MaxIterations = 1 << 16;
   while (const CFGBlock *Block = Worklist.dequeue()) {
 if (++Iterations > MaxIterations) {
   return llvm::createStringError(std::errc::timed_out,


Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -11,6 +11,7 @@
 //
 //===--===//
 
+#include 
 #include 
 #include 
 #include 
@@ -330,10 +331,17 @@
   // converging. To limit the damage (infinite loops) that these bugs can cause,
   // limit the number of iterations.
   // FIXME: Consider making the maximum number of iterations configurable.
+  // FIXME: Consider restricting the number of backedges followed, rather than
+  // iterations.
   // FIXME: Set up statistics (see llvm/ADT/Statistic.h) to count average number
   // of iterations, number of functions that time out, etc.
+  static constexpr uint32_t MaxAverageVisitsPerBlock = 4;
+  static constexpr uint32_t AbsoluteMaxIterations = 1 << 16;
+  const uint32_t RelativeMaxIterations =
+  MaxAverageVisitsPerBlock * BlockStates.size();
+  const uint32_t MaxIterations =
+  std::min(RelativeMaxIterations, AbsoluteMaxIterations);
   uint32_t Iterations = 0;
-  static constexpr uint32_t MaxIterations = 1 << 16;
   while (const CFGBlock *Block = Worklist.dequeue()) {
 if (++Iterations > MaxIterations) {
   return llvm::createStringError(std::errc::timed_out,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126031: [libclang] add supporting for indexing/visiting C++ concepts

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added a comment.

Sure, investigating.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126031

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

[PATCH] D126316: [clang][dataflow] Make limit on fixpoint-algorithm iterations proportional to size of CFG.

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added a comment.

An alternative approach is to maintain separate counters for back edges and 
bail if those reach a certain limit. But this global limit is way simpler, so 
it looks good to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126316

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

[PATCH] D126316: [clang][dataflow] Make limit on fixpoint-algorithm iterations proportional to size of CFG.

[Thorsten via Phabricator via cfe-commits]

tschuett added a comment.

or `min(MaxAverageVisitsPerBlock * BlockStates.size(), 2^16);`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126316

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

[PATCH] D126031: [libclang] add supporting for indexing/visiting C++ concepts

[Jake Egan via Phabricator via cfe-commits]

Jake-Egan added a comment.

Hi, these tests fail on AIX, could you take a look please?

https://lab.llvm.org/buildbot/#/builders/214/builds/1489


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126031

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

[PATCH] D126316: [clang][dataflow] Make limit on fixpoint-algorithm iterations proportional to size of CFG.

[Dmitri Gribenko via Phabricator via cfe-commits]

gribozavr2 added inline comments.



Comment at: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp:336
+  static constexpr uint32_t MaxAverageVisitsPerBlock = 4;
+  const uint32_t MaxIterations = MaxAverageVisitsPerBlock * BlockStates.size();
   uint32_t Iterations = 0;

Could you cap the computed number at 1<<16 still?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126316

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

[PATCH] D126316: [clang][dataflow] Make limit on fixpoint-algorithm iterations proportional to size of CFG.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel created this revision.
ymandel added reviewers: xazax.hun, li.zhe.hua, sgatev.
Herald added subscribers: tschuett, steakhal, rnkovacs.
Herald added a project: All.
ymandel requested review of this revision.
Herald added a project: clang.

Currently, the maximum number of iterations of the loop for finding the fixpoint
of the dataflow analysis is set at 2^16. When things go wrong in an analysis,
this can be far too large.  This patch changes the limit to be proportional to
the size of the CFG, which will generally be far smaller than 2^16.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126316

Files:
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp


Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -332,8 +332,9 @@
   // FIXME: Consider making the maximum number of iterations configurable.
   // FIXME: Set up statistics (see llvm/ADT/Statistic.h) to count average 
number
   // of iterations, number of functions that time out, etc.
+  static constexpr uint32_t MaxAverageVisitsPerBlock = 4;
+  const uint32_t MaxIterations = MaxAverageVisitsPerBlock * BlockStates.size();
   uint32_t Iterations = 0;
-  static constexpr uint32_t MaxIterations = 1 << 16;
   while (const CFGBlock *Block = Worklist.dequeue()) {
 if (++Iterations > MaxIterations) {
   return llvm::createStringError(std::errc::timed_out,


Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -332,8 +332,9 @@
   // FIXME: Consider making the maximum number of iterations configurable.
   // FIXME: Set up statistics (see llvm/ADT/Statistic.h) to count average number
   // of iterations, number of functions that time out, etc.
+  static constexpr uint32_t MaxAverageVisitsPerBlock = 4;
+  const uint32_t MaxIterations = MaxAverageVisitsPerBlock * BlockStates.size();
   uint32_t Iterations = 0;
-  static constexpr uint32_t MaxIterations = 1 << 16;
   while (const CFGBlock *Block = Worklist.dequeue()) {
 if (++Iterations > MaxIterations) {
   return llvm::createStringError(std::errc::timed_out,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D125667: [pseudo] A basic implementation of compiling cxx grammar at build time.

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/pseudo/lib/cxx/CXX.cpp:17
+static const char *CxxBNF =
+#include "CXXBNF.inc"
+;

sammccall wrote:
> this is worth a try, but I think (some versions of?) MSVC don't like long 
> string literals.
> 
> Stackoverflow says 2k per "chunk" ("one" "two" "three") and 64k total.
> Integer arrays can be larger...
> 
> So let's start with simple readable options, and make them progressively 
> uglier if we hit limits.
ah, good point. And you're right -- the previous version raw string literal 
doesn't compile with MSVC v19 `(397): error C2026: string too big, 
trailing characters truncated`. Changing to string chunks seems to work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125667

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

[PATCH] D125667: [pseudo] A basic implementation of compiling cxx grammar at build time.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 431746.
hokein marked 3 inline comments as done.
hokein added a comment.

rebase, and emit string chunks rather than a long raw string literal (to make 
msvc happy)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125667

Files:
  clang-tools-extra/pseudo/CMakeLists.txt
  clang-tools-extra/pseudo/gen/CMakeLists.txt
  clang-tools-extra/pseudo/gen/Main.cpp
  clang-tools-extra/pseudo/include/CMakeLists.txt
  clang-tools-extra/pseudo/include/clang-pseudo/cxx/CXX.h
  clang-tools-extra/pseudo/lib/CMakeLists.txt
  clang-tools-extra/pseudo/lib/Grammar.cpp
  clang-tools-extra/pseudo/lib/GrammarBNF.cpp
  clang-tools-extra/pseudo/lib/LRGraph.cpp
  clang-tools-extra/pseudo/lib/LRTable.cpp
  clang-tools-extra/pseudo/lib/LRTableBuild.cpp
  clang-tools-extra/pseudo/lib/cxx/CMakeLists.txt
  clang-tools-extra/pseudo/lib/cxx/CXX.cpp
  clang-tools-extra/pseudo/lib/grammar/CMakeLists.txt
  clang-tools-extra/pseudo/lib/grammar/Grammar.cpp
  clang-tools-extra/pseudo/lib/grammar/GrammarBNF.cpp
  clang-tools-extra/pseudo/lib/grammar/LRGraph.cpp
  clang-tools-extra/pseudo/lib/grammar/LRTable.cpp
  clang-tools-extra/pseudo/lib/grammar/LRTableBuild.cpp

Index: clang-tools-extra/pseudo/lib/LRTableBuild.cpp
===
--- /dev/null
+++ clang-tools-extra/pseudo/lib/LRTableBuild.cpp
@@ -1,146 +0,0 @@
-//===--- LRTableBuild.cpp - Build a LRTable from LRGraph -*- C++-*-===//
-//
-// 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-pseudo/Grammar.h"
-#include "clang-pseudo/LRGraph.h"
-#include "clang-pseudo/LRTable.h"
-#include "clang/Basic/TokenKinds.h"
-#include 
-
-namespace llvm {
-template <> struct DenseMapInfo {
-  using Entry = clang::pseudo::LRTable::Entry;
-  static inline Entry getEmptyKey() {
-static Entry E{static_cast(-1), 0,
-   clang::pseudo::LRTable::Action::sentinel()};
-return E;
-  }
-  static inline Entry getTombstoneKey() {
-static Entry E{static_cast(-2), 0,
-   clang::pseudo::LRTable::Action::sentinel()};
-return E;
-  }
-  static unsigned getHashValue(const Entry ) {
-return llvm::hash_combine(I.State, I.Symbol, I.Act.opaque());
-  }
-  static bool isEqual(const Entry , const Entry ) {
-return LHS.State == RHS.State && LHS.Symbol == RHS.Symbol &&
-   LHS.Act == RHS.Act;
-  }
-};
-} // namespace llvm
-
-namespace clang {
-namespace pseudo {
-
-class LRTable::Builder {
-public:
-  Builder(llvm::ArrayRef> StartStates)
-  : StartStates(StartStates) {}
-
-  bool insert(Entry E) { return Entries.insert(std::move(E)).second; }
-  LRTable build(const GrammarTable ) && {
-// E.g. given the following parsing table with 3 states and 3 terminals:
-//
-//ab c
-// +---++---+-+
-// |state0 || s0,r0 | |
-// |state1 | acc|   | |
-// |state2 ||  r1   | |
-// +---++---+-+
-//
-// The final LRTable:
-//  - TerminalOffset: [a] = 0, [b] = 1, [c] = 4, [d] = 4 (d is a sentinel)
-//  -  States: [ 1,0,  0,  2]
-//Actions: [ acc, s0, r0, r1]
-//   ~~~ corresponding range for terminal a
-//~~ corresponding range for terminal b
-// First step, we sort all entries by (Symbol, State, Action).
-std::vector Sorted(Entries.begin(), Entries.end());
-llvm::sort(Sorted, [](const Entry , const Entry ) {
-  return std::forward_as_tuple(L.Symbol, L.State, L.Act.opaque()) <
- std::forward_as_tuple(R.Symbol, R.State, R.Act.opaque());
-});
-
-LRTable Table;
-Table.Actions.reserve(Sorted.size());
-Table.States.reserve(Sorted.size());
-// We are good to finalize the States and Actions.
-for (const auto  : Sorted) {
-  Table.Actions.push_back(E.Act);
-  Table.States.push_back(E.State);
-}
-// Initialize the terminal and nonterminal offset, all ranges are empty by
-// default.
-Table.TerminalOffset = std::vector(GT.Terminals.size() + 1, 0);
-Table.NontermOffset = std::vector(GT.Nonterminals.size() + 1, 0);
-size_t SortedIndex = 0;
-for (SymbolID NonterminalID = 0; NonterminalID < Table.NontermOffset.size();
- ++NonterminalID) {
-  Table.NontermOffset[NonterminalID] = SortedIndex;
-  while (SortedIndex < Sorted.size() &&
- Sorted[SortedIndex].Symbol == NonterminalID)
-++SortedIndex;
-}
-for (size_t Terminal = 0; Terminal < Table.TerminalOffset.size();
- ++Terminal) {
-  Table.TerminalOffset[Terminal] = SortedIndex;
-  while (SortedIndex < 

[PATCH] D125622: [clang-tidy] Reject invalid enum initializers in C files

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.c:10
+// C forbids comma operator in initializing expressions.
+#define BAD_OP 1, 2
+

LegalizeAdulthood wrote:
> aaron.ballman wrote:
> > Can you add a test:
> > ```
> > #define GOOD_OP (1, 2)
> > ```
> > to make sure it still gets converted to an enum?
> Yeah, another one I was thinking of is when someone does [[ 
> https://godbolt.org/z/c677je8s1 | something as disgusting as this. ]]
> 
> ```
> #define ARGS 1, 2
> #define OTHER_ARGS (1, 2)
> 
> int f(int x, int y) { return x + y; }
> 
> int main()
> {
> return f(ARGS) + f OTHER_ARGS;
> }
> ```
> 
> However, the only real way to handle avoiding conversion of the 2nd case is 
> to examine the context of macro expansion.  This is another edge case that 
> will have to be handled subsequently.
> 
> This gets tricky because AFAIK there is no way to select expressions in the 
> AST that result from macro expansion.  You have to match the macro expansion 
> locations against AST nodes to identify the node(s) that match the expansion 
> location yourself.
That's a good test case (for some definition of good)! :-)

At this point, there's a few options:

1) Go back to the way things were -- disallow comma expressions, even in 
parens. Document it as a limitation.
2) Accept comma expressions in parens, ignore the problem case like you 
described above. Document it as a limitation?
3) Try to solve every awful code construct we can ever imagine. Document the 
check is perfect in every way, but probably not land it for several years.

I think I'd be happy with #2 but I could also live with #1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125622

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

[PATCH] D126314: [clang][dataflow] Relax `Environment` comparison operation.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel created this revision.
ymandel added reviewers: xazax.hun, sgatev, li.zhe.hua.
Herald added subscribers: tschuett, steakhal, rnkovacs.
Herald added a project: All.
ymandel requested review of this revision.
Herald added a project: clang.

Ignore `MemberLocToStruct` in environment comparison. As an ancillary data
structure, including it is redundant. We also can generate environments which
differ in their `MemberLocToStruct` but are otherwise equivalent.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126314

Files:
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp


Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -3120,4 +3120,59 @@
   });
 }
 
+TEST_F(TransferTest, LoopWithStructReferenceAssignmentConverges) {
+  std::string Code = R"(
+struct Lookup {
+  int x;
+};
+
+void target(Lookup val, bool b) {
+  const Lookup* l = nullptr;
+  while (b) {
+l = 
+/*[[p-inner]]*/
+  }
+  (void)0;
+  /*[[p-outer]]*/
+}
+  )";
+  // The key property that we are verifying is implicit in `runDataflow` --
+  // namely, that the analysis succeeds, rather than hitting the maximum number
+  // of iterations.
+  runDataflow(
+  Code, [](llvm::ArrayRef<
+   std::pair>>
+   Results,
+   ASTContext ) {
+ASSERT_THAT(Results,
+ElementsAre(Pair("p-outer", _), Pair("p-inner", _)));
+const Environment  = Results[0].second.Env;
+const Environment  = Results[1].second.Env;
+
+const ValueDecl *ValDecl = findValueDecl(ASTCtx, "val");
+ASSERT_THAT(ValDecl, NotNull());
+
+const ValueDecl *LDecl = findValueDecl(ASTCtx, "l");
+ASSERT_THAT(LDecl, NotNull());
+
+// Inner.
+auto *LVal = dyn_cast(
+InnerEnv.getValue(*LDecl, SkipPast::None));
+ASSERT_THAT(LVal, NotNull());
+
+EXPECT_EQ(>getPointeeLoc(),
+  InnerEnv.getStorageLocation(*ValDecl, SkipPast::Reference));
+
+// Outer.
+LVal = dyn_cast(
+OuterEnv.getValue(*LDecl, SkipPast::None));
+ASSERT_THAT(LVal, NotNull());
+
+// The loop body may not have been executed, so we should not conclude
+// that `l` points to `val`.
+EXPECT_NE(>getPointeeLoc(),
+  OuterEnv.getStorageLocation(*ValDecl, SkipPast::Reference));
+});
+}
+
 } // namespace
Index: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
===
--- clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -239,9 +239,6 @@
   if (ExprToLoc != Other.ExprToLoc)
 return false;
 
-  if (MemberLocToStruct != Other.MemberLocToStruct)
-return false;
-
   // Compare the contents for the intersection of their domains.
   for (auto  : LocToVal) {
 const StorageLocation *Loc = Entry.first;


Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -3120,4 +3120,59 @@
   });
 }
 
+TEST_F(TransferTest, LoopWithStructReferenceAssignmentConverges) {
+  std::string Code = R"(
+struct Lookup {
+  int x;
+};
+
+void target(Lookup val, bool b) {
+  const Lookup* l = nullptr;
+  while (b) {
+l = 
+/*[[p-inner]]*/
+  }
+  (void)0;
+  /*[[p-outer]]*/
+}
+  )";
+  // The key property that we are verifying is implicit in `runDataflow` --
+  // namely, that the analysis succeeds, rather than hitting the maximum number
+  // of iterations.
+  runDataflow(
+  Code, [](llvm::ArrayRef<
+   std::pair>>
+   Results,
+   ASTContext ) {
+ASSERT_THAT(Results,
+ElementsAre(Pair("p-outer", _), Pair("p-inner", _)));
+const Environment  = Results[0].second.Env;
+const Environment  = Results[1].second.Env;
+
+const ValueDecl *ValDecl = findValueDecl(ASTCtx, "val");
+ASSERT_THAT(ValDecl, NotNull());
+
+const ValueDecl *LDecl = findValueDecl(ASTCtx, "l");
+ASSERT_THAT(LDecl, NotNull());
+
+// Inner.
+auto *LVal = dyn_cast(
+InnerEnv.getValue(*LDecl, SkipPast::None));
+ASSERT_THAT(LVal, NotNull());
+
+EXPECT_EQ(>getPointeeLoc(),
+  InnerEnv.getStorageLocation(*ValDecl, SkipPast::Reference));
+
+// Outer.
+LVal = dyn_cast(
+OuterEnv.getValue(*LDecl, SkipPast::None));
+

[PATCH] D126308: cmake: use llvm dir variables for clang/utils/hmaptool

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov created this revision.
Herald added a subscriber: mgorny.
Herald added a project: All.
mizvekov published this revision for review.
mizvekov added reviewers: bruno, mgorny, Ericson2314, sgraenitz, 
stephenneuendorffer.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Install hmaptool using the LLVM specific variables, so
everything goes in the right place in case llvm is included
from a top level CMakeLists.txt.

Signed-off-by: Matheus Izvekov 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126308

Files:
  clang/utils/hmaptool/CMakeLists.txt


Index: clang/utils/hmaptool/CMakeLists.txt
===
--- clang/utils/hmaptool/CMakeLists.txt
+++ clang/utils/hmaptool/CMakeLists.txt
@@ -1,19 +1,9 @@
-set(CLANG_HMAPTOOL hmaptool)
+add_custom_command(OUTPUT "${LLVM_TOOLS_BINARY_DIR}/hmaptool"
+   COMMAND "${CMAKE_COMMAND}" -E copy 
"${CMAKE_CURRENT_SOURCE_DIR}/hmaptool" "${LLVM_TOOLS_BINARY_DIR}"
+   DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/hmaptool")
 
-add_custom_command(OUTPUT 
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/${CLANG_HMAPTOOL}
-   COMMAND ${CMAKE_COMMAND} -E make_directory
- ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin
-   COMMAND ${CMAKE_COMMAND} -E copy
- ${CMAKE_CURRENT_SOURCE_DIR}/${CLANG_HMAPTOOL}
- ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/
-   DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${CLANG_HMAPTOOL})
-
-list(APPEND Depends 
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/${CLANG_HMAPTOOL})
-install(PROGRAMS ${CLANG_HMAPTOOL}
-DESTINATION "${CMAKE_INSTALL_BINDIR}"
-COMPONENT hmaptool)
-
-add_custom_target(hmaptool ALL DEPENDS ${Depends})
+install(PROGRAMS hmaptool DESTINATION "${LLVM_UTILS_INSTALL_DIR}}" COMPONENT 
hmaptool)
+add_custom_target(hmaptool ALL DEPENDS "${LLVM_TOOLS_BINARY_DIR}/hmaptool")
 set_target_properties(hmaptool PROPERTIES FOLDER "Utils")
 
 if(NOT LLVM_ENABLE_IDE)


Index: clang/utils/hmaptool/CMakeLists.txt
===
--- clang/utils/hmaptool/CMakeLists.txt
+++ clang/utils/hmaptool/CMakeLists.txt
@@ -1,19 +1,9 @@
-set(CLANG_HMAPTOOL hmaptool)
+add_custom_command(OUTPUT "${LLVM_TOOLS_BINARY_DIR}/hmaptool"
+   COMMAND "${CMAKE_COMMAND}" -E copy "${CMAKE_CURRENT_SOURCE_DIR}/hmaptool" "${LLVM_TOOLS_BINARY_DIR}"
+   DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/hmaptool")
 
-add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/${CLANG_HMAPTOOL}
-   COMMAND ${CMAKE_COMMAND} -E make_directory
- ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin
-   COMMAND ${CMAKE_COMMAND} -E copy
- ${CMAKE_CURRENT_SOURCE_DIR}/${CLANG_HMAPTOOL}
- ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/
-   DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${CLANG_HMAPTOOL})
-
-list(APPEND Depends ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/${CLANG_HMAPTOOL})
-install(PROGRAMS ${CLANG_HMAPTOOL}
-DESTINATION "${CMAKE_INSTALL_BINDIR}"
-COMPONENT hmaptool)
-
-add_custom_target(hmaptool ALL DEPENDS ${Depends})
+install(PROGRAMS hmaptool DESTINATION "${LLVM_UTILS_INSTALL_DIR}}" COMPONENT hmaptool)
+add_custom_target(hmaptool ALL DEPENDS "${LLVM_TOOLS_BINARY_DIR}/hmaptool")
 set_target_properties(hmaptool PROPERTIES FOLDER "Utils")
 
 if(NOT LLVM_ENABLE_IDE)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D125904: [Cuda] Use fallback method to mangle externalized decls if no CUID given

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:6836
+
+  // If the CUID is not specified we try to generate a unique postfix.
+  if (getLangOpts().CUID.empty()) {

tra wrote:
> > However, [CUID] is not always availible. 
> 
> The question is -- when and why is it not available? I'm getting the feeling 
> that we're fixing the consequence here, not the root cause.
> 
> Is there a reason we can't make sure that the driver always generates a cuid 
> for offload subcompilations and error out if it's needed but is not provided?
> That would make this fallback unnecessary and would be a more robust approach 
> in general.
> 
So, I'm more in favor of this approach because it doesn't require extra 
intervention from the compiler driver, this makes it less convoluted to do 
split compilation since we don't have an extra arguments. The way I would 
prefer it, is that we do this implicitly by default without requiring extra 
thought from the driver, but if it's not good enough we can support the manual 
`CUID` approach to let the user override it. I think this is a cleaner 
implementation, and is mostly coming from my support for CUDA in the new driver 
which currently doesn't implement the CUID as we do with the old driver. 
Generally I'd prefer things to behave independent of the driver, so we can 
consider host and device compilation more separately.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125904

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

[PATCH] D126061: [clang] [WIP] Reject non-declaration C++11 attributes on declarations

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

rsmith added inline comments.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:9118
+  ProcessDeclAttributeOptions Options;
+  Options.IncludeCXX11Attributes = AL.isCXX11Attribute();
+  ProcessDeclAttribute(*this, nullptr, ASDecl, AL, Options);

aaron.ballman wrote:
> rsmith wrote:
> > This seems to be equivalent to setting `IncludeCXX11Attributes` to `true`, 
> > which seems to be equivalent to not setting it at all.
> Hmmm, not quite -- `AL.isCXX11Attribute()` may return `false` (like for the 
> GNU spelling of this attribute).
It might, but we only care about the value of `IncludeCXX11Attributes` when 
processing a C++11 attribute, so it doesn't matter how this flag is set for a 
non-C++11 attribute.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126061

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

[PATCH] D126183: Implement soft reset of the diagnostics engine.

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

rsmith added a comment.

I don't think we can live with the `#define private public` approach, not least 
because this violates the ODR and might lead to compile failures using modules 
as a result. As an alternative, how about:

- Adding a `friend void DiagnosticTestHelper();` declaration to 
`DiagnosicsEngine`
- Defining that function in `DiagnosticTest.cpp` and calling it to do your 
checks of the diagnostics engine's state.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126183

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

[PATCH] D125904: [Cuda] Use fallback method to mangle externalized decls if no CUID given

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:6836
+
+  // If the CUID is not specified we try to generate a unique postfix.
+  if (getLangOpts().CUID.empty()) {

> However, [CUID] is not always availible. 

The question is -- when and why is it not available? I'm getting the feeling 
that we're fixing the consequence here, not the root cause.

Is there a reason we can't make sure that the driver always generates a cuid 
for offload subcompilations and error out if it's needed but is not provided?
That would make this fallback unnecessary and would be a more robust approach 
in general.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125904

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

[PATCH] D126093: Sema: adjust assertion to account for deduced types

[Saleem Abdulrasool via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
compnerd marked an inline comment as done.
Closed by commit rGb159108bc5eb: Sema: adjust assertion to account for deduced 
types (authored by compnerd).

Changed prior to commit:
  https://reviews.llvm.org/D126093?vs=431084=431720#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126093

Files:
  clang/include/clang/Sema/DeclSpec.h
  clang/test/Sema/typerep-typespec.c


Index: clang/test/Sema/typerep-typespec.c
===
--- /dev/null
+++ clang/test/Sema/typerep-typespec.c
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -std=c11 %s -fsyntax-only -verify
+// REQUIRES: asserts
+
+struct dispatch_object_s;
+void _dispatch_queue_get_head(struct dispatch_object_s *volatile 
dq_items_head) {
+  (_Atomic __typeof__(dq_items_head) *)0; // expected-warning{{expression 
result unused}}
+}
+void g(void) {
+  (_Atomic __typeof__(struct dispatch_object_s *volatile) *)0; // 
expected-warning{{expression result unused}}
+}
Index: clang/include/clang/Sema/DeclSpec.h
===
--- clang/include/clang/Sema/DeclSpec.h
+++ clang/include/clang/Sema/DeclSpec.h
@@ -516,7 +516,8 @@
   SourceLocation getTypeSpecSatLoc() const { return TSSatLoc; }
 
   SourceLocation getTypeSpecTypeNameLoc() const {
-assert(isDeclRep((TST) TypeSpecType) || TypeSpecType == TST_typename);
+assert(isDeclRep((TST)TypeSpecType) || isTypeRep((TST)TypeSpecType) ||
+   isExprRep((TST)TypeSpecType));
 return TSTNameLoc;
   }
 


Index: clang/test/Sema/typerep-typespec.c
===
--- /dev/null
+++ clang/test/Sema/typerep-typespec.c
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -std=c11 %s -fsyntax-only -verify
+// REQUIRES: asserts
+
+struct dispatch_object_s;
+void _dispatch_queue_get_head(struct dispatch_object_s *volatile dq_items_head) {
+  (_Atomic __typeof__(dq_items_head) *)0; // expected-warning{{expression result unused}}
+}
+void g(void) {
+  (_Atomic __typeof__(struct dispatch_object_s *volatile) *)0; // expected-warning{{expression result unused}}
+}
Index: clang/include/clang/Sema/DeclSpec.h
===
--- clang/include/clang/Sema/DeclSpec.h
+++ clang/include/clang/Sema/DeclSpec.h
@@ -516,7 +516,8 @@
   SourceLocation getTypeSpecSatLoc() const { return TSSatLoc; }
 
   SourceLocation getTypeSpecTypeNameLoc() const {
-assert(isDeclRep((TST) TypeSpecType) || TypeSpecType == TST_typename);
+assert(isDeclRep((TST)TypeSpecType) || isTypeRep((TST)TypeSpecType) ||
+   isExprRep((TST)TypeSpecType));
 return TSTNameLoc;
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] b159108 - Sema: adjust assertion to account for deduced types

[Saleem Abdulrasool via cfe-commits]

Author: Saleem Abdulrasool
Date: 2022-05-24T17:49:44Z
New Revision: b159108bc5ebd7f37373896ece1da8f49612f7a6

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

LOG: Sema: adjust assertion to account for deduced types

Previous changes for the BTF attributes introduced a new sub-tree
visitation.  That uncovered that when accessing the typespec location we
would assert that the type specification is either a type declaration or
`typename`.  However, `typename` was explicitly permitted.  This change
predates the introduction of newer deduced type representations such as
`__underlying_type` from C++ and the addition of the GNU `__typeof__`
expression.

Thanks to aaron.ballman for the valuable discussion and pointer to
`isTypeRep`.

Differential Revision: https://reviews.llvm.org/D126093
Reviewed By: aaron.ballman, yonghong-song

Added: 
clang/test/Sema/typerep-typespec.c

Modified: 
clang/include/clang/Sema/DeclSpec.h

Removed: 




diff  --git a/clang/include/clang/Sema/DeclSpec.h 
b/clang/include/clang/Sema/DeclSpec.h
index 6a7fbe8282d85..c03ead9c79b34 100644
--- a/clang/include/clang/Sema/DeclSpec.h
+++ b/clang/include/clang/Sema/DeclSpec.h
@@ -516,7 +516,8 @@ class DeclSpec {
   SourceLocation getTypeSpecSatLoc() const { return TSSatLoc; }
 
   SourceLocation getTypeSpecTypeNameLoc() const {
-assert(isDeclRep((TST) TypeSpecType) || TypeSpecType == TST_typename);
+assert(isDeclRep((TST)TypeSpecType) || isTypeRep((TST)TypeSpecType) ||
+   isExprRep((TST)TypeSpecType));
 return TSTNameLoc;
   }
 

diff  --git a/clang/test/Sema/typerep-typespec.c 
b/clang/test/Sema/typerep-typespec.c
new file mode 100644
index 0..001131306a4a9
--- /dev/null
+++ b/clang/test/Sema/typerep-typespec.c
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -std=c11 %s -fsyntax-only -verify
+// REQUIRES: asserts
+
+struct dispatch_object_s;
+void _dispatch_queue_get_head(struct dispatch_object_s *volatile 
dq_items_head) {
+  (_Atomic __typeof__(dq_items_head) *)0; // expected-warning{{expression 
result unused}}
+}
+void g(void) {
+  (_Atomic __typeof__(struct dispatch_object_s *volatile) *)0; // 
expected-warning{{expression result unused}}
+}



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

[clang] 3723868 - [OpenMP] Fix file arguments for embedding bitcode in the linker wrapper

[Joseph Huber via cfe-commits]

Author: Joseph Huber
Date: 2022-05-24T13:45:52-04:00
New Revision: 3723868d9e07de5d4a7468a4c2c74fc8517afc14

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

LOG: [OpenMP] Fix file arguments for embedding bitcode in the linker wrapper

Summary:
The linker wrapper supports embedding bitcode images instead of linked
device images to facilitate JIT in the device runtime. However, we were
incorrectly passing in the file twice when this option was set. This
patch makes sure we only use the intermediate result of the LTO pass and
don't add the final output to the full job.

In the future we will want to add both of these andle handle that
accoridngly to allow the runtime to either use the AoT compiled version
or JIT compile the bitcode version if availible.

Added: 


Modified: 
clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp

Removed: 




diff  --git a/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp 
b/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
index a06409fdab610..74c03a26b884f 100644
--- a/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ b/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -1012,8 +1012,14 @@ Error linkBitcodeFiles(SmallVectorImpl 
,
   if (Error Err = LTOBackend->run(AddStream))
 return Err;
 
+  // If we are embedding bitcode we only need the intermediate output.
+  if (EmbedBitcode) {
+InputFiles = NewInputFiles;
+return Error::success();
+  }
+
   // Is we are compiling for NVPTX we need to run the assembler first.
-  if (TheTriple.isNVPTX() && !EmbedBitcode) {
+  if (TheTriple.isNVPTX()) {
 for (auto  : Files) {
   auto FileOrErr = nvptx::assemble(File, TheTriple, Arch, !WholeProgram);
   if (!FileOrErr)



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

[PATCH] D125828: [OpenMP] Add parsing/sema support for omp_all_memory reserved locator

[Mike Rice 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 rG9ba937112fa6: [OpenMP] Add parsing/sema support for 
omp_all_memory reserved locator (authored by mikerice).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125828

Files:
  clang/include/clang/AST/OpenMPClause.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/OpenMPKinds.def
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/OpenMPClause.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/OpenMP/task_ast_print.cpp
  clang/test/OpenMP/task_depend_messages.cpp

Index: clang/test/OpenMP/task_depend_messages.cpp
===
--- clang/test/OpenMP/task_depend_messages.cpp
+++ clang/test/OpenMP/task_depend_messages.cpp
@@ -1,10 +1,10 @@
 // RUN: %clang_cc1 -verify=expected,omp45 -fopenmp-version=45 -fopenmp -ferror-limit 100 -o - -std=c++11 %s -Wuninitialized
 // RUN: %clang_cc1 -verify=expected,omp50 -fopenmp-version=50 -fopenmp -ferror-limit 100 -o - -std=c++11 %s -Wuninitialized
-// RUN: %clang_cc1 -verify=expected,omp51 -fopenmp-version=51 -fopenmp -ferror-limit 100 -o - -std=c++11 %s -Wuninitialized
+// RUN: %clang_cc1 -verify=expected,omp51,omp51warn -fopenmp-version=51 -fopenmp -ferror-limit 100 -o - -std=c++11 %s -Wuninitialized
 
 // RUN: %clang_cc1 -verify=expected,omp45 -fopenmp-version=45 -fopenmp-simd -ferror-limit 100 -o - -std=c++11 %s -Wuninitialized
 // RUN: %clang_cc1 -verify=expected,omp50 -fopenmp-version=50 -fopenmp-simd -ferror-limit 100 -o - -std=c++11 %s -Wuninitialized
-// RUN: %clang_cc1 -verify=expected,omp51 -fopenmp-version=51 -fopenmp-simd -ferror-limit 100 -o - -std=c++11 %s -Wuninitialized
+// RUN: %clang_cc1 -verify=expected,omp51,omp51warn -fopenmp-version=51 -fopenmp-simd -ferror-limit 100 -o - -std=c++11 %s -Wuninitialized
 
 typedef void *omp_depend_t;
 
@@ -85,6 +85,10 @@
   argc = 0;
 #pragma omp task depend(iterator(i = 0:10, i = 0:10), in : argv[i]) // omp45-error {{expected 'in', 'out', 'inout' or 'mutexinoutset' in OpenMP clause 'depend'}} omp45-error {{use of undeclared identifier 'i'}} omp50-error {{redefinition of 'i'}} omp50-note {{previous definition is here}}  omp51-error {{redefinition of 'i'}} omp51-note {{previous definition is here}}
   i = 0; // expected-error {{use of undeclared identifier 'i'}}
-
+#pragma omp task depend(in: argc, omp_all_memory) // omp45-error {{use of undeclared identifier 'omp_all_memory'}} omp50-error {{use of undeclared identifier 'omp_all_memory'}} omp51-error {{reserved locator 'omp_all_memory' requires 'out' or 'inout' dependency types}}
+#pragma omp task depend(out: omp_all_memory, argc, omp_all_memory) // omp45-error {{use of undeclared identifier 'omp_all_memory'}} omp45-error {{use of undeclared identifier 'omp_all_memory'}} omp50-error {{use of undeclared identifier 'omp_all_memory'}} omp50-error {{use of undeclared identifier 'omp_all_memory'}} omp51warn-warning {{reserved locator 'omp_all_memory' cannot be specified more than once}}
+  // expected-error@+1 {{use of undeclared identifier 'omp_all_memory'}}
+#pragma omp task depend(out: argc) private(argc) allocate(argc, omp_all_memory)
+  argc = 0;
   return 0;
 }
Index: clang/test/OpenMP/task_ast_print.cpp
===
--- clang/test/OpenMP/task_ast_print.cpp
+++ clang/test/OpenMP/task_ast_print.cpp
@@ -1,10 +1,10 @@
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=50 -ast-print %s | FileCheck %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -std=c++11 -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -std=c++11 -include-pch %t -fsyntax-only -verify %s -ast-print | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=51 -ast-print %s | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=51 -x c++ -std=c++11 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=51 -std=c++11 -include-pch %t -fsyntax-only -verify %s -ast-print | FileCheck %s
 
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-version=50 -ast-print %s | FileCheck %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -std=c++11 -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -std=c++11 -include-pch %t -fsyntax-only -verify %s -ast-print | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-version=51 -ast-print %s | FileCheck %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=51 -x c++ -std=c++11 -emit-pch -o %t %s
+// RUN: %clang_cc1 

[clang] 9ba9371 - [OpenMP] Add parsing/sema support for omp_all_memory reserved locator

[Mike Rice via cfe-commits]

Author: Mike Rice
Date: 2022-05-24T10:28:59-07:00
New Revision: 9ba937112fa6d4076e4a98b587a334786b6c0d9c

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

LOG: [OpenMP] Add parsing/sema support for omp_all_memory reserved locator

Adds support for the reserved locator 'omp_all_memory' for use
in depend clauses with 'out' or 'inout' dependence-types.

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

Added: 


Modified: 
clang/include/clang/AST/OpenMPClause.h
clang/include/clang/Basic/DiagnosticParseKinds.td
clang/include/clang/Basic/OpenMPKinds.def
clang/include/clang/Parse/Parser.h
clang/include/clang/Sema/Sema.h
clang/lib/AST/OpenMPClause.cpp
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/lib/Parse/ParseOpenMP.cpp
clang/lib/Sema/SemaOpenMP.cpp
clang/lib/Sema/TreeTransform.h
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/test/OpenMP/task_ast_print.cpp
clang/test/OpenMP/task_depend_messages.cpp

Removed: 




diff  --git a/clang/include/clang/AST/OpenMPClause.h 
b/clang/include/clang/AST/OpenMPClause.h
index 3103f61d4248d..a745df1143468 100644
--- a/clang/include/clang/AST/OpenMPClause.h
+++ b/clang/include/clang/AST/OpenMPClause.h
@@ -4746,14 +4746,24 @@ class OMPDependClause final
   friend OMPVarListClause;
   friend TrailingObjects;
 
-  /// Dependency type (one of in, out, inout).
-  OpenMPDependClauseKind DepKind = OMPC_DEPEND_unknown;
+public:
+  struct DependDataTy final {
+/// Dependency type (one of in, out, inout).
+OpenMPDependClauseKind DepKind = OMPC_DEPEND_unknown;
 
-  /// Dependency type location.
-  SourceLocation DepLoc;
+/// Dependency type location.
+SourceLocation DepLoc;
 
-  /// Colon location.
-  SourceLocation ColonLoc;
+/// Colon location.
+SourceLocation ColonLoc;
+
+/// Location of 'omp_all_memory'.
+SourceLocation OmpAllMemoryLoc;
+  };
+
+private:
+  /// Dependency type and source locations.
+  DependDataTy Data;
 
   /// Number of loops, associated with the depend clause.
   unsigned NumLoops = 0;
@@ -4784,13 +4794,16 @@ class OMPDependClause final
 NumLoops(NumLoops) {}
 
   /// Set dependency kind.
-  void setDependencyKind(OpenMPDependClauseKind K) { DepKind = K; }
+  void setDependencyKind(OpenMPDependClauseKind K) { Data.DepKind = K; }
 
   /// Set dependency kind and its location.
-  void setDependencyLoc(SourceLocation Loc) { DepLoc = Loc; }
+  void setDependencyLoc(SourceLocation Loc) { Data.DepLoc = Loc; }
 
   /// Set colon location.
-  void setColonLoc(SourceLocation Loc) { ColonLoc = Loc; }
+  void setColonLoc(SourceLocation Loc) { Data.ColonLoc = Loc; }
+
+  /// Set the 'omp_all_memory' location.
+  void setOmpAllMemoryLoc(SourceLocation Loc) { Data.OmpAllMemoryLoc = Loc; }
 
   /// Sets optional dependency modifier.
   void setModifier(Expr *DepModifier);
@@ -4802,18 +4815,15 @@ class OMPDependClause final
   /// \param StartLoc Starting location of the clause.
   /// \param LParenLoc Location of '('.
   /// \param EndLoc Ending location of the clause.
-  /// \param DepKind Dependency type.
-  /// \param DepLoc Location of the dependency type.
-  /// \param ColonLoc Colon location.
+  /// \param Data Dependency type and source locations.
   /// \param VL List of references to the variables.
   /// \param NumLoops Number of loops that is associated with this depend
   /// clause.
   static OMPDependClause *Create(const ASTContext , SourceLocation StartLoc,
  SourceLocation LParenLoc,
- SourceLocation EndLoc, Expr *DepModifier,
- OpenMPDependClauseKind DepKind,
- SourceLocation DepLoc, SourceLocation 
ColonLoc,
- ArrayRef VL, unsigned NumLoops);
+ SourceLocation EndLoc, DependDataTy Data,
+ Expr *DepModifier, ArrayRef VL,
+ unsigned NumLoops);
 
   /// Creates an empty clause with \a N variables.
   ///
@@ -4825,7 +4835,16 @@ class OMPDependClause final
   unsigned NumLoops);
 
   /// Get dependency type.
-  OpenMPDependClauseKind getDependencyKind() const { return DepKind; }
+  OpenMPDependClauseKind getDependencyKind() const { return Data.DepKind; }
+
+  /// Get dependency type location.
+  SourceLocation getDependencyLoc() const { return Data.DepLoc; }
+
+  /// Get colon location.
+  SourceLocation getColonLoc() const { return Data.ColonLoc; }
+
+  /// Get 'omp_all_memory' location.
+  SourceLocation getOmpAllMemoryLoc() const { return Data.OmpAllMemoryLoc; }
 
   /// Return optional depend modifier.
   Expr 

[PATCH] D124752: [HLSL] clang codeGen for HLSLShaderAttr.

[Xiang Li via Phabricator via cfe-commits]

python3kgae added inline comments.



Comment at: clang/lib/AST/Mangle.cpp:138
 
+  // HLSL shader entry function never need to be mangled.
+  if (getASTContext().getLangOpts().HLSL && D->hasAttr())

Anastasia wrote:
> Does HLSL shader entry inherits the same behavior as C-linkage functions  
> (extern C) e.g. they can't be overloaded, templated, etc? If that's the case 
> it might be easier to add C-linkage to it during parsing and then you can 
> inherit the rest of logic including excluding it from mangling... This is how 
> we implement kernel function handling in clang for OpenCL.
Yes. It is like kernel for OpenCL.
I'll change to extern C.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124752

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

[PATCH] D126158: [MLIR][GPU] Replace fdiv on fp16 with promoted (fp32) multiplication with reciprocal plus one (conditional) Newton iteration.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

I would suggest separating it into separate LLVM and MLIR patches.

LLVM changes look OK to me. No idea about MLIR. we would probably want to lower 
fp16 fdiv the same way in LLVM, too, but that would also have to be a separate 
patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126158

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

[PATCH] D126061: [clang] [WIP] Reject non-declaration C++11 attributes on declarations

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Thank you for your work on this, I generally like this new approach and think 
we're heading in the right direction.




Comment at: clang/include/clang/Sema/DeclSpec.h:1853-1856
   /// Attrs - Attributes.
   ParsedAttributes Attrs;
 
+  ParsedAttributes DeclarationAttrs;

We should probably rename `Attrs` to be less generic and add some comments to 
explain why there are two lists of parsed attributes.



Comment at: clang/include/clang/Sema/ParsedAttr.h:657-658
+  /// "slides" to the decl-specifier-seq).
+  /// Attributes with GNU, __declspec or keyword syntax generally slide
+  /// to the decl-specifier-seq. C++11 attributes specified ahead of the
+  /// declaration always appertain to the declaration according to the 
standard,

rsmith wrote:
> I don't think this sentence is correct: "Attributes with GNU, __declspec or 
> keyword syntax generally slide to the decl-specifier-seq." Instead, I think 
> those attribute syntaxes are never parsed as declaration attributes in the 
> first place, so there is no possibility of "sliding" anywhere -- they simply 
> always are decl-spec attributes.
That's fair -- I tend to think "sliding" is also what happens (at least 
notionally) in a case like `__attribute__((address_space(1))) int *i;` because 
it's a type attribute rather than a declaration attribute, but that's also a 
declaration specifier, so it doesn't really slide anywhere.



Comment at: clang/lib/Parse/ParseDecl.cpp:2188
 // Parse the next declarator.
-D.clear();
+D.clearExceptDeclarationAttrs();
 D.setCommaLoc(CommaLoc);

rsmith wrote:
> I wonder if a name like `prepareForNextDeclarator` or `clearForComma` would 
> be better here -- something that indicates why we're clearing rather than 
> describing how.
Personally, I like `prepareForNextDeclarator()` -- that's nice and clear (to 
me).



Comment at: clang/lib/Parse/ParseDecl.cpp:4323-4326
+// C2x draft 6.7.2.1/9 : "The optional attribute specifier sequence in a
+// member declaration appertains to each of the members declared by the
+// member declarator list; it shall not appear if the optional member
+// declarator list is omitted."

Good catch! This also applies in C++: 
http://eel.is/c++draft/class#mem.general-14

I think you should add some test coverage for this, along the lines of:
```
struct S {
  [[clang::annotate("test")]] int; // The attribute should be diagnosed (as an 
error?)
};
```



Comment at: clang/lib/Parse/ParseDecl.cpp:6978-6997
 // Parse any C++11 attributes.
-MaybeParseCXX11Attributes(DS.getAttributes());
+ParsedAttributes ArgDeclAttrs(AttrFactory);
+MaybeParseCXX11Attributes(ArgDeclAttrs);
 
-// Skip any Microsoft attributes before a param.
-MaybeParseMicrosoftAttributes(DS.getAttributes());
-
-SourceLocation DSStart = Tok.getLocation();
+ParsedAttributes ArgDeclSpecAttrs(AttrFactory);
 
 // If the caller parsed attributes for the first argument, add them now.

rsmith wrote:
> Seems to be mostly pre-existing, but I don't think this is right. The 
> `FirstArgAttrs` are all decl-specifier attributes (they're parsed in 
> `ParseParenDeclarator`, where we look for GNU attributes and `__declspec` 
> attributes), so if we parsed any of those, we should not now parse any syntax 
> that is supposed to precede decl-specifier attributes. The current code 
> allows attributes to appear in the wrong order in the case where we need to 
> disambiguate a paren declarator: https://godbolt.org/z/bzK6n8obM (note that 
> the `g` case properly errors, but the `f` case that needs lookahead to 
> determine whether the `(` is introducing a function declarator incorrectly 
> accepts misplaced attributes).
Good catch!



Comment at: clang/lib/Parse/ParseObjc.cpp:1233-1234
   // Now actually move the attributes over.
   takeDeclAttributes(attrs, D.getMutableDeclSpec().getAttributes());
+  takeDeclAttributes(attrs, D.getDeclarationAttributes());
   takeDeclAttributes(attrs, D.getAttributes());

rsmith wrote:
> I think we should keep the attributes in appearance order.
+1

FWIW, we run into some "fun" bugs with attribute orders and declaration merging 
where the orders are opposite and it causes problems as in 
https://godbolt.org/z/58jTM4sGM (note how the error and the note swap 
positions), so the order of attributes tends to be important (both for semantic 
behavior as well as diagnostic behavior).



Comment at: clang/lib/Parse/ParseStmt.cpp:198
+  ParsedAttributes Attrs(AttrFactory);
+  ConcatenateAttributes(CXX11Attrs, GNUAttrs, Attrs);
+

I *think* this is going to be okay because attributes at the start of a 
statement have a very specific ordering, but one thing I was slightly worried 
about is attribute orders 

[PATCH] D126274: [clangd] Handle '--' in QueryDriverDatabase

[Nathan Ridge via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG175833ed6f62: [clangd] Handle -- in 
QueryDriverDatabase (authored by nridge).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126274

Files:
  clang-tools-extra/clangd/QueryDriverDatabase.cpp


Index: clang-tools-extra/clangd/QueryDriverDatabase.cpp
===
--- clang-tools-extra/clangd/QueryDriverDatabase.cpp
+++ clang-tools-extra/clangd/QueryDriverDatabase.cpp
@@ -50,6 +50,7 @@
 #include "llvm/Support/Regex.h"
 #include "llvm/Support/ScopedPrinter.h"
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -238,10 +239,17 @@
 tooling::CompileCommand &
 addSystemIncludes(tooling::CompileCommand ,
   llvm::ArrayRef SystemIncludes) {
+  std::vector ToAppend;
   for (llvm::StringRef Include : SystemIncludes) {
 // FIXME(kadircet): This doesn't work when we have "--driver-mode=cl"
-Cmd.CommandLine.push_back("-isystem");
-Cmd.CommandLine.push_back(Include.str());
+ToAppend.push_back("-isystem");
+ToAppend.push_back(Include.str());
+  }
+  if (!ToAppend.empty()) {
+// Just append when `--` isn't present.
+auto InsertAt = llvm::find(Cmd.CommandLine, "--");
+Cmd.CommandLine.insert(InsertAt, std::make_move_iterator(ToAppend.begin()),
+   std::make_move_iterator(ToAppend.end()));
   }
   return Cmd;
 }
@@ -254,7 +262,9 @@
   if (Arg == "-target" || Arg.startswith("--target="))
 return Cmd;
 }
-Cmd.CommandLine.push_back("--target=" + Target);
+// Just append when `--` isn't present.
+auto InsertAt = llvm::find(Cmd.CommandLine, "--");
+Cmd.CommandLine.insert(InsertAt, "--target=" + Target);
   }
   return Cmd;
 }


Index: clang-tools-extra/clangd/QueryDriverDatabase.cpp
===
--- clang-tools-extra/clangd/QueryDriverDatabase.cpp
+++ clang-tools-extra/clangd/QueryDriverDatabase.cpp
@@ -50,6 +50,7 @@
 #include "llvm/Support/Regex.h"
 #include "llvm/Support/ScopedPrinter.h"
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -238,10 +239,17 @@
 tooling::CompileCommand &
 addSystemIncludes(tooling::CompileCommand ,
   llvm::ArrayRef SystemIncludes) {
+  std::vector ToAppend;
   for (llvm::StringRef Include : SystemIncludes) {
 // FIXME(kadircet): This doesn't work when we have "--driver-mode=cl"
-Cmd.CommandLine.push_back("-isystem");
-Cmd.CommandLine.push_back(Include.str());
+ToAppend.push_back("-isystem");
+ToAppend.push_back(Include.str());
+  }
+  if (!ToAppend.empty()) {
+// Just append when `--` isn't present.
+auto InsertAt = llvm::find(Cmd.CommandLine, "--");
+Cmd.CommandLine.insert(InsertAt, std::make_move_iterator(ToAppend.begin()),
+   std::make_move_iterator(ToAppend.end()));
   }
   return Cmd;
 }
@@ -254,7 +262,9 @@
   if (Arg == "-target" || Arg.startswith("--target="))
 return Cmd;
 }
-Cmd.CommandLine.push_back("--target=" + Target);
+// Just append when `--` isn't present.
+auto InsertAt = llvm::find(Cmd.CommandLine, "--");
+Cmd.CommandLine.insert(InsertAt, "--target=" + Target);
   }
   return Cmd;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits