[PATCH] D128204: [clangd] Add fix-it for inserting IWYU pragma: keep

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

> I had another idea about offering the export pragma when in a header file but 
> I don't know if that's going too far

There are definitely cases where this is conceptually "right" fix, but it's 
hard to guess that in clangd (well at least without having some codebase wide 
analysis), and offering it all the time would definitely confuse users.

> One of the main issues I have is due to templates not being instantiated 
> which can result in symbols that are actually used not being picked up as the 
> template instantiation that uses them isn't actually instantiated.

I guess you're talking about having the template pattern in the main file, but 
all the instantiations are in dependents of the code. My mental model was 
around making the dependents have the include for the type, instead of having 
it in the file providing the template pattern (header).  Does that make sense?
This kind of breaks down when there's actually some types used by all the 
instantiations, as you'd want them to be included by the header. But I think we 
should be able to diagnose these cases, as usage of this type should be 
non-dependent (at least in the cases I can think of), so this sounds like a 
bug/improvement.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128204

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

[PATCH] D113545: [C++20] [Module] Support reachable definition initially/partially

[Chuanqi Xu via Phabricator via cfe-commits]

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

Add test from https://eel.is/c++draft/module.context#example-1


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

https://reviews.llvm.org/D113545

Files:
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/Basic/Module.h
  clang/include/clang/Sema/Lookup.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaCXXScopeSpec.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaModule.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  
clang/test/CXX/basic/basic.lookup/basic.lookup.argdep/p4-friend-in-reachable-class.cpp
  clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
  clang/test/CXX/module/module.context/p7.cpp
  clang/test/CXX/module/module.import/p2.cpp
  clang/test/CXX/module/module.interface/p2.cpp
  clang/test/CXX/module/module.interface/p7.cpp
  clang/test/CXX/module/module.reach/ex1.cpp
  clang/test/CXX/module/module.reach/p2.cpp
  clang/test/CXX/module/module.reach/p4/TransitiveImport.cpp
  clang/test/CXX/module/module.reach/p5.cpp
  clang/test/CXX/module/module.unit/p7/t6.cpp
  clang/test/CXX/modules-ts/basic/basic.link/p2/other.cpp
  clang/test/Modules/Reachability-Private.cpp
  clang/test/Modules/Reachability-func-default-arg.cpp
  clang/test/Modules/Reachability-func-ret.cpp
  clang/test/Modules/Reachability-template-default-arg.cpp
  clang/test/Modules/Reachability-template-instantiation.cpp
  clang/test/Modules/Reachability-using-templates.cpp
  clang/test/Modules/Reachability-using.cpp
  clang/test/Modules/cxx20-10-1-ex2.cpp
  clang/test/Modules/derived_class.cpp
  clang/test/Modules/explicitly-specialized-template.cpp
  clang/test/Modules/module-private.cpp
  clang/test/Modules/template-function-specialization.cpp
  clang/test/Modules/template_default_argument.cpp

Index: clang/test/Modules/template_default_argument.cpp
===
--- /dev/null
+++ clang/test/Modules/template_default_argument.cpp
@@ -0,0 +1,29 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/B.cppm -emit-module-interface -o %t/B.pcm
+// RUN: %clang_cc1 -std=c++20 -fprebuilt-module-path=%t %t/Use.cpp -fsyntax-only -verify
+//
+//--- templ.h
+template 
+class templ {};
+template 
+void templ_func() {}
+
+//--- B.cppm
+module;
+#include "templ.h"
+export module B;
+export template 
+templ bar() {
+  templ_func();
+  return {};
+}
+
+//--- Use.cpp
+// expected-no-diagnostics
+import B;
+auto foo() {
+  return bar();
+}
Index: clang/test/Modules/template-function-specialization.cpp
===
--- /dev/null
+++ clang/test/Modules/template-function-specialization.cpp
@@ -0,0 +1,60 @@
+// RUN: rm -fr %t
+// RUN: mkdir %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/foo.cppm -o %t/foo.pcm
+// RUN: %clang_cc1 -std=c++20 -fprebuilt-module-path=%t %t/Use.cpp -verify -fsyntax-only
+//
+//--- foo.cppm
+module;
+# 3 __FILE__ 1 // use the next physical line number here (and below)
+template 
+void foo() {
+}
+
+template <>
+void foo() {
+}
+
+template 
+void foo2() {
+}
+
+template <>
+void foo2() {
+}
+
+template 
+void foo3() {
+}
+
+template <>
+void foo3();
+
+export module foo;
+export using ::foo;
+export using ::foo3;
+
+export template 
+void foo4() {
+}
+
+export template <>
+void foo4() {
+}
+
+//--- Use.cpp
+import foo;
+void use() {
+  foo();
+  foo();
+  foo2(); // expected-error {{missing '#include'; 'foo2' must be declared before it is used}}
+ // expected-note@* {{declaration here is not visible}}
+  foo2();   // expected-error {{missing '#include'; 'foo2' must be declared before it is used}}
+ // expected-note@* {{declaration here is not visible}}
+  foo3();
+  foo3();
+
+  foo4();
+  foo4();
+}
Index: clang/test/Modules/module-private.cpp
===
--- clang/test/Modules/module-private.cpp
+++ clang/test/Modules/module-private.cpp
@@ -21,8 +21,8 @@
   vector vec; // expected-error{{no template named 'vector'}}
 
   VisibleStruct vs;
-  vs.field = 0; // expected-error{{no member named 'field' in 'VisibleStruct'}}
-  vs.setField(1); // expected-error{{no member named 'setField' in 'VisibleStruct'}}
+  vs.field = 0;
+  vs.setField(1);
 
   return hidden_var; // expected-error{{use of undeclared identifier 'hidden_var'}}
 }
Index: clang/test/Modules/explicitly-specialized-template.cpp
===
--- /dev/null
+++ clang/test/Modules/explicitly-specialized-template.cpp
@@ -0,0 +1,47 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: 

[PATCH] D127873: [clang-format] Fix misplacement of `*` in declaration of pointer to struct

[Jack Huang via Phabricator via cfe-commits]

jackhong12 updated this revision to Diff 438921.
jackhong12 marked an inline comment as done.
jackhong12 added a comment.

I have added a variable for `MatchingLBrace->getPreviousNonComment()`.

Thanks. I am not sure which modification will be better, the patch I submitted 
or the following code.

  FormatToken *BeforeLBraceToken = nullptr;
  if (MatchingLBrace)
BeforeLBraceToken = MatchingLBrace->getPreviousNonComment();
  
  if (BeforeLBraceToken && BeforeLBraceToken->is(TT_TemplateCloser))
return TT_BinaryOperator;


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

https://reviews.llvm.org/D127873

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

Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -85,6 +85,32 @@
   Tokens = annotate("case &x:");
   EXPECT_EQ(Tokens.size(), 5u) << Tokens;
   EXPECT_TOKEN(Tokens[1], tok::amp, TT_UnaryOperator);
+
+  Tokens = annotate("struct {\n"
+"} *ptr;");
+  EXPECT_EQ(Tokens.size(), 7u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
+  Tokens = annotate("union {\n"
+"} *ptr;");
+  EXPECT_EQ(Tokens.size(), 7u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
+  Tokens = annotate("class {\n"
+"} *ptr;");
+  EXPECT_EQ(Tokens.size(), 7u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
+
+  Tokens = annotate("struct {\n"
+"} &&ptr = {};");
+  EXPECT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::ampamp, TT_PointerOrReference);
+  Tokens = annotate("union {\n"
+"} &&ptr = {};");
+  EXPECT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::ampamp, TT_PointerOrReference);
+  Tokens = annotate("class {\n"
+"} &&ptr = {};");
+  EXPECT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::ampamp, TT_PointerOrReference);
 }
 
 TEST_F(TokenAnnotatorTest, UnderstandsUsesOfPlusAndMinus) {
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -10431,6 +10431,67 @@
   "void F();",
   getGoogleStyleWithColumns(68));
 
+  FormatStyle Style = getLLVMStyle();
+  Style.PointerAlignment = FormatStyle::PAS_Left;
+  verifyFormat("struct {\n"
+   "}* ptr;",
+   Style);
+  verifyFormat("union {\n"
+   "}* ptr;",
+   Style);
+  verifyFormat("class {\n"
+   "}* ptr;",
+   Style);
+  verifyFormat("struct {\n"
+   "}&& ptr = {};",
+   Style);
+  verifyFormat("union {\n"
+   "}&& ptr = {};",
+   Style);
+  verifyFormat("class {\n"
+   "}&& ptr = {};",
+   Style);
+
+  Style.PointerAlignment = FormatStyle::PAS_Middle;
+  verifyFormat("struct {\n"
+   "} * ptr;",
+   Style);
+  verifyFormat("union {\n"
+   "} * ptr;",
+   Style);
+  verifyFormat("class {\n"
+   "} * ptr;",
+   Style);
+  verifyFormat("struct {\n"
+   "} && ptr = {};",
+   Style);
+  verifyFormat("union {\n"
+   "} && ptr = {};",
+   Style);
+  verifyFormat("class {\n"
+   "} && ptr = {};",
+   Style);
+
+  Style.PointerAlignment = FormatStyle::PAS_Right;
+  verifyFormat("struct {\n"
+   "} *ptr;",
+   Style);
+  verifyFormat("union {\n"
+   "} *ptr;",
+   Style);
+  verifyFormat("class {\n"
+   "} *ptr;",
+   Style);
+  verifyFormat("struct {\n"
+   "} &&ptr = {};",
+   Style);
+  verifyFormat("union {\n"
+   "} &&ptr = {};",
+   Style);
+  verifyFormat("class {\n"
+   "} &&ptr = {};",
+   Style);
+
   verifyIndependentOfContext("MACRO(int *i);");
   verifyIndependentOfContext("MACRO(auto *a);");
   verifyIndependentOfContext("MACRO(const A *a);");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2304,6 +2304,28 @@
 if (NextToken->isOneOf(tok::comma, tok::semi))
   return TT_PointerOrReference;
 
+// After right braces, star tokens are likely to be pointers to struct,
+// union, or class.
+//   struct {} *ptr;
+if (PrevToken->is(tok::r_brace) && Tok.is(tok::star))
+  return TT_PointerOrReference;
+
+// For "} &&"
+if (PrevToken->is(tok::r_brace) && Tok.is(tok::ampamp

[PATCH] D113545: [C++20] [Module] Support reachable definition initially/partially

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

In D113545#3598412 , @iains wrote:

> As for review, I can try to pick up the "nits" but not sure that I know the 
> instantiation sub=system too well, so it would be better if @rsmith could 
> cast an eye over those parts.

Yeah, @rsmith should be the best one to review this. But as you can find, this 
revision is opened for months... and the revision blocks many uses of C++20 
modules. I really hope someone could push this forward... This was tested 
before internally.

> let's discuss the 10.6 example first (I'd guess 10.7 cases will need to be 
> reviewed too)
>
>   // RUN: rm -rf %t
>   // RUN: split-file %s %t
>   // RUN: cd %t
>   
>   // RUN: %clang_cc1 -std=c++20 -emit-header-unit -xc++-header-unit-header 
> std-10-6-ex1-decl.h \
>   // RUN: -o decl.pcm
>   
>   // RUN: %clang_cc1 -std=c++20 -emit-header-unit -xc++-header-unit-header 
> std-10-6-ex1-defn.h \
>   // RUN: -o defn.pcm
>   
>   // RUN: %clang_cc1 -std=c++20 -emit-module-interface std-10-6-ex1-stuff.cpp 
> \
>   // RUN: -o stuff.pcm
>   
>   // RUN: %clang_cc1 -std=c++20 -emit-module-interface std-10-6-ex1-M1.cpp \
>   // RUN: -fmodule-file=stuff.pcm -o M1.pcm  -fmodule-file=defn.pcm
>   
>   // RUN: %clang_cc1 -std=c++20 -emit-module-interface std-10-6-ex1-M2.cpp \
>   // RUN: -fmodule-file=stuff.pcm -o M2.pcm  -fmodule-file=decl.pcm
>   
>   // RUN: %clang_cc1 -std=c++20 std-10-6-ex1-use.cpp \
>   // RUN: -fmodule-file=M1.pcm -fmodule-file=M2.pcm  -fsyntax-only
>   
>   //--- std-10-6-ex1-decl.h
>   struct X;
>   
>   //--- std-10-6-ex1-defn.h
>   struct X {};
>   
>   //--- std-10-6-ex1-stuff.cpp
>   export module stuff;
>   export template void foo(T, U u) { auto v = u; }
>   export template void bar(T, U u) { auto v = *u; }
>   
>   //--- std-10-6-ex1-M1.cpp
>   export module M1;
>   import "std-10-6-ex1-defn.h"; // provides struct X {};
>   import stuff;
>   
>   export template void f(T t) {
> X x;
> foo(t, x); 
>   }
>   
>   //--- std-10-6-ex1-M2.cpp
>   export module M2;
>   import "std-10-6-ex1-decl.h"; // provides struct X; (not a definition)
>   
>   import stuff;
>   export template void g(T t) {
> X *x;
> bar(t, x); 
>   }
>   
>   //--- std-10-6-ex1-use.cpp
>   import M1;
>   import M2;
>   
>   void test() {
> f(0);
> g(0);
>   }

Thanks for reporting this. I've add the tests. Then my implementation would 
complain that the definition of ''X' is not reachable when it tries to 
instantiate `g(T)`. But from my personal reading to [module.context]p2:

> During the implicit instantiation of a template whose point of instantiation 
> is specified as that of an enclosing specialization ([temp.point]), the 
> instantiation context is the union of the instantiation context of the 
> enclosing specialization and, if the template is defined in a module 
> interface unit of a module M and the point of instantiation is not in a 
> module interface unit of M, the point at the end of the declaration-seq of 
> the primary module interface unit of M (prior to the private-module-fragment, 
> if any).

I feel the diagnostic might make sense. Since the template function 'g(T)' is 
defined in a module interface unit. And the point of  instantiation is not in a 
module interface unit of that module. So the point should at the end of the 
primary module interface unit M2 . So the 
definition of X shouldn't be reachable here. So the diagnostic makes sense. 
I'll send this one to WG21.

> as suspected, we also have a missing diagnostic in 10.7 ex1

Yes, this was added before at clang/test/CXX/module/module.reach/ex1.cpp. And I 
add a FIXME there:

  // FIXME: We should emit an error for unreachable definition of B.
  void g() { f(); }

I'll file an issue for it once this landed. BTW, the compiler would behave 
properly if:

  //--- M.cppm
  export module M;
  export import :A;
  import :B;
  export B foo();
  export void f(B b = B());
  //--- Use.cpp
  export module X;
  import M;
  void g() { f(foo()); } // complains successfully

This looks even more straight forward.

> (I think we might also have some issues with poor diagnostics for items in 
> PMF (saying that an import is required before use, but of course that import 
> is impossible - e.g. 10.5)

Yes, there are many problems. And as the title said, this is an initial 
implementation and these problems are not regression bugs so I feel like it 
should be good to fix them in later versions.


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

https://reviews.llvm.org/D113545

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

[PATCH] D113545: [C++20] [Module] Support reachable definition initially/partially

[Chuanqi Xu via Phabricator via cfe-commits]

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

Update comments for the test of [module.context]p7.


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

https://reviews.llvm.org/D113545

Files:
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/Basic/Module.h
  clang/include/clang/Sema/Lookup.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaCXXScopeSpec.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaModule.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  
clang/test/CXX/basic/basic.lookup/basic.lookup.argdep/p4-friend-in-reachable-class.cpp
  clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
  clang/test/CXX/module/module.context/p7.cpp
  clang/test/CXX/module/module.import/p2.cpp
  clang/test/CXX/module/module.interface/p2.cpp
  clang/test/CXX/module/module.interface/p7.cpp
  clang/test/CXX/module/module.reach/ex1.cpp
  clang/test/CXX/module/module.reach/p2.cpp
  clang/test/CXX/module/module.reach/p4/TransitiveImport.cpp
  clang/test/CXX/module/module.reach/p5.cpp
  clang/test/CXX/module/module.unit/p7/t6.cpp
  clang/test/CXX/modules-ts/basic/basic.link/p2/other.cpp
  clang/test/Modules/Reachability-Private.cpp
  clang/test/Modules/Reachability-func-default-arg.cpp
  clang/test/Modules/Reachability-func-ret.cpp
  clang/test/Modules/Reachability-template-default-arg.cpp
  clang/test/Modules/Reachability-template-instantiation.cpp
  clang/test/Modules/Reachability-using-templates.cpp
  clang/test/Modules/Reachability-using.cpp
  clang/test/Modules/cxx20-10-1-ex2.cpp
  clang/test/Modules/derived_class.cpp
  clang/test/Modules/explicitly-specialized-template.cpp
  clang/test/Modules/module-private.cpp
  clang/test/Modules/template-function-specialization.cpp
  clang/test/Modules/template_default_argument.cpp

Index: clang/test/Modules/template_default_argument.cpp
===
--- /dev/null
+++ clang/test/Modules/template_default_argument.cpp
@@ -0,0 +1,29 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/B.cppm -emit-module-interface -o %t/B.pcm
+// RUN: %clang_cc1 -std=c++20 -fprebuilt-module-path=%t %t/Use.cpp -fsyntax-only -verify
+//
+//--- templ.h
+template 
+class templ {};
+template 
+void templ_func() {}
+
+//--- B.cppm
+module;
+#include "templ.h"
+export module B;
+export template 
+templ bar() {
+  templ_func();
+  return {};
+}
+
+//--- Use.cpp
+// expected-no-diagnostics
+import B;
+auto foo() {
+  return bar();
+}
Index: clang/test/Modules/template-function-specialization.cpp
===
--- /dev/null
+++ clang/test/Modules/template-function-specialization.cpp
@@ -0,0 +1,60 @@
+// RUN: rm -fr %t
+// RUN: mkdir %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/foo.cppm -o %t/foo.pcm
+// RUN: %clang_cc1 -std=c++20 -fprebuilt-module-path=%t %t/Use.cpp -verify -fsyntax-only
+//
+//--- foo.cppm
+module;
+# 3 __FILE__ 1 // use the next physical line number here (and below)
+template 
+void foo() {
+}
+
+template <>
+void foo() {
+}
+
+template 
+void foo2() {
+}
+
+template <>
+void foo2() {
+}
+
+template 
+void foo3() {
+}
+
+template <>
+void foo3();
+
+export module foo;
+export using ::foo;
+export using ::foo3;
+
+export template 
+void foo4() {
+}
+
+export template <>
+void foo4() {
+}
+
+//--- Use.cpp
+import foo;
+void use() {
+  foo();
+  foo();
+  foo2(); // expected-error {{missing '#include'; 'foo2' must be declared before it is used}}
+ // expected-note@* {{declaration here is not visible}}
+  foo2();   // expected-error {{missing '#include'; 'foo2' must be declared before it is used}}
+ // expected-note@* {{declaration here is not visible}}
+  foo3();
+  foo3();
+
+  foo4();
+  foo4();
+}
Index: clang/test/Modules/module-private.cpp
===
--- clang/test/Modules/module-private.cpp
+++ clang/test/Modules/module-private.cpp
@@ -21,8 +21,8 @@
   vector vec; // expected-error{{no template named 'vector'}}
 
   VisibleStruct vs;
-  vs.field = 0; // expected-error{{no member named 'field' in 'VisibleStruct'}}
-  vs.setField(1); // expected-error{{no member named 'setField' in 'VisibleStruct'}}
+  vs.field = 0;
+  vs.setField(1);
 
   return hidden_var; // expected-error{{use of undeclared identifier 'hidden_var'}}
 }
Index: clang/test/Modules/explicitly-specialized-template.cpp
===
--- /dev/null
+++ clang/test/Modules/explicitly-specialized-template.cpp
@@ -0,0 +1,47 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 

[PATCH] D113545: [C++20] [Module] Support reachable definition initially/partially

[Iain Sandoe via Phabricator via cfe-commits]

iains added a comment.

I think it is helpful to collect the standard examples into one place (i.e. 
test/Modules) and name them for the standard version (i.e. cxx20-N-M-exO.cpp) 
.. because

- the details of the examples do change from one version of the standard to the 
next, because of changes in the normative text
- some of the examples illustrate more than one bullet point
- it makes it easier to find them for someone who is starting work on this area.

(not a big deal, but now we have some on one place and some in another - which 
is why I had missed that you already had one of the cases)

I will rebase my changes on this - and I have a patch for the 10.5 PMF issues 
(under test),


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

https://reviews.llvm.org/D113545

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

[clang] 706e89d - Fix interaction of pragma FENV_ACCESS with other pragmas

[Serge Pavlov via cfe-commits]

Author: Serge Pavlov
Date: 2022-06-22T15:13:54+07:00
New Revision: 706e89db97d3dea63dac1ee2c5a26cb2af9651a2

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

LOG: Fix interaction of pragma FENV_ACCESS with other pragmas

Previously `#pragma STDC FENV_ACCESS ON` always set dynamic rounding
mode and strict exception handling. It is not correct in the presence
of other pragmas that also modify rounding mode and exception handling.
For example, the effect of previous pragma FENV_ROUND could be
cancelled, which is not conformant with the C standard. Also
`#pragma STDC FENV_ACCESS OFF` turned off only FEnvAccess flag, leaving
rounding mode and exception handling unchanged, which is incorrect in
general case.

Concrete rounding and exception mode depend on a combination of several
factors like various pragmas and command-line options. During the review
of this patch an idea was proposed that the semantic actions associated
with such pragmas should only set appropriate flags. Actual rounding
mode and exception handling should be calculated taking into account the
state of all relevant options. In such implementation the pragma
FENV_ACCESS should not override properties set by other pragmas but
should set them if such setting is absent.

To implement this approach the following main changes are made:

- Field `FPRoundingMode` is removed from `LangOptions`. Actually there
  are no options that set it to arbitrary rounding mode, the choice was
  only `dynamic` or `tonearest`. Instead, a new boolean flag
  `RoundingMath` is added, with the same meaning as the corresponding
  command-line option.

- Type `FPExceptionModeKind` now has possible value `FPE_Default`. It
  does not represent any particular exception mode but indicates that
  such mode was not set and default value should be used. It allows to
  distinguish the case:

{
#pragma STDC FENV_ACCESS ON
...
}

  where the pragma must set FPE_Strict, from the case:

{
#pragma clang fp exceptions(ignore)
#pragma STDC FENV_ACCESS ON
...
}

  where exception mode should remain `FPE_Ignore`.

  - Class `FPOptions` has now methods `getRoundingMode` and
  `getExceptionMode`, which calculates the respective properties from
  other specified FP properties.

  - Class `LangOptions` has now methods `getDefaultRoundingMode` and
  `getDefaultExceptionMode`, which calculates default modes from the
  specified options and should be used instead of `getRoundingMode` and
  `getFPExceptionMode` of the same class.

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

Added: 


Modified: 
clang/include/clang/Basic/FPOptions.def
clang/include/clang/Basic/LangOptions.def
clang/include/clang/Basic/LangOptions.h
clang/include/clang/Driver/Options.td
clang/include/clang/Sema/Sema.h
clang/lib/AST/ExprConstant.cpp
clang/lib/CodeGen/CGCall.cpp
clang/lib/CodeGen/CodeGenFunction.cpp
clang/lib/Frontend/CompilerInstance.cpp
clang/lib/Parse/ParsePragma.cpp
clang/lib/Sema/SemaAttr.cpp
clang/test/AST/ast-dump-fpfeatures.cpp
clang/test/CodeGen/pragma-fenv_access.c

Removed: 




diff  --git a/clang/include/clang/Basic/FPOptions.def 
b/clang/include/clang/Basic/FPOptions.def
index 224c1827144f5..1dfbbb549c874 100644
--- a/clang/include/clang/Basic/FPOptions.def
+++ b/clang/include/clang/Basic/FPOptions.def
@@ -14,9 +14,10 @@
 
 // OPTION(name, type, width, previousName)
 OPTION(FPContractMode, LangOptions::FPModeKind, 2, First)
-OPTION(RoundingMode, LangOptions::RoundingMode, 3, FPContractMode)
-OPTION(FPExceptionMode, LangOptions::FPExceptionModeKind, 2, RoundingMode)
-OPTION(AllowFEnvAccess, bool, 1, FPExceptionMode)
+OPTION(RoundingMath, bool, 1, FPContractMode)
+OPTION(ConstRoundingMode, LangOptions::RoundingMode, 3, RoundingMath)
+OPTION(SpecifiedExceptionMode, LangOptions::FPExceptionModeKind, 2, 
ConstRoundingMode)
+OPTION(AllowFEnvAccess, bool, 1, SpecifiedExceptionMode)
 OPTION(AllowFPReassociate, bool, 1, AllowFEnvAccess)
 OPTION(NoHonorNaNs, bool, 1, AllowFPReassociate)
 OPTION(NoHonorInfs, bool, 1, NoHonorNaNs)

diff  --git a/clang/include/clang/Basic/LangOptions.def 
b/clang/include/clang/Basic/LangOptions.def
index aa346ba239391..c41b5ddc7fa11 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -311,8 +311,8 @@ COMPATIBLE_LANGOPT(CLFiniteMathOnly , 1, 0, 
"__FINITE_MATH_ONLY__ predefined mac
 /// FP_CONTRACT mode (on/off/fast).
 BENIGN_ENUM_LANGOPT(DefaultFPContractMode, FPModeKind, 2, FPM_Off, "FP 
contraction type")
 COMPATIBLE_LANGOPT(ExpStrictFP, 1, false, "Enable experimental strict floating 
point")
-BENIGN_ENUM_LANGOPT(FPRoundingMode, RoundingMode, 3, 
RoundingMode::NearestTiesToEven, "FP Rou

[PATCH] D126364: Fix interaction of pragma FENV_ACCESS with other pragmas

[Serge Pavlov 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 rG706e89db97d3: Fix interaction of pragma FENV_ACCESS with 
other pragmas (authored by sepavloff).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126364

Files:
  clang/include/clang/Basic/FPOptions.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/test/AST/ast-dump-fpfeatures.cpp
  clang/test/CodeGen/pragma-fenv_access.c

Index: clang/test/CodeGen/pragma-fenv_access.c
===
--- clang/test/CodeGen/pragma-fenv_access.c
+++ clang/test/CodeGen/pragma-fenv_access.c
@@ -1,5 +1,15 @@
-// RUN: %clang_cc1 -fexperimental-strict-floating-point -ffp-exception-behavior=strict -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck %s
-// RUN: %clang_cc1 -fexperimental-strict-floating-point -ffp-exception-behavior=strict -triple %itanium_abi_triple -emit-llvm %s -o - -fms-extensions -DMS | FileCheck %s
+// RUN: %clang_cc1 -fexperimental-strict-floating-point -ffp-exception-behavior=strict -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck --check-prefixes=CHECK,STRICT %s
+// RUN: %clang_cc1 -fexperimental-strict-floating-point -ffp-exception-behavior=strict -triple %itanium_abi_triple -emit-llvm %s -o - -fms-extensions -DMS | FileCheck --check-prefixes=CHECK,STRICT %s
+// RUN: %clang_cc1 -fexperimental-strict-floating-point -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck --check-prefixes=CHECK,DEFAULT %s
+
+
+float func_00(float x, float y) {
+  return x + y;
+}
+// CHECK-LABEL: @func_00
+// STRICT: call float @llvm.experimental.constrained.fadd.f32(float {{.*}}, float {{.*}}, metadata !"round.tonearest", metadata !"fpexcept.strict")
+// DEFAULT: fadd float
+
 
 #ifdef MS
 #pragma fenv_access (on)
@@ -20,7 +30,7 @@
   return x + y;
 }
 // CHECK-LABEL: @func_02
-// CHECK: call float @llvm.experimental.constrained.fadd.f32(float {{.*}}, float {{.*}}, metadata !"round.dynamic", metadata !"fpexcept.ignore")
+// CHECK: call float @llvm.experimental.constrained.fadd.f32(float {{.*}}, float {{.*}}, metadata !"round.tonearest", metadata !"fpexcept.ignore")
 
 
 float func_03(float x, float y) {
@@ -41,7 +51,16 @@
   return x + y;
 }
 // CHECK-LABEL: @func_04
-// CHECK: call float @llvm.experimental.constrained.fadd.f32(float {{.*}}, float {{.*}}, metadata !"round.dynamic", metadata !"fpexcept.ignore")
+// STRICT: call float @llvm.experimental.constrained.fadd.f32(float {{.*}}, float {{.*}}, metadata !"round.tonearest", metadata !"fpexcept.ignore")
+// DEFAULT: fadd float
+
+
+float func_04a(float x, float y) {
+  #pragma float_control(except, on)
+  return x + y;
+}
+// CHECK-LABEL: @func_04a
+// CHECK: call float @llvm.experimental.constrained.fadd.f32(float {{.*}}, float {{.*}}, metadata !"round.tonearest", metadata !"fpexcept.strict")
 
 
 float func_05(float x, float y) {
@@ -57,18 +76,151 @@
   return x + y;
 }
 // CHECK-LABEL: @func_06
-// CHECK: call float @llvm.experimental.constrained.fadd.f32(float {{.*}}, float {{.*}}, metadata !"round.dynamic", metadata !"fpexcept.ignore")
+// STRICT: call float @llvm.experimental.constrained.fadd.f32(float {{.*}}, float {{.*}}, metadata !"round.tonearest", metadata !"fpexcept.ignore")
+// DEFAULT: fadd float
 
 
 float func_07(float x, float y) {
   x -= y;
   if (x) {
 #pragma STDC FENV_ACCESS ON
-y *= 2;
+y *= 2.0F;
   }
-  return y + 4;
+  return y + 4.0F;
 }
 // CHECK-LABEL: @func_07
-// CHECK: call float @llvm.experimental.constrained.fsub.f32(float {{.*}}, float {{.*}}, metadata !"round.dynamic", metadata !"fpexcept.strict")
-// CHECK: call float @llvm.experimental.constrained.fmul.f32(float {{.*}}, float {{.*}}, metadata !"round.dynamic", metadata !"fpexcept.strict")
+// STRICT: call float @llvm.experimental.constrained.fsub.f32(float {{.*}}, float {{.*}}, metadata !"round.tonearest", metadata !"fpexcept.strict")
+// STRICT: call float @llvm.experimental.constrained.fmul.f32(float {{.*}}, float {{.*}}, metadata !"round.dynamic", metadata !"fpexcept.strict")
+// STRICT: call float @llvm.experimental.constrained.fadd.f32(float {{.*}}, float {{.*}}, metadata !"round.tonearest", metadata !"fpexcept.strict")
+// DEFAULT: call float @llvm.experimental.constrained.fsub.f32(float {{.*}}, float {{.*}}, metadata !"round.tonearest", metadata !"fpexcept.ignore")
+// DEFAULT: call float @llvm.experimental.constrained.fmul.f32(float {{.*}}, float {{.*}}, metadata !"round.dynamic", metadata !"fpexcept.strict")
+// DEFAULT: call float @llvm.

[PATCH] D113545: [C++20] [Module] Support reachable definition initially/partially

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

In D113545#3601031 , @iains wrote:

> I think it is helpful to collect the standard examples into one place (i.e. 
> test/Modules) and name them for the standard version (i.e. cxx20-N-M-exO.cpp) 
> .. because
>
> - the details of the examples do change from one version of the standard to 
> the next, because of changes in the normative text
> - some of the examples illustrate more than one bullet point
> - it makes it easier to find them for someone who is starting work on this 
> area.
>
> (not a big deal, but now we have some on one place and some in another - 
> which is why I had missed that you already had one of the cases)
>
> I will rebase my changes on this - and I have a patch for the 10.5 PMF issues 
> (under test),

I prefer to put them under test/CXX/module/xxx. Since it looks like test/CXX is 
intended to match the standard wording. Another reason is that it looks like we 
prefer to cite standard in the style of [module.context]p7 instead of 10.6-p7 
since the number might change. And you mentioned it too.

> some of the examples illustrate more than one bullet point

It doesn't matter since the example it self would live in a certain paragraph.

> it makes it easier to find them for someone who is starting work on this area.

I feel like it would be helpful to put them under CXX since the tests under 
modules mixed many things about OC modules and Clang modules. The reason why 
some tests of the revision lives in test/Modules is might be hard to find the 
corresponding wording in the standard. But for things which is clearly 
corresponding to the standard, I always put them in test/CXX.


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

https://reviews.llvm.org/D113545

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

[PATCH] D128328: [C++20][Modules] Improve handing of Private Module Fragment diagnostics.

[Iain Sandoe via Phabricator via cfe-commits]

iains created this revision.
Herald added a project: All.
iains added reviewers: urnathan, ChuanqiXu.
iains added a subscriber: clang-modules.
iains published this revision for review.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This adds a check for exported inline functions, that there is a definition in
the definition domain (which, in practice, can only be the module purview but
before any PMF starts) since the PMF definition domain cannot contain exports.

This is:
[dcl.inline]/7
If an inline function or variable that is attached to a named module is 
declared in
a definition domain, it shall be defined in that domain.

The patch also amends diagnostic output by excluding the PMF sub-module from the
set considered as sources of missing decls.  There is no point in telling the 
user
that the import of a PMF object is missing - since such objects are never 
reachable
to an importer.  We still show the definition (as unreachable), to help point 
out
this.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128328

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaModule.cpp
  clang/test/Modules/cxx20-10-5-ex1.cpp

Index: clang/test/Modules/cxx20-10-5-ex1.cpp
===
--- /dev/null
+++ clang/test/Modules/cxx20-10-5-ex1.cpp
@@ -0,0 +1,50 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface std-10-5-ex1-interface.cpp \
+// RUN: -DBAD_FWD_DECL  -fsyntax-only -verify
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface std-10-5-ex1-interface.cpp \
+// RUN: -o A.pcm
+
+// RUN: %clang_cc1 -std=c++20 std-10-5-ex1-use.cpp  -fmodule-file=A.pcm \
+// RUN:-fsyntax-only -verify
+
+//--- std-10-5-ex1-interface.cpp
+
+export module A;
+#ifdef BAD_FWD_DECL
+export inline void fn_e(); // expected-error {{exported inline functions must be defined within the module purview and before any private module fragment}}
+#endif
+export inline void ok_fn() {}
+export inline void ok_fn2();
+inline void fn_m();
+static void fn_s();
+export struct X;
+export void g(X *x) {
+  fn_s();
+  fn_m();
+}
+export X *factory();
+void ok_fn2() {}
+
+module :private;
+struct X {};
+X *factory() {
+  return new X();
+}
+
+void fn_e() {}
+void fn_m() {}
+void fn_s() {}
+
+//--- std-10-5-ex1-use.cpp
+
+import A;
+
+void foo() {
+  X x; // expected-error 1+{{missing '#include'; 'X' must be defined before it is used}}
+   // expected-n...@std-10-5-ex1-interface.cpp:19 1+{{definition here is not reachable}}
+  X *p = factory();
+}
Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -892,6 +892,17 @@
 diagExportedUnnamedDecl(*this, UnnamedDeclKind::Context, Child,
 BlockStart);
   }
+  if (auto *FD = dyn_cast(Child)) {
+// [dcl.inline]/7
+// If an inline function or variable that is attached to a named module
+// is declared in a definition domain, it shall be defined in that
+// domain.
+// So, if the current declaration does not have a definition, we must
+// check at the end of the TU (or when the PMF starts) to see that we
+// have a definition at that point.
+if (FD->isInlineSpecified() && !FD->isDefined())
+  PendingInlineExports.insert(FD);
+  }
 }
   }
 
Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -5425,7 +5425,7 @@
   llvm::SmallVector UniqueModules;
   llvm::SmallDenseSet UniqueModuleSet;
   for (auto *M : Modules) {
-if (M->Kind == Module::GlobalModuleFragment)
+if (M->isGlobalModule() || M->isPrivateModule())
   continue;
 if (UniqueModuleSet.insert(M).second)
   UniqueModules.push_back(M);
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -1095,6 +1095,15 @@
 PerformPendingInstantiations();
   }
 
+  if (Kind == TUFragmentKind::Normal && !PendingInlineExports.empty()) {
+for (auto *D : PendingInlineExports)
+  if (auto *FD = dyn_cast(D)) {
+if (!FD->isDefined())
+  Diag(FD->getLocation(), diag::err_export_inline_not_defined);
+  }
+PendingInlineExports.clear();
+  }
+
   emitDeferredDiags();
 
   assert(LateParsedInstantiations.empty() &&
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -2245,6 +2245,10 @@
   /// Namespace definitions that we will export when they finish.
   l

[PATCH] D113545: [C++20] [Module] Support reachable definition initially/partially

[Iain Sandoe via Phabricator via cfe-commits]

iains added a comment.

In D113545#3601050 , @ChuanqiXu wrote:

> In D113545#3601031 , @iains wrote:
>
>> I think it is helpful to collect the standard examples into one place (i.e. 
>> test/Modules) and name them for the standard version (i.e. 
>> cxx20-N-M-exO.cpp) .. because
>>
>> - the details of the examples do change from one version of the standard to 
>> the next, because of changes in the normative text
>> - some of the examples illustrate more than one bullet point
>> - it makes it easier to find them for someone who is starting work on this 
>> area.
>>
>> (not a big deal, but now we have some on one place and some in another - 
>> which is why I had missed that you already had one of the cases)



> I prefer to put them under test/CXX/module/xxx. Since it looks like test/CXX 
> is intended to match the standard wording. Another reason is that it looks 
> like we prefer to cite standard in the style of [module.context]p7 instead of 
> 10.6-p7 since the number might change. And you mentioned it too.

What I was referring to is that the content of the example. the bullet point(s) 
and even whether the example exists could change between c++20 and, say, c++23 
... but as noted this is not a big deal :)


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

https://reviews.llvm.org/D113545

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

[PATCH] D113545: [C++20] [Module] Support reachable definition initially/partially

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

In D113545#3601069 , @iains wrote:

> In D113545#3601050 , @ChuanqiXu 
> wrote:
>
>> In D113545#3601031 , @iains wrote:
>>
>>> I think it is helpful to collect the standard examples into one place (i.e. 
>>> test/Modules) and name them for the standard version (i.e. 
>>> cxx20-N-M-exO.cpp) .. because
>>>
>>> - the details of the examples do change from one version of the standard to 
>>> the next, because of changes in the normative text
>>> - some of the examples illustrate more than one bullet point
>>> - it makes it easier to find them for someone who is starting work on this 
>>> area.
>>>
>>> (not a big deal, but now we have some on one place and some in another - 
>>> which is why I had missed that you already had one of the cases)
>
>
>
>> I prefer to put them under test/CXX/module/xxx. Since it looks like test/CXX 
>> is intended to match the standard wording. Another reason is that it looks 
>> like we prefer to cite standard in the style of [module.context]p7 instead 
>> of 10.6-p7 since the number might change. And you mentioned it too.
>
> What I was referring to is that the content of the example. the bullet 
> point(s) and even whether the example exists could change between c++20 and, 
> say, c++23 ... but as noted this is not a big deal :)

Yeah, it shouldn't be a big problem : )


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

https://reviews.llvm.org/D113545

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

[PATCH] D128328: [C++20][Modules] Improve handing of Private Module Fragment diagnostics.

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

It looks like we need to handle inline variable as well to match the intention.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11155
+def err_export_inline_not_defined : Error<
+  "exported inline functions must be defined within the module purview"
+  " and before any private module fragment">;

From my reading, 'exported' is not emphasized.



Comment at: clang/lib/Sema/SemaModule.cpp:895-905
+  if (auto *FD = dyn_cast(Child)) {
+// [dcl.inline]/7
+// If an inline function or variable that is attached to a named module
+// is declared in a definition domain, it shall be defined in that
+// domain.
+// So, if the current declaration does not have a definition, we must
+// check at the end of the TU (or when the PMF starts) to see that we

So we might need to move this to somewhere else.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128328

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

[PATCH] D128329: [clangd] Also mark output arguments of operator call expressions

[Christian Kandeler via Phabricator via cfe-commits]

ckandeler created this revision.
Herald added subscribers: usaxena95, kadircet, arphaman.
Herald added a project: All.
ckandeler requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

There's no reason that arguments to e.g. lambda calls should be treated
differently than those to "real" functions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128329

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -738,6 +738,11 @@
   )cpp",
   // Modifier for variables passed as non-const references
   R"cpp(
+struct $Class_decl[[ClassWithOp]] {
+void operator()(int);
+void operator()(int, int &);
+void operator()(int, int, const int &);
+};
 void $Function_decl[[fun]](int, const int,
int*, const int*,
int&, const int&,
@@ -759,6 +764,13 @@
$LocalVariable[[array]], 
$LocalVariable_usedAsMutableReference[[array]], 
$LocalVariable[[array]]
);
+  [](int){}($LocalVariable[[val]]);
+  [](int&){}($LocalVariable_usedAsMutableReference[[val]]);
+  [](const int&){}($LocalVariable[[val]]);
+  $Class[[ClassWithOp]] $LocalVariable_decl[[c]];
+  $LocalVariable[[c]]($LocalVariable[[val]]);
+  $LocalVariable[[c]](0, $LocalVariable_usedAsMutableReference[[val]]);
+  $LocalVariable[[c]](0, 0, $LocalVariable[[val]]);
 }
 struct $Class_decl[[S]] {
   $Class_decl[[S]](int&) {
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -538,12 +538,20 @@
   return true;
 
 // FIXME ...here it would make sense though.
-if (isa(E))
-  return true;
+Expr **args = nullptr;
+unsigned numArgs = 0;
+if (const auto callOp = dyn_cast(E)) {
+  if (callOp->getOperator() != OO_Call)
+return true;
+  args = E->getArgs() + 1;
+  numArgs = E->getNumArgs() - 1;
+} else {
+  args = E->getArgs();
+  numArgs = E->getNumArgs();
+}
 
 highlightMutableReferenceArguments(
-dyn_cast_or_null(E->getCalleeDecl()),
-{E->getArgs(), E->getNumArgs()});
+dyn_cast_or_null(E->getCalleeDecl()), {args, numArgs});
 
 return true;
   }


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -738,6 +738,11 @@
   )cpp",
   // Modifier for variables passed as non-const references
   R"cpp(
+struct $Class_decl[[ClassWithOp]] {
+void operator()(int);
+void operator()(int, int &);
+void operator()(int, int, const int &);
+};
 void $Function_decl[[fun]](int, const int,
int*, const int*,
int&, const int&,
@@ -759,6 +764,13 @@
$LocalVariable[[array]], $LocalVariable_usedAsMutableReference[[array]], 
$LocalVariable[[array]]
);
+  [](int){}($LocalVariable[[val]]);
+  [](int&){}($LocalVariable_usedAsMutableReference[[val]]);
+  [](const int&){}($LocalVariable[[val]]);
+  $Class[[ClassWithOp]] $LocalVariable_decl[[c]];
+  $LocalVariable[[c]]($LocalVariable[[val]]);
+  $LocalVariable[[c]](0, $LocalVariable_usedAsMutableReference[[val]]);
+  $LocalVariable[[c]](0, 0, $LocalVariable[[val]]);
 }
 struct $Class_decl[[S]] {
   $Class_decl[[S]](int&) {
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -538,12 +538,20 @@
   return true;
 
 // FIXME ...here it would make sense though.
-if (isa(E))
-  return true;
+Expr **args = nullptr;
+unsigned numArgs = 0;
+if (const auto callOp = dyn_cast(E)) {
+  if (callOp->getOperator() != OO_Call)
+return true;
+  args = E->getArgs() + 1;
+  numArgs = E->getNumArgs() - 1;
+   

[PATCH] D128282: [WebAssembly] Update test to run it in opaque pointers mode

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

In D128282#3600355 , @tlively wrote:

> I think the lines still differ in that one tests wasm32 and the other tests 
> wasm64 (the triples are different).

Yeah, but the convention used elsewhere in this test file is to use 
`WEBASSEMBLY:` (which is a common check prefix for both wasm32 and wasm64 run 
lines) in the cases where the output is the same.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128282

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

[PATCH] D112916: [clang-tidy] Confusable identifiers detection

[Whisperity via Phabricator via cfe-commits]

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

LGTM. Thanks!


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

https://reviews.llvm.org/D112916

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

[PATCH] D127460: Rename GCCBuiltin into ClangBuiltin

[Guillaume Gomez via Phabricator via cfe-commits]

GuillaumeGomez marked an inline comment as done.
GuillaumeGomez added a comment.

Is there anything else for me to do in here so it gets merged? (Sorry if I 
missed it but I couldn't find out the exact merge process in the documentation)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127460

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

[PATCH] D127184: [clangd] Add to header map

[Florian Albrechtskirchinger via Phabricator via cfe-commits]

falbrechtskirchinger added a comment.

In D127184#3588226 , @nridge wrote:

> In D127184#3577165 , 
> @falbrechtskirchinger wrote:
>
>> bits/mofunc_impl.h
>
> I see this included from `bits/move_only_function.h`, so I think 
> `` would make sense for it.

Right. I somehow erroneously concluded that `bits/mofunc_impl.h` was replaced 
by `bits/move_only_function.h`.

>> bits/new_allocator.h
>
> I see this included from ``, we could add that. 
> (There are a few more implementation headers in `experimental/bits` which are 
> included by standard headers in `` that we could consider 
> adding.)

I did see that and excluded `> bits/specfun.h
>
> I see this included from ``.

I missed the C headers in general because I didn't realize that they're kept in 
a separate directory in the libstdc++ source tree. The difference between 
source and install tree has bitten me a few times.

>> I've seen `*.tcc` files being mapped and have identified the following 
>> missing files:
>> Should these be added as well?
>
> I think we can skip these as they only contain definitions, and code 
> completion should choose the file containing the declaration.

Then maybe we should just remove all `*.tcc` files instead? I may do so in a 
separate commit that can be discarded.

About some seemingly random mappings. There are more candidates. I'll handle 
those in a separate commit for easy review.

In D127184#3596339 , @sammccall wrote:

> Apologies for not getting to this before vacation, and thanks Nathan for 
> looking at this. (I'll leave for you to stamp)
>
> This is fine with me as-is, but I think this mapping shouldn't be our 
> *preferred* way to solve this problem, and should eventually go away.
>
> We also have a mapping of **symbol** names to headers (StdSymbols.inc). This 
> is obviously more portable, both in the sense that it works when editing 
> using e.g. MS STL etc, and that the results don't reflect quirks of the 
> stdlib you're using.
> The reason this mapping fails for `std::ranges::transform` is that the 
> mapping file was extracted from an old C++17 cppreference dump. The 
> cppreference format has changed so to run it on a newer dump it'd need some 
> updates.

With some additional pointers, I'd be happy to look into that next.

One more thing. What about extension headers (``)?
The current mappings are both very incomplete and also very wrong, or so I'd 
argue.
For example, `"ext/new_allocator.h"` maps to `` but should map to 
itself. It's not an internal header but a GNU extension to the C++ standard 
library.
I've identified and mapped about 50 headers in that category, but omitted the 
subdirectory ``.

  $ find ext/pb_ds -type f | wc -l
  243

That's a bit much for now.

I'll finish everything up as described within about a week.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127184

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

[PATCH] D128204: [clangd] Add fix-it for inserting IWYU pragma: keep

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

In D128204#3600973 , @kadircet wrote:

>> One of the main issues I have is due to templates not being instantiated 
>> which can result in symbols that are actually used not being picked up as 
>> the template instantiation that uses them isn't actually instantiated.
>
> I guess you're talking about having the template pattern in the main file, 
> but all the instantiations are in dependents of the code. My mental model was 
> around making the dependents have the include for the type, instead of having 
> it in the file providing the template pattern (header).  Does that make sense?
> This kind of breaks down when there's actually some types used by all the 
> instantiations, as you'd want them to be included by the header. But I think 
> we should be able to diagnose these cases, as usage of this type should be 
> non-dependent (at least in the cases I can think of), so this sounds like a 
> bug/improvement.

A specific example i encountered is `clang/Tooling/DiagnosticsYaml.h` Which 
defines template specializations for inputting/outputting yaml io. That file 
must be included if you ever want to emit diagnostics as YAML, but the typical 
use case is to just use the operator<< on a yaml stream. This function 
internally will use those specializations, but as clangd doesn't look into the 
function calls and expand all those instantiations, they are treated as being 
unused(There's many bugs already related to this) and as such the header is 
marked as being unused.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128204

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

[PATCH] D127446: [clang-tidy] Add `-verify-config` command line argument

[Nathan James via Phabricator via cfe-commits]

njames93 marked 4 inline comments as done.
njames93 added inline comments.



Comment at: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp:263
+Check the config files to ensure each check and
+option is recognised.
+)"),

aaron.ballman wrote:
> 
:)



Comment at: 
clang-tools-extra/test/clang-tidy/infrastructure/verify-config.cpp:12
+
+// CHECK-VERIFY-DAG: command-line option '-config': warning: Unknown Check 
'readability-else-after-ret'; did you mean 'readability-else-after-return'
+// CHECK-VERIFY-DAG: command-line option '-config': warning: Unknown Check 
Option 'modernize-lop-convert.UseCxx20ReverseRanges'; did you mean 
'modernize-loop-convert.UseCxx20ReverseRanges'

aaron.ballman wrote:
> It's unfortunate that `warning: ` appears in the middle of the diagnostic as 
> opposed to at the start. I wonder if this can be reworked to say: `warning: 
> Unknown check 'whatever'; did you mean 'whatever'? [-verify-config]` or 
> something?
> 
> Also, no test coverage for the error case and for the unknown check case 
> where there's no closest match worth talking about.
Warning appearing in the middle is kind of by design as when clang emits 
diagnostics, the source location is the first thing emitted, then the 
type(warning|error). In this case `command-line option '-config'` is the 
"source location"

> Also, no test coverage for the error case.
I'm not 100% on that, there is no checking when the check glob is actually 
built and I haven't figured out how to break it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127446

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

[PATCH] D127446: [clang-tidy] Add `-verify-config` command line argument

[Nathan James via Phabricator via cfe-commits]

njames93 updated this revision to Diff 438953.
njames93 marked an inline comment as done.
njames93 added a comment.

Address reviewer comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127446

Files:
  clang-tools-extra/clang-tidy/ClangTidy.cpp
  clang-tools-extra/clang-tidy/ClangTidy.h
  clang-tools-extra/clang-tidy/ClangTidyCheck.cpp
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h
  clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/index.rst
  clang-tools-extra/test/clang-tidy/infrastructure/verify-config.cpp

Index: clang-tools-extra/test/clang-tidy/infrastructure/verify-config.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/verify-config.cpp
@@ -0,0 +1,17 @@
+// RUN: clang-tidy -verify-config --config='' | FileCheck %s -check-prefix=CHECK-VERIFY-OK
+// CHECK-VERIFY-OK: No config errors detected.
+
+// RUN: not clang-tidy -verify-config \
+// RUN: --checks='-*,bad*glob,llvm*,llvm-includeorder,my-made-up-check' --config='{Checks: "readability-else-after-ret", \
+// RUN: CheckOptions: [{key: "IgnoreMacros", value: "true"}, \
+// RUN:{key: "StriceMode", value: "true"}, \
+// RUN:{key: modernize-lop-convert.UseCxx20ReverseRanges, value: true} \
+// RUN:   ]}' 2>&1 | FileCheck %s \
+// RUN: -check-prefix=CHECK-VERIFY -implicit-check-not='{{warning|error}}:'
+
+// CHECK-VERIFY-DAG: command-line option '-config': warning: unknown check 'readability-else-after-ret'; did you mean 'readability-else-after-return' [-verify-config]
+// CHECK-VERIFY-DAG: command-line option '-config': warning: unknown check option 'modernize-lop-convert.UseCxx20ReverseRanges'; did you mean 'modernize-loop-convert.UseCxx20ReverseRanges' [-verify-config]
+// CHECK-VERIFY-DAG: command-line option '-config': warning: unknown check option 'StriceMode'; did you mean 'StrictMode' [-verify-config]
+// CHECK-VERIFY: command-line option '-checks': warning: check glob 'bad*glob' doesn't match any known check [-verify-config]
+// CHECK-VERIFY: command-line option '-checks': warning: unknown check 'llvm-includeorder'; did you mean 'llvm-include-order' [-verify-config]
+// CHECK-VERIFY: command-line option '-checks': warning: unknown check 'my-made-up-check' [-verify-config]
Index: clang-tools-extra/docs/clang-tidy/index.rst
===
--- clang-tools-extra/docs/clang-tidy/index.rst
+++ clang-tools-extra/docs/clang-tidy/index.rst
@@ -244,6 +244,9 @@
 standard output supports colors.
 This option overrides the 'UseColor' option in
 .clang-tidy file, if any.
+--verify-config-
+ Check the config files to ensure each check and
+ option is recognized.
 --vfsoverlay=-
  Overlay the virtual filesystem described by file
  over the real file system.
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -110,6 +110,9 @@
   from suppressing diagnostics associated with macro arguments. This fixes
   `Issue 55134 `_.
 
+- Added an option -verify-config which will check the config file to ensure each
+  `Checks` and `CheckOptions` entries are recognised.
+
 New checks
 ^^
 
Index: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -19,6 +19,7 @@
 #include "../ClangTidyForceLinker.h"
 #include "../GlobList.h"
 #include "clang/Tooling/CommonOptionsParser.h"
+#include "llvm/ADT/StringSet.h"
 #include "llvm/Support/InitLLVM.h"
 #include "llvm/Support/PluginLoader.h"
 #include "llvm/Support/Process.h"
@@ -257,6 +258,12 @@
 )"),
   cl::init(false), cl::cat(ClangTidyCategory));
 
+static cl::opt VerifyConfig("verify-config", cl::desc(R"(
+Check the config files to ensure each check and
+option is recognized.
+)"),
+  cl::init(false), cl::cat(ClangTidyCategory));
+
 namespace clang {
 namespace tidy {
 
@@ -385,6 +392,74 @@
   return FS;
 }
 
+static StringRef closest(StringRef Value, const StringSet<> &Allowed) {
+  unsigned MaxEdit = 5U;
+  StringRef Closest;
+  for (auto Item : Allowed.keys()) {
+unsigned Cur = Value.edit_distance_insensitive(Item, true, MaxEdit);
+ 

[PATCH] D127460: Rename GCCBuiltin into ClangBuiltin

[Simon Pilgrim via Phabricator via cfe-commits]

RKSimon added a comment.

It looks like this is good to go - do you have commit access?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127460

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

[PATCH] D127460: Rename GCCBuiltin into ClangBuiltin

[Guillaume Gomez via Phabricator via cfe-commits]

GuillaumeGomez added a comment.

This is my first LLVM contribution so I don't think I do? If I do have a commit 
access anyway, do you have a link to the documentation where it explains what 
I'm supposed to do by any chance?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127460

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

[PATCH] D126859: [clangd] Validate clang-tidy CheckOptions in clangd config

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

In D126859#3599340 , @kadircet wrote:

> I also agree with the typo correction verdict. In theory there'll be two 
> cases:
>
> - typo correction helps,  in which case it'll be obvious from the warning 
> itself.
> - typo correction doesn't help, because the option doesn't exist at all, 
> we'll be just showing a random option. I don't think how this'll be helpful.
>
> So I don't think this is providing much of a value compared to the extra 
> logic.

The correction only shows near misses, so it wouldn't show completely random 
options.
However it's only really there to prevent you having to look at the 
documentation for the check, so I'm happy to remove it.




Comment at: clang-tools-extra/clangd/TidyProvider.cpp:291
+  static void *call() {
+return new tidy::NamesAndOptions(tidy::getAllChecksAndOptions(false));
+  }

kadircet wrote:
> sammccall wrote:
> > it seems strange that clang-tidy provides this API to query what checks are 
> > linked in, but it constructs an expensive object every time rather than 
> > just creating a static one once and returning a reference to it. (i.e. the 
> > memoization is on the caller side)
> > Should we fix that API instead?
> +1
The clang-tidy API is still a WIP. but it doesn't really make sense to memoize 
it on the tidy side as its s function that is only ever going to be called once 
in clang-tidy.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126859

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

[PATCH] D127460: Rename GCCBuiltin into ClangBuiltin

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 requested changes to this revision.
xbolva00 added a comment.
This revision now requires changes to proceed.

Patch description needs to be added, especially answer the question why we 
should rename it, why we want it..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127460

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

[PATCH] D128314: [Clang-tidy] Fixing bugs in clang-tidy infinite-loop checker

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

Can this patch be split in two, it seems strange to be fixing 2 unrelated bugs 
in one patch.
One fix for the ObjC nodes and another for the patch for the static local 
variables.

Also please can you run git clang-format over this patch.




Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:167-172
+if (const Decl * Callee = Call->getDirectCallee()) {
+const Decl * CanoCallee = Callee->getCanonicalDecl();
+
+Callees.insert(CanoCallee);
+} else
+return false; // unresolved call

nit:



Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:175-180
+if (const ObjCMethodDecl * Callee = Call->getMethodDecl()) {
+const Decl * CanoCallee = Callee->getCanonicalDecl();
+
+Callees.insert(CanoCallee);
+} else
+return false; // unresolved call

Nit: as above



Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:182-187
+for (const Stmt * Child : StmtNode->children())
+if (Child && populateCallees(Child, Callees))
+continue;
+else
+return false;
+return true;

Nit:

Also sometimes, some of the stmts in children can be null and that's expected, 
is there any reason we are disregarding that case.



Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:198-208
+for (llvm::ArrayRef::iterator EltI = SCC.begin(),
+  EltE = SCC.end();
+ EltI != EltE; ++EltI) {
+CallGraphNode * GNode = *EltI;
+const Decl * CanoDecl = GNode->getDecl()->getCanonicalDecl();
+
+containsFunc |= CanoDecl == Func;

This can be rewritten as a range for 
```lang=c++
for (CallGraphNode* GNode : SCC) ...```



Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:204
+
+containsFunc |= CanoDecl == Func;
+overlap |= Callees.contains(CanoDecl);





Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:218-221
+for (const Stmt * Child : Cond->children())
+if (Child && hasStaticLocalVariable(Child))
+return true;
+return false;




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128314

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

[PATCH] D127460: Rename GCCBuiltin into ClangBuiltin

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

In D127460#3601152 , @GuillaumeGomez 
wrote:

> This is my first LLVM contribution so I don't think I do? If I do have a 
> commit access anyway, do you have a link to the documentation where it 
> explains what I'm supposed to do by any chance?

https://llvm.org/docs/DeveloperPolicy.html#id17


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127460

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

[PATCH] D127270: [clang-format] Add space in placement new expression

[omar ahmed via Phabricator via cfe-commits]

omarahmed updated this revision to Diff 438962.
omarahmed added a comment.

Format files


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127270

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/tools/dump_format_style.py
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -10130,6 +10130,42 @@
 "void delete(link p);\n",
 format("void new (link p);\n"
"void delete (link p);\n"));
+
+  FormatStyle AfterPlacementOperator = getLLVMStyle();
+  AfterPlacementOperator.SpaceBeforeParens = FormatStyle::SBPO_Custom;
+  EXPECT_EQ(
+  AfterPlacementOperator.SpaceBeforeParensOptions.AfterPlacementOperator,
+  FormatStyle::SpaceBeforeParensCustom::APO_Leave);
+  EXPECT_EQ("new (buf) int;", format("new (buf) int;", AfterPlacementOperator));
+  EXPECT_EQ("new(buf) int;", format("new(buf) int;", AfterPlacementOperator));
+
+  AfterPlacementOperator.SpaceBeforeParensOptions.AfterPlacementOperator =
+  FormatStyle::SpaceBeforeParensCustom::APO_Never;
+  verifyFormat("struct A {\n"
+   "  int *a;\n"
+   "  A(int *p) : a(new(p) int) {\n"
+   "new(p) int;\n"
+   "int *b = new(p) int;\n"
+   "int *c = new(p) int(3);\n"
+   "delete(b);\n"
+   "  }\n"
+   "};",
+   AfterPlacementOperator);
+  verifyFormat("void operator new(void *foo) ATTRIB;", AfterPlacementOperator);
+
+  AfterPlacementOperator.SpaceBeforeParensOptions.AfterPlacementOperator =
+  FormatStyle::SpaceBeforeParensCustom::APO_Always;
+  verifyFormat("struct A {\n"
+   "  int *a;\n"
+   "  A(int *p) : a(new (p) int) {\n"
+   "new (p) int;\n"
+   "int *b = new (p) int;\n"
+   "int *c = new (p) int(3);\n"
+   "delete (b);\n"
+   "  }\n"
+   "};",
+   AfterPlacementOperator);
+  verifyFormat("void operator new(void *foo) ATTRIB;", AfterPlacementOperator);
 }
 
 TEST_F(FormatTest, UnderstandsUsesOfStarAndAmp) {
@@ -20308,6 +20344,24 @@
   SpaceBeforeParens,
   FormatStyle::SBPO_ControlStatementsExceptControlMacros);
 
+  Style.SpaceBeforeParens = FormatStyle::SBPO_Custom;
+  Style.SpaceBeforeParensOptions.AfterPlacementOperator =
+  FormatStyle::SpaceBeforeParensCustom::APO_Always;
+  CHECK_PARSE("SpaceBeforeParensOptions:\n"
+  "  AfterPlacementOperator: Never",
+  SpaceBeforeParensOptions.AfterPlacementOperator,
+  FormatStyle::SpaceBeforeParensCustom::APO_Never);
+
+  CHECK_PARSE("SpaceBeforeParensOptions:\n"
+  "  AfterPlacementOperator: Always",
+  SpaceBeforeParensOptions.AfterPlacementOperator,
+  FormatStyle::SpaceBeforeParensCustom::APO_Always);
+
+  CHECK_PARSE("SpaceBeforeParensOptions:\n"
+  "  AfterPlacementOperator: Leave",
+  SpaceBeforeParensOptions.AfterPlacementOperator,
+  FormatStyle::SpaceBeforeParensCustom::APO_Leave);
+
   Style.ColumnLimit = 123;
   FormatStyle BaseStyle = getLLVMStyle();
   CHECK_PARSE("BasedOnStyle: LLVM", ColumnLimit, BaseStyle.ColumnLimit);
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3393,6 +3393,18 @@
 if (Left.is(TT_IfMacro))
   return Style.SpaceBeforeParensOptions.AfterIfMacros ||
  spaceRequiredBeforeParens(Right);
+if (Style.SpaceBeforeParens == FormatStyle::SBPO_Custom &&
+Left.isOneOf(tok::kw_new, tok::kw_delete) &&
+Right.isNot(TT_OverloadedOperatorLParen) &&
+!(Line.MightBeFunctionDecl && Left.is(TT_FunctionDeclarationName))) {
+  if (Style.SpaceBeforeParensOptions.AfterPlacementOperator ==
+  FormatStyle::SpaceBeforeParensCustom::APO_Always ||
+  (Style.SpaceBeforeParensOptions.AfterPlacementOperator ==
+   FormatStyle::SpaceBeforeParensCustom::APO_Leave &&
+   Right.hasWhitespaceBefore()))
+return true;
+  return false;
+}
 if (Line.Type == LT_ObjCDecl)
   return true;
 if (Left.is(tok::semi))
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -936,6 +936,7 @@
Spacing.AfterFunctionDeclarationName);
 IO.mapOptional("AfterIfMacros", Spacing.AfterIfMacros);
 IO.mapOptional("AfterOverloade

[PATCH] D127446: [clang-tidy] Add `-verify-config` command line argument

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/infrastructure/verify-config.cpp:12
+
+// CHECK-VERIFY-DAG: command-line option '-config': warning: Unknown Check 
'readability-else-after-ret'; did you mean 'readability-else-after-return'
+// CHECK-VERIFY-DAG: command-line option '-config': warning: Unknown Check 
Option 'modernize-lop-convert.UseCxx20ReverseRanges'; did you mean 
'modernize-loop-convert.UseCxx20ReverseRanges'

njames93 wrote:
> aaron.ballman wrote:
> > It's unfortunate that `warning: ` appears in the middle of the diagnostic 
> > as opposed to at the start. I wonder if this can be reworked to say: 
> > `warning: Unknown check 'whatever'; did you mean 'whatever'? 
> > [-verify-config]` or something?
> > 
> > Also, no test coverage for the error case and for the unknown check case 
> > where there's no closest match worth talking about.
> Warning appearing in the middle is kind of by design as when clang emits 
> diagnostics, the source location is the first thing emitted, then the 
> type(warning|error). In this case `command-line option '-config'` is the 
> "source location"
> 
> > Also, no test coverage for the error case.
> I'm not 100% on that, there is no checking when the check glob is actually 
> built and I haven't figured out how to break it.
>  then the type(warning|error). In this case command-line option '-config' is 
> the "source location"

Ah, thanks for explaining your logic. FWIW, Clang uses a different style for 
that (``): https://godbolt.org/z/f1rdsbjqe Perhaps we should 
follow suit? (In fact, we could use the diagnostic engine for this instead of 
emitting to the error stream ourselves?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127446

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

[PATCH] D128333: [clang][flang] Disable defaulting to `-fpie` for LLVM Flang

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski created this revision.
awarzynski added reviewers: rovka, MaskRay, schweitz, Leporacanthicus.
Herald added subscribers: jsji, StephenFan, pengfei, kristof.beyls.
Herald added a reviewer: sscalpone.
Herald added projects: Flang, All.
awarzynski requested review of this revision.
Herald added subscribers: cfe-commits, jdoerfert.
Herald added a project: clang.

In, https://reviews.llvm.org/D120305, CLANG_DEFAULT_PIE_ON_LINUX was set
to `On` by default. However, neither `-fpie` nor `-fpic` are currently
supported in LLVM Flang. Hence, in this patch the behaviour controlled
with CLANG_DEFAULT_PIE_ON_LINUX is refined not to apply to Flang.

Another way to look at this is that CLANG_DEFAULT_PIE_ON_LINUX is
currently affecting both Clang and Flang. IIUC, the intention for this
CMake variable has always been to only affect Clang. This patch makes
sure that that's the case.

Without this change, you might see errors like this on X86_64:

  /usr/bin/ld: main.o: relocation R_X86_64_32 against `.bss' can not be used 
when making a PIE object; recompile with -fPIC

I've not experienced any issues on AArch64. That's probably because on
AArch64 some object files happen to be position independent without
needing -fpie or -fpic.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128333

Files:
  clang/lib/Driver/ToolChains/Linux.cpp
  flang/test/Driver/no-pie.f90


Index: flang/test/Driver/no-pie.f90
===
--- /dev/null
+++ flang/test/Driver/no-pie.f90
@@ -0,0 +1,12 @@
+! Verify that in contrast to Clang, Flang does not default to generating 
position independent executables/code
+
+!-
+! RUN COMMANDS
+!-
+! RUN: %flang -### -flang-experimental-exec %S/Inputs/hello.f90 2>&1 | 
FileCheck %s
+
+!
+! EXPECTED OUTPUT
+!
+! CHECK-NOT: fpie
+! CHECK-NOT: fpic
Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -699,8 +699,9 @@
 }
 
 bool Linux::isPIEDefault(const llvm::opt::ArgList &Args) const {
-  return CLANG_DEFAULT_PIE_ON_LINUX || getTriple().isAndroid() ||
- getTriple().isMusl() || getSanitizerArgs(Args).requiresPIE();
+  return !getDriver().IsFlangMode() &&
+ (CLANG_DEFAULT_PIE_ON_LINUX || getTriple().isAndroid() ||
+  getTriple().isMusl() || getSanitizerArgs(Args).requiresPIE());
 }
 
 bool Linux::IsAArch64OutlineAtomicsDefault(const ArgList &Args) const {


Index: flang/test/Driver/no-pie.f90
===
--- /dev/null
+++ flang/test/Driver/no-pie.f90
@@ -0,0 +1,12 @@
+! Verify that in contrast to Clang, Flang does not default to generating position independent executables/code
+
+!-
+! RUN COMMANDS
+!-
+! RUN: %flang -### -flang-experimental-exec %S/Inputs/hello.f90 2>&1 | FileCheck %s
+
+!
+! EXPECTED OUTPUT
+!
+! CHECK-NOT: fpie
+! CHECK-NOT: fpic
Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -699,8 +699,9 @@
 }
 
 bool Linux::isPIEDefault(const llvm::opt::ArgList &Args) const {
-  return CLANG_DEFAULT_PIE_ON_LINUX || getTriple().isAndroid() ||
- getTriple().isMusl() || getSanitizerArgs(Args).requiresPIE();
+  return !getDriver().IsFlangMode() &&
+ (CLANG_DEFAULT_PIE_ON_LINUX || getTriple().isAndroid() ||
+  getTriple().isMusl() || getSanitizerArgs(Args).requiresPIE());
 }
 
 bool Linux::IsAArch64OutlineAtomicsDefault(const ArgList &Args) const {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126694: [C++20][Modules] Implementation of GMF decl elision.

[Iain Sandoe via Phabricator via cfe-commits]

iains updated this revision to Diff 438968.
iains marked 2 inline comments as done.
iains added a comment.

reabsed onto latest version of D113545 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126694

Files:
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Decl.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaModule.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaStmtAsm.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/test/AST/ast-dump-decl.c
  clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
  clang/test/Modules/cxx-templates.cpp
  clang/test/Modules/cxx20-10-4-ex2.cpp
  clang/test/Modules/explicitly-specialized-template.cpp
  clang/test/Modules/template-function-specialization.cpp

Index: clang/test/Modules/template-function-specialization.cpp
===
--- clang/test/Modules/template-function-specialization.cpp
+++ clang/test/Modules/template-function-specialization.cpp
@@ -51,7 +51,9 @@
   foo2(); // expected-error {{missing '#include'; 'foo2' must be declared before it is used}}
  // expected-note@* {{declaration here is not visible}}
   foo2();   // expected-error {{missing '#include'; 'foo2' must be declared before it is used}}
+ // expected-error@-1 {{missing '#include'; explicit specialization of 'foo2' must be declared before it is used}}
  // expected-note@* {{declaration here is not visible}}
+ // expected-note@* {{explicit specialization declared here is not reachable}}
   foo3();
   foo3();
 
Index: clang/test/Modules/explicitly-specialized-template.cpp
===
--- clang/test/Modules/explicitly-specialized-template.cpp
+++ clang/test/Modules/explicitly-specialized-template.cpp
@@ -42,6 +42,6 @@
 foo f; // expected-error {{'foo' must be declared before it is used}}
 // expected-note@* {{declaration here is not visible}}
 int bar() {
-  X x;
-  return x.print();
+  X y;
+  return y.print();
 }
Index: clang/test/Modules/cxx20-10-4-ex2.cpp
===
--- /dev/null
+++ clang/test/Modules/cxx20-10-4-ex2.cpp
@@ -0,0 +1,60 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+
+// RUN: %clang_cc1 -std=c++20 std-10-4-ex2-interface.cpp \
+// RUN:  -emit-module-interface -o M.pcm -Wno-unused-value
+// RUN: %clang_cc1 -std=c++20 std-10-4-ex2-implementation.cpp \
+// RUN:  -fmodule-file=M.pcm -fsyntax-only -verify
+//--- std-10-4-ex2.h
+
+namespace N {
+struct X {};
+int d();
+int e();
+inline int f(X, int = d()) { return e(); }
+int g(X);
+int h(X);
+} // namespace N
+
+//--- std-10-4-ex2-interface.cpp
+
+module;
+
+#include "std-10-4-ex2.h"
+
+export module M;
+
+template  int use_f() {
+  N::X x;   // N::X, N, and  ::  are decl-reachable from use_f
+  return f(x, 123); // N::f is decl-reachable from use_f,
+// N::e is indirectly decl-reachable from use_f
+//   because it is decl-reachable from N::f, and
+// N::d is decl-reachable from use_f
+//   because it is decl-reachable from N::f
+//   even though it is not used in this call
+}
+
+template  int use_g() {
+  N::X x; // N::X, N, and :: are decl-reachable from use_g
+  return g((T(), x)); // N::g is not decl-reachable from use_g
+}
+
+template  int use_h() {
+  N::X x; // N::X, N, and :: are decl-reachable from use_h
+  return h((T(), x)); // N::h is not decl-reachable from use_h, but
+  // N::h is decl-reachable from use_h
+}
+
+int k = use_h();
+// use_h is decl-reachable from k, so
+// N::h is decl-reachable from k
+
+//--- std-10-4-ex2-implementation.cpp
+
+module M;
+
+int a = use_f();
+int b = use_g(); // expected-er...@std-10-4-ex2-interface.cpp:20 {{use of undeclared identifier 'g'}}
+  // expected-note@-1 {{in instantiation of function template specialization 'use_g' requested here}}
+int c = use_h();
Index: clang/test/Modules/cxx-templates.cpp
===
--- clang/test/Modules/cxx-templates.cpp
+++ clang/test/Modules/cxx-templates.cpp
@@ -252,7 +252,7 @@
 // CHECK-DUMP:  ClassTemplateDecl {{.*}} <{{.*[/\\]}}cxx-templates-common.h:1:1, {{.*}}>  col:{{.*}} in cxx_templates_common SomeTemplate
 // CHECK-DUMP:ClassTemplateSpecializationDecl {{.*}} prev {{.*}} SomeT

[PATCH] D128333: [clang][flang] Disable defaulting to `-fpie` for LLVM Flang

[Kiran Chandramohan via Phabricator via cfe-commits]

kiranchandramohan added a comment.

Is the longer-term plan to support this in Flang as well? 
Does this affect building object files too or is it just the executable? How 
would this affect mixed C++/Fortran programs if the Clang and Flang settings 
are different?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128333

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

[PATCH] D128297: [pseudo] Track heads as GSS nodes, rather than as "pending actions".

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

Thanks, this looks a reasonable change to me.




Comment at: clang-tools-extra/pseudo/include/clang-pseudo/GLR.h:140
+  const ForestNode &NextTok, const ParseParams &Params,
+  std::vector &NewHeads);
+// Applies available reductions on Heads, appending resulting heads to the 
list.

nit: change NewHeads to a pointer? it seems clearer that NewHeads is the output 
of the function from the caller side `glrShift(OldHeads, ..., &NewHeads)`.

I think it would be clearer if glrShift just returns NewHeads, but I understand 
we want to avoid temporary object for performance reasons. 



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/grammar/LRTable.h:132
   StateID getGoToState(StateID State, SymbolID Nonterminal) const;
+  llvm::Optional getShiftState(StateID State, SymbolID Terminal) 
const;
 

the function signature (return type) of `getGotoState` and `getShiftState` is 
not symmetry, it is fine and by design (we never all getGoToState on an invalid 
Nonterminal, it is guaranteed by the LR parser, but we might call getShiftState 
on a dead head). It is probably worth a comment explicitly specifying the 
difference.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:67
+   G.symbolName(Terminals[I].symbol()), 
Terminals[I].symbol()));
+glrShift(Heads, Terminals[I], Params, NextHeads);
+std::swap(Heads, NextHeads);

I can see the benefit of keep them tight in the loop (and doing a shift before 
reduce), but I found the code is a bit confusing, it took me a while to 
understand.

- the concept `Heads` and `NextHeads` are different for glrShift, and glrReduce 
-- The NextHeads returned by the glrShift should be the Heads used in 
glrReduce, so I was confused when reading `glrReduce(Heads)` the code at first 
glance -- until I realized that there is a `swap(Heads, NextHeads)` on L68...
- it seems a little weird that at the end of the loop, we do a cleanup on 
NextHeads directly (I would image there is a `swap(Head, NextHead)` and then 
cleanup)

Instead of naming the two lists as `Heads` and `NewHeads`, how about naming 
them `HeadsForShift` (or `ShiftHeads`) and `HeadsForReduce`? the code would 
look like

```
for ( ... ) {
  glrShift(HeadsForShift, ..., &HeadsForReduce);
  
  glrReduce(HeadsForReduce, ..., &HeadsForShift);
}
```

It looks clearer to me.






Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:69
+std::swap(Heads, NextHeads);
+SymbolID Lookahead = I + 1 == Terminals.size() ? tokenSymbol(tok::eof)
+   : Terminals[I + 1].symbol();

I'd probably leave a blank line deliberately after glrShift, because the 
glrReduce work on the *next* I+1 token.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:111
+  const ForestNode &NewTok, const ParseParams &Params,
+  std::vector &NewHeads) {
   assert(NewTok.kind() == ForestNode::Terminal);

nit: add a `NewHeads.empty` assertion? 



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:200
 // 0--5(pointer)   // 5 is goto(0, pointer)
-void glrReduce(std::vector &PendingReduce, const ParseParams 
&Params,
-   NewHeadCallback NewHeadCB) {
+void glrReduce(std::vector &Heads, SymbolID Lookahead,
+   const ParseParams &Params) {

IIRC, in glrReduce, we only append newly-created GSS nodes in Heads, and never 
to do deleting, so the Heads will end up with lots of unnecessary heads (heads 
created for reduces), and we will call `getShiftState` on them. 

We know that after glrReduce, active heads are heads with available shift 
actions, so we can optimize it further, we could just use a vector 
which just contains active heads , this could be done in the popPending. I 
think it will increase the performance by reducing the number of unnecessary 
heads.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:264
+  // PoppedHeads is our position within it.
+  unsigned PoppedHeads = 0;
   // Pop walks up the parent chain(s) for a reduction from Head by to Rule.

might be name it PoppedHeadIndex?



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:360
 
   // Invoking the callback for new heads, a real GLR parser may add new
   // reduces to the PendingReduce queue!

the comment is stale now.



Comment at: clang-tools-extra/pseudo/lib/grammar/LRTable.cpp:78
+  assert(pseudo::isToken(Terminal) && "expected terminal symbol!");
+  for (const auto &Result : find(State, Terminal))
+if (Result.kind() == Action::Shift)

instead of using find directly, just use `getActions()`.



Comment at: clang-tools-extra/pseudo/lib/grammar/LRTable.cpp:79
+  for (const auto &Result : find(Stat

[PATCH] D127976: [IR] Move vector.insert/vector.extract out of experimental namespace

[Bradley Smith via Phabricator via cfe-commits]

bsmith updated this revision to Diff 438975.
bsmith added a comment.

- Further improve clarity on usable types in LangRef


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127976

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vget.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vlmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vset.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vget.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vset.c
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.cpp
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_dupq-bfloat.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_dupq.c
  clang/test/CodeGen/aarch64-sve-vls-arith-ops.c
  clang/test/CodeGen/aarch64-sve-vls-bitwise-ops.c
  clang/test/CodeGen/aarch64-sve-vls-compare-ops.c
  clang/test/CodeGen/aarch64-sve-vls-shift-ops.c
  clang/test/CodeGen/aarch64-sve-vls-subscript-ops.c
  
clang/test/CodeGen/aarch64_neon_sve_bridge_intrinsics/acle_neon_sve_bridge_dup_neonq.c
  
clang/test/CodeGen/aarch64_neon_sve_bridge_intrinsics/acle_neon_sve_bridge_get_neonq.c
  
clang/test/CodeGen/aarch64_neon_sve_bridge_intrinsics/acle_neon_sve_bridge_set_neonq.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-bitcast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-codegen.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-globals.c
  llvm/docs/LangRef.rst
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/CodeGen/BasicTTIImpl.h
  llvm/include/llvm/IR/IRBuilder.h
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/Analysis/InstructionSimplify.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/IR/AutoUpgrade.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
  llvm/lib/Target/AArch64/SVEIntrinsicOpts.cpp
  llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
  llvm/test/Analysis/CostModel/AArch64/sve-intrinsics.ll
  llvm/test/Analysis/CostModel/RISCV/rvv-shuffle.ll
  llvm/test/Bitcode/upgrade-vector-insert-extract-intrinsics.ll
  llvm/test/Bitcode/upgrade-vector-insert-extract-intrinsics.ll.bc
  llvm/test/CodeGen/AArch64/dag-combine-insert-subvector.ll
  llvm/test/CodeGen/AArch64/insert-subvector-res-legalization.ll
  llvm/test/CodeGen/AArch64/split-vector-insert.ll
  llvm/test/CodeGen/AArch64/sve-extract-fixed-from-scalable-vector.ll
  llvm/test/CodeGen/AArch64/sve-extract-fixed-vector.ll
  llvm/test/CodeGen/AArch64/sve-extract-scalable-vector.ll
  llvm/test/CodeGen/AArch64/sve-extract-vector-to-predicate-store.ll
  llvm/test/CodeGen/AArch64/sve-fixed-length-extract-subvector.ll
  llvm/test/CodeGen/AArch64/sve-insert-vector-to-predicate-load.ll
  llvm/test/CodeGen/AArch64/sve-insert-vector.ll
  llvm/test/CodeGen/AArch64/sve-no-typesize-warnings.ll
  llvm/test/CodeGen/AArch64/sve-punpklo-combine.ll
  llvm/test/CodeGen/AArch64/sve-vecreduce-fold.ll
  llvm/test/CodeGen/RISCV/rvv/extract-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-extract-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-insert-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/insert-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/mgather-sdnode.ll
  llvm/test/CodeGen/RISCV/rvv/mscatter-sdnode.ll
  llvm/test/CodeGen/RISCV/rvv/vpload.ll
  llvm/test/Transforms/InstCombine/AArch64/sve-intrinsic-opts-cmpne.ll
  llvm/test/Transforms/InstCombine/canonicalize-vector-extract.ll
  llvm/test/Transforms/InstCombine/canonicalize-vector-insert.ll
  llvm/test/Transforms/InstSimplify/extract-vector.ll
  llvm/test/Transforms/InstSimplify/insert-vector.ll
  llvm/test/Transforms/InterleavedAccess/AArch64/sve-interleaved-accesses.ll
  llvm/test/Verifier/extract-vector-mismatched-element-types.ll
  llvm/test/Verifier/insert-extract-intrinsics-invalid.ll
  llvm/test/Verifier/insert-vector-mismatched-element-types.ll

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

[PATCH] D128059: [Clang] Add a warning on invalid UTF-8 in comments.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Lex/Lexer.cpp:2702-2703
 // (probably ending) '/' character.
-if (CurPtr + 24 < BufferEnd &&
+// When diagnosing invalid UTF-8 sequences we always skip the fast
+// vectorized path.
+if (!WarnOnInvalidUtf8 && CurPtr + 24 < BufferEnd &&

However, *this* seems like it could noticeably impact performance, especially 
for C code (including C header files in C++ mode), and may be worth getting 
measurements for.



Comment at: clang/lib/Lex/Lexer.cpp:2399
+  getSourceLocation(CurPtr));
+  bool UnicodeDecodeFailed = false;
+

cor3ntin wrote:
> aaron.ballman wrote:
> > It looks like this can move into the `while` loop and we can remove some `= 
> > false` from within the loop?
> The idea here is to not diagnose a contiguous sequence of invalid code units 
> more than once
> The sequence  `0x80x0x80x80` for example will only warn one for example. The 
> goal is to avoid noise when, for example there is a long comment in 
> Windows-1251 encoded cyrillic. it would warn one per word (because the spaces 
> would decode fine) rather than one per contiguous non-sense character.
> It's also somewhat necessary because we can't know where the end of the 
> invalid "character" is, better to be greedy. 
> (The test file check that behavior)
Oh derp, you're right (of course), sorry for the noise!



Comment at: clang/lib/Lex/Lexer.cpp:2407
+// diagnostic only once per sequence that cannot be decoded.
+while ((!WarnOnInvalidUtf8 || isASCII(C)) && C != 0 && // Potentially EOF.
+   C != '\n' && C != '\r') { // Newline or DOS-style newline.

cor3ntin wrote:
> aaron.ballman wrote:
> > Do you have some idea of performance cost for enabling the warning with a 
> > large TU? Are we talking .5%? 1%? 5%? noise?
> This adds 2 comparisons when the warning is enbled (is ASCII(c) is simply `C 
> < 0x80`) - so it should be noise, but I have not run benchmark.
> It might be more noticeable within multi line comments as there the 
> optimization that vectorizes the comment skipping on SSE2 platforms is simply 
> skipped when this optimization is enabled.
Ah, no need to run the benchmark then, I was thinking this would involve 
function call overhead and more complex checking for the `isASCII` call than 
exists in reality.



Comment at: clang/lib/Lex/Lexer.cpp:2417
+  if (Length == 0) {
+if (!UnicodeDecodeFailed) {
+  Diag(CurPtr, diag::warn_invalid_utf8_in_comment);

cor3ntin wrote:
> aaron.ballman wrote:
> > aaron.ballman wrote:
> > > 
> > So if unicode decoding didn't fail... diagnose? :-) The naming here seems 
> > unfortunate.
> `if(!UnicodeDecodeFailedInThePreviousLoopIteration)` ? I'm open to suggestion 
> here
`UnicodeDecodingAlreadyDiagnosed`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128059

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

[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D127923#3600422 , @vangthao wrote:

> In D127923#3599451 , @aaron.ballman 
> wrote:
>
>> Is there a reason the remarks can't use individual diagnostic emissions to 
>> simulate newlines? Or is this perhaps a demonstration that the remarks 
>> should not be using the diagnostic engine at all and should be emitting 
>> their output to a user-controllable stream (or file)?
>
> An issue with using multiple diagnostic emissions to simulate newlines is 
> that there are repeated information such as diagnostic location and diagopts 
> reprinted for each line. This creates a lot of noise and makes the output 
> harder to read.

I can see how that's the case if the prefix information is different with each 
diagnostic line, but if they're all repeating the same prefix, that noise 
should be lessened by quite a bit (and for those truly distracted by it, using 
the same prefix each time makes it easier to strip the prefix in an editor). 
e.g.,

  remark: foo.cl:27:0: 6 instructions in function
  remark: foo.cl:27:0: Kernel Name: test_kernel
  remark: foo.cl:27:0: SGPRs: 24
  remark: foo.cl:27:0: VGPRs: 9
  remark: foo.cl:27:0: AGPRs: 43
  remark: foo.cl:27:0: ScratchSize [bytes/thread]: 0
  remark: foo.cl:27:0: Occupancy [waves/SIMD]: 5
  remark: foo.cl:27:0: SGPRs Spill: 0
  remark: foo.cl:27:0: VGPRs Spill: 0
  remark: foo.cl:27:0: LDS Size [bytes/block]: 512
  remark: foo.cl:27:0: --

doesn't look that terrible to me because all the salient information is 
visually aligned. (Line wrapping would be an issue, but the same is true for 
line wrapping mixed with manual newlines.) Do you have the ability to control 
the location of the diagnostic so you can keep the prefix the same throughout 
the report (or use the same prefix within a notional "section" of the report so 
that blocks of related remarks are visually grouped with the same prefix)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127923

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

[PATCH] D128333: [clang][flang] Disable defaulting to `-fpie` for LLVM Flang

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski added a comment.

In D128333#3601299 , 
@kiranchandramohan wrote:

> Is the longer-term plan to support this in Flang as well?

I don't see why not. AFAIK, the switch in Clang took a while and happened 
gradually - so we probably shouldn't rush this in Flang. We'd also need to 
check the behavior in `gfortran` (so that we maintain consistency).

> Does this affect building object files too or is it just the executable?

Just the executable.

AFAIK, `isPIEDefault` is only used in tools::ParsePICArgs 

 . In Flang, we don't support any of `-fpic/-fPIC/-fpie/-fPIE`. And 
`CLANG_DEFAULT_PIE_ON_LINUX` leads to `-fpie` being added by default to the 
final linker invocation (when generating the executable). But that doesn't make 
sense if the object files were generated with `-fpic`. Hence the change.

> How would this affect mixed C++/Fortran programs if the Clang and Flang 
> settings are different?

Good question! We've not experimented with mixed C++/Fortran programs enough, 
so I don't have an answer. But we should probably create a GitHub ticket to 
restore consistency between Clang and Flang.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128333

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

[PATCH] D128207: [clang-doc][NFC] Fix reference invalidation assertion failure.

[liushuai wang via Phabricator via cfe-commits]

MTC added a comment.

Sorry for the delayed response. Adding the regression test is not as simple as 
I thought, **first of all clang-tools-extra does not enable the //assert//**, 
see 
https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/test/lit.site.cfg.py.in
 . And add the clang-doc when enable `--format=html` is little bit of tricky.

> Also, I wonder if assign could/should add logic to be resilient to this.

Eventhough `destroy_range()` does nothing for now, there are indeed potential 
risks.

  void assign(in_iter in_start, in_iter in_end) {
this->assertSafeToReferenceAfterClear(in_start, in_end);
clear();
append(in_start, in_end);
  }
  void clear() {
this->destroy_range(this->begin(), this->end());
this->Size = 0;
  }


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D128207

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

[PATCH] D127487: [Sema] Fix assertion failure when instantiating requires expression

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov updated this revision to Diff 438977.
ilya-biryukov added a comment.

- Update test, check error messages


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127487

Files:
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/test/SemaTemplate/concepts-PR54629.cpp

Index: clang/test/SemaTemplate/concepts-PR54629.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/concepts-PR54629.cpp
@@ -0,0 +1,58 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+
+template 
+struct A {
+  void primary();
+};
+
+template 
+  requires requires(T &t) { requires sizeof(t) > 4; }
+struct A {
+  void specialization1();
+};
+
+template 
+  requires requires(T &t) { requires sizeof(t) > 8; }
+struct A {
+  void specialization2();
+};
+
+int main() {
+  A().primary();
+  A().specialization1();
+  A(); // expected-error {{ambiguous partial specialization}}
+ // expected-note@10 {{partial specialization matches [with T = char[16]}}
+ // expected-note@16 {{partial specialization matches [with T = char[16]}}
+}
+
+// Check error messages when no overload with constraints matches.
+template 
+void foo()
+  requires requires(T &t) { requires sizeof(t) < 4; }
+{}
+
+template 
+void foo()
+  requires requires(T &t) { requires sizeof(t) > 4; }
+{}
+
+template 
+void foo()
+  requires requires(T &t) { requires sizeof(t) > 8; }
+{}
+
+void test() {
+  foo();
+  // expected-error@-1 {{no matching function for call to 'foo'}}
+  // expected-note@31 {{candidate template ignored: constraints not satisfied}}
+  // expected-note@32 {{because 'sizeof (t) < 4' (4 < 4) evaluated to false}}
+  // expected-note@36 {{candidate template ignored: constraints not satisfied}}
+  // expected-note@37 {{because 'sizeof (t) > 4' (4 > 4) evaluated to false}}
+  // expected-note@41 {{candidate template ignored: constraints not satisfied}}
+  // expected-note@42 {{because 'sizeof (t) > 8' (4 > 8) evaluated to false}}
+
+  foo();
+  // expected-error@-1 {{call to 'foo' is ambiguous}}
+  // expected-note@36 {{candidate function}}
+  // expected-note@41 {{candidate function}}
+}
Index: clang/lib/Sema/SemaTemplateInstantiate.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -10,12 +10,14 @@
 //===--===/
 
 #include "TreeTransform.h"
+#include "clang/AST/ASTConcept.h"
 #include "clang/AST/ASTConsumer.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/ASTLambda.h"
 #include "clang/AST/ASTMutationListener.h"
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/Expr.h"
+#include "clang/AST/ExprConcepts.h"
 #include "clang/AST/PrettyDeclStackTrace.h"
 #include "clang/AST/TypeVisitor.h"
 #include "clang/Basic/LangOptions.h"
@@ -2022,6 +2024,7 @@
   Req->getConstraintExpr()->getSourceRange());
 
   ExprResult TransConstraint;
+  ConstraintSatisfaction Satisfaction;
   TemplateDeductionInfo Info(Req->getConstraintExpr()->getBeginLoc());
   {
 EnterExpressionEvaluationContext ContextRAII(
@@ -2033,6 +2036,25 @@
 if (ConstrInst.isInvalid())
   return nullptr;
 TransConstraint = TransformExpr(Req->getConstraintExpr());
+if (!TransConstraint.isInvalid()) {
+  bool CheckSucceeded =
+  SemaRef.CheckConstraintExpression(TransConstraint.get());
+  (void)CheckSucceeded;
+  assert(CheckSucceeded || Trap.hasErrorOccurred() &&
+   "CheckConstraintExpression failed, but "
+   "did not produce a SFINAE error");
+}
+// Use version of CheckConstraintSatisfaction that does no substitutions.
+if (!TransConstraint.isInvalid() &&
+!TransConstraint.get()->isInstantiationDependent() &&
+!Trap.hasErrorOccurred()) {
+  bool CheckFailed = SemaRef.CheckConstraintSatisfaction(
+  TransConstraint.get(), Satisfaction);
+  (void)CheckFailed;
+  assert(!CheckFailed || Trap.hasErrorOccurred() &&
+ "CheckConstraintSatisfaction failed, "
+ "but did not produce a SFINAE error");
+}
 if (TransConstraint.isInvalid() || Trap.hasErrorOccurred())
   return RebuildNestedRequirement(createSubstDiag(SemaRef, Info,
   [&] (llvm::raw_ostream& OS) {
@@ -2040,7 +2062,11 @@
 SemaRef.getPrintingPolicy());
   }));
   }
-  return RebuildNestedRequirement(TransConstraint.get());
+  if (TransConstraint.get()->isInstantiationDependent())
+return new (SemaRef.Context)
+concepts::NestedRequirement(TransConstraint.get());
+  return new (SemaRef.Context) concepts::NestedRequirement(
+  SemaRef.Context, TransCons

[PATCH] D127487: [Sema] Fix assertion failure when instantiating requires expression

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov marked an inline comment as done.
ilya-biryukov added a comment.

@erichkeane could you take another look at this?




Comment at: clang/test/SemaTemplate/concepts-PR54629.cpp:10
+int main() {
+  A a;
+}

ilya-biryukov wrote:
> erichkeane wrote:
> > Simply 'doesn't crash' isn't quite enough for a test here, I would like to 
> > see some level of confirmation which of the versions of "A" get selected 
> > here.  So perhaps `A{}.some_func();` call that wouldn't be 
> > valid/etc.  And perhaps a situation where both instances  have a constraint 
> > and and we diagnose why it doesn't fit?
> > 
> > 
> > 
> I have added the test for primary template vs specialization.
> Keeping a comment open to add a test for two specializations too, I will do 
> this a bit later.
Added a check for error messages in case of ambiguous specializations and no 
matching specialization (in terms of function overloads).
For classes there is no way to cause no matching specialization AFAICT.
Either a primary template will be picked and no error message will be shown or 
its requirements will fail and the error message will not mention the 
specializations at all.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127487

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

[PATCH] D128337: [clang-tidy] Extend spelling for CheckOptions

[Nathan James via Phabricator via cfe-commits]

njames93 created this revision.
njames93 added reviewers: aaron.ballman, alexfh.
Herald added subscribers: carlosgalvezp, arphaman, xazax.hun.
Herald added a project: All.
njames93 requested review of this revision.
Herald added subscribers: cfe-commits, aheejin.
Herald added a project: clang-tools-extra.

The current way to specify CheckOptions is pretty verbose and unintuitive.
Given that the options are a dictionary it makes much more sense to treat them 
as such in the config files.
Example:

  CheckOptions: {SomeCheck.Option: true, SomeCheck.OtherOption: 'ignore'}
  # Or
  CheckOptions:
SomeCheck.Option: true
SomeCheck.OtherOption: 'ignore'

This change will still handle the old syntax with no issue, ensuring we don't 
screw up users current config files.

The only observable differences are support for the new syntax and 
`-dump=config` will emit using the new syntax.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128337

Files:
  clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
  clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
  clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/Contributing.rst
  clang-tools-extra/docs/clang-tidy/index.rst
  clang-tools-extra/test/clang-tidy/checkers/google-module.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/Inputs/config-files/4/key-dict/.clang-tidy
  clang-tools-extra/test/clang-tidy/infrastructure/config-files.cpp

Index: clang-tools-extra/test/clang-tidy/infrastructure/config-files.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/config-files.cpp
+++ clang-tools-extra/test/clang-tidy/infrastructure/config-files.cpp
@@ -15,12 +15,16 @@
 // CHECK-COMMAND-LINE: HeaderFilterRegex: from command line
 
 // For this test we have to use names of the real checks because otherwise values are ignored.
+// Running with the old key: , value:  CheckOptions
 // RUN: clang-tidy -dump-config %S/Inputs/config-files/4/44/- -- | FileCheck %s -check-prefix=CHECK-CHILD4
+// Running with the new :  syntax
+// RUN: clang-tidy -dump-config %S/Inputs/config-files/4/key-dict/- -- | FileCheck %s -check-prefix=CHECK-CHILD4
+
 // CHECK-CHILD4: Checks: {{.*}}modernize-loop-convert,modernize-use-using,llvm-qualified-auto
-// CHECK-CHILD4-DAG: - key: llvm-qualified-auto.AddConstToQualified{{ *[[:space:]] *}}value: 'true'
-// CHECK-CHILD4-DAG: - key: modernize-loop-convert.MaxCopySize{{ *[[:space:]] *}}value: '20'
-// CHECK-CHILD4-DAG: - key: modernize-loop-convert.MinConfidence{{ *[[:space:]] *}}value: reasonable
-// CHECK-CHILD4-DAG: - key: modernize-use-using.IgnoreMacros{{ *[[:space:]] *}}value: 'false'
+// CHECK-CHILD4-DAG: llvm-qualified-auto.AddConstToQualified: 'true'
+// CHECK-CHILD4-DAG: modernize-loop-convert.MaxCopySize: '20'
+// CHECK-CHILD4-DAG: modernize-loop-convert.MinConfidence: reasonable
+// CHECK-CHILD4-DAG: modernize-use-using.IgnoreMacros: 'false'
 
 // RUN: clang-tidy --explain-config %S/Inputs/config-files/4/44/- -- | FileCheck %s -check-prefix=CHECK-EXPLAIN
 // CHECK-EXPLAIN: 'llvm-qualified-auto' is enabled in the {{.*}}{{[/\\]}}Inputs{{[/\\]}}config-files{{[/\\]}}4{{[/\\]}}44{{[/\\]}}.clang-tidy.
@@ -32,14 +36,21 @@
 // RUN: Checks: -llvm-qualified-auto, \
 // RUN: CheckOptions: [{key: modernize-loop-convert.MaxCopySize, value: 21}]}' \
 // RUN: %S/Inputs/config-files/4/44/- -- | FileCheck %s -check-prefix=CHECK-CHILD5
+// Also test with the {Key: Value} Syntax specified on command line
+// RUN: clang-tidy -dump-config \
+// RUN: --config='{InheritParentConfig: true, \
+// RUN: Checks: -llvm-qualified-auto, \
+// RUN: CheckOptions: {modernize-loop-convert.MaxCopySize: 21}}' \
+// RUN: %S/Inputs/config-files/4/44/- -- | FileCheck %s -check-prefix=CHECK-CHILD5
+
 // CHECK-CHILD5: Checks: {{.*}}modernize-loop-convert,modernize-use-using,llvm-qualified-auto,-llvm-qualified-auto
-// CHECK-CHILD5-DAG: - key: modernize-loop-convert.MaxCopySize{{ *[[:space:]] *}}value: '21'
-// CHECK-CHILD5-DAG: - key: modernize-loop-convert.MinConfidence{{ *[[:space:]] *}}value: reasonable
-// CHECK-CHILD5-DAG: - key: modernize-use-using.IgnoreMacros{{ *[[:space:]] *}}value: 'false'
+// CHECK-CHILD5-DAG: modernize-loop-convert.MaxCopySize: '21'
+// CHECK-CHILD5-DAG: modernize-loop-convert.MinConfidence: reasonable
+// CHECK-CHILD5-DAG: modernize-use-using.IgnoreMacros: 'false'
 
 // RUN: clang-tidy -dump-config \
 // RUN: --config='{InheritParentConfig: false, \
 // RUN: Checks: -llvm-qualified-auto}' \
 // RUN: %S/Inputs/config-files/4/44/- -- | FileCheck %s -check-prefix=CHECK-CHILD6
 // CHECK-CHILD6: Checks: {{.*-llvm-qualified-auto'? *$}}
-// CHECK-CHILD6-NOT: - key: modernize-use-using.IgnoreMacros
+// CHECK-CHILD6-NOT: modernize-use-using.IgnoreMacros
Index: clang-tools-extra/test/clang-tidy/infrastructure/Inputs/config-files/4/key-dict/.clang-tidy
=

[PATCH] D127446: [clang-tidy] Add `-verify-config` command line argument

[Nathan James via Phabricator via cfe-commits]

njames93 added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/infrastructure/verify-config.cpp:12
+
+// CHECK-VERIFY-DAG: command-line option '-config': warning: Unknown Check 
'readability-else-after-ret'; did you mean 'readability-else-after-return'
+// CHECK-VERIFY-DAG: command-line option '-config': warning: Unknown Check 
Option 'modernize-lop-convert.UseCxx20ReverseRanges'; did you mean 
'modernize-loop-convert.UseCxx20ReverseRanges'

aaron.ballman wrote:
> njames93 wrote:
> > aaron.ballman wrote:
> > > It's unfortunate that `warning: ` appears in the middle of the diagnostic 
> > > as opposed to at the start. I wonder if this can be reworked to say: 
> > > `warning: Unknown check 'whatever'; did you mean 'whatever'? 
> > > [-verify-config]` or something?
> > > 
> > > Also, no test coverage for the error case and for the unknown check case 
> > > where there's no closest match worth talking about.
> > Warning appearing in the middle is kind of by design as when clang emits 
> > diagnostics, the source location is the first thing emitted, then the 
> > type(warning|error). In this case `command-line option '-config'` is the 
> > "source location"
> > 
> > > Also, no test coverage for the error case.
> > I'm not 100% on that, there is no checking when the check glob is actually 
> > built and I haven't figured out how to break it.
> >  then the type(warning|error). In this case command-line option '-config' 
> > is the "source location"
> 
> Ah, thanks for explaining your logic. FWIW, Clang uses a different style for 
> that (``): https://godbolt.org/z/f1rdsbjqe Perhaps we should 
> follow suit? (In fact, we could use the diagnostic engine for this instead of 
> emitting to the error stream ourselves?)
The issue is, we don't have the actual source information right now to print 
better error messages.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127446

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

[PATCH] D128059: [Clang] Add a warning on invalid UTF-8 in comments.

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin updated this revision to Diff 438984.
cor3ntin added a comment.

s/UnicodeDecodeFailed/UnicodeDecodingAlreadyDiagnosed/


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128059

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/lib/Lex/Lexer.cpp
  clang/test/Lexer/comment-invalid-utf8.c
  llvm/include/llvm/Support/ConvertUTF.h
  llvm/lib/Support/ConvertUTF.cpp

Index: llvm/lib/Support/ConvertUTF.cpp
===
--- llvm/lib/Support/ConvertUTF.cpp
+++ llvm/lib/Support/ConvertUTF.cpp
@@ -417,6 +417,16 @@
 return isLegalUTF8(source, length);
 }
 
+/*
+ * Exported function to return the size of the first utf-8 code unit sequence,
+ * Or 0 if the sequence is not valid;
+ */
+unsigned getUTF8SequenceSize(const UTF8 *source, const UTF8 *sourceEnd) {
+  int length = trailingBytesForUTF8[*source] + 1;
+  return (length > sourceEnd - source && isLegalUTF8(source, length)) ? length
+  : 0;
+}
+
 /* - */
 
 static unsigned
Index: llvm/include/llvm/Support/ConvertUTF.h
===
--- llvm/include/llvm/Support/ConvertUTF.h
+++ llvm/include/llvm/Support/ConvertUTF.h
@@ -181,6 +181,8 @@
 
 Boolean isLegalUTF8String(const UTF8 **source, const UTF8 *sourceEnd);
 
+unsigned getUTF8SequenceSize(const UTF8 *source, const UTF8 *sourceEnd);
+
 unsigned getNumBytesForUTF8(UTF8 firstByte);
 
 /*/
Index: clang/lib/Lex/Lexer.cpp
===
--- clang/lib/Lex/Lexer.cpp
+++ clang/lib/Lex/Lexer.cpp
@@ -2391,13 +2391,39 @@
   //
   // This loop terminates with CurPtr pointing at the newline (or end of buffer)
   // character that ends the line comment.
+
+  bool WarnOnInvalidUtf8 =
+  !isLexingRawMode() &&
+  !PP->getDiagnostics().isIgnored(diag::warn_invalid_utf8_in_comment,
+  getSourceLocation(CurPtr));
+  bool UnicodeDecodingAlreadyDiagnosed = false;
+
   char C;
   while (true) {
 C = *CurPtr;
 // Skip over characters in the fast loop.
-while (C != 0 &&// Potentially EOF.
-   C != '\n' && C != '\r')  // Newline or DOS-style newline.
+// Warn on invalid UTF-8 if the corresponding warning is enabled, emitting a
+// diagnostic only once per sequence that cannot be decoded.
+while ((!WarnOnInvalidUtf8 || isASCII(C)) && C != 0 && // Potentially EOF.
+   C != '\n' && C != '\r') { // Newline or DOS-style newline.
   C = *++CurPtr;
+  UnicodeDecodingAlreadyDiagnosed = false;
+}
+
+if (WarnOnInvalidUtf8 && !isASCII(C)) {
+  unsigned Length = llvm::getUTF8SequenceSize(
+  (const llvm::UTF8 *)CurPtr, (const llvm::UTF8 *)BufferEnd);
+  if (Length == 0) {
+if (!UnicodeDecodingAlreadyDiagnosed)
+  Diag(CurPtr, diag::warn_invalid_utf8_in_comment);
+UnicodeDecodingAlreadyDiagnosed = true;
+++CurPtr;
+  } else {
+UnicodeDecodingAlreadyDiagnosed = false;
+CurPtr += Length;
+  }
+  continue;
+}
 
 const char *NextLine = CurPtr;
 if (C != 0) {
@@ -2664,10 +2690,18 @@
   if (C == '/')
 C = *CurPtr++;
 
+  bool WarnOnInvalidUtf8 =
+  !isLexingRawMode() &&
+  !PP->getDiagnostics().isIgnored(diag::warn_invalid_utf8_in_comment,
+  getSourceLocation(CurPtr));
+  bool UnicodeDecodingAlreadyDiagnosed = false;
+
   while (true) {
 // Skip over all non-interesting characters until we find end of buffer or a
 // (probably ending) '/' character.
-if (CurPtr + 24 < BufferEnd &&
+// When diagnosing invalid UTF-8 sequences we always skip the fast
+// vectorized path.
+if (!WarnOnInvalidUtf8 && CurPtr + 24 < BufferEnd &&
 // If there is a code-completion point avoid the fast scan because it
 // doesn't check for '\0'.
 !(PP && PP->getCodeCompletionFileLoc() == FileLoc)) {
@@ -2714,9 +2748,27 @@
   C = *CurPtr++;
 }
 
-// Loop to scan the remainder.
-while (C != '/' && C != '\0')
-  C = *CurPtr++;
+// Loop to scan the remainder, warning on invalid UTF-8
+// if the corresponding warning is enabled, emitting a diagnostic only once
+// per sequence that cannot be decoded.
+while (C != '/' && C != '\0') {
+  if (!WarnOnInvalidUtf8 || isASCII(C)) {
+UnicodeDecodingAlreadyDiagnosed = false;
+C = *CurPtr++;
+continue;
+  }
+  unsigned Length = llvm::getUTF8SequenceSize(
+  (const llvm::UTF8 *)CurPtr - 1, (const llvm::UTF8 *)BufferEnd);
+  if (Length == 0) {
+if (!UnicodeDecodingAlr

[PATCH] D125916: [PowerPC] Defined and lowered llvm.ppc.kill.canary intrinsic

[Paul Scoropan via Phabricator via cfe-commits]

pscoro updated this revision to Diff 438985.
pscoro added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

[PowerPC] implemented kill_canary intrinsic and tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125916

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/CodeGen/PowerPC/builtins-ppc-stackprotect.c
  clang/test/CodeGen/PowerPC/builtins-ppc.c
  final.patch
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll
  mypatch.patch

Index: mypatch.patch
===
--- /dev/null
+++ mypatch.patch
@@ -0,0 +1,14 @@
+commit f11c8790cad5554c4dad7a14c0d177bacd99eb22
+Author: Paul Scoropan 
+Date:   Tue Jun 21 13:57:35 2022 -0400
+
+finished
+
+diff --git a/AIX-OS-headers b/AIX-OS-headers
+deleted file mode 12
+index c2adefef9991..
+--- a/AIX-OS-headers
 /dev/null
+@@ -1 +0,0 @@
+-/home/pauls/llvm/dev_3105/AIX-OS-headers
+\ No newline at end of file
Index: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll
@@ -0,0 +1,20 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   FileCheck %s
+
+
+declare void @llvm.ppc.kill.canary()
+define dso_local void @test_kill_canary() {
+; CHECK-LABEL: test_kill_canary:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:lis 3, 19564
+; CHECK-NEXT:ori 3, 3, 22125
+; CHECK-NEXT:stw 3, -17(1)
+; CHECK-NEXT:blr
+entry:
+  call void @llvm.ppc.kill.canary()
+  ret void
+}
+
+
+
Index: llvm/lib/Target/PowerPC/PPCISelLowering.cpp
===
--- llvm/lib/Target/PowerPC/PPCISelLowering.cpp
+++ llvm/lib/Target/PowerPC/PPCISelLowering.cpp
@@ -11127,6 +11127,38 @@
 }
 break;
   }
+  case Intrinsic::ppc_kill_canary: {
+MachineFunction &MF = DAG.getMachineFunction();
+if (MF.getFunction().hasFnAttribute(Attribute::SafeStack)) {
+	break;
+}
+MachineFrameInfo &MFI = MF.getFrameInfo();
+int SPI = MFI.getStackProtectorIndex(); // should return  -1
+
+PPCFunctionInfo *FuncInfo = MF.getInfo();
+EVT PtrVT = getPointerTy(MF.getDataLayout());
+
+MFI.CreateStackObject(16, Align(16), false);
+SDValue FIN = DAG.getFrameIndex(FuncInfo->getVarArgsFrameIndex(), PtrVT); // frame index
+
+unsigned int deadBird = 0x4C6C566D; // replaces canary word
+
+SDValue Store = DAG.getStore( // create store instr, stores (deadBird + 0) into addr (frame index + stack protector)
+Op->getOperand(0), 
+DL,
+	DAG.getConstant(deadBird, DL, MVT::i32), 
+DAG.getNode( // add frame index, stack protector index, return node result
+ISD::ADD,
+DL,  
+PtrVT,
+FIN,   
+DAG.getConstant(SPI, DL, PtrVT)
+), 
+MachinePointerInfo() 
+);
+return Store;
+break;
+  }
   default:
 break;
   }
Index: llvm/include/llvm/IR/IntrinsicsPowerPC.td
===
--- llvm/include/llvm/IR/IntrinsicsPowerPC.td
+++ llvm/include/llvm/IR/IntrinsicsPowerPC.td
@@ -217,6 +217,11 @@
   : Intrinsic<[llvm_float_ty],
   [llvm_float_ty, llvm_float_ty, llvm_float_ty, llvm_vararg_ty],
   [IntrNoMem]>;
+  def int_ppc_kill_canary
+  : GCCBuiltin<"__builtin_ppc_kill_canary">, 
+Intrinsic<[],
+  [],
+  [IntrWriteMem, IntrHasSideEffects]>;
 }
 
 let TargetPrefix = "ppc" in {  // All PPC intrinsics start with "llvm.ppc.".
Index: final.patch
===
--- /dev/null
+++ final.patch
@@ -0,0 +1,14 @@
+commit f11c8790cad5554c4dad7a14c0d177bacd99eb22
+Author: Paul Scoropan 
+Date:   Tue Jun 21 13:57:35 2022 -0400
+
+finished
+
+diff --git a/AIX-OS-headers b/AIX-OS-headers
+deleted file mode 12
+index c2adefef9991..
+--- a/AIX-OS-headers
 /dev/null
+@@ -1 +0,0 @@
+-/home/pauls/llvm/dev_3105/AIX-OS-headers
+\ No newline at end of file
Index: clang/test/CodeGen/PowerPC/builtins-ppc.c
===
--- clang/test/CodeGen/PowerPC/builtins-ppc.c
+++ clang/test/CodeGen/PowerPC/builtins-ppc.c
@@ -74,3 +74,13 @@
   // CHECK: call float (float, float, float, ...) @llvm.ppc.minfs(float %5, float %6, float %7, float %8)
   res = __builtin_ppc_minfs(a, b, c, d);
 }
+/*
+void test_builtin_ppc_kill_canary() {
+  // CHECK: call void

[PATCH] D128299: [pseudo] Add a fast-path to GLR reduce when both pop and push are trivial

[Haojian Wu via Phabricator via cfe-commits]

hokein accepted this revision.
hokein added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:269
+  // bypass all these fancy queues and pop+push directly. This is very common.
+  auto PopAndPushTrivial = [&]() -> bool {
+if (!Sequences.empty() || Heads.size() != PoppedHeads + 1)

IMO, it is exactly what the reduction implementation would look like for a 
linear LR parsing :)

maybe encode the linear in the name?



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:270
+  auto PopAndPushTrivial = [&]() -> bool {
+if (!Sequences.empty() || Heads.size() != PoppedHeads + 1)
+  return false;

The patch description is really nice document, and help to me to justify the 
code. I'd suggest adding them in the comment as well.

> there must be no pending pushes and only one head available to pop
> the head must have only one reduction rule
> the reduction path must be a straight line (no multiple parents)





Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:320
 for (; PoppedHeads < Heads.size(); ++PoppedHeads) {
-  // FIXME: if there's exactly one head in the queue, and the pop stage
-  // is trivial, we could pop + push without touching the expensive queues.
+  if (PopAndPushTrivial())
+continue;

This seems very clever -- for trivial case, the main reduce loop is happening 
here.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:323
   for (const auto &A :
Params.Table.getActions(Heads[PoppedHeads]->State, Lookahead)) {
 if (A.kind() != LRTable::Action::Reduce)

we could save an extra call of `Params.Table.getActions` -- we call it at the 
beginning of the loop body and store the results in a local var, and use it in 
PopAndPushTrivial and here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128299

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

[PATCH] D125916: [PowerPC] Defined and lowered llvm.ppc.kill.canary intrinsic

[Paul Scoropan via Phabricator via cfe-commits]

pscoro updated this revision to Diff 438987.
pscoro added a comment.

[PowerPC]
Removed accidental patch files


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125916

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/CodeGen/PowerPC/builtins-ppc-stackprotect.c
  clang/test/CodeGen/PowerPC/builtins-ppc.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll

Index: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll
@@ -0,0 +1,20 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   FileCheck %s
+
+
+declare void @llvm.ppc.kill.canary()
+define dso_local void @test_kill_canary() {
+; CHECK-LABEL: test_kill_canary:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:lis 3, 19564
+; CHECK-NEXT:ori 3, 3, 22125
+; CHECK-NEXT:stw 3, -17(1)
+; CHECK-NEXT:blr
+entry:
+  call void @llvm.ppc.kill.canary()
+  ret void
+}
+
+
+
Index: llvm/lib/Target/PowerPC/PPCISelLowering.cpp
===
--- llvm/lib/Target/PowerPC/PPCISelLowering.cpp
+++ llvm/lib/Target/PowerPC/PPCISelLowering.cpp
@@ -11127,6 +11127,38 @@
 }
 break;
   }
+  case Intrinsic::ppc_kill_canary: {
+MachineFunction &MF = DAG.getMachineFunction();
+if (MF.getFunction().hasFnAttribute(Attribute::SafeStack)) {
+	break;
+}
+MachineFrameInfo &MFI = MF.getFrameInfo();
+int SPI = MFI.getStackProtectorIndex(); // should return  -1
+
+PPCFunctionInfo *FuncInfo = MF.getInfo();
+EVT PtrVT = getPointerTy(MF.getDataLayout());
+
+MFI.CreateStackObject(16, Align(16), false);
+SDValue FIN = DAG.getFrameIndex(FuncInfo->getVarArgsFrameIndex(), PtrVT); // frame index
+
+unsigned int deadBird = 0x4C6C566D; // replaces canary word
+
+SDValue Store = DAG.getStore( // create store instr, stores (deadBird + 0) into addr (frame index + stack protector)
+Op->getOperand(0), 
+DL,
+	DAG.getConstant(deadBird, DL, MVT::i32), 
+DAG.getNode( // add frame index, stack protector index, return node result
+ISD::ADD,
+DL,  
+PtrVT,
+FIN,   
+DAG.getConstant(SPI, DL, PtrVT)
+), 
+MachinePointerInfo() 
+);
+return Store;
+break;
+  }
   default:
 break;
   }
Index: llvm/include/llvm/IR/IntrinsicsPowerPC.td
===
--- llvm/include/llvm/IR/IntrinsicsPowerPC.td
+++ llvm/include/llvm/IR/IntrinsicsPowerPC.td
@@ -217,6 +217,11 @@
   : Intrinsic<[llvm_float_ty],
   [llvm_float_ty, llvm_float_ty, llvm_float_ty, llvm_vararg_ty],
   [IntrNoMem]>;
+  def int_ppc_kill_canary
+  : GCCBuiltin<"__builtin_ppc_kill_canary">, 
+Intrinsic<[],
+  [],
+  [IntrWriteMem, IntrHasSideEffects]>;
 }
 
 let TargetPrefix = "ppc" in {  // All PPC intrinsics start with "llvm.ppc.".
Index: clang/test/CodeGen/PowerPC/builtins-ppc.c
===
--- clang/test/CodeGen/PowerPC/builtins-ppc.c
+++ clang/test/CodeGen/PowerPC/builtins-ppc.c
@@ -74,3 +74,13 @@
   // CHECK: call float (float, float, float, ...) @llvm.ppc.minfs(float %5, float %6, float %7, float %8)
   res = __builtin_ppc_minfs(a, b, c, d);
 }
+/*
+void test_builtin_ppc_kill_canary() {
+  // CHECK: call void @llvm.ppc.kill.canary()
+  __builtin_ppc_kill_canary();
+}
+
+void test_kill_canary() {
+  // CHECK: call void @llvm.ppc.kill.canary()
+  __kill_canary();
+}*/
Index: clang/test/CodeGen/PowerPC/builtins-ppc-stackprotect.c
===
--- /dev/null
+++ clang/test/CodeGen/PowerPC/builtins-ppc-stackprotect.c
@@ -0,0 +1,23 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -O2 -triple powerpc64-unknown-linux-gnu \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | \
+// RUN:  FileCheck %s
+// RUN: %clang_cc1 -O2 -triple powerpc64le-unknown-linux-gnu \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr8 | \
+// RUN:  FileCheck %s
+// RUN: %clang_cc1 -O2 -triple powerpc-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | \
+// RUN:  FileCheck %s
+// RUN: %clang_cc1 -O2 -triple powerpc64-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | \
+// RUN:  FileCheck %s
+
+void test_builtin_ppc_kill_canary() {
+  // CHECK: call void @llvm.ppc.kill.canary()
+  __builtin_ppc_kill_canary();
+}
+
+void test_kill_canary() {
+  

[PATCH] D125916: [PowerPC] Defined and lowered llvm.ppc.kill.canary intrinsic

[Paul Scoropan via Phabricator via cfe-commits]

pscoro updated this revision to Diff 438988.
pscoro added a comment.

[PowerPC]
Removed commented change


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125916

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/CodeGen/PowerPC/builtins-ppc-stackprotect.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll

Index: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll
@@ -0,0 +1,20 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   FileCheck %s
+
+
+declare void @llvm.ppc.kill.canary()
+define dso_local void @test_kill_canary() {
+; CHECK-LABEL: test_kill_canary:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:lis 3, 19564
+; CHECK-NEXT:ori 3, 3, 22125
+; CHECK-NEXT:stw 3, -17(1)
+; CHECK-NEXT:blr
+entry:
+  call void @llvm.ppc.kill.canary()
+  ret void
+}
+
+
+
Index: llvm/lib/Target/PowerPC/PPCISelLowering.cpp
===
--- llvm/lib/Target/PowerPC/PPCISelLowering.cpp
+++ llvm/lib/Target/PowerPC/PPCISelLowering.cpp
@@ -11127,6 +11127,38 @@
 }
 break;
   }
+  case Intrinsic::ppc_kill_canary: {
+MachineFunction &MF = DAG.getMachineFunction();
+if (MF.getFunction().hasFnAttribute(Attribute::SafeStack)) {
+	break;
+}
+MachineFrameInfo &MFI = MF.getFrameInfo();
+int SPI = MFI.getStackProtectorIndex(); // should return  -1
+
+PPCFunctionInfo *FuncInfo = MF.getInfo();
+EVT PtrVT = getPointerTy(MF.getDataLayout());
+
+MFI.CreateStackObject(16, Align(16), false);
+SDValue FIN = DAG.getFrameIndex(FuncInfo->getVarArgsFrameIndex(), PtrVT); // frame index
+
+unsigned int deadBird = 0x4C6C566D; // replaces canary word
+
+SDValue Store = DAG.getStore( // create store instr, stores (deadBird + 0) into addr (frame index + stack protector)
+Op->getOperand(0), 
+DL,
+	DAG.getConstant(deadBird, DL, MVT::i32), 
+DAG.getNode( // add frame index, stack protector index, return node result
+ISD::ADD,
+DL,  
+PtrVT,
+FIN,   
+DAG.getConstant(SPI, DL, PtrVT)
+), 
+MachinePointerInfo() 
+);
+return Store;
+break;
+  }
   default:
 break;
   }
Index: llvm/include/llvm/IR/IntrinsicsPowerPC.td
===
--- llvm/include/llvm/IR/IntrinsicsPowerPC.td
+++ llvm/include/llvm/IR/IntrinsicsPowerPC.td
@@ -217,6 +217,11 @@
   : Intrinsic<[llvm_float_ty],
   [llvm_float_ty, llvm_float_ty, llvm_float_ty, llvm_vararg_ty],
   [IntrNoMem]>;
+  def int_ppc_kill_canary
+  : GCCBuiltin<"__builtin_ppc_kill_canary">, 
+Intrinsic<[],
+  [],
+  [IntrWriteMem, IntrHasSideEffects]>;
 }
 
 let TargetPrefix = "ppc" in {  // All PPC intrinsics start with "llvm.ppc.".
Index: clang/test/CodeGen/PowerPC/builtins-ppc-stackprotect.c
===
--- /dev/null
+++ clang/test/CodeGen/PowerPC/builtins-ppc-stackprotect.c
@@ -0,0 +1,23 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -O2 -triple powerpc64-unknown-linux-gnu \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | \
+// RUN:  FileCheck %s
+// RUN: %clang_cc1 -O2 -triple powerpc64le-unknown-linux-gnu \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr8 | \
+// RUN:  FileCheck %s
+// RUN: %clang_cc1 -O2 -triple powerpc-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | \
+// RUN:  FileCheck %s
+// RUN: %clang_cc1 -O2 -triple powerpc64-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | \
+// RUN:  FileCheck %s
+
+void test_builtin_ppc_kill_canary() {
+  // CHECK: call void @llvm.ppc.kill.canary()
+  __builtin_ppc_kill_canary();
+}
+
+void test_kill_canary() {
+  // CHECK: call void @llvm.ppc.kill.canary()
+  __kill_canary();
+}
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -122,6 +122,7 @@
   Builder.defineMacro("__fetch_and_orlp", "__builtin_ppc_fetch_and_orlp");
   Builder.defineMacro("__fetch_and_swap", "__builtin_ppc_fetch_and_swap");
   Builder.defineMacro("__fetch_and_swaplp", "__builtin_ppc_fetch_and_swaplp");
+  Builder.defineMacro("__kill_canary", "__builtin_ppc_kill_canary");
   Builder.defineMacro("__ldarx", "__builtin_ppc_ldarx");
   Builder.defineMacro("__lwar

[PATCH] D127460: Rename GCCBuiltin into ClangBuiltin

[Guillaume Gomez via Phabricator via cfe-commits]

GuillaumeGomez updated this revision to Diff 438989.
GuillaumeGomez added a comment.

Rename GCCBuiltin into ClangBuiltin.

This patch is needeed because developers expect "GCCBuiltin" items to be the 
GCC intrinsics equivalent and not the Clang internals.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127460

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  llvm/include/llvm/ADT/Triple.h
  llvm/include/llvm/IR/Intrinsics.h
  llvm/include/llvm/IR/Intrinsics.td
  llvm/include/llvm/IR/IntrinsicsAArch64.td
  llvm/include/llvm/IR/IntrinsicsAMDGPU.td
  llvm/include/llvm/IR/IntrinsicsARM.td
  llvm/include/llvm/IR/IntrinsicsBPF.td
  llvm/include/llvm/IR/IntrinsicsHexagon.td
  llvm/include/llvm/IR/IntrinsicsMips.td
  llvm/include/llvm/IR/IntrinsicsNVVM.td
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/include/llvm/IR/IntrinsicsSystemZ.td
  llvm/include/llvm/IR/IntrinsicsVE.td
  llvm/include/llvm/IR/IntrinsicsVEVL.gen.td
  llvm/include/llvm/IR/IntrinsicsX86.td
  llvm/include/llvm/IR/IntrinsicsXCore.td
  llvm/lib/IR/Function.cpp
  llvm/utils/TableGen/CodeGenIntrinsics.h
  llvm/utils/TableGen/CodeGenTarget.cpp
  llvm/utils/TableGen/IntrinsicEmitter.cpp

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

[PATCH] D127460: Rename GCCBuiltin into ClangBuiltin

[Guillaume Gomez via Phabricator via cfe-commits]

GuillaumeGomez added a comment.

In D127460#3601193 , @xbolva00 wrote:

> Patch description needs to be added, especially answer the question why we 
> should rename it, why we want it..

I updated the description to explain why it is needed. I'm not sure how big 
it's supposed to be so I didn't enter into the details though.

In D127460#3601205 , @xbolva00 wrote:

> In D127460#3601152 , 
> @GuillaumeGomez wrote:
>
>> This is my first LLVM contribution so I don't think I do? If I do have a 
>> commit access anyway, do you have a link to the documentation where it 
>> explains what I'm supposed to do by any chance?
>
> https://llvm.org/docs/DeveloperPolicy.html#id17

Thanks! Once this is approved, I'll do it then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127460

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

[PATCH] D125916: [PowerPC] Defined and lowered llvm.ppc.kill.canary intrinsic

[Paul Scoropan via Phabricator via cfe-commits]

pscoro added a comment.

@shchenz I have added the test cases.
This intrinsic is defined in order to test the stackprotect functionality on 
xlf. Use the -qdebug=smashstack flag to use it, make sure that 
-qstackprotect=all is also set


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125916

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

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam marked 7 inline comments as done.
zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGExprComplex.cpp:896
+
+ComplexPairTy ComplexExprEmitter::EmitPromoted(const Expr *E) {
+  if (auto *BinOp = dyn_cast(E->IgnoreParens())) {

pengfei wrote:
> rjmccall wrote:
> > pengfei wrote:
> > > rjmccall wrote:
> > > > zahiraam wrote:
> > > > > rjmccall wrote:
> > > > > > `EmitPromoted` should take the promotion type.
> > > > > > 
> > > > > > You are missing the logic in this file which handles *unpromoted* 
> > > > > > emission (where you have a binary operator but the context wants an 
> > > > > > unpromoted value) by recognizing that you need to do a promoted 
> > > > > > operation and then truncate.
> > > > > Sorry but not sure what you mean here. A case where we don't want any 
> > > > > promotion would be:
> > > > > 
> > > > > float _Complex add(float _Complex a, float _Complex b) {
> > > > >   return a + b;
> > > > > }
> > > > > 
> > > > > In this case, getPromotionType would return the null type and 
> > > > > EmitBinOps would just go through the  "older" control path where 
> > > > > there is no promotion.
> > > > > Unless I misunderstood your comment?
> > > > > 
> > > > > 
> > > > I'm talking about the unpromoted emission path for an operation that we 
> > > > want to *internally* promote.  So like your example but using 
> > > > `_Float16` — we want to emit the binary `+` as a `float` operation, but 
> > > > the context needs an unpromoted value because it's going to be returned.
> > > > 
> > > > The promoted emission path (the various `EmitPromoted` methods) 
> > > > represents a request by the caller to produce a result that doesn't 
> > > > match the formal type of the expression.  The normal emission path 
> > > > `Visit` etc.) represents a request by the caller to produce a result 
> > > > normally, i.e. one that matches the formal type.  In general, we always 
> > > > start in the latter because arbitrary contexts always expect a value of 
> > > > the formal type; it's only these recursive calls within promoted 
> > > > emitters that contextually want a promoted value.
> > > > 
> > > > In your current patch, you're entering the promoted path by 
> > > > special-casing one context that frequently terminates promoted 
> > > > emission: `EmitComplexExprIntoLValue`, which is used for things like 
> > > > assignment.  That's not the right way to handle it, though.  Instead, 
> > > > you should do like I asked you to do with the scalar emitter, which is 
> > > > to recognize in the normal emission path for a promotable operation 
> > > > (like binary `+`) that you need to promote the operation and then 
> > > > unpromote the result.  Then things like `EmitComplexExprIntoLValue` 
> > > > will continue to simply enter the normal path because that's the kind 
> > > > of value they need, and the promotion logic will do the right thing 
> > > > from there to ensure we don't emit a `_Float16` operation in LLVM IR.
> > > > 
> > > > Incidentally, I thought of another context that you ought to do 
> > > > promotion for: when we're converting a promotable value to a larger 
> > > > floating-point type, we should presumably convert the promoted value 
> > > > directly rather than truncating it to the unpromoted type before the 
> > > > conversion.
> > > I'm not familiar with the FE details, but I understand the background is 
> > > just to promote expressions that have more than one operation. So I agree 
> > > with @zahiraam, and
> > > > to ensure we don't emit a _Float16 operation in LLVM IR
> > > is not what we expected here.
> > > 
> > > `_Float16` is a ABI type for which a target supported has to lower any 
> > > `_Float16` operations in LLVM IR. See what we have done on X86 backend by 
> > > D107082.
> > > 
> > > That said, a single `a + b` can be and should be emitted as `%c = fadd 
> > > half %a, %b`.
> > Well, you can provide operation-by-operation lowering support if you want 
> > to, but what's going to come out of Clang IRGen in this mode is not going 
> > to rely on it.  It's far easier to just emit these operations differently, 
> > always using `float`, than to try to recognize the special cases where all 
> > the inputs are naturally `half` and so you might as well emit a `half` 
> > operation.
> > 
> > And I think the postcondition that `half` operations don't come out of 
> > IRGen is a generally useful property even if you've already written this 
> > lowering code.  Among other things, it makes it easy to test that you 
> > haven't missed a case where you should be doing promoted emission.
> We define `_Float16` as ABI type and require targets to support the ABI 
> lowering. See 
> https://clang.llvm.org/docs/LanguageExtensions.html#half-precision-floating-point
>  Promoting in FE doesn't mean it works on any targets by default, so I think 
> it's not much useful.
> We need to support `-fexcess-precision=16` the same as GCC does, it's easier 
>

[PATCH] D128059: [Clang] Add a warning on invalid UTF-8 in comments.

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin updated this revision to Diff 438990.
cor3ntin added a comment.

Make sure the warning is off by default.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128059

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/lib/Lex/Lexer.cpp
  clang/test/Lexer/comment-invalid-utf8.c
  llvm/include/llvm/Support/ConvertUTF.h
  llvm/lib/Support/ConvertUTF.cpp

Index: llvm/lib/Support/ConvertUTF.cpp
===
--- llvm/lib/Support/ConvertUTF.cpp
+++ llvm/lib/Support/ConvertUTF.cpp
@@ -417,6 +417,16 @@
 return isLegalUTF8(source, length);
 }
 
+/*
+ * Exported function to return the size of the first utf-8 code unit sequence,
+ * Or 0 if the sequence is not valid;
+ */
+unsigned getUTF8SequenceSize(const UTF8 *source, const UTF8 *sourceEnd) {
+  int length = trailingBytesForUTF8[*source] + 1;
+  return (length > sourceEnd - source && isLegalUTF8(source, length)) ? length
+  : 0;
+}
+
 /* - */
 
 static unsigned
Index: llvm/include/llvm/Support/ConvertUTF.h
===
--- llvm/include/llvm/Support/ConvertUTF.h
+++ llvm/include/llvm/Support/ConvertUTF.h
@@ -181,6 +181,8 @@
 
 Boolean isLegalUTF8String(const UTF8 **source, const UTF8 *sourceEnd);
 
+unsigned getUTF8SequenceSize(const UTF8 *source, const UTF8 *sourceEnd);
+
 unsigned getNumBytesForUTF8(UTF8 firstByte);
 
 /*/
Index: clang/lib/Lex/Lexer.cpp
===
--- clang/lib/Lex/Lexer.cpp
+++ clang/lib/Lex/Lexer.cpp
@@ -2391,13 +2391,39 @@
   //
   // This loop terminates with CurPtr pointing at the newline (or end of buffer)
   // character that ends the line comment.
+
+  bool WarnOnInvalidUtf8 =
+  !isLexingRawMode() &&
+  !PP->getDiagnostics().isIgnored(diag::warn_invalid_utf8_in_comment,
+  getSourceLocation(CurPtr));
+  bool UnicodeDecodingAlreadyDiagnosed = false;
+
   char C;
   while (true) {
 C = *CurPtr;
 // Skip over characters in the fast loop.
-while (C != 0 &&// Potentially EOF.
-   C != '\n' && C != '\r')  // Newline or DOS-style newline.
+// Warn on invalid UTF-8 if the corresponding warning is enabled, emitting a
+// diagnostic only once per sequence that cannot be decoded.
+while ((!WarnOnInvalidUtf8 || isASCII(C)) && C != 0 && // Potentially EOF.
+   C != '\n' && C != '\r') { // Newline or DOS-style newline.
   C = *++CurPtr;
+  UnicodeDecodingAlreadyDiagnosed = false;
+}
+
+if (WarnOnInvalidUtf8 && !isASCII(C)) {
+  unsigned Length = llvm::getUTF8SequenceSize(
+  (const llvm::UTF8 *)CurPtr, (const llvm::UTF8 *)BufferEnd);
+  if (Length == 0) {
+if (!UnicodeDecodingAlreadyDiagnosed)
+  Diag(CurPtr, diag::warn_invalid_utf8_in_comment);
+UnicodeDecodingAlreadyDiagnosed = true;
+++CurPtr;
+  } else {
+UnicodeDecodingAlreadyDiagnosed = false;
+CurPtr += Length;
+  }
+  continue;
+}
 
 const char *NextLine = CurPtr;
 if (C != 0) {
@@ -2664,10 +2690,18 @@
   if (C == '/')
 C = *CurPtr++;
 
+  bool WarnOnInvalidUtf8 =
+  !isLexingRawMode() &&
+  !PP->getDiagnostics().isIgnored(diag::warn_invalid_utf8_in_comment,
+  getSourceLocation(CurPtr));
+  bool UnicodeDecodingAlreadyDiagnosed = false;
+
   while (true) {
 // Skip over all non-interesting characters until we find end of buffer or a
 // (probably ending) '/' character.
-if (CurPtr + 24 < BufferEnd &&
+// When diagnosing invalid UTF-8 sequences we always skip the fast
+// vectorized path.
+if (!WarnOnInvalidUtf8 && CurPtr + 24 < BufferEnd &&
 // If there is a code-completion point avoid the fast scan because it
 // doesn't check for '\0'.
 !(PP && PP->getCodeCompletionFileLoc() == FileLoc)) {
@@ -2714,9 +2748,27 @@
   C = *CurPtr++;
 }
 
-// Loop to scan the remainder.
-while (C != '/' && C != '\0')
-  C = *CurPtr++;
+// Loop to scan the remainder, warning on invalid UTF-8
+// if the corresponding warning is enabled, emitting a diagnostic only once
+// per sequence that cannot be decoded.
+while (C != '/' && C != '\0') {
+  if (!WarnOnInvalidUtf8 || isASCII(C)) {
+UnicodeDecodingAlreadyDiagnosed = false;
+C = *CurPtr++;
+continue;
+  }
+  unsigned Length = llvm::getUTF8SequenceSize(
+  (const llvm::UTF8 *)CurPtr - 1, (const llvm::UTF8 *)BufferEnd);
+  if (Length == 0) {
+if (!UnicodeDecodingAlreadyDiagnosed)

[PATCH] D128043: [flang][driver] Add support for `-O{0|1|2|3}`

[Diana Picus via Phabricator via cfe-commits]

rovka added inline comments.



Comment at: flang/include/flang/Frontend/CodeGenOptions.def:12
+// Optionally, the user may also define ENUM_CODEGENOPT (for options
+// that have enumeration type and VALUE_CODEGENOPT is a code
+// generation option that describes a value rather than a flag.

I'm not sure I understand the difference between CODEGENOPT and 
VALUE_CODEGENOPT. Is it that CODEGENOPT is actually a kind of BOOL_CODEGENOPT, 
that should always have just 1 bit? Do we really need both?



Comment at: flang/include/flang/Frontend/CodeGenOptions.def:25
+
+#ifndef ENUM_CODEGENOPT
+#  define ENUM_CODEGENOPT(Name, Type, Bits, Default) \

This isn't used yet, can we skip it?



Comment at: flang/include/flang/Frontend/FrontendActions.h:202
   bool beginSourceFileAction() override;
+  /// Sets up LLVM's TargetMachine, configures llvmModule accordingly
   void setUpTargetMachine();





Comment at: flang/lib/Frontend/FrontendActions.cpp:617
 /// \param [in] llvmModule LLVM module to lower to assembly/machine-code
 /// \param [out] os Output stream to emit the generated code to
+

Shouldn't this comment go away too?



Comment at: flang/lib/Frontend/FrontendActions.cpp:711
 
+  // Run LLVM's middle-end (i.e. the optimizer)
+  runOptimizationPipeline(*os);





Comment at: flang/lib/Frontend/FrontendActions.cpp:724
   if (action == BackendActionTy::Backend_EmitBC) {
-generateLLVMBCImpl(*tm, *llvmModule, *os);
+// This action has effectively been completed in runOptimizationPipeline
 return;





Comment at: flang/lib/Frontend/FrontendActions.cpp:728
 
+  // Run LLVM's backend and generate either assembly or machine code
   if (action == BackendActionTy::Backend_EmitAssembly ||





Comment at: flang/test/Driver/default-optimization-pipelines.f90:1
+! Verify that`-O{n}` is indeed taken into account when definining the LLVM 
optimization/middle-end pass pass pipeline.
+




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128043

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

[PATCH] D127460: Rename GCCBuiltin into ClangBuiltin

[Guillaume Gomez via Phabricator via cfe-commits]

GuillaumeGomez added a comment.

So from the documentation:

> Prior to obtaining commit access, it is common practice to request that 
> someone with commit access commits on your behalf. When doing so, please 
> provide the name and email address you would like to use in the Author 
> property of the commit.

So as git commit author I use:

"Guillaume Gomez "

Can someone commit on my behalf please?

Thanks in advance!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127460

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

[PATCH] D127812: [AArch64] Function multiversioning support added.

[Daniel Kiss via Phabricator via cfe-commits]

danielkiss added a comment.

In D127812#3599530 , @aaron.ballman 
wrote:

> In D127812#3587223 , @ilinpv wrote:
>
>> In D127812#3585249 , @erichkeane 
>> wrote:
>>
>>> I'm concerned as to the design of this addition, I don't particularly 
>>> appreciate the reasons for making 'target_clones' different, nor the 
>>> purpose for adding a new attribute instead of using 'target' for what seems 
>>> like exactly that?  IF the new spelling is THAT necessary, we perhaps don't 
>>> need a whole new attribute for it either.
>>
>> Thank you for fair concern, "target_clones" for AArch64 has different 
>> format, semantic, e.g. "default" is not required.  Therefore it diverges 
>> with X86 in these parts.
>
> Is it *necessary* that it diverges like this? (Is there some published 
> standards document you're trying to conform to, is there an implementation 
> difficulty with not diverging, something else?)

In ACLE there are a few rules/behaviour documented around what should be the 
behaviour of the "default" for example. Making for example "default" optional 
hopefully makes the adation of multi versioning seamless as possible. Compilers 
won't support from day one these attributes therefore the goal was to make the 
whole addition of a multi versioned function as less distributive as possible 
while the code is still compiled with older compilers too.

  // this is the original code
  // mandating __attribute__ ((target ("default"))) would not work with the 
today's compilers
  void foo(){}
  
  // new backward compatible code
  #ifdef __ARM_FEATURE_FUNCTION_MULTI_VERSIONING
  __attribute__ ((target_version("fancy_feature")))
  void foo(){}
  #endif

if the "default" is not mandated here, it felt not right to mandate it for the 
`target_clones` either.

>> "target" attribute has been already used and supported on AArch64 in a 
>> different sense, like target("arm"), target("dotprod"), 
>> target("branch-protection=bti"). The intention of creating new 
>> "target_version" attribute is not to overlap with that. It also has 
>> different format, mangling and semantic, e.g. treating function without 
>> attribute as "default", and option to disable attribute droping function 
>> multi versions. Do these explanations dispel your concern?
>
> Do I understand correctly that AArch64 was using an attribute named `target` 
> which does not behave like the attribute with the same name in GCC and Clang 
> on other architectures, and now you'd like to introduce a new attribute which 
> does behave like `target` but under a different name? If I have that correct, 
> I don't think that's reasonable -- there's far too much possibility for 
> confusion with that situation already, and adding a new attribute only 
> increases the confusion. I'm not certain where the technical debt came from, 
> but we shouldn't increase the burden on users here; I think `target` and 
> `target_clones` should be made to work consistently across architectures if 
> at all possible.

Your understanding is correct. `target` attribute has two usage model. One is 
just redefine the to be used codegen options, this is used already widely for 
Arm and AArch64. The other use of the `target` attribute is the multi 
versioning and the rational for the `target_version` attribute is the easier 
distinction between the two usage mode, also not to break any code out there by 
changing the behaviour of an attribute.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127812

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

[clang-tools-extra] bb29702 - Don't treat invalid parameters as being unused

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2022-06-22T08:56:38-04:00
New Revision: bb297024fad2f6c3ccaaa6a5c3a270f73f15f3ac

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

LOG: Don't treat invalid parameters as being unused

The misc-unused-parameters check would trigger false positive warnings
about the parameter being unused when the parameter declaration was
invalid. No longer issue the warning in that case on the assumption
that most parameters are used in practice, so the extra diagnostic is
most likely a false positive.

Fixes #56152

Added: 
clang-tools-extra/test/clang-tidy/checkers/misc-unused-invalid-parameter.cpp

Modified: 
clang-tools-extra/clang-tidy/misc/UnusedParametersCheck.cpp
clang-tools-extra/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/misc/UnusedParametersCheck.cpp 
b/clang-tools-extra/clang-tidy/misc/UnusedParametersCheck.cpp
index 149d63ff1e62f..669132024af77 100644
--- a/clang-tools-extra/clang-tidy/misc/UnusedParametersCheck.cpp
+++ b/clang-tools-extra/clang-tidy/misc/UnusedParametersCheck.cpp
@@ -135,6 +135,9 @@ void UnusedParametersCheck::warnOnUnusedParameter(
 const MatchFinder::MatchResult &Result, const FunctionDecl *Function,
 unsigned ParamIndex) {
   const auto *Param = Function->getParamDecl(ParamIndex);
+  // Don't bother to diagnose invalid parameters as being unused.
+  if (Param->isInvalidDecl())
+return;
   auto MyDiag = diag(Param->getLocation(), "parameter %0 is unused") << Param;
 
   if (!Indexer) {

diff  --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index 1f1c4c87112aa..7a660c0230cbe 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -110,6 +110,9 @@ Improvements to clang-tidy
   from suppressing diagnostics associated with macro arguments. This fixes
   `Issue 55134 `_.
 
+- Invalid parameters are no longer treated as being implicitly unused for the
+  `-misc-unused-parameters` check. This fixes `Issue 56152 
`_.
+
 New checks
 ^^
 

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/misc-unused-invalid-parameter.cpp 
b/clang-tools-extra/test/clang-tidy/checkers/misc-unused-invalid-parameter.cpp
new file mode 100644
index 0..e7642e79b1a47
--- /dev/null
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/misc-unused-invalid-parameter.cpp
@@ -0,0 +1,10 @@
+// RUN: %check_clang_tidy -fix-errors %s misc-unused-parameters %t
+
+namespace GH56152 {
+// There's no way to know whether the parameter is used or not if the parameter
+// is an invalid declaration. Ensure the diagnostic is suppressed in this case.
+void func(unknown_type value) { // CHECK-MESSAGES: :[[@LINE]]:11: error: 
unknown type name 'unknown_type'
+  value += 1;
+}
+}
+



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

[PATCH] D128043: [flang][driver] Add support for `-O{0|1|2|3}`

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski added a comment.

Thanks for taking a look, @peixin! Just to clarify - I'm not really looking 
into `-Os`, `-Ofast` or `-Oz` at the moment. But I'm always happy to review 
driver patches :)




Comment at: clang/include/clang/Driver/Options.td:732
+def O_flag : Flag<["-"], "O">, Flags<[CC1Option,FC1Option]>, Alias, 
AliasArgs<["1"]>;
 def Ofast : Joined<["-"], "Ofast">, Group, Flags<[CC1Option]>;
 def P : Flag<["-"], "P">, Flags<[CC1Option,FlangOption,FC1Option]>, 
Group,

peixin wrote:
> Will enabling Ofast require more changes in the flang frontend? If yes, it is 
> OK to support it in another patch later.
I would much prefer to have it implemented it in a dedicated patch.

For every option, one has to consider the semantics in the compiler driver 
(`flang-new`) vs frontend driver (`flang-new -fc1`) and then, in case of 
code-gen flags, the difference between middle-end and back-end pass pipelines. 
So quite a few things :)

In general, I'm in favor of doing this incrementally, in small patches. This 
makes reviewing and testing easier and more self-contained. Is that OK?



Comment at: flang/include/flang/Frontend/CodeGenOptions.def:30
+
+VALUE_CODEGENOPT(OptimizationLevel, 2, 0) ///< The -O[0-3] option specified.
+

peixin wrote:
> I saw `clang/include/clang/Basic/CodeGenOptions.def` has the following:
> ```
> VALUE_CODEGENOPT(OptimizationLevel, 2, 0) ///< The -O[0-3] option specified.
> VALUE_CODEGENOPT(OptimizeSize, 2, 0) ///< If -Os (==1) or -Oz (==2) is 
> specified.
> ```
> 
> Do `-Os` and `-Oz` need extra processing in flang drivers? If yes, it is OK 
> to support it in another patch later.
> Do -Os and -Oz need extra processing in flang drivers? 

These are code-size optimisation flags, so the logic will be a bit different.

Also, I'm very much in favor of small, incremental and self-contained patches. 
Splitting this into regular and size optimizations seemed like a natural split.



Comment at: flang/lib/Frontend/CodeGenOptions.cpp:8
+//===--===//
+
+#include "flang/Frontend/CodeGenOptions.h"

peixin wrote:
> Miss the following?
> ```
> //
> // Coding style: https://mlir.llvm.org/getting_started/DeveloperGuide/
> //
> //===--===//
> ```
> 
Good catch, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128043

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

[PATCH] D127446: [clang-tidy] Add `-verify-config` command line argument

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!




Comment at: 
clang-tools-extra/test/clang-tidy/infrastructure/verify-config.cpp:12
+
+// CHECK-VERIFY-DAG: command-line option '-config': warning: Unknown Check 
'readability-else-after-ret'; did you mean 'readability-else-after-return'
+// CHECK-VERIFY-DAG: command-line option '-config': warning: Unknown Check 
Option 'modernize-lop-convert.UseCxx20ReverseRanges'; did you mean 
'modernize-loop-convert.UseCxx20ReverseRanges'

njames93 wrote:
> aaron.ballman wrote:
> > njames93 wrote:
> > > aaron.ballman wrote:
> > > > It's unfortunate that `warning: ` appears in the middle of the 
> > > > diagnostic as opposed to at the start. I wonder if this can be reworked 
> > > > to say: `warning: Unknown check 'whatever'; did you mean 'whatever'? 
> > > > [-verify-config]` or something?
> > > > 
> > > > Also, no test coverage for the error case and for the unknown check 
> > > > case where there's no closest match worth talking about.
> > > Warning appearing in the middle is kind of by design as when clang emits 
> > > diagnostics, the source location is the first thing emitted, then the 
> > > type(warning|error). In this case `command-line option '-config'` is the 
> > > "source location"
> > > 
> > > > Also, no test coverage for the error case.
> > > I'm not 100% on that, there is no checking when the check glob is 
> > > actually built and I haven't figured out how to break it.
> > >  then the type(warning|error). In this case command-line option '-config' 
> > > is the "source location"
> > 
> > Ah, thanks for explaining your logic. FWIW, Clang uses a different style 
> > for that (``): https://godbolt.org/z/f1rdsbjqe Perhaps we 
> > should follow suit? (In fact, we could use the diagnostic engine for this 
> > instead of emitting to the error stream ourselves?)
> The issue is, we don't have the actual source information right now to print 
> better error messages.
After some off-list discussion (thanks @njames93!) I'm retracting my concerns 
here for the moment because there are larger issues with the diagnostics engine 
to be solved first.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127446

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

[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

[Erich Keane via Phabricator via cfe-commits]

erichkeane marked an inline comment as done.
erichkeane added a comment.

In D126907#3600876 , @ChuanqiXu wrote:

> Great progress!
>
> In D126907#3599835 , @erichkeane 
> wrote:
>
>> Note that the failure comes down to:
>>
>>   template concept C = T::f();
>>   template class P> struct S1{};
>>   template struct X{};
>>   S1 s11;
>>
>> and requires the -frelaxed-template-template-args flag:
>>
>>   [ekeane1@scsel-clx-24 build]$  ./bin/clang -cc1 -std=c++20 temp.cpp 
>> -frelaxed-template-template-args
>>   temp.cpp:5:4: error: template template argument 'X' is more constrained 
>> than template template parameter 'P'
>>   S1 s11;
>>  ^
>>   temp.cpp:3:29: note: 'P' declared here
>>   template  class P> struct S1{};
>>   ^
>>   temp.cpp:4:20: note: 'X' declared here
>>   template struct X{};
>>  ^
>>   1 error generated.
>
> As far as I could tell, we could omit the diagnostic by deleting 
> https://github.com/llvm/llvm-project/blob/bc74bca5363270e987c2e3c263bfaaeb6ceab66f/clang/include/clang/Sema/SemaConcept.h#L45-L53
>
> This change is obsolutely wrong but it shows the bug comes from 
> `ParameterMapping` so we could locate 
> https://github.com/llvm/llvm-project/blob/bc74bca5363270e987c2e3c263bfaaeb6ceab66f/clang/lib/Sema/SemaConcept.cpp#L723
>  further.

Thanks for the debugging help!  I'm not sure what you mean by "Locating it 
further"?  Best I can tell looking so far, is the fact that the 'depths' still 
point based on the 'root', but this is comparing thinking they are relative to 
the decl themselves.  I see the 'SubstTemplateArguments' there that looks 
suspicious, so there is probably something about setting up my template 
parameters correctly there/the MLTAL.

Thanks for the comments and debugging help again!




Comment at: clang/test/Driver/crash-report.cpp:28
+// RUNX: cat %t/crash-report-*.cpp | FileCheck --check-prefix=CHECKSRC %s
+// RUNX: cat %t/crash-report-*.sh | FileCheck --check-prefix=CHECKSH %s
 

ChuanqiXu wrote:
> What's the meaning of RUNX?
Woops!  I didn't add this test change to GIT, but it apparently still showed up 
with 'diff'.  For some reason, once I switched to lldb the llvm-symbolizer 
takes a HUGE amount of time during this test when doing check-all, so I used 
the 'X' to disable the test locally.  This is not intended to be committed.


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

https://reviews.llvm.org/D126907

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

[PATCH] D127446: [clang-tidy] Add `-verify-config` command line argument

[Nathan James via Phabricator via cfe-commits]

njames93 added subscribers: kadircet, sammccall.
njames93 added a comment.

Before this lands @sammccall @kadircet Do you have any concerns about this API 
for getting the options not building a static instance here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127446

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

[PATCH] D122677: [prototype] include-cleaner library

[serge via Phabricator via cfe-commits]

serge-sans-paille added a comment.

Hey Sam, any update on this one? How can I help?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122677

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

[PATCH] D128043: [flang][driver] Add support for `-O{0|1|2|3}`

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski updated this revision to Diff 438995.
awarzynski marked 3 inline comments as done.
awarzynski added a comment.

Address comments from Peixin and Diana

Main change - removed ENUM_CODEGENOPT and VALUE_CODEGENOPT from 
CodeGenOptions.dev.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128043

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/CodeGenOptions.def
  flang/include/flang/Frontend/CodeGenOptions.h
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/include/flang/Frontend/FrontendActions.h
  flang/lib/Frontend/CMakeLists.txt
  flang/lib/Frontend/CodeGenOptions.cpp
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/test/Driver/default-optimization-pipelines.f90
  flang/test/Driver/driver-help.f90

Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -95,6 +95,7 @@
 ! HELP-FC1-NEXT: -fdebug-measure-parse-tree
 ! HELP-FC1-NEXT: Measure the parse tree
 ! HELP-FC1-NEXT: -fdebug-module-writer   Enable debug messages while writing module files
+! HELP-FC1-NEXT: -fdebug-pass-managerPrints debug information for the new pass manage
 ! HELP-FC1-NEXT: -fdebug-pre-fir-treeDump the pre-FIR tree
 ! HELP-FC1-NEXT: -fdebug-unparse-no-sema Unparse and stop (skips the semantic checks)
 ! HELP-FC1-NEXT: -fdebug-unparse-with-symbols
@@ -119,6 +120,7 @@
 ! HELP-FC1-NEXT: -fno-analyzed-objects-for-unparse
 ! HELP-FC1-NEXT:Do not use the analyzed objects when unparsing
 ! HELP-FC1-NEXT: -fno-automatic Implies the SAVE attribute for non-automatic local objects in subprograms unless RECURSIVE
+! HELP-FC1-NEXT: -fno-debug-pass-manager Disables debug printing for the new pass manager
 ! HELP-FC1-NEXT: -fno-reformat  Dump the cooked character stream in -E mode
 ! HELP-FC1-NEXT: -fopenacc  Enable OpenACC
 ! HELP-FC1-NEXT: -fopenmp   Parse OpenMP pragmas and generate parallel code.
Index: flang/test/Driver/default-optimization-pipelines.f90
===
--- /dev/null
+++ flang/test/Driver/default-optimization-pipelines.f90
@@ -0,0 +1,24 @@
+! Verify that`-O{n}` is indeed taken into account when defining the LLVM optimization/middle-end pass pass pipeline.
+
+!---
+! RUN LINES
+!---
+! RUN: %flang_fc1 -S -O0 %s -fdebug-pass-manager -o /dev/null 2>&1 | FileCheck %s --check-prefix=CHECK-O0
+! RUN: %flang_fc1 -S -O2 %s -fdebug-pass-manager -o /dev/null 2>&1 | FileCheck %s --check-prefix=CHECK-O2
+
+!---
+! EXPECTED OUTPUT
+!---
+! CHECK-O0-NOT: Running pass: SimplifyCFGPass on simple_loop_
+! CHECK-O0: Running analysis: TargetLibraryAnalysis on simple_loop_
+
+! CHECK-O2: Running pass: SimplifyCFGPass on simple_loop_
+
+!---
+! INPUT
+!---
+subroutine simple_loop
+  integer :: i
+  do i=1,5
+  end do
+end subroutine
Index: flang/lib/Frontend/FrontendActions.cpp
===
--- flang/lib/Frontend/FrontendActions.cpp
+++ flang/lib/Frontend/FrontendActions.cpp
@@ -46,6 +46,7 @@
 #include "llvm/IRReader/IRReader.h"
 #include "llvm/MC/TargetRegistry.h"
 #include "llvm/Passes/PassBuilder.h"
+#include "llvm/Passes/StandardInstrumentations.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/SourceMgr.h"
 #include "llvm/Target/TargetMachine.h"
@@ -538,7 +539,6 @@
   /*Features=*/"",
   llvm::TargetOptions(), llvm::None));
   assert(tm && "Failed to create TargetMachine");
-  llvmModule->setDataLayout(tm->createDataLayout());
 }
 
 static std::unique_ptr
@@ -610,23 +610,59 @@
   codeGenPasses.run(llvmModule);
 }
 
-/// Generate LLVM byte code file from the input LLVM module.
-///
-/// \param [in] tm Target machine to aid the code-gen pipeline set-up
-/// \param [in] llvmModule LLVM module to lower to assembly/machine-code
-/// \param [out] os Output stream to emit the generated code to
-static void generateLLVMBCImpl(llvm::TargetMachine &tm,
-   llvm::Module &llvmModule,
-   llvm::raw_pwrite_stream &os) {
-  // Set-up the pass manager
-  llvm::ModulePassManager mpm;
+static llvm::OptimizationLevel
+mapToLevel(const Fortran::frontend::CodeGenOptions &opts) {
+  switch (opts.OptimizationLevel) {
+  default:
+llvm_unreachable("Invalid optimization level!");
+  case 0:
+return llvm::OptimizationLevel::O0;
+  case 1:
+return llvm::OptimizationLevel::O1;
+  case 2:
+return llvm::OptimizationLevel::O2;
+  case 3:
+return llvm::OptimizationLevel::O3;
+  }
+}
+
+void CodeGe

[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

My objection to the original patch was including things like the "" lines 
as remarks to mark a section. I don't think these should be emitted as remarks 
and are a display function the frontend should take care of if we want any kind 
of grouping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127923

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

[clang] 958a885 - [LinkerWrapper] Rework the linker wrapper and use owning binaries

[Joseph Huber via cfe-commits]

Author: Joseph Huber
Date: 2022-06-22T09:24:10-04:00
New Revision: 958a8850508088766fe19202037e2f46805e2c65

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

LOG: [LinkerWrapper] Rework the linker wrapper and use owning binaries

The linker wrapper currently eagerly extracts all identified offloading
binaries to a file. This isn't ideal because we will soon open these
files again to examine their symbols for LTO and other things.
Additionally, we may not use every extracted file in the case of static
libraries. This would be very noisy in the case of static libraries that
may contain code for several targets not participating in the current
link.

Recent changes allow us to treat an Offloading binary as a standard
binary class. So that allows us to use an OwningBinary to model the
file. Now we keep it in memory and only write it once we know which
files will be participating in the final link job. This also reworks a
lot of the structure around how we handle this by removing the old
DeviceFile class.

The main benefit from this is that the following doesn't output 32+ files and
instead will only output a single temp file for the linked module.
```
$ clang input.c -fopenmp --offload-arch=sm_70 -foffload-lto -save-temps
```

Reviewed By: JonChesterfield

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

Added: 


Modified: 
clang/test/Driver/linker-wrapper.c
clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp

Removed: 




diff  --git a/clang/test/Driver/linker-wrapper.c 
b/clang/test/Driver/linker-wrapper.c
index 51b5f73223639..ecd196313f5e8 100644
--- a/clang/test/Driver/linker-wrapper.c
+++ b/clang/test/Driver/linker-wrapper.c
@@ -92,3 +92,14 @@
 
 // LINKER_ARGS: lld{{.*}}-flavor gnu --no-undefined -shared -o {{.*}}.out 
{{.*}}.o a
 // LINKER_ARGS: nvlink{{.*}}-m64 -o {{.*}}.out -arch sm_70 {{.*}}.o a b
+
+// RUN: clang-offload-packager -o %t-lib.out \
+// RUN:   
--image=file=%S/Inputs/dummy-elf.o,kind=openmp,triple=nvptx64-nvidia-cuda,arch=sm_70
 \
+// RUN:   
--image=file=%S/Inputs/dummy-elf.o,kind=cuda,triple=nvptx64-nvidia-cuda,arch=sm_52
+// RUN: %clang -cc1 %s -triple x86_64-unknown-linux-gnu -emit-obj -o %t.o 
-fembed-offload-object=%t-lib.out
+// RUN: llvm-ar rcs %t.a %t.o
+// RUN: rm -f %t.o
+// RUN: %clang -cc1 %s -triple x86_64-unknown-linux-gnu -emit-obj -o %t-obj.o
+// RUN: clang-linker-wrapper --host-triple x86_64-unknown-linux-gnu --dry-run 
-save-temps \
+// RUN:   -linker-path /usr/bin/ld -- %t.a %t-obj.o -o a.out
+// RUN: not ls *-device-*

diff  --git a/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp 
b/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
index 4e0b5ab2024cc..75dee95b7030c 100644
--- a/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ b/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -28,6 +28,7 @@
 #include "llvm/Object/Archive.h"
 #include "llvm/Object/ArchiveWriter.h"
 #include "llvm/Object/Binary.h"
+#include "llvm/Object/IRObjectFile.h"
 #include "llvm/Object/ObjectFile.h"
 #include "llvm/Object/OffloadBinary.h"
 #include "llvm/Support/CommandLine.h"
@@ -68,8 +69,7 @@ static cl::opt LinkerUserPath("linker-path", 
cl::Required,

cl::cat(ClangLinkerWrapperCategory));
 
 static cl::opt
-TargetFeatures("target-feature",
-   cl::desc("Target features for triple"),
+TargetFeatures("target-feature", cl::desc("Target features for triple"),
cl::cat(ClangLinkerWrapperCategory));
 
 static cl::opt OptLevel("opt-level",
@@ -114,9 +114,8 @@ static cl::list
cl::value_desc(" or ="),
cl::cat(ClangLinkerWrapperCategory));
 
-static cl::opt Verbose("v",
- cl::desc("Verbose output from tools"),
- 
+static cl::opt Verbose("v", cl::desc("Verbose output from tools"),
+
  cl::cat(ClangLinkerWrapperCategory));
 
 static cl::opt DebugInfo(
@@ -165,63 +164,43 @@ static codegen::RegisterCodeGenFlags CodeGenFlags;
 /// 
diff erent but it should work for what is passed here.
 static constexpr unsigned FatbinaryOffset = 0x50;
 
-/// Information for a device offloading file extracted from the host.
-struct DeviceFile {
-  DeviceFile(OffloadKind Kind, StringRef TheTriple, StringRef Arch,
- StringRef Filename)
-  : Kind(Kind), TheTriple(TheTriple), Arch(Arch), Filename(Filename) {}
+using OffloadingImage = OffloadBinary::OffloadingImage;
+
+/// A class to contain the binary information for a single OffloadBinary.
+class OffloadFile : public OwningBinary {
+public:
+  using TargetID = std::pair;
+
+  OffloadFile(std::unique_ptr Binary,
+  std::unique_ptr Buffer)
+  : OwningBinary(std::move

[PATCH] D127246: [LinkerWrapper] Rework the linker wrapper and use owning binaries

[Joseph Huber via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG958a88505080: [LinkerWrapper] Rework the linker wrapper and 
use owning binaries (authored by jhuber6).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127246

Files:
  clang/test/Driver/linker-wrapper.c
  clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp

Index: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -28,6 +28,7 @@
 #include "llvm/Object/Archive.h"
 #include "llvm/Object/ArchiveWriter.h"
 #include "llvm/Object/Binary.h"
+#include "llvm/Object/IRObjectFile.h"
 #include "llvm/Object/ObjectFile.h"
 #include "llvm/Object/OffloadBinary.h"
 #include "llvm/Support/CommandLine.h"
@@ -68,8 +69,7 @@
cl::cat(ClangLinkerWrapperCategory));
 
 static cl::opt
-TargetFeatures("target-feature",
-   cl::desc("Target features for triple"),
+TargetFeatures("target-feature", cl::desc("Target features for triple"),
cl::cat(ClangLinkerWrapperCategory));
 
 static cl::opt OptLevel("opt-level",
@@ -114,9 +114,8 @@
cl::value_desc(" or ="),
cl::cat(ClangLinkerWrapperCategory));
 
-static cl::opt Verbose("v",
- cl::desc("Verbose output from tools"),
- 
+static cl::opt Verbose("v", cl::desc("Verbose output from tools"),
+
  cl::cat(ClangLinkerWrapperCategory));
 
 static cl::opt DebugInfo(
@@ -165,63 +164,43 @@
 /// different but it should work for what is passed here.
 static constexpr unsigned FatbinaryOffset = 0x50;
 
-/// Information for a device offloading file extracted from the host.
-struct DeviceFile {
-  DeviceFile(OffloadKind Kind, StringRef TheTriple, StringRef Arch,
- StringRef Filename)
-  : Kind(Kind), TheTriple(TheTriple), Arch(Arch), Filename(Filename) {}
+using OffloadingImage = OffloadBinary::OffloadingImage;
+
+/// A class to contain the binary information for a single OffloadBinary.
+class OffloadFile : public OwningBinary {
+public:
+  using TargetID = std::pair;
+
+  OffloadFile(std::unique_ptr Binary,
+  std::unique_ptr Buffer)
+  : OwningBinary(std::move(Binary), std::move(Buffer)) {}
 
-  OffloadKind Kind;
-  std::string TheTriple;
-  std::string Arch;
-  std::string Filename;
+  /// We use the Triple and Architecture pair to group linker inputs together.
+  /// This conversion function lets us use these files in a hash-map.
+  operator TargetID() const {
+return std::make_pair(getBinary()->getTriple(), getBinary()->getArch());
+  }
 };
 
 namespace llvm {
-/// Helper that allows DeviceFile to be used as a key in a DenseMap. For now we
-/// assume device files with matching architectures and triples but different
-/// offloading kinds should be handlded together, this may not be true in the
-/// future.
-
-// Provide DenseMapInfo for OffloadKind.
+// Provide DenseMapInfo so that OffloadKind can be used in a DenseMap.
 template <> struct DenseMapInfo {
   static inline OffloadKind getEmptyKey() { return OFK_LAST; }
   static inline OffloadKind getTombstoneKey() {
 return static_cast(OFK_LAST + 1);
   }
-  static unsigned getHashValue(const OffloadKind &Val) { return Val * 37U; }
+  static unsigned getHashValue(const OffloadKind &Val) { return Val; }
 
   static bool isEqual(const OffloadKind &LHS, const OffloadKind &RHS) {
 return LHS == RHS;
   }
 };
-template <> struct DenseMapInfo {
-  static DeviceFile getEmptyKey() {
-return {DenseMapInfo::getEmptyKey(),
-DenseMapInfo::getEmptyKey(),
-DenseMapInfo::getEmptyKey(),
-DenseMapInfo::getEmptyKey()};
-  }
-  static DeviceFile getTombstoneKey() {
-return {DenseMapInfo::getTombstoneKey(),
-DenseMapInfo::getTombstoneKey(),
-DenseMapInfo::getTombstoneKey(),
-DenseMapInfo::getTombstoneKey()};
-  }
-  static unsigned getHashValue(const DeviceFile &I) {
-return DenseMapInfo::getHashValue(I.TheTriple) ^
-   DenseMapInfo::getHashValue(I.Arch);
-  }
-  static bool isEqual(const DeviceFile &LHS, const DeviceFile &RHS) {
-return LHS.TheTriple == RHS.TheTriple && LHS.Arch == RHS.Arch;
-  }
-};
 } // namespace llvm
 
 namespace {
 
 Error extractFromBuffer(std::unique_ptr Buffer,
-SmallVectorImpl &DeviceFiles);
+SmallVectorImpl &DeviceFiles);
 
 void printCommands(ArrayRef CmdArgs) {
   if (CmdArgs.empty())
@@ -232,7 +211,7 @@
 llvm::errs() << *IC << (std::next(IC) != IE ? " " : "\n");
 }
 
-// Forward user requested arguments to the device linking job.
+/// Forward user requested arguments to the devi

[clang] 21e29b6 - [Clang] Allow multiple comma separated arguments to `--offload-arch=`

[Joseph Huber via cfe-commits]

Author: Joseph Huber
Date: 2022-06-22T09:25:04-04:00
New Revision: 21e29b6ce734cca1557aa801740078d98c3ff447

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

LOG: [Clang] Allow multiple comma separated arguments to `--offload-arch=`

This patch updates the `--[no-]offload-arch` command line arguments to
allow the user to pass in many architectures in a single argument rather
than specifying it multiple times. This means that the following command
line,
```
clang foo.cu --offload-arch=sm_70 --offload-arch=sm_80
```
can become:
```
clang foo.cu --offload-arch=sm_70,sm_80
```

Reviewed By: ye-luo

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

Added: 


Modified: 
clang/lib/Driver/Driver.cpp
clang/test/Driver/cuda-bindings.cu
clang/test/Driver/openmp-offload-gpu-new.c

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 385c194cdeb7..67bcb418a52e 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -2977,7 +2977,7 @@ class OffloadingActionBuilder final {
  << "--offload";
   }
 
-  // Collect all cuda_gpu_arch parameters, removing duplicates.
+  // Collect all offload arch parameters, removing duplicates.
   std::set GpuArchs;
   bool Error = false;
   for (Arg *A : Args) {
@@ -2986,21 +2986,22 @@ class OffloadingActionBuilder final {
   continue;
 A->claim();
 
-StringRef ArchStr = A->getValue();
-if (A->getOption().matches(options::OPT_no_offload_arch_EQ) &&
-ArchStr == "all") {
-  GpuArchs.clear();
-  continue;
+for (StringRef ArchStr : llvm::split(A->getValue(), ",")) {
+  if (A->getOption().matches(options::OPT_no_offload_arch_EQ) &&
+  ArchStr == "all") {
+GpuArchs.clear();
+  } else {
+ArchStr = getCanonicalOffloadArch(ArchStr);
+if (ArchStr.empty()) {
+  Error = true;
+} else if (A->getOption().matches(options::OPT_offload_arch_EQ))
+  GpuArchs.insert(ArchStr);
+else if (A->getOption().matches(options::OPT_no_offload_arch_EQ))
+  GpuArchs.erase(ArchStr);
+else
+  llvm_unreachable("Unexpected option.");
+  }
 }
-ArchStr = getCanonicalOffloadArch(ArchStr);
-if (ArchStr.empty()) {
-  Error = true;
-} else if (A->getOption().matches(options::OPT_offload_arch_EQ))
-  GpuArchs.insert(ArchStr);
-else if (A->getOption().matches(options::OPT_no_offload_arch_EQ))
-  GpuArchs.erase(ArchStr);
-else
-  llvm_unreachable("Unexpected option.");
   }
 
   auto &&ConflictingArchs = getConflictOffloadArchCombination(GpuArchs);
@@ -4356,14 +4357,15 @@ Driver::getOffloadArchs(Compilation &C, const 
llvm::opt::DerivedArgList &Args,
   llvm::DenseSet Archs;
   for (auto &Arg : Args) {
 if (Arg->getOption().matches(options::OPT_offload_arch_EQ)) {
-  Archs.insert(
-  getCanonicalArchString(C, Args, Arg->getValue(), TC->getTriple()));
+  for (StringRef Arch : llvm::split(Arg->getValue(), ","))
+Archs.insert(getCanonicalArchString(C, Args, Arch, TC->getTriple()));
 } else if (Arg->getOption().matches(options::OPT_no_offload_arch_EQ)) {
-  if (Arg->getValue() == StringRef("all"))
-Archs.clear();
-  else
-Archs.erase(
-getCanonicalArchString(C, Args, Arg->getValue(), TC->getTriple()));
+  for (StringRef Arch : llvm::split(Arg->getValue(), ",")) {
+if (Arch == StringRef("all"))
+  Archs.clear();
+else
+  Archs.erase(getCanonicalArchString(C, Args, Arch, TC->getTriple()));
+  }
 }
   }
 

diff  --git a/clang/test/Driver/cuda-bindings.cu 
b/clang/test/Driver/cuda-bindings.cu
index 178db31a2905..6cc21251bfdd 100644
--- a/clang/test/Driver/cuda-bindings.cu
+++ b/clang/test/Driver/cuda-bindings.cu
@@ -40,6 +40,7 @@
 // Test two gpu architectures with complete compilation.
 //
 // RUN: %clang -target powerpc64le-ibm-linux-gnu -ccc-print-bindings 
--cuda-gpu-arch=sm_30 --cuda-gpu-arch=sm_35 %s 2>&1 \
+// RUN: %clang -target powerpc64le-ibm-linux-gnu -ccc-print-bindings 
--offload-arch=sm_30,sm_35 %s 2>&1 \
 // RUN: | FileCheck -check-prefix=BIN2 %s
 // BIN2: # "nvptx64-nvidia-cuda" - "clang",{{.*}} output:
 // BIN2-NOT: cuda-bindings-device-cuda-nvptx64

diff  --git a/clang/test/Driver/openmp-offload-gpu-new.c 
b/clang/test/Driver/openmp-offload-gpu-new.c
index 8eb197af1fd4..4c2748515cf0 100644
--- a/clang/test/Driver/openmp-offload-gpu-new.c
+++ b/clang/test/Driver/openmp-offload-gpu-new.c
@@ -51,6 +51,8 @@
 // CHECK-TEMP-BINDI

[PATCH] D128206: [Clang] Allow multiple comma separated arguments to `--offload-arch=`

[Joseph Huber 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 rG21e29b6ce734: [Clang] Allow multiple comma separated 
arguments to `--offload-arch=` (authored by jhuber6).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128206

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/cuda-bindings.cu
  clang/test/Driver/openmp-offload-gpu-new.c


Index: clang/test/Driver/openmp-offload-gpu-new.c
===
--- clang/test/Driver/openmp-offload-gpu-new.c
+++ clang/test/Driver/openmp-offload-gpu-new.c
@@ -51,6 +51,8 @@
 // CHECK-TEMP-BINDINGS: "x86_64-unknown-linux-gnu" - "Offload::Packager", 
inputs: ["[[DEVICE_OBJ:.+]]"], output: "[[BINARY:.+.out]]"
 
 // RUN:   %clang -### --target=x86_64-unknown-linux-gnu -ccc-print-bindings 
-fopenmp -fopenmp-targets=nvptx64-nvidia-cuda --offload-arch=sm_52 
--offload-arch=sm_70 -nogpulib %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-ARCH-BINDINGS
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -ccc-print-bindings 
-fopenmp -fopenmp-targets=nvptx64-nvidia-cuda --offload-arch=sm_52,sm_70 
-nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-ARCH-BINDINGS
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -ccc-print-bindings 
-fopenmp -fopenmp-targets=nvptx64-nvidia-cuda 
--offload-arch=sm_52,sm_70,sm_35,sm_80 --no-offload-arch=sm_35,sm_80 -nogpulib 
%s 2>&1 | FileCheck %s --check-prefix=CHECK-ARCH-BINDINGS
 // CHECK-ARCH-BINDINGS: "x86_64-unknown-linux-gnu" - "clang", inputs: 
["[[INPUT:.*]]"], output: "[[HOST_BC:.*]]"
 // CHECK-ARCH-BINDINGS: "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT]]", 
"[[HOST_BC]]"], output: "[[DEVICE_BC_SM_52:.*]]"
 // CHECK-ARCH-BINDINGS: "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: 
["[[DEVICE_BC_SM_52]]"], output: "[[DEVICE_OBJ_SM_52:.*]]"
Index: clang/test/Driver/cuda-bindings.cu
===
--- clang/test/Driver/cuda-bindings.cu
+++ clang/test/Driver/cuda-bindings.cu
@@ -40,6 +40,7 @@
 // Test two gpu architectures with complete compilation.
 //
 // RUN: %clang -target powerpc64le-ibm-linux-gnu -ccc-print-bindings 
--cuda-gpu-arch=sm_30 --cuda-gpu-arch=sm_35 %s 2>&1 \
+// RUN: %clang -target powerpc64le-ibm-linux-gnu -ccc-print-bindings 
--offload-arch=sm_30,sm_35 %s 2>&1 \
 // RUN: | FileCheck -check-prefix=BIN2 %s
 // BIN2: # "nvptx64-nvidia-cuda" - "clang",{{.*}} output:
 // BIN2-NOT: cuda-bindings-device-cuda-nvptx64
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -2977,7 +2977,7 @@
  << "--offload";
   }
 
-  // Collect all cuda_gpu_arch parameters, removing duplicates.
+  // Collect all offload arch parameters, removing duplicates.
   std::set GpuArchs;
   bool Error = false;
   for (Arg *A : Args) {
@@ -2986,21 +2986,22 @@
   continue;
 A->claim();
 
-StringRef ArchStr = A->getValue();
-if (A->getOption().matches(options::OPT_no_offload_arch_EQ) &&
-ArchStr == "all") {
-  GpuArchs.clear();
-  continue;
+for (StringRef ArchStr : llvm::split(A->getValue(), ",")) {
+  if (A->getOption().matches(options::OPT_no_offload_arch_EQ) &&
+  ArchStr == "all") {
+GpuArchs.clear();
+  } else {
+ArchStr = getCanonicalOffloadArch(ArchStr);
+if (ArchStr.empty()) {
+  Error = true;
+} else if (A->getOption().matches(options::OPT_offload_arch_EQ))
+  GpuArchs.insert(ArchStr);
+else if (A->getOption().matches(options::OPT_no_offload_arch_EQ))
+  GpuArchs.erase(ArchStr);
+else
+  llvm_unreachable("Unexpected option.");
+  }
 }
-ArchStr = getCanonicalOffloadArch(ArchStr);
-if (ArchStr.empty()) {
-  Error = true;
-} else if (A->getOption().matches(options::OPT_offload_arch_EQ))
-  GpuArchs.insert(ArchStr);
-else if (A->getOption().matches(options::OPT_no_offload_arch_EQ))
-  GpuArchs.erase(ArchStr);
-else
-  llvm_unreachable("Unexpected option.");
   }
 
   auto &&ConflictingArchs = getConflictOffloadArchCombination(GpuArchs);
@@ -4356,14 +4357,15 @@
   llvm::DenseSet Archs;
   for (auto &Arg : Args) {
 if (Arg->getOption().matches(options::OPT_offload_arch_EQ)) {
-  Archs.insert(
-  getCanonicalArchString(C, Args, Arg->getValue(), TC->getTriple()));
+  for (StringRef Arch : llvm::split(Arg->getValue(), ","))
+Archs.insert(getCanonicalArchString(C, Args, Arch, TC->getTriple()));
 } else if (Arg->getOption().match

[PATCH] D128043: [flang][driver] Add support for `-O{0|1|2|3}`

[Peixin Qiao via Phabricator via cfe-commits]

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

LGTM




Comment at: clang/include/clang/Driver/Options.td:732
+def O_flag : Flag<["-"], "O">, Flags<[CC1Option,FC1Option]>, Alias, 
AliasArgs<["1"]>;
 def Ofast : Joined<["-"], "Ofast">, Group, Flags<[CC1Option]>;
 def P : Flag<["-"], "P">, Flags<[CC1Option,FlangOption,FC1Option]>, 
Group,

awarzynski wrote:
> peixin wrote:
> > Will enabling Ofast require more changes in the flang frontend? If yes, it 
> > is OK to support it in another patch later.
> I would much prefer to have it implemented it in a dedicated patch.
> 
> For every option, one has to consider the semantics in the compiler driver 
> (`flang-new`) vs frontend driver (`flang-new -fc1`) and then, in case of 
> code-gen flags, the difference between middle-end and back-end pass 
> pipelines. So quite a few things :)
> 
> In general, I'm in favor of doing this incrementally, in small patches. This 
> makes reviewing and testing easier and more self-contained. Is that OK?
> In general, I'm in favor of doing this incrementally, in small patches. This 
> makes reviewing and testing easier and more self-contained. Is that OK?

Cannot agree more.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128043

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

[PATCH] D127487: [Sema] Fix assertion failure when instantiating requires expression

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:2039
 TransConstraint = TransformExpr(Req->getConstraintExpr());
+if (!TransConstraint.isInvalid()) {
+  bool CheckSucceeded =

I think I'd rather collapse this into SOMETHING like:

``` assert((TransConstraint.isInvalid() || 
(SemaRef.CheckConstraintExpr(TransConstraint.get() || Trap.hasErrorOccurred()) 
&& "...");```

I think thats right?  



Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:2048
+// Use version of CheckConstraintSatisfaction that does no substitutions.
+if (!TransConstraint.isInvalid() &&
+!TransConstraint.get()->isInstantiationDependent() &&

Same sorta thing here, if our check is only used for an assert, we should call 
it in the assert.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127487

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

[PATCH] D113107: Support of expression granularity for _Float16.

[Phoebe Wang via Phabricator via cfe-commits]

pengfei added inline comments.



Comment at: clang/lib/CodeGen/CGExprComplex.cpp:896
+
+ComplexPairTy ComplexExprEmitter::EmitPromoted(const Expr *E) {
+  if (auto *BinOp = dyn_cast(E->IgnoreParens())) {

zahiraam wrote:
> pengfei wrote:
> > rjmccall wrote:
> > > pengfei wrote:
> > > > rjmccall wrote:
> > > > > zahiraam wrote:
> > > > > > rjmccall wrote:
> > > > > > > `EmitPromoted` should take the promotion type.
> > > > > > > 
> > > > > > > You are missing the logic in this file which handles *unpromoted* 
> > > > > > > emission (where you have a binary operator but the context wants 
> > > > > > > an unpromoted value) by recognizing that you need to do a 
> > > > > > > promoted operation and then truncate.
> > > > > > Sorry but not sure what you mean here. A case where we don't want 
> > > > > > any promotion would be:
> > > > > > 
> > > > > > float _Complex add(float _Complex a, float _Complex b) {
> > > > > >   return a + b;
> > > > > > }
> > > > > > 
> > > > > > In this case, getPromotionType would return the null type and 
> > > > > > EmitBinOps would just go through the  "older" control path where 
> > > > > > there is no promotion.
> > > > > > Unless I misunderstood your comment?
> > > > > > 
> > > > > > 
> > > > > I'm talking about the unpromoted emission path for an operation that 
> > > > > we want to *internally* promote.  So like your example but using 
> > > > > `_Float16` — we want to emit the binary `+` as a `float` operation, 
> > > > > but the context needs an unpromoted value because it's going to be 
> > > > > returned.
> > > > > 
> > > > > The promoted emission path (the various `EmitPromoted` methods) 
> > > > > represents a request by the caller to produce a result that doesn't 
> > > > > match the formal type of the expression.  The normal emission path 
> > > > > `Visit` etc.) represents a request by the caller to produce a result 
> > > > > normally, i.e. one that matches the formal type.  In general, we 
> > > > > always start in the latter because arbitrary contexts always expect a 
> > > > > value of the formal type; it's only these recursive calls within 
> > > > > promoted emitters that contextually want a promoted value.
> > > > > 
> > > > > In your current patch, you're entering the promoted path by 
> > > > > special-casing one context that frequently terminates promoted 
> > > > > emission: `EmitComplexExprIntoLValue`, which is used for things like 
> > > > > assignment.  That's not the right way to handle it, though.  Instead, 
> > > > > you should do like I asked you to do with the scalar emitter, which 
> > > > > is to recognize in the normal emission path for a promotable 
> > > > > operation (like binary `+`) that you need to promote the operation 
> > > > > and then unpromote the result.  Then things like 
> > > > > `EmitComplexExprIntoLValue` will continue to simply enter the normal 
> > > > > path because that's the kind of value they need, and the promotion 
> > > > > logic will do the right thing from there to ensure we don't emit a 
> > > > > `_Float16` operation in LLVM IR.
> > > > > 
> > > > > Incidentally, I thought of another context that you ought to do 
> > > > > promotion for: when we're converting a promotable value to a larger 
> > > > > floating-point type, we should presumably convert the promoted value 
> > > > > directly rather than truncating it to the unpromoted type before the 
> > > > > conversion.
> > > > I'm not familiar with the FE details, but I understand the background 
> > > > is just to promote expressions that have more than one operation. So I 
> > > > agree with @zahiraam, and
> > > > > to ensure we don't emit a _Float16 operation in LLVM IR
> > > > is not what we expected here.
> > > > 
> > > > `_Float16` is a ABI type for which a target supported has to lower any 
> > > > `_Float16` operations in LLVM IR. See what we have done on X86 backend 
> > > > by D107082.
> > > > 
> > > > That said, a single `a + b` can be and should be emitted as `%c = fadd 
> > > > half %a, %b`.
> > > Well, you can provide operation-by-operation lowering support if you want 
> > > to, but what's going to come out of Clang IRGen in this mode is not going 
> > > to rely on it.  It's far easier to just emit these operations 
> > > differently, always using `float`, than to try to recognize the special 
> > > cases where all the inputs are naturally `half` and so you might as well 
> > > emit a `half` operation.
> > > 
> > > And I think the postcondition that `half` operations don't come out of 
> > > IRGen is a generally useful property even if you've already written this 
> > > lowering code.  Among other things, it makes it easy to test that you 
> > > haven't missed a case where you should be doing promoted emission.
> > We define `_Float16` as ABI type and require targets to support the ABI 
> > lowering. See 
> > https://clang.llvm.org/docs/LanguageExtensions.html#half-precision-floating-point
> >  Promoting in FE doesn'

[clang] a9fd8b9 - [LinkerWrapper] Fix calls to deleted Error constructor on older compilers

[Joseph Huber via cfe-commits]

Author: Joseph Huber
Date: 2022-06-22T09:39:23-04:00
New Revision: a9fd8b911331dad1b5f94e3aba5ce0927e632ade

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

LOG: [LinkerWrapper] Fix calls to deleted Error constructor on older compilers

Summary:
A recent patch added some new code paths to the linker wrapper. Older
compilers seem to have problems with returning errors wrapped in
an Excepted type without explicitly moving them. This caused failures in
some of the buildbots. This patch fixes that.

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 75dee95b7030..f21f144fe424 100644
--- a/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ b/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -1022,7 +1022,7 @@ Expected writeOffloadFile(const OffloadFile 
&File) {
   if (Error Err = createOutputFile(Prefix + "-" + Binary.getTriple() + "-" +
Binary.getArch(),
Suffix, TempFile))
-return Err;
+return std::move(Err);
 
   Expected> OutputOrErr =
   FileOutputBuffer::create(TempFile, Binary.getImage().size());
@@ -1032,7 +1032,7 @@ Expected writeOffloadFile(const OffloadFile 
&File) {
   std::copy(Binary.getImage().bytes_begin(), Binary.getImage().bytes_end(),
 Output->getBufferStart());
   if (Error E = Output->commit())
-return E;
+return std::move(E);
 
   return static_cast(TempFile);
 }
@@ -1188,7 +1188,7 @@ linkAndWrapDeviceFiles(SmallVectorImpl 
&LinkerInputFiles) {
 // First link and remove all the input files containing bitcode.
 SmallVector InputFiles;
 if (Error Err = linkBitcodeFiles(Input, InputFiles, Triple, Arch))
-  return Err;
+  return std::move(Err);
 
 // Write any remaining device inputs to an output file for the linker job.
 for (const OffloadFile &File : Input) {



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

[PATCH] D128048: Add a new clang option "-ftime-trace-path"

[Jamie Schmeiser via Phabricator via cfe-commits]

jamieschmeiser added a comment.

Can you please use git rebase -i to collapse all the changes into a single 
change?  If this isn't done, it is difficult to know what is being reviewed as 
the changes only show the differences since your last revision, not all of the 
changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128048

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

[PATCH] D128048: Add a new clang option "-ftime-trace-path"

[Whitney Tsang via Phabricator via cfe-commits]

Whitney added a comment.

In D128048#3601579 , @jamieschmeiser 
wrote:

> Can you please use git rebase -i to collapse all the changes into a single 
> change?  If this isn't done, it is difficult to know what is being reviewed 
> as the changes only show the differences since your last revision, not all of 
> the changes.

I can see all the changes, make sure your link is not suffix with "new", or 
check the history tab to see what is it comparing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128048

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

[PATCH] D128048: Add a new clang option "-ftime-trace-path"

[dongjunduo via Phabricator via cfe-commits]

dongjunduo marked 4 inline comments as done.
dongjunduo added a comment.

In D128048#3601579 , @jamieschmeiser 
wrote:

> Can you please use git rebase -i to collapse all the changes into a single 
> change?  If this isn't done, it is difficult to know what is being reviewed 
> as the changes only show the differences since your last revision, not all of 
> the changes.

It seems that I have collapsed all the commits.  The panel "Revision 
Contents=>Commits" shows only a single commit record. Is that what you mean? : )


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128048

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

[PATCH] D127803: Generate the capture for field when the field is used with implicit default.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: clang/lib/Sema/SemaExprMember.cpp:1873-1877
+if (auto *PrivateCopy =
+isOpenMPFDCaptureDecl(Field, Base.get(), IsArrow, OpLoc, &SS,
+  /*TemplateKWLoc=*/SourceLocation(), Field,
+  FoundDecl, /*HadMultipleCandidates=*/false,
+  MemberNameInfo, MemberType, VK, OK))

Why do we need this function? Implicit private rule should apply (if should) 
only to this-Юашдув kind of expressions, if something like parent.field 
expression is used, parent should be private, not private.field. Or I'm missing 
something?



Comment at: clang/lib/Sema/SemaOpenMP.cpp:201
+using ImplicitFDCapTy = std::pair;
+// List of captuer fields
+llvm::SmallVector ImplicitDefaultFirstprivateFDs;

///



Comment at: clang/lib/Sema/SemaOpenMP.cpp:1129-1130
   }
+  // get captured field from ImplicitDefaultFirstprivateFDs
+  VarDecl *getImplicitFDCapExprDecl(const FieldDecl *FD) {
+const_iterator I = begin();

1. Use /// style of comment.
2. const member function?



Comment at: clang/lib/Sema/SemaOpenMP.cpp:1141
+  return nullptr;
+for (auto IFD : I->ImplicitDefaultFirstprivateFDs)
+  if (IFD.first.first == FD && IFD.first.second == Sz)

`const auto &`?



Comment at: clang/lib/Sema/SemaOpenMP.cpp:1146-1147
+  }
+  // Check if capture decl is field captured in ImplicitDefaultFirstprivateFDs
+  bool isImplicitDefaultFirstprivateFD(VarDecl *VD) {
+const_iterator I = begin();

1. Use /// style of comment.
2. const member function?



Comment at: clang/lib/Sema/SemaOpenMP.cpp:1155
+  return false;
+for (auto IFD : I->ImplicitDefaultFirstprivateFDs)
+  if (IFD.second == VD)

`const auto &`?



Comment at: clang/lib/Sema/SemaOpenMP.cpp:1160
+  }
+  // Store capture FD info in ImplicitDefaultFirstprivateFDs
+  void addImplicitDefaultFirstprivateFD(const FieldDecl *FD, VarDecl *VD) {

/// style



Comment at: clang/lib/Sema/SemaOpenMP.cpp:1167-1168
+  if (I->DefaultAttr == DSA_private || I->DefaultAttr == DSA_firstprivate) 
{
+I->ImplicitDefaultFirstprivateFDs.emplace_back(std::make_pair(FD, Sz),
+   VD);
+break;

just `emplace_back(FD, Sz, VD);`?



Comment at: clang/lib/Sema/SemaOpenMP.cpp:2410
 D,
-[](OpenMPClauseKind C, bool AppliedToPointee) {
+[](OpenMPClauseKind C, bool AppliedToPointee, ...) {
   return isOpenMPPrivate(C) && !AppliedToPointee;

Better to add an actual param type here but without Param name


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127803

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

[clang] 17e2702 - Clang AttributeReference: emit entries for "Undocumented" attributes.

[James Y Knight via cfe-commits]

Author: James Y Knight
Date: 2022-06-22T09:55:05-04:00
New Revision: 17e27025287b96026a4351e1d73931bb0c76dac2

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

LOG: Clang AttributeReference: emit entries for "Undocumented" attributes.

Almost all attributes currently marked `Undocumented` are user-facing
attributes which _ought_ to be documented, but nobody has written it
yet. This change ensures that we at least acknowledge that these
attributes exist in the documentation, even if we have no description
of their semantics.

A new category, `InternalOnly` has been added for those few attributes
which are not user-facing, and should remain omitted from the docs.

Added: 


Modified: 
clang/docs/InternalsManual.rst
clang/include/clang/Basic/Attr.td
clang/utils/TableGen/ClangAttrEmitter.cpp

Removed: 




diff  --git a/clang/docs/InternalsManual.rst b/clang/docs/InternalsManual.rst
index 8ef88225f1809..72228fcc2e0ae 100644
--- a/clang/docs/InternalsManual.rst
+++ b/clang/docs/InternalsManual.rst
@@ -2920,7 +2920,7 @@ that is named after the attribute being documented.
 
 If the attribute is not for public consumption, or is an implicitly-created
 attribute that has no visible spelling, the documentation list can specify the
-``Undocumented`` object. Otherwise, the attribute should have its documentation
+``InternalOnly`` object. Otherwise, the attribute should have its documentation
 added to AttrDocs.td.
 
 Documentation derives from the ``Documentation`` tablegen type. All derived

diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 5f77073413fbf..cb47215f7e1d1 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -19,10 +19,19 @@ def DocCatType : DocumentationCategory<"Type Attributes">;
 def DocCatStmt : DocumentationCategory<"Statement Attributes">;
 def DocCatDecl : DocumentationCategory<"Declaration Attributes">;
 
-// Attributes listed under the Undocumented category do not generate any public
-// documentation. Ideally, this category should be used for internal-only
-// attributes which contain no spellings.
-def DocCatUndocumented : DocumentationCategory<"Undocumented">;
+// This category is for attributes which have not yet been properly documented,
+// but should be.
+def DocCatUndocumented : DocumentationCategory<"Undocumented"> {
+  let Content = [{
+This section lists attributes which are recognized by Clang, but which are
+currently missing documentation.
+}];
+}
+
+// Attributes listed under the InternalOnly category do not generate any entry
+// in the documentation.  This category should be used only when we _want_
+// to not document the attribute, e.g. if the attribute has no spellings.
+def DocCatInternalOnly : DocumentationCategory<"InternalOnly">;
 
 class DocDeprecated {
   // If the Replacement field is empty, no replacement will be listed with the
@@ -48,11 +57,17 @@ class Documentation {
   DocDeprecated Deprecated;
 }
 
-// Specifies that the attribute is explicitly undocumented. This can be a
-// helpful placeholder for the attribute while working on the implementation,
-// but should not be used once feature work has been completed.
+// Specifies that the attribute is explicitly omitted from the documentation,
+// because it is not intended to be user-facing.
+def InternalOnly : Documentation {
+  let Category = DocCatInternalOnly;
+}
+
+// Specifies that the attribute is undocumented, but that it _should_ have
+// documentation.
 def Undocumented : Documentation {
   let Category = DocCatUndocumented;
+  let Content = "No documentation.";
 }
 
 include "clang/Basic/AttrDocs.td"
@@ -626,7 +641,7 @@ class IgnoredAttr : Attr {
   let Ignored = 1;
   let ASTNode = 0;
   let SemaHandler = 0;
-  let Documentation = [Undocumented];
+  let Documentation = [InternalOnly];
 }
 
 //
@@ -706,14 +721,14 @@ def AlignMac68k : InheritableAttr {
   // This attribute has no spellings as it is only ever created implicitly.
   let Spellings = [];
   let SemaHandler = 0;
-  let Documentation = [Undocumented];
+  let Documentation = [InternalOnly];
 }
 
 def AlignNatural : InheritableAttr {
   // This attribute has no spellings as it is only ever created implicitly.
   let Spellings = [];
   let SemaHandler = 0;
-  let Documentation = [Undocumented];
+  let Documentation = [InternalOnly];
 }
 
 def AlwaysInline : DeclOrStmtAttr {
@@ -1188,7 +1203,7 @@ def CUDAInvalidTarget : InheritableAttr {
   let Spellings = [];
   let Subjects = SubjectList<[Function]>;
   let LangOpts = [CUDA];
-  let Documentation = [Undocumented];
+  let Documentation = [InternalOnly];
 }
 
 def CUDALaunchBounds : InheritableAttr {
@@ -1440,7 +1455,9 @@ def Final : InheritableAttr {
   let Spellings = [Keyword<"fina

[PATCH] D126859: [clangd] Validate clang-tidy CheckOptions in clangd config

[Nathan James via Phabricator via cfe-commits]

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

Remove typo correction support.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126859

Files:
  clang-tools-extra/clangd/ConfigCompile.cpp
  clang-tools-extra/clangd/TidyProvider.cpp
  clang-tools-extra/clangd/TidyProvider.h
  clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp

Index: clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp
===
--- clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp
+++ clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp
@@ -338,7 +338,9 @@
   EXPECT_EQ(
   Conf.Diagnostics.ClangTidy.Checks,
   "bugprone-use-after-move,llvm-*,-llvm-include-order,-readability-*");
-  EXPECT_THAT(Diags.Diagnostics, IsEmpty());
+  EXPECT_THAT(Diags.Diagnostics,
+  ElementsAre(diagMessage(
+  "unknown clang-tidy option 'example-check.ExampleOption'")));
 #else // !CLANGD_TIDY_CHECKS
   EXPECT_EQ(Conf.Diagnostics.ClangTidy.Checks, "llvm-*,-readability-*");
   EXPECT_THAT(
@@ -346,7 +348,9 @@
   ElementsAre(
   diagMessage(
   "clang-tidy check 'bugprone-use-after-move' was not found"),
-  diagMessage("clang-tidy check 'llvm-include-order' was not found")));
+  diagMessage("clang-tidy check 'llvm-include-order' was not found"),
+  diagMessage(
+  "unknown clang-tidy option 'example-check.ExampleOption'")));
 #endif
 }
 
@@ -355,6 +359,7 @@
   Tidy.Add.emplace_back("unknown-check");
   Tidy.Remove.emplace_back("*");
   Tidy.Remove.emplace_back("llvm-includeorder");
+
   EXPECT_TRUE(compileAndApply());
   // Ensure bad checks are stripped from the glob.
   EXPECT_EQ(Conf.Diagnostics.ClangTidy.Checks, "-*");
@@ -368,6 +373,43 @@
   diagKind(llvm::SourceMgr::DK_Warning;
 }
 
+TEST_F(ConfigCompileTests, TidyBadOptions) {
+  auto &Tidy = Frag.Diagnostics.ClangTidy;
+  Tidy.CheckOptions.emplace_back(
+  std::make_pair(std::string("BadGlobal"), std::string("true")));
+  Tidy.CheckOptions.emplace_back(
+  std::make_pair(std::string("StrictModes"), std::string("true")));
+  Tidy.CheckOptions.emplace_back(std::make_pair(
+  std::string("readability-braces-around-statements.ShortStatementsLines"),
+  std::string("1")));
+  Tidy.CheckOptions.emplace_back(std::make_pair(
+  std::string("readability-braces-around-statements.ShortStatementLines"),
+  std::string("1")));
+  EXPECT_TRUE(compileAndApply());
+#if CLANGD_TIDY_CHECKS
+  EXPECT_THAT(
+  Diags.Diagnostics,
+  ElementsAre(
+  diagMessage("unknown clang-tidy option 'BadGlobal'"),
+  diagMessage("unknown clang-tidy option 'StrictModes'"),
+  diagMessage(
+  "unknown clang-tidy option "
+  "'readability-braces-around-statements.ShortStatementsLines'")));
+#else // !CLANGD_TIDY_CHECKS
+  EXPECT_THAT(
+  Diags.Diagnostics,
+  ElementsAre(
+  diagMessage("unknown clang-tidy option 'BadGlobal'"),
+  diagMessage("unknown clang-tidy option 'StrictModes';"),
+  diagMessage(
+  "unknown clang-tidy option "
+  "'readability-braces-around-statements.ShortStatementsLines'"),
+  diagMessage(
+  "unknown clang-tidy option "
+  "'readability-braces-around-statements.ShortStatementLines'")));
+#endif
+}
+
 TEST_F(ConfigCompileTests, ExternalServerNeedsTrusted) {
   Fragment::IndexBlock::ExternalBlock External;
   External.Server.emplace("xxx");
Index: clang-tools-extra/clangd/TidyProvider.h
===
--- clang-tools-extra/clangd/TidyProvider.h
+++ clang-tools-extra/clangd/TidyProvider.h
@@ -60,6 +60,8 @@
 /// \pre \p must not be empty, must not contain '*' or ',' or start with '-'.
 bool isRegisteredTidyCheck(llvm::StringRef Check);
 
+bool isRecognisedTidyOption(llvm::StringRef CheckOption);
+
 } // namespace clangd
 } // namespace clang
 
Index: clang-tools-extra/clangd/TidyProvider.cpp
===
--- clang-tools-extra/clangd/TidyProvider.cpp
+++ clang-tools-extra/clangd/TidyProvider.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "TidyProvider.h"
+#include "../clang-tidy/ClangTidy.h"
 #include "../clang-tidy/ClangTidyModuleRegistry.h"
 #include "Config.h"
 #include "support/FileCache.h"
@@ -18,6 +19,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSet.h"
 #include "llvm/Support/Allocator.h"
+#include "llvm/Support/ManagedStatic.h"
 #include "llvm/Support/Process.h"
 #include "llvm/Support/SourceMgr.h"
 #include 
@@ -283,24 +285,30 @@
   return Opts;
 }
 
+namespace {
+struct Creator {
+  static void *call() {
+return new tidy::NamesAndOptions(tidy::getAl

[PATCH] D112916: [clang-tidy] Confusable identifiers detection

[serge 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 rGc3574ef739fb: [clang-tidy] Confusable identifiers detection 
(authored by serge-sans-paille).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112916

Files:
  clang-tools-extra/clang-tidy/misc/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/ConfusableIdentifierCheck.cpp
  clang-tools-extra/clang-tidy/misc/ConfusableIdentifierCheck.h
  clang-tools-extra/clang-tidy/misc/ConfusableTable/BuildConfusableTable.cpp
  clang-tools-extra/clang-tidy/misc/ConfusableTable/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/ConfusableTable/confusables.txt
  clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/misc-confusable-identifiers.rst
  clang-tools-extra/test/clang-tidy/checkers/misc-confusable-identifiers.cpp

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

[PATCH] D128307: [pseudo] Store reduction sequences by pointer in heaps, instead of by value.

[Haojian Wu via Phabricator via cfe-commits]

hokein accepted this revision.
hokein added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:208
+  // Underlying storage for sequences pointed to by stored SequenceRefs.
+  std::deque SequenceStorage;
+  // We don't actually destroy the sequences between calls, to reuse storage.

I start to have a nervous feeling that we're going to add more and more 
intermediate data structure, which increases the complexity of the code, but I 
think the improvement is large enough to justify. 



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:220
 const GSS::Node* Base = nullptr;
-Sequence Seq;
+Sequence *Seq;
   };

nit: add a default value nullptr



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:270
+
+Sequences.emplace(F, PushSpec{N, Seq});
 return;

Just an idea (no action required)

If we want to do further optmization, here if a sequence have multiple Bases, 
we will have multiple elements in `Sequences` -- they have the form of (F, 
PushSpec{N, Seq}) where only N (the base node) is different. 

- if we change the PushSpec::Base to store the child node of Base, we could 
save a bunch of space in Sequences. (The base can be retrieved dynamically from 
the `child->parents()`).



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:317
   FamilySequences.emplace_back(Sequences.top().first.Rule,
-   Sequences.top().second.Seq);
+   *Sequences.top().second.Seq); // XXX
   FamilyBases.emplace_back(

What's XXX?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128307

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

[PATCH] D128337: [clang-tidy] Extend spelling for CheckOptions

[Nathan James via Phabricator via cfe-commits]

njames93 updated this revision to Diff 439018.
njames93 added a comment.
Herald added subscribers: usaxena95, kadircet.

Update some test files using new syntax.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128337

Files:
  clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
  clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
  clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
  clang-tools-extra/clangd/unittests/TidyProviderTests.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/Contributing.rst
  clang-tools-extra/docs/clang-tidy/index.rst
  clang-tools-extra/test/clang-tidy/checkers/google-module.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/Inputs/config-files/4/key-dict/.clang-tidy
  clang-tools-extra/test/clang-tidy/infrastructure/config-files.cpp

Index: clang-tools-extra/test/clang-tidy/infrastructure/config-files.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/config-files.cpp
+++ clang-tools-extra/test/clang-tidy/infrastructure/config-files.cpp
@@ -15,12 +15,16 @@
 // CHECK-COMMAND-LINE: HeaderFilterRegex: from command line
 
 // For this test we have to use names of the real checks because otherwise values are ignored.
+// Running with the old key: , value:  CheckOptions
 // RUN: clang-tidy -dump-config %S/Inputs/config-files/4/44/- -- | FileCheck %s -check-prefix=CHECK-CHILD4
+// Running with the new :  syntax
+// RUN: clang-tidy -dump-config %S/Inputs/config-files/4/key-dict/- -- | FileCheck %s -check-prefix=CHECK-CHILD4
+
 // CHECK-CHILD4: Checks: {{.*}}modernize-loop-convert,modernize-use-using,llvm-qualified-auto
-// CHECK-CHILD4-DAG: - key: llvm-qualified-auto.AddConstToQualified{{ *[[:space:]] *}}value: 'true'
-// CHECK-CHILD4-DAG: - key: modernize-loop-convert.MaxCopySize{{ *[[:space:]] *}}value: '20'
-// CHECK-CHILD4-DAG: - key: modernize-loop-convert.MinConfidence{{ *[[:space:]] *}}value: reasonable
-// CHECK-CHILD4-DAG: - key: modernize-use-using.IgnoreMacros{{ *[[:space:]] *}}value: 'false'
+// CHECK-CHILD4-DAG: llvm-qualified-auto.AddConstToQualified: 'true'
+// CHECK-CHILD4-DAG: modernize-loop-convert.MaxCopySize: '20'
+// CHECK-CHILD4-DAG: modernize-loop-convert.MinConfidence: reasonable
+// CHECK-CHILD4-DAG: modernize-use-using.IgnoreMacros: 'false'
 
 // RUN: clang-tidy --explain-config %S/Inputs/config-files/4/44/- -- | FileCheck %s -check-prefix=CHECK-EXPLAIN
 // CHECK-EXPLAIN: 'llvm-qualified-auto' is enabled in the {{.*}}{{[/\\]}}Inputs{{[/\\]}}config-files{{[/\\]}}4{{[/\\]}}44{{[/\\]}}.clang-tidy.
@@ -32,14 +36,21 @@
 // RUN: Checks: -llvm-qualified-auto, \
 // RUN: CheckOptions: [{key: modernize-loop-convert.MaxCopySize, value: 21}]}' \
 // RUN: %S/Inputs/config-files/4/44/- -- | FileCheck %s -check-prefix=CHECK-CHILD5
+// Also test with the {Key: Value} Syntax specified on command line
+// RUN: clang-tidy -dump-config \
+// RUN: --config='{InheritParentConfig: true, \
+// RUN: Checks: -llvm-qualified-auto, \
+// RUN: CheckOptions: {modernize-loop-convert.MaxCopySize: 21}}' \
+// RUN: %S/Inputs/config-files/4/44/- -- | FileCheck %s -check-prefix=CHECK-CHILD5
+
 // CHECK-CHILD5: Checks: {{.*}}modernize-loop-convert,modernize-use-using,llvm-qualified-auto,-llvm-qualified-auto
-// CHECK-CHILD5-DAG: - key: modernize-loop-convert.MaxCopySize{{ *[[:space:]] *}}value: '21'
-// CHECK-CHILD5-DAG: - key: modernize-loop-convert.MinConfidence{{ *[[:space:]] *}}value: reasonable
-// CHECK-CHILD5-DAG: - key: modernize-use-using.IgnoreMacros{{ *[[:space:]] *}}value: 'false'
+// CHECK-CHILD5-DAG: modernize-loop-convert.MaxCopySize: '21'
+// CHECK-CHILD5-DAG: modernize-loop-convert.MinConfidence: reasonable
+// CHECK-CHILD5-DAG: modernize-use-using.IgnoreMacros: 'false'
 
 // RUN: clang-tidy -dump-config \
 // RUN: --config='{InheritParentConfig: false, \
 // RUN: Checks: -llvm-qualified-auto}' \
 // RUN: %S/Inputs/config-files/4/44/- -- | FileCheck %s -check-prefix=CHECK-CHILD6
 // CHECK-CHILD6: Checks: {{.*-llvm-qualified-auto'? *$}}
-// CHECK-CHILD6-NOT: - key: modernize-use-using.IgnoreMacros
+// CHECK-CHILD6-NOT: modernize-use-using.IgnoreMacros
Index: clang-tools-extra/test/clang-tidy/infrastructure/Inputs/config-files/4/key-dict/.clang-tidy
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/Inputs/config-files/4/key-dict/.clang-tidy
@@ -0,0 +1,7 @@
+InheritParentConfig: true
+Checks: 'llvm-qualified-auto'
+CheckOptions:
+  modernize-loop-convert.MaxCopySize: '20'
+  llvm-qualified-auto.AddConstToQualified: 'true'
+  IgnoreMacros: 'false'
+
Index: clang-tools-extra/test/clang-tidy/checkers/google-module.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/google-module.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/google-modu

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 439020.
zahiraam marked 2 inline comments as done.

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

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/Float16-complex.c
  clang/test/CodeGen/X86/avx512fp16-complex.c
  clang/test/Sema/Float16.c
  clang/test/Sema/conversion-target-dep.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,18 +1,10 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/conversion-target-dep.c
===
--- clang/test/Sema/conversion-target-dep.c
+++ clang/test/Sema/conversion-target-dep.c
@@ -6,7 +6,7 @@
 
 long double ld;
 double d;
-_Float16 f16; // x86-error {{_Float16 is not supported on this target}}
+_Float16 f16;
 
 int main(void) {
   ld = d; // x86-warning {{implicit conversion increases floating-point precision: 'double' to 'long double'}}
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,18 +1,12 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
+
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=X86-PROM
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
   // X86-LABEL: @add_half_rr(
@@ -85,7 +86,29 @@
   return a * b;
 }
 _Float16 _Complex mul_half_cc(_Float16 _Complex a, _Float16 _Complex b) {
-  // X86-LABEL: @mul_half_cc(
+  // CHECK: @mul_half_cc(
+
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: %[[AC:[^ ]+]] = fmul float
+  // X86-PROM: %[[BD:[^ ]+]] = fmul float
+  // X86-PROM: %[[AD:[^ ]+]] = fmul float
+  // X86-PROM: %[[BC:[^ ]+]] = fmul float
+  // X86-PROM: %[[RR:[^ ]+]] = fsub float
+  // X86-PROM: %[[RI:[^ ]+]] = fadd float
+  // X86-PROM: fcmp uno float %[[RR]]
+  // X86-PROM: fcmp uno float %[[RI]]
+  // X86-PROM: call <2 x float> @__mulsc3(
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: %[[RETR:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: %[[RETI:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: store half {{.*}}, ptr %[[RETR]]
+  // X86-PROM: store half {

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGExprComplex.cpp:896
+
+ComplexPairTy ComplexExprEmitter::EmitPromoted(const Expr *E) {
+  if (auto *BinOp = dyn_cast(E->IgnoreParens())) {

pengfei wrote:
> zahiraam wrote:
> > pengfei wrote:
> > > rjmccall wrote:
> > > > pengfei wrote:
> > > > > rjmccall wrote:
> > > > > > zahiraam wrote:
> > > > > > > rjmccall wrote:
> > > > > > > > `EmitPromoted` should take the promotion type.
> > > > > > > > 
> > > > > > > > You are missing the logic in this file which handles 
> > > > > > > > *unpromoted* emission (where you have a binary operator but the 
> > > > > > > > context wants an unpromoted value) by recognizing that you need 
> > > > > > > > to do a promoted operation and then truncate.
> > > > > > > Sorry but not sure what you mean here. A case where we don't want 
> > > > > > > any promotion would be:
> > > > > > > 
> > > > > > > float _Complex add(float _Complex a, float _Complex b) {
> > > > > > >   return a + b;
> > > > > > > }
> > > > > > > 
> > > > > > > In this case, getPromotionType would return the null type and 
> > > > > > > EmitBinOps would just go through the  "older" control path where 
> > > > > > > there is no promotion.
> > > > > > > Unless I misunderstood your comment?
> > > > > > > 
> > > > > > > 
> > > > > > I'm talking about the unpromoted emission path for an operation 
> > > > > > that we want to *internally* promote.  So like your example but 
> > > > > > using `_Float16` — we want to emit the binary `+` as a `float` 
> > > > > > operation, but the context needs an unpromoted value because it's 
> > > > > > going to be returned.
> > > > > > 
> > > > > > The promoted emission path (the various `EmitPromoted` methods) 
> > > > > > represents a request by the caller to produce a result that doesn't 
> > > > > > match the formal type of the expression.  The normal emission path 
> > > > > > `Visit` etc.) represents a request by the caller to produce a 
> > > > > > result normally, i.e. one that matches the formal type.  In 
> > > > > > general, we always start in the latter because arbitrary contexts 
> > > > > > always expect a value of the formal type; it's only these recursive 
> > > > > > calls within promoted emitters that contextually want a promoted 
> > > > > > value.
> > > > > > 
> > > > > > In your current patch, you're entering the promoted path by 
> > > > > > special-casing one context that frequently terminates promoted 
> > > > > > emission: `EmitComplexExprIntoLValue`, which is used for things 
> > > > > > like assignment.  That's not the right way to handle it, though.  
> > > > > > Instead, you should do like I asked you to do with the scalar 
> > > > > > emitter, which is to recognize in the normal emission path for a 
> > > > > > promotable operation (like binary `+`) that you need to promote the 
> > > > > > operation and then unpromote the result.  Then things like 
> > > > > > `EmitComplexExprIntoLValue` will continue to simply enter the 
> > > > > > normal path because that's the kind of value they need, and the 
> > > > > > promotion logic will do the right thing from there to ensure we 
> > > > > > don't emit a `_Float16` operation in LLVM IR.
> > > > > > 
> > > > > > Incidentally, I thought of another context that you ought to do 
> > > > > > promotion for: when we're converting a promotable value to a larger 
> > > > > > floating-point type, we should presumably convert the promoted 
> > > > > > value directly rather than truncating it to the unpromoted type 
> > > > > > before the conversion.
> > > > > I'm not familiar with the FE details, but I understand the background 
> > > > > is just to promote expressions that have more than one operation. So 
> > > > > I agree with @zahiraam, and
> > > > > > to ensure we don't emit a _Float16 operation in LLVM IR
> > > > > is not what we expected here.
> > > > > 
> > > > > `_Float16` is a ABI type for which a target supported has to lower 
> > > > > any `_Float16` operations in LLVM IR. See what we have done on X86 
> > > > > backend by D107082.
> > > > > 
> > > > > That said, a single `a + b` can be and should be emitted as `%c = 
> > > > > fadd half %a, %b`.
> > > > Well, you can provide operation-by-operation lowering support if you 
> > > > want to, but what's going to come out of Clang IRGen in this mode is 
> > > > not going to rely on it.  It's far easier to just emit these operations 
> > > > differently, always using `float`, than to try to recognize the special 
> > > > cases where all the inputs are naturally `half` and so you might as 
> > > > well emit a `half` operation.
> > > > 
> > > > And I think the postcondition that `half` operations don't come out of 
> > > > IRGen is a generally useful property even if you've already written 
> > > > this lowering code.  Among other things, it makes it easy to test that 
> > > > you haven't missed a case where you should be doing promoted emission.
> > > We define 

[clang-tools-extra] 721875d - Reland "[gn build] (manually) port b94db7ed7eaf (Confusables.inc)"

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2022-06-22T10:38:14-04:00
New Revision: 721875db2b8a1bff8ac2ed353aca7809904d7187

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

LOG: Reland "[gn build] (manually) port b94db7ed7eaf (Confusables.inc)"

b94db7ed7eaf relanded in c3574ef739fb.

This relands commit 180bae08a04d4dc, rebased across the new version of
commit c3574ef739fb, and rebased across 10f7255d32b690.

Added: 

llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/misc/ConfusableTable/BUILD.gn

Modified: 
clang-tools-extra/clang-tidy/misc/ConfusableTable/CMakeLists.txt
llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/misc/BUILD.gn

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/misc/ConfusableTable/CMakeLists.txt 
b/clang-tools-extra/clang-tidy/misc/ConfusableTable/CMakeLists.txt
index 56eb23ff05dd3..836863c80b762 100644
--- a/clang-tools-extra/clang-tidy/misc/ConfusableTable/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/misc/ConfusableTable/CMakeLists.txt
@@ -1 +1,3 @@
-add_llvm_executable(make-confusable-table BuildConfusableTable.cpp)
+add_llvm_executable(make-confusable-table
+  BuildConfusableTable.cpp
+  )

diff  --git 
a/llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/misc/BUILD.gn 
b/llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/misc/BUILD.gn
index 5463d61e5ff84..aa7c11170c667 100644
--- a/llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/misc/BUILD.gn
+++ b/llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/misc/BUILD.gn
@@ -1,7 +1,22 @@
+import("//llvm/utils/gn/build/compiled_action.gni")
+
+compiled_action("Confusables.inc") {
+  tool = "ConfusableTable:make_confusable_table"
+
+  inputs = [ "ConfusableTable/confusables.txt" ]
+  outputs = [ "$target_gen_dir/$target_name" ]
+  args = [
+rebase_path(inputs[0], root_build_dir),
+rebase_path(outputs[0], root_build_dir),
+  ]
+}
+
 static_library("misc") {
   output_name = "clangTidyMiscModule"
   configs += [ "//llvm/utils/gn/build:clang_code" ]
+  include_dirs = [ target_gen_dir ]
   deps = [
+":Confusables.inc",
 "//clang-tools-extra/clang-tidy",
 "//clang-tools-extra/clang-tidy/utils",
 "//clang/lib/AST",
@@ -14,6 +29,7 @@ static_library("misc") {
 "//llvm/lib/Support",
   ]
   sources = [
+"ConfusableIdentifierCheck.cpp",
 "DefinitionsInHeadersCheck.cpp",
 "MiscTidyModule.cpp",
 "MisleadingBidirectional.cpp",

diff  --git 
a/llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/misc/ConfusableTable/BUILD.gn
 
b/llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/misc/ConfusableTable/BUILD.gn
new file mode 100644
index 0..41be2ae88d7cb
--- /dev/null
+++ 
b/llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/misc/ConfusableTable/BUILD.gn
@@ -0,0 +1,4 @@
+executable("make_confusable_table") {
+  deps = [ "//llvm/lib/Support" ]
+  sources = [ "BuildConfusableTable.cpp" ]
+}



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

[PATCH] D128119: [clang] enforce instantiation of constexpr template functions

[serge via Phabricator via cfe-commits]

serge-sans-paille updated this revision to Diff 439022.

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

https://reviews.llvm.org/D128119

Files:
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/SemaCXX/constexpr-late-instantiation.cpp


Index: clang/test/SemaCXX/constexpr-late-instantiation.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/constexpr-late-instantiation.cpp
@@ -0,0 +1,17 @@
+// Make sure foo is sinstantiated and we don't get a link error
+// RUN: %clang_cc1 -S -emit-llvm %s -o- | FileCheck %s
+
+template 
+constexpr T foo(T a);
+
+// CHECK-LABEL: define {{.*}} @main
+int main() {
+  // CHECK: call {{.*}} @_Z3fooIiET_S0_
+  int k = foo(5);
+}
+
+// CHECK-LABEL: define {{.*}} @_Z3fooIiET_S0_
+template 
+constexpr T foo(T a) {
+  return a;
+}
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -4856,6 +4856,10 @@
 if (getLangOpts().CPlusPlus11)
   Diag(PointOfInstantiation, diag::note_inst_declaration_hint)
 << Function;
+  } else if (!Recursive) {
+Function->setInstantiationIsPending(true);
+PendingInstantiations.push_back(
+std::make_pair(Function, PointOfInstantiation));
   }
 }
 


Index: clang/test/SemaCXX/constexpr-late-instantiation.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/constexpr-late-instantiation.cpp
@@ -0,0 +1,17 @@
+// Make sure foo is sinstantiated and we don't get a link error
+// RUN: %clang_cc1 -S -emit-llvm %s -o- | FileCheck %s
+
+template 
+constexpr T foo(T a);
+
+// CHECK-LABEL: define {{.*}} @main
+int main() {
+  // CHECK: call {{.*}} @_Z3fooIiET_S0_
+  int k = foo(5);
+}
+
+// CHECK-LABEL: define {{.*}} @_Z3fooIiET_S0_
+template 
+constexpr T foo(T a) {
+  return a;
+}
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -4856,6 +4856,10 @@
 if (getLangOpts().CPlusPlus11)
   Diag(PointOfInstantiation, diag::note_inst_declaration_hint)
 << Function;
+  } else if (!Recursive) {
+Function->setInstantiationIsPending(true);
+PendingInstantiations.push_back(
+std::make_pair(Function, PointOfInstantiation));
   }
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D125916: [PowerPC] Defined and lowered llvm.ppc.kill.canary intrinsic

[ChenZheng via Phabricator via cfe-commits]

shchenz added inline comments.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11136
+MachineFrameInfo &MFI = MF.getFrameInfo();
+int SPI = MFI.getStackProtectorIndex(); // should return  -1
+

Why should return -1?



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11144
+
+unsigned int deadBird = 0x4C6C566D; // replaces canary word
+

nit: the first letter should be upper for `deadBird` according to LLVM coding 
style.

And how can we make sure `0x4C6C566D` is not the same with the canary word load 
with `TargetOpcode::LOAD_STACK_GUARD`?



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11146
+
+SDValue Store = DAG.getStore( // create store instr, stores (deadBird + 0) 
into addr (frame index + stack protector)
+Op->getOperand(0), 

Need to run clang-format for the new codes.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11160
+return Store;
+break;
+  }

nit: no need for the break after a return



Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:3
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu < %s | 
\
+; RUN:   FileCheck %s
+

We may also need to add test cases for AIX 32/64 bit too as stack protector is 
also supported on AIX.



Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:13
+; CHECK-NEXT:stw 3, -17(1)
+; CHECK-NEXT:blr
+entry:

This seems wrong. When there is no stack protector related instructions in the 
function, we should not generate the killed store to the stack slot for canary 
word.

The store instruction now will store a word to the caller unexpectedly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125916

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

[PATCH] D127142: [HIP] Link with clang_rt.builtins

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D127142#3600809 , @MaskRay wrote:

> Magically deciding a default value for --unwindlib or --rtlib is not nice. 
> You may emit a warning if the selected default happens to be incompatible 
> with HIP.

We build clang not just for compiling HIP programs. For C/C++ programs, we want 
to use the default runtime and unwind library.

We only want to change the default runtime and unwind library for HIP.


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

https://reviews.llvm.org/D127142

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

[PATCH] D113107: Support of expression granularity for _Float16.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Supporting the lowering in the backend is sensible in order to support 
`-fexcess-precision=16`, because I agree that the most reasonable IR output in 
that configuration is to simply generate `half` operations.  But under 
`-fexcess-precision=32`, I do not want the frontend to be in the business of 
recognizing cases where promoted emission is unnecessary, because that is just 
a lot of extra complexity for something that's already fairly special-case 
logic; among other things, it will tend to hide bugs.

> I don't understand, how can we check the missed cases if the promotion was 
> done in FE?

You simply test that you do not see any unpromoted operations coming out of the 
frontend.  Any operation emitted on `half` (except conversions to and from 
other types) is probably a missed opportunity to be doing promoted emission.  
For example, if we saw that `x += y + z` performed a `half` operation for the 
final addition, it would suggest that we had a bug in the emission of `+=`, not 
just because we were emitting a `half` operation but because we were likely 
failing to propagate promoted emission into the RHS of the operator, i.e. that 
we were introducing an unnecessary truncation there.

Of course, knowing that we aren't doing operations on `half` doesn't mean we 
aren't doing unnecessary truncations explicitly, so we still need to be testing 
such cases.  But it's an easy way to see bugs when simply scanning the IR 
generated for a program.


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

https://reviews.llvm.org/D113107

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

[PATCH] D127898: [clang][dataflow] Add API to separate analysis from diagnosis

[Stanislav Gatev via Phabricator via cfe-commits]

sgatev added inline comments.



Comment at: clang/include/clang/Analysis/FlowSensitive/Diagnosis.h:26
+template 
+using Diagnosis =
+std::function;

Let's add some documentation for `Diagnosis` and `diagnoseCFG`.



Comment at: clang/include/clang/Analysis/FlowSensitive/Diagnosis.h:27
+using Diagnosis =
+std::function;
+

`#include `



Comment at: clang/include/clang/Analysis/FlowSensitive/Diagnosis.h:32
+const ControlFlowContext &CFCtx,
+std::vector> &BlockStates,
+const Environment &Env, TypeErasedDataflowAnalysis &Analysis,

`#include ` and `#include "llvm/ADT/Optional.h"`



Comment at: clang/include/clang/Analysis/FlowSensitive/Diagnosis.h:49
+  }
+  return std::move(Diags);
+}

`#include `



Comment at: clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h:49
+template  struct DiagnoseState {
+  DiagnoseState(DiagsT &Diags, const Environment &Env)
+  : Diags(Diags), Env(Env) {}

Move this to Diagnosis.h?



Comment at: 
clang/include/clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h:76
 
+class UncheckedOptionalAccessDiagnosis {
+public:

Move this to a new UncheckedOptionalAccessDiagnosis.(h,cpp)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127898

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

[PATCH] D128351: [clang] missing outer template levels when checking template constraints

[Sirui Mu via Phabricator via cfe-commits]

Lancern created this revision.
Lancern added reviewers: Richard, smith.
Herald added a project: All.
Lancern requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

When checking constraint satisfaction on template arguments, the outer
template levels are not added to MultiLevelTemplateArgumentList.

Fix bugs https://github.com/llvm/llvm-project/issues/50845


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128351

Files:
  clang/lib/Sema/SemaConcept.cpp
  clang/test/Sema/template-member-constraint.cpp


Index: clang/test/Sema/template-member-constraint.cpp
===
--- /dev/null
+++ clang/test/Sema/template-member-constraint.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 %s -std=c++20 -fsyntax-only -verify
+
+template 
+concept Foo = true;
+
+template 
+struct Bar {};
+
+template 
+struct Baz {
+  template 
+  using BazBar = Bar;
+
+  using BazBarInt = BazBar; // expected-no-diagnostics
+};
+
+template 
+struct contiguous_range {
+  template 
+requires(const_range == false)
+  using basic_iterator = int;
+
+  auto begin() {
+return basic_iterator{}; // expected-no-diagnostics
+  }
+};
Index: clang/lib/Sema/SemaConcept.cpp
===
--- clang/lib/Sema/SemaConcept.cpp
+++ clang/lib/Sema/SemaConcept.cpp
@@ -293,6 +293,7 @@
 
   MultiLevelTemplateArgumentList MLTAL;
   MLTAL.addOuterTemplateArguments(TemplateArgs);
+  MLTAL.addOuterRetainedLevels(Template->getTemplateDepth());
 
   for (const Expr *ConstraintExpr : ConstraintExprs) {
 if (calculateConstraintSatisfaction(S, Template, TemplateArgs,


Index: clang/test/Sema/template-member-constraint.cpp
===
--- /dev/null
+++ clang/test/Sema/template-member-constraint.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 %s -std=c++20 -fsyntax-only -verify
+
+template 
+concept Foo = true;
+
+template 
+struct Bar {};
+
+template 
+struct Baz {
+  template 
+  using BazBar = Bar;
+
+  using BazBarInt = BazBar; // expected-no-diagnostics
+};
+
+template 
+struct contiguous_range {
+  template 
+requires(const_range == false)
+  using basic_iterator = int;
+
+  auto begin() {
+return basic_iterator{}; // expected-no-diagnostics
+  }
+};
Index: clang/lib/Sema/SemaConcept.cpp
===
--- clang/lib/Sema/SemaConcept.cpp
+++ clang/lib/Sema/SemaConcept.cpp
@@ -293,6 +293,7 @@
 
   MultiLevelTemplateArgumentList MLTAL;
   MLTAL.addOuterTemplateArguments(TemplateArgs);
+  MLTAL.addOuterRetainedLevels(Template->getTemplateDepth());
 
   for (const Expr *ConstraintExpr : ConstraintExprs) {
 if (calculateConstraintSatisfaction(S, Template, TemplateArgs,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D128352: [clang][dataflow] Use diagnosis API in optional checker

[Sam Estep via Phabricator via cfe-commits]

samestep created this revision.
Herald added subscribers: martong, tschuett, carlosgalvezp, xazax.hun.
Herald added a project: All.
samestep requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128352

Files:
  clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp


Index: clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
@@ -17,11 +17,12 @@
 #include "clang/Analysis/FlowSensitive/DataflowAnalysisContext.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Analysis/FlowSensitive/Diagnosis.h"
 #include "clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h"
-#include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
 #include "clang/Analysis/FlowSensitive/WatchedLiteralsSolver.h"
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/Any.h"
+#include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/Error.h"
 #include 
@@ -31,16 +32,16 @@
 namespace tidy {
 namespace bugprone {
 using ast_matchers::MatchFinder;
-using dataflow::SourceLocationsLattice;
+using dataflow::UncheckedOptionalAccessDiagnosis;
 using dataflow::UncheckedOptionalAccessModel;
 using llvm::Optional;
 
 static constexpr llvm::StringLiteral FuncID("fun");
 
-static Optional
+static Optional>
 analyzeFunction(const FunctionDecl &FuncDecl, ASTContext &ASTCtx) {
   using dataflow::ControlFlowContext;
-  using dataflow::DataflowAnalysisState;
+  using dataflow::TypeErasedDataflowAnalysisState;
   using llvm::Expected;
 
   Expected Context =
@@ -52,23 +53,31 @@
   std::make_unique());
   dataflow::Environment Env(AnalysisContext, FuncDecl);
   UncheckedOptionalAccessModel Analysis(ASTCtx);
-  
Expected>>>
+  Expected>>
   BlockToOutputState =
-  dataflow::runDataflowAnalysis(*Context, Analysis, Env);
+  dataflow::runTypeErasedDataflowAnalysis(*Context, Analysis, Env);
   if (!BlockToOutputState)
 return llvm::None;
-  assert(Context->getCFG().getExit().getBlockID() < 
BlockToOutputState->size());
 
-  const Optional>
-  &ExitBlockState =
-  (*BlockToOutputState)[Context->getCFG().getExit().getBlockID()];
+  const Optional &ExitBlockState =
+  (*BlockToOutputState)[Context->getCFG().getExit().getBlockID()];
   // `runDataflowAnalysis` doesn't guarantee that the exit block is visited;
   // for example, when it is unreachable.
   // FIXME: Diagnose violations even when the exit block is unreachable.
   if (!ExitBlockState)
 return llvm::None;
 
-  return std::move(ExitBlockState->Lattice);
+  UncheckedOptionalAccessDiagnosis Diagnosis(ASTCtx);
+  dataflow::Diagnosis>
+  Diagnose = [&Diagnosis](const Stmt *Stmt,
+  const UncheckedOptionalAccessModel::Lattice &,
+  const dataflow::Environment &Env) {
+return Diagnosis.diagnose(Stmt, Env);
+  };
+
+  return dataflow::diagnoseCFG(*Context, *BlockToOutputState, Env, Analysis,
+   std::move(Diagnose));
 }
 
 void UncheckedOptionalAccessCheck::registerMatchers(MatchFinder *Finder) {
@@ -97,9 +106,9 @@
   if (FuncDecl->isTemplated())
 return;
 
-  if (Optional Errors =
+  if (Optional> Errors =
   analyzeFunction(*FuncDecl, *Result.Context))
-for (const SourceLocation &Loc : Errors->getSourceLocations())
+for (const SourceLocation &Loc : *Errors)
   diag(Loc, "unchecked access to optional value");
 }
 


Index: clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
@@ -17,11 +17,12 @@
 #include "clang/Analysis/FlowSensitive/DataflowAnalysisContext.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Analysis/FlowSensitive/Diagnosis.h"
 #include "clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h"
-#include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
 #include "clang/Analysis/FlowSensitive/WatchedLiteralsSolver.h"
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/Any.h"
+#include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/Error.h"
 #include 
@@ -31,16 +32,16 @@
 namespace tidy {
 namespace bugprone {
 using ast_matchers::MatchFinder;
-using dataflow::SourceLocationsLattice;
+using dataflow::UncheckedOptionalAccessDiagnosis;
 u

[PATCH] D128048: Add a new clang option "-ftime-trace-path"

[Jamie Schmeiser via Phabricator via cfe-commits]

jamieschmeiser added a comment.

In D128048#3601588 , @Whitney wrote:

> In D128048#3601579 , 
> @jamieschmeiser wrote:
>
>> Can you please use git rebase -i to collapse all the changes into a single 
>> change?  If this isn't done, it is difficult to know what is being reviewed 
>> as the changes only show the differences since your last revision, not all 
>> of the changes.
>
> I can see all the changes, make sure your link is not suffix with "new", or 
> check the history tab to see what is it comparing.

It had the /new on the path.  I removed it and now I can see everything.  
Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128048

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

[PATCH] D126164: [flang][Driver] Refine _when_ driver diagnostics are formatted

[Peixin Qiao via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG430841605d49: [flang][Driver] Refine _when_ driver 
diagnostics are formatted (authored by peixin).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126164

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/include/flang/Frontend/FrontendOptions.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/test/Driver/color-diagnostics-forwarding.f90
  flang/test/Driver/color-diagnostics.f90
  flang/test/Driver/driver-help.f90

Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -83,6 +83,7 @@
 ! HELP-FC1-NEXT: -falternative-parameter-statement
 ! HELP-FC1-NEXT: Enable the old style PARAMETER statement
 ! HELP-FC1-NEXT: -fbackslashSpecify that backslash in string introduces an escape character
+! HELP-FC1-NEXT: -fcolor-diagnostics Enable colors in diagnostics
 ! HELP-FC1-NEXT: -fdebug-dump-all   Dump symbols and the parse tree after the semantic checks
 ! HELP-FC1-NEXT: -fdebug-dump-parse-tree-no-sema
 ! HELP-FC1-NEXT:Dump the parse tree (skips the semantic checks)
Index: flang/test/Driver/color-diagnostics.f90
===
--- /dev/null
+++ flang/test/Driver/color-diagnostics.f90
@@ -0,0 +1,23 @@
+! Test the behaviors of -f{no-}color-diagnostics.
+! Windows command prompt doesn't support ANSI escape sequences.
+! REQUIRES: shell
+
+! RUN: not %flang %s -fcolor-diagnostics 2>&1 \
+! RUN: | FileCheck %s --check-prefix=CHECK_CD
+! RUN: not %flang %s -fno-color-diagnostics 2>&1 \
+! RUN: | FileCheck %s --check-prefix=CHECK_NCD
+! RUN: not %flang_fc1 %s -fcolor-diagnostics 2>&1 \
+! RUN: | FileCheck %s --check-prefix=CHECK_CD
+! RUN: not %flang_fc1 %s -fno-color-diagnostics 2>&1 \
+! RUN: | FileCheck %s --check-prefix=UNSUPPORTED_OPTION
+! RUN: not %flang_fc1 %s 2>&1 | FileCheck %s --check-prefix=CHECK_NCD
+
+! CHECK_CD: {{.*}}[0;1;31merror: {{.*}}[0m{{.*}}[1mSemantic errors in {{.*}}color-diagnostics.f90{{.*}}[0m
+
+! CHECK_NCD: Semantic errors in {{.*}}color-diagnostics.f90
+
+! UNSUPPORTED_OPTION: error: unknown argument: '-fno-color-diagnostics'
+
+program m
+  integer :: i = k
+end
Index: flang/test/Driver/color-diagnostics-forwarding.f90
===
--- /dev/null
+++ flang/test/Driver/color-diagnostics-forwarding.f90
@@ -0,0 +1,21 @@
+! Test that flang-new forwards -f{no-}color-diagnostics options to
+! flang-new -fc1 as expected.
+
+! RUN: %flang -fsyntax-only -### %s -o %t 2>&1 -fcolor-diagnostics \
+! RUN:   | FileCheck %s --check-prefix=CHECK-CD
+! CHECK-CD: "-fc1"{{.*}} "-fcolor-diagnostics"
+
+! RUN: %flang -fsyntax-only -### %s -o %t 2>&1 -fno-color-diagnostics \
+! RUN:   | FileCheck %s --check-prefix=CHECK-NCD
+! CHECK-NCD-NOT: "-fc1"{{.*}} "-fcolor-diagnostics"
+
+! Check that the last flag wins.
+! RUN: %flang -fsyntax-only -### %s -o %t 2>&1 \
+! RUN: -fno-color-diagnostics -fcolor-diagnostics \
+! RUN:   | FileCheck %s --check-prefix=CHECK-NCD_CD_S
+! CHECK-NCD_CD_S: "-fc1"{{.*}} "-fcolor-diagnostics"
+
+! RUN: %flang -fsyntax-only -### %s -o %t 2>&1 \
+! RUN: -fcolor-diagnostics -fno-color-diagnostics \
+! RUN:   | FileCheck %s --check-prefix=CHECK-CD_NCD_S
+! CHECK-CD_NCD_S-NOT: "-fc1"{{.*}} "-fcolor-diagnostics"
Index: flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
===
--- flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
+++ flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
@@ -158,6 +158,9 @@
 return false;
   }
 
+  // Honor color diagnostics.
+  flang->getDiagnosticOpts().ShowColors = flang->getFrontendOpts().showColors;
+
   // Create and execute the frontend action.
   std::unique_ptr act(createFrontendAction(*flang));
   if (!act)
Index: flang/lib/Frontend/CompilerInvocation.cpp
===
--- flang/lib/Frontend/CompilerInvocation.cpp
+++ flang/lib/Frontend/CompilerInvocation.cpp
@@ -53,10 +53,11 @@
 //===--===//
 // Deserialization (from args)
 //===--===//
-static bool parseShowColorsArgs(
-const llvm::opt::ArgList &args, bool defaultColor) {
-  // Color diagnostics default to auto ("on" if terminal supports) in the driver
-  // but default to off in cc1, needing an explicit OPT_fdiagnostics_color.
+static bool par

[clang] 4308416 - [flang][Driver] Refine _when_ driver diagnostics are formatted

[Peixin Qiao via cfe-commits]

Author: Peixin Qiao
Date: 2022-06-22T23:56:34+08:00
New Revision: 430841605d49f515b6a671ec772135cf67ca9506

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

LOG: [flang][Driver] Refine _when_ driver diagnostics are formatted

This patch refines //when// driver diagnostics are formatted so that
`flang-new` and `flang-new -fc1` behave consistently with `clang` and
`clang -cc1`, respectively. This change only applies to driver diagnostics.
Scanning, parsing and semantic diagnostics are separate and not covered here.

**NEW BEHAVIOUR**
To illustrate the new behaviour, consider the following input file:
```! file.f90
program m
  integer :: i = k
end
```
In the following invocations, "error: Semantic errors in file.f90" _will be_
formatted:
```
$ flang-new file.f90
error: Semantic errors in file.f90
./file.f90:2:18: error: Must be a constant value
integer :: i = k
$ flang-new -fc1 -fcolor-diagnostics file.f90
error: Semantic errors in file.f90
./file.f90:2:18: error: Must be a constant value
integer :: i = k
```

However, in the following invocations, "error: Semantic errors in file.f90"
_will not be_ formatted:
```
$ flang-new -fno-color-diagnostics file.f90
error: Semantic errors in file.f90
./file.f90:2:18: error: Must be a constant value
integer :: i = k
$ flang-new -fc1 file.f90
error: Semantic errors in file.f90
./file.f90:2:18: error: Must be a constant value
integer :: i = k
```

Before this change, none of the above would be formatted. Note also that the
default behaviour in `flang-new` is different to `flang-new -fc1` (this is
consistent with Clang).

**NOTES ON IMPLEMENTATION**
Note that the diagnostic options are parsed in `createAndPopulateDiagOpt`s in
driver.cpp. That's where the driver's `DiagnosticEngine` options are set. Like
most command-line compiler driver options, these flags are "claimed" in
Flang.cpp (i.e.  when creating a frontend driver invocation) by calling
`getLastArg` rather than in driver.cpp.

In Clang's Options.td, `defm color_diagnostics` is replaced with two separate
definitions: `def fcolor_diagnostics` and def fno_color_diagnostics`. That's
because originally `color_diagnostics` derived from `OptInCC1FFlag`, which is a
multiclass for opt-in options in CC1. In order to preserve the current
behaviour in `clang -cc1` (i.e. to keep `-fno-color-diagnostics` unavailable in
`clang -cc1`) and to implement similar behaviour in `flang-new -fc1`, we can't
re-use `OptInCC1FFlag`.

Formatting is only available in consoles that support it and will normally mean 
that
the message is printed in bold + color.

Co-authored-by: Andrzej Warzynski 

Reviewed By: rovka

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

Added: 
flang/test/Driver/color-diagnostics-forwarding.f90
flang/test/Driver/color-diagnostics.f90

Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Flang.cpp
flang/include/flang/Frontend/CompilerInvocation.h
flang/include/flang/Frontend/FrontendOptions.h
flang/lib/Frontend/CompilerInvocation.cpp
flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
flang/test/Driver/driver-help.f90

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 7aea7324cf241..4c0f0ada36547 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -1355,8 +1355,11 @@ def fclang_abi_compat_EQ : Joined<["-"], 
"fclang-abi-compat=">, Group, MetaVarName<"">, 
Values<".,latest">,
   HelpText<"Attempt to match the ABI of Clang ">;
 def fclasspath_EQ : Joined<["-"], "fclasspath=">, Group;
-defm color_diagnostics : OptInCC1FFlag<"color-diagnostics", "Enable", 
"Disable", " colors in diagnostics",
-  [CoreOption, FlangOption]>;
+def fcolor_diagnostics : Flag<["-"], "fcolor-diagnostics">, Group,
+  Flags<[CoreOption, CC1Option, FlangOption, FC1Option]>,
+  HelpText<"Enable colors in diagnostics">;
+def fno_color_diagnostics : Flag<["-"], "fno-color-diagnostics">, 
Group,
+  Flags<[CoreOption, FlangOption]>, HelpText<"Disable colors in diagnostics">;
 def : Flag<["-"], "fdiagnostics-color">, Group, Flags<[CoreOption]>, 
Alias;
 def : Flag<["-"], "fno-diagnostics-color">, Group, 
Flags<[CoreOption]>, Alias;
 def fdiagnostics_color_EQ : Joined<["-"], "fdiagnostics-color=">, 
Group;

diff  --git a/clang/lib/Driver/ToolChains/Flang.cpp 
b/clang/lib/Driver/ToolChains/Flang.cpp
index ab9287d880a95..aeab9d5fc417f 100644
--- a/clang/lib/Driver/ToolChains/Flang.cpp
+++ b/clang/lib/Driver/ToolChains/Flang.cpp
@@ -65,6 +65,7 @@ void Flang::ConstructJob(Compilation &C, const JobAction &JA,
   const llvm::Triple &Triple = TC.getEffectiveTriple();
   const std::string &TripleStr = Triple.getTriple();
 
+  const Driver &D = TC.getDr

[PATCH] D128352: [clang][dataflow] Use diagnosis API in optional checker

[Sam Estep via Phabricator via cfe-commits]

samestep updated this revision to Diff 439042.
samestep added a comment.

Remove unnecessary ExitBlock code


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128352

Files:
  clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp


Index: clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
@@ -17,11 +17,12 @@
 #include "clang/Analysis/FlowSensitive/DataflowAnalysisContext.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Analysis/FlowSensitive/Diagnosis.h"
 #include "clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h"
-#include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
 #include "clang/Analysis/FlowSensitive/WatchedLiteralsSolver.h"
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/Any.h"
+#include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/Error.h"
 #include 
@@ -31,16 +32,16 @@
 namespace tidy {
 namespace bugprone {
 using ast_matchers::MatchFinder;
-using dataflow::SourceLocationsLattice;
+using dataflow::UncheckedOptionalAccessDiagnosis;
 using dataflow::UncheckedOptionalAccessModel;
 using llvm::Optional;
 
 static constexpr llvm::StringLiteral FuncID("fun");
 
-static Optional
+static Optional>
 analyzeFunction(const FunctionDecl &FuncDecl, ASTContext &ASTCtx) {
   using dataflow::ControlFlowContext;
-  using dataflow::DataflowAnalysisState;
+  using dataflow::TypeErasedDataflowAnalysisState;
   using llvm::Expected;
 
   Expected Context =
@@ -52,23 +53,23 @@
   std::make_unique());
   dataflow::Environment Env(AnalysisContext, FuncDecl);
   UncheckedOptionalAccessModel Analysis(ASTCtx);
-  
Expected>>>
+  Expected>>
   BlockToOutputState =
-  dataflow::runDataflowAnalysis(*Context, Analysis, Env);
+  dataflow::runTypeErasedDataflowAnalysis(*Context, Analysis, Env);
   if (!BlockToOutputState)
 return llvm::None;
-  assert(Context->getCFG().getExit().getBlockID() < 
BlockToOutputState->size());
 
-  const Optional>
-  &ExitBlockState =
-  (*BlockToOutputState)[Context->getCFG().getExit().getBlockID()];
-  // `runDataflowAnalysis` doesn't guarantee that the exit block is visited;
-  // for example, when it is unreachable.
-  // FIXME: Diagnose violations even when the exit block is unreachable.
-  if (!ExitBlockState)
-return llvm::None;
+  UncheckedOptionalAccessDiagnosis Diagnosis(ASTCtx);
+  dataflow::Diagnosis>
+  Diagnose = [&Diagnosis](const Stmt *Stmt,
+  const UncheckedOptionalAccessModel::Lattice &,
+  const dataflow::Environment &Env) {
+return Diagnosis.diagnose(Stmt, Env);
+  };
 
-  return std::move(ExitBlockState->Lattice);
+  return dataflow::diagnoseCFG(*Context, *BlockToOutputState, Env, Analysis,
+   std::move(Diagnose));
 }
 
 void UncheckedOptionalAccessCheck::registerMatchers(MatchFinder *Finder) {
@@ -97,9 +98,9 @@
   if (FuncDecl->isTemplated())
 return;
 
-  if (Optional Errors =
+  if (Optional> Errors =
   analyzeFunction(*FuncDecl, *Result.Context))
-for (const SourceLocation &Loc : Errors->getSourceLocations())
+for (const SourceLocation &Loc : *Errors)
   diag(Loc, "unchecked access to optional value");
 }
 


Index: clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
@@ -17,11 +17,12 @@
 #include "clang/Analysis/FlowSensitive/DataflowAnalysisContext.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Analysis/FlowSensitive/Diagnosis.h"
 #include "clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h"
-#include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
 #include "clang/Analysis/FlowSensitive/WatchedLiteralsSolver.h"
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/Any.h"
+#include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/Error.h"
 #include 
@@ -31,16 +32,16 @@
 namespace tidy {
 namespace bugprone {
 using ast_matchers::MatchFinder;
-using dataflow::SourceLocationsLattice;
+using dataflow::UncheckedOptionalAccessDiagnosis;
 using dataflow::UncheckedOptionalAccessModel;
 using llvm::Optional;
 
 static constexpr llvm::StringLiteral FuncID("fun");
 
-static Optional
+static Optional>
 analyzeFunction(const FunctionDec

[PATCH] D127487: [Sema] Fix assertion failure when instantiating requires expression

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:2039
 TransConstraint = TransformExpr(Req->getConstraintExpr());
+if (!TransConstraint.isInvalid()) {
+  bool CheckSucceeded =

erichkeane wrote:
> I think I'd rather collapse this into SOMETHING like:
> 
> ``` assert((TransConstraint.isInvalid() || 
> (SemaRef.CheckConstraintExpr(TransConstraint.get() || 
> Trap.hasErrorOccurred()) && "...");```
> 
> I think thats right?  
`CheckConstraintExpression` has to always run, even when assertions are 
disabled. It does checks for C++ semantics, e.g. checks that the type is bool.

The assertion is only there to check that whenever the function fails, `Trap` 
captures the actual diagnostic so the code below that relies on 
`hasErrorOccurred` ends up in a valid state.



Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:2048
+// Use version of CheckConstraintSatisfaction that does no substitutions.
+if (!TransConstraint.isInvalid() &&
+!TransConstraint.get()->isInstantiationDependent() &&

erichkeane wrote:
> Same sorta thing here, if our check is only used for an assert, we should 
> call it in the assert.
See the comment above, the call to `CheckConstraintSatisfaction` is also to 
implement semantic C++ checks, not solely for assertion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127487

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

[PATCH] D128043: [flang][driver] Add support for `-O{0|1|2|3}`

[Peixin Qiao via Phabricator via cfe-commits]

peixin added a comment.

LGTM




Comment at: clang/lib/Driver/ToolChains/Flang.cpp:133
+  CmdArgs.push_back("-O3");
+  TC.getDriver().Diag(diag::warn_O4_is_O3);
+} else {

Nit: I have committed D126164, and you can rebase and use D directly, which is 
the style in `Clang.cpp`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128043

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

[PATCH] D127487: [Sema] Fix assertion failure when instantiating requires expression

[Erich Keane via Phabricator via cfe-commits]

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

Ah, i see!  Thanks for the explanation!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127487

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

[PATCH] D128354: Comment Diagnosis.h and add missing headers

[Sam Estep via Phabricator via cfe-commits]

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

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128354

Files:
  clang/include/clang/Analysis/FlowSensitive/Diagnosis.h


Index: clang/include/clang/Analysis/FlowSensitive/Diagnosis.h
===
--- clang/include/clang/Analysis/FlowSensitive/Diagnosis.h
+++ clang/include/clang/Analysis/FlowSensitive/Diagnosis.h
@@ -18,14 +18,22 @@
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h"
 #include "llvm/ADT/DenseSet.h"
+#include "llvm/ADT/Optional.h"
+#include 
+#include 
+#include 
 
 namespace clang {
 namespace dataflow {
 
+/// Looks at a single statement using the `Lattice` and `Environment` at that
+/// program point from running a dataflow analysis, and returns any 
diagnostics.
 template 
 using Diagnosis =
 std::function;
 
+/// Collects diagnostics from all blocks in a CFG, given some dataflow analysis
+/// results and a `Diagnose` function which can be run on individual 
statements.
 template 
 llvm::DenseSet diagnoseCFG(
 const ControlFlowContext &CFCtx,


Index: clang/include/clang/Analysis/FlowSensitive/Diagnosis.h
===
--- clang/include/clang/Analysis/FlowSensitive/Diagnosis.h
+++ clang/include/clang/Analysis/FlowSensitive/Diagnosis.h
@@ -18,14 +18,22 @@
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h"
 #include "llvm/ADT/DenseSet.h"
+#include "llvm/ADT/Optional.h"
+#include 
+#include 
+#include 
 
 namespace clang {
 namespace dataflow {
 
+/// Looks at a single statement using the `Lattice` and `Environment` at that
+/// program point from running a dataflow analysis, and returns any diagnostics.
 template 
 using Diagnosis =
 std::function;
 
+/// Collects diagnostics from all blocks in a CFG, given some dataflow analysis
+/// results and a `Diagnose` function which can be run on individual statements.
 template 
 llvm::DenseSet diagnoseCFG(
 const ControlFlowContext &CFCtx,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127898: [clang][dataflow] Add API to separate analysis from diagnosis

[Sam Estep via Phabricator via cfe-commits]

samestep updated this revision to Diff 439045.
samestep added a comment.

Comment Diagnosis.h and add missing headers


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127898

Files:
  clang/include/clang/Analysis/FlowSensitive/Diagnosis.h


Index: clang/include/clang/Analysis/FlowSensitive/Diagnosis.h
===
--- clang/include/clang/Analysis/FlowSensitive/Diagnosis.h
+++ clang/include/clang/Analysis/FlowSensitive/Diagnosis.h
@@ -18,14 +18,22 @@
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h"
 #include "llvm/ADT/DenseSet.h"
+#include "llvm/ADT/Optional.h"
+#include 
+#include 
+#include 
 
 namespace clang {
 namespace dataflow {
 
+/// Looks at a single statement using the `Lattice` and `Environment` at that
+/// program point from running a dataflow analysis, and returns any 
diagnostics.
 template 
 using Diagnosis =
 std::function;
 
+/// Collects diagnostics from all blocks in a CFG, given some dataflow analysis
+/// results and a `Diagnose` function which can be run on individual 
statements.
 template 
 llvm::DenseSet diagnoseCFG(
 const ControlFlowContext &CFCtx,


Index: clang/include/clang/Analysis/FlowSensitive/Diagnosis.h
===
--- clang/include/clang/Analysis/FlowSensitive/Diagnosis.h
+++ clang/include/clang/Analysis/FlowSensitive/Diagnosis.h
@@ -18,14 +18,22 @@
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h"
 #include "llvm/ADT/DenseSet.h"
+#include "llvm/ADT/Optional.h"
+#include 
+#include 
+#include 
 
 namespace clang {
 namespace dataflow {
 
+/// Looks at a single statement using the `Lattice` and `Environment` at that
+/// program point from running a dataflow analysis, and returns any diagnostics.
 template 
 using Diagnosis =
 std::function;
 
+/// Collects diagnostics from all blocks in a CFG, given some dataflow analysis
+/// results and a `Diagnose` function which can be run on individual statements.
 template 
 llvm::DenseSet diagnoseCFG(
 const ControlFlowContext &CFCtx,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127898: [clang][dataflow] Add API to separate analysis from diagnosis

[Sam Estep via Phabricator via cfe-commits]

samestep marked 4 inline comments as done.
samestep added inline comments.



Comment at: clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h:49
+template  struct DiagnoseState {
+  DiagnoseState(DiagsT &Diags, const Environment &Env)
+  : Diags(Diags), Env(Env) {}

sgatev wrote:
> Move this to Diagnosis.h?
I'd prefer to keep it in `MatchSwitch.h` alongside `TransferState`, unless we 
plan to, e.g., move that type to `DataflowAnalysis.h`.



Comment at: 
clang/include/clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h:76
 
+class UncheckedOptionalAccessDiagnosis {
+public:

sgatev wrote:
> Move this to a new UncheckedOptionalAccessDiagnosis.(h,cpp)?
OK! I'll do that next.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127898

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