[PATCH] D142315: [clang] Add test for CWG1111

[Vlad Serebrennikov 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 rG5fc73b7502fb: [clang] Add test for CWG (authored by 
Endill).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142315

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


Index: clang/www/cxx_dr_status.html
===
--- clang/www/cxx_dr_status.html
+++ clang/www/cxx_dr_status.html
@@ -6473,7 +6473,7 @@
 https://wg21.link/cwg;>
 C++11
 Remove dual-scope lookup of member template names
-Unknown
+Yes
   
   
 https://wg21.link/cwg1112;>1112
@@ -14117,7 +14117,7 @@
 https://wg21.link/cwg2385;>2385
 CD5
 Lookup for conversion-function-ids
-Unknown
+N/A
   
   
 https://wg21.link/cwg2386;>2386
Index: clang/test/CXX/drs/dr23xx.cpp
===
--- clang/test/CXX/drs/dr23xx.cpp
+++ clang/test/CXX/drs/dr23xx.cpp
@@ -169,6 +169,8 @@
 } //namespace dr2303
 #endif
 
+// dr2385: na
+
 namespace dr2394 { // dr2394: 15
 
 struct A {};
Index: clang/test/CXX/drs/dr11xx.cpp
===
--- clang/test/CXX/drs/dr11xx.cpp
+++ clang/test/CXX/drs/dr11xx.cpp
@@ -4,6 +4,46 @@
 // RUN: %clang_cc1 -std=c++17 %s -verify -fexceptions -fcxx-exceptions 
-pedantic-errors
 // RUN: %clang_cc1 -std=c++2a %s -verify -fexceptions -fcxx-exceptions 
-pedantic-errors
 
+namespace dr { // dr: yes
+namespace example1 {
+template  struct set;
+
+struct X {
+  template  void set(const T );
+};
+void foo() {
+  X x;
+#pragma clang diagnostic push
+#if __cplusplus < 201103L
+#pragma clang diagnostic ignored "-Wambiguous-member-template"
+#endif
+  x.set(3.2);
+#pragma clang diagnostic pop
+}
+
+struct Y {};
+void bar() {
+  Y y;
+  y.set(3.2); // expected-error {{no member named 'set' in 
'dr::example1::Y'}}
+}
+} // namespace example1
+
+namespace example2 {
+struct A {};
+namespace N {
+struct A {
+  void g() {}
+  template  operator T();
+};
+} // namespace N
+
+void baz() {
+  N::A a;
+  a.operator A();
+}
+} // namespace example2
+} // namespace dr
+
 namespace dr1113 { // dr1113: partial
   namespace named {
 extern int a; // expected-note {{previous}}


Index: clang/www/cxx_dr_status.html
===
--- clang/www/cxx_dr_status.html
+++ clang/www/cxx_dr_status.html
@@ -6473,7 +6473,7 @@
 https://wg21.link/cwg;>
 C++11
 Remove dual-scope lookup of member template names
-Unknown
+Yes
   
   
 https://wg21.link/cwg1112;>1112
@@ -14117,7 +14117,7 @@
 https://wg21.link/cwg2385;>2385
 CD5
 Lookup for conversion-function-ids
-Unknown
+N/A
   
   
 https://wg21.link/cwg2386;>2386
Index: clang/test/CXX/drs/dr23xx.cpp
===
--- clang/test/CXX/drs/dr23xx.cpp
+++ clang/test/CXX/drs/dr23xx.cpp
@@ -169,6 +169,8 @@
 } //namespace dr2303
 #endif
 
+// dr2385: na
+
 namespace dr2394 { // dr2394: 15
 
 struct A {};
Index: clang/test/CXX/drs/dr11xx.cpp
===
--- clang/test/CXX/drs/dr11xx.cpp
+++ clang/test/CXX/drs/dr11xx.cpp
@@ -4,6 +4,46 @@
 // RUN: %clang_cc1 -std=c++17 %s -verify -fexceptions -fcxx-exceptions -pedantic-errors
 // RUN: %clang_cc1 -std=c++2a %s -verify -fexceptions -fcxx-exceptions -pedantic-errors
 
+namespace dr { // dr: yes
+namespace example1 {
+template  struct set;
+
+struct X {
+  template  void set(const T );
+};
+void foo() {
+  X x;
+#pragma clang diagnostic push
+#if __cplusplus < 201103L
+#pragma clang diagnostic ignored "-Wambiguous-member-template"
+#endif
+  x.set(3.2);
+#pragma clang diagnostic pop
+}
+
+struct Y {};
+void bar() {
+  Y y;
+  y.set(3.2); // expected-error {{no member named 'set' in 'dr::example1::Y'}}
+}
+} // namespace example1
+
+namespace example2 {
+struct A {};
+namespace N {
+struct A {
+  void g() {}
+  template  operator T();
+};
+} // namespace N
+
+void baz() {
+  N::A a;
+  a.operator A();
+}
+} // namespace example2
+} // namespace dr
+
 namespace dr1113 { // dr1113: partial
   namespace named {
 extern int a; // expected-note {{previous}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 5fc73b7 - [clang] Add test for CWG1111

[Vlad Serebrennikov via cfe-commits]

Author: Vlad Serebrennikov
Date: 2023-02-11T10:53:08+03:00
New Revision: 5fc73b7502fbbb46faa57a558c8661822b2b5215

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

LOG: [clang] Add test for CWG

Also mark [[ https://wg21.link/cwg2385 | CWG2385 ]] as `na`, because it 
eliminates wording inconsistency introduced by [[ https://wg21.link/cwg | 
CWG ]] resolution.

Reviewed By: #clang-language-wg, erichkeane

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

Added: 


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

Removed: 




diff  --git a/clang/test/CXX/drs/dr11xx.cpp b/clang/test/CXX/drs/dr11xx.cpp
index 81fbc1e3ef1b..23756ff1927e 100644
--- a/clang/test/CXX/drs/dr11xx.cpp
+++ b/clang/test/CXX/drs/dr11xx.cpp
@@ -4,6 +4,46 @@
 // RUN: %clang_cc1 -std=c++17 %s -verify -fexceptions -fcxx-exceptions 
-pedantic-errors
 // RUN: %clang_cc1 -std=c++2a %s -verify -fexceptions -fcxx-exceptions 
-pedantic-errors
 
+namespace dr { // dr: yes
+namespace example1 {
+template  struct set;
+
+struct X {
+  template  void set(const T );
+};
+void foo() {
+  X x;
+#pragma clang diagnostic push
+#if __cplusplus < 201103L
+#pragma clang diagnostic ignored "-Wambiguous-member-template"
+#endif
+  x.set(3.2);
+#pragma clang diagnostic pop
+}
+
+struct Y {};
+void bar() {
+  Y y;
+  y.set(3.2); // expected-error {{no member named 'set' in 
'dr::example1::Y'}}
+}
+} // namespace example1
+
+namespace example2 {
+struct A {};
+namespace N {
+struct A {
+  void g() {}
+  template  operator T();
+};
+} // namespace N
+
+void baz() {
+  N::A a;
+  a.operator A();
+}
+} // namespace example2
+} // namespace dr
+
 namespace dr1113 { // dr1113: partial
   namespace named {
 extern int a; // expected-note {{previous}}

diff  --git a/clang/test/CXX/drs/dr23xx.cpp b/clang/test/CXX/drs/dr23xx.cpp
index 371ead504bf3..59e1f27491d2 100644
--- a/clang/test/CXX/drs/dr23xx.cpp
+++ b/clang/test/CXX/drs/dr23xx.cpp
@@ -169,6 +169,8 @@ void g() {
 } //namespace dr2303
 #endif
 
+// dr2385: na
+
 namespace dr2394 { // dr2394: 15
 
 struct A {};

diff  --git a/clang/www/cxx_dr_status.html b/clang/www/cxx_dr_status.html
index 39e5a64d571f..8123c476abb8 100755
--- a/clang/www/cxx_dr_status.html
+++ b/clang/www/cxx_dr_status.html
@@ -6473,7 +6473,7 @@ C++ defect report implementation 
status
 https://wg21.link/cwg;>
 C++11
 Remove dual-scope lookup of member template names
-Unknown
+Yes
   
   
 https://wg21.link/cwg1112;>1112
@@ -14117,7 +14117,7 @@ C++ defect report implementation 
status
 https://wg21.link/cwg2385;>2385
 CD5
 Lookup for conversion-function-ids
-Unknown
+N/A
   
   
 https://wg21.link/cwg2386;>2386



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

[PATCH] D143745: Make section attribute and -ffunction-sections play nicely

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

If one TU has more than one section of the same name, there is no guarantee 
they are adjacent after linking. Linker scripts and `--shuffle-sections` can 
adjust them.
I don't mind a behavior change if GCC is willing to do the same. But without, 
it's safer to use an option.

Created a feature request for GCC: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761


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

https://reviews.llvm.org/D143745

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

[clang] 22fb66e - [clang][NFC] Add another example to CWG952 test

[Vlad Serebrennikov via cfe-commits]

Author: Vlad Serebrennikov
Date: 2023-02-11T10:25:59+03:00
New Revision: 22fb66eb94b643c858c2beecbcfac438a7fa29ed

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

LOG: [clang][NFC] Add another example to CWG952 test

Added: 


Modified: 
clang/test/CXX/drs/dr9xx.cpp

Removed: 




diff  --git a/clang/test/CXX/drs/dr9xx.cpp b/clang/test/CXX/drs/dr9xx.cpp
index 039ba431e4a1..cce0b6ecf209 100644
--- a/clang/test/CXX/drs/dr9xx.cpp
+++ b/clang/test/CXX/drs/dr9xx.cpp
@@ -73,6 +73,7 @@ namespace dr948 { // dr948: 3.7
 }
 
 namespace dr952 { // dr952: yes
+namespace example1 {
 struct A {
   typedef int I; // #dr952-typedef-decl
 };
@@ -98,6 +99,16 @@ struct C : B {
 }
   };
 };
+} // namespace example1
+namespace example2 {
+struct A {
+protected:
+  static int x;
+};
+struct B : A {
+  friend int get(B) { return x; }
+};
+} // namespace example2
 } // namespace dr952
 
 namespace dr974 { // dr974: yes



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

[PATCH] D142986: Enable multilib.yaml in the BareMetal ToolChain

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: clang/test/Driver/baremetal-multilib.cpp:19
+// CHECK-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" 
"-Bstatic"
+// CHECK-SAME: 
"-L{{.*}}/baremetal_multilib/bin/../lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/lib"
+// CHECK-SAME: "-lc" "-lm" "-lclang_rt.builtins"

Use a style similar to `linux-cross.cpp`.

Test a few variants (https://github.com/MaskRay/Config/wiki/LLVM#clanglibdriver)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142986

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

[PATCH] D143763: [Clang] Add clangMinimumVersion to multilib.yaml

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

I think this patch can be merged into a previous one that introduces `variants` 
and `flagMap`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143763

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

[PATCH] D142933: Add -print-multi-selection-flags argument

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

> Add -print-multi-selection-flags argument

"option" is a better term. Since the option doesn't take an argument, "flag" 
applies as well.

`[Driver] Add -print-multi-selection-flags`

The summary is empty. Is that intended? We need some description what the new 
option does.




Comment at: clang/lib/Driver/ToolChain.cpp:273
+  if (SanArgs.needsAsanRt()) {
+Result.push_back("fsanitize=address");
+  }

remove braces



Comment at: clang/lib/Driver/ToolChain.cpp:297
+
+  // Sort alphabetically
+  std::sort(Result.begin(), Result.end());

This function overly uses blank lines. 

```
// Sort and remove duplicates.
std::sort(Result.begin(), Result.end());
Result.erase(std::unique(Result.begin(), Result.end()), Result.end());
return Result;
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142933

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

[PATCH] D142905: Change multilib selection algorithm

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

Mention `MultilibSet::select` in the summary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142905

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

[PATCH] D142905: Change multilib selection algorithm

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: clang/lib/Driver/Multilib.cpp:53
+  for (StringRef Flag : PrintArgs) {
+OS << "@" << Flag.substr(1);
   }

remove braces



Comment at: clang/lib/Driver/Multilib.cpp:99
+  multilib_list Result = select(Flags);
+  if (Result.empty()) {
 return false;

remove braces


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142905

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

[PATCH] D142905: Change multilib selection algorithm

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

Use `[Driver] ` for pure driver patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142905

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

[clang] 89ba737 - [clang] Mark CWG2165 as N/A

[Vlad Serebrennikov via cfe-commits]

Author: Vlad Serebrennikov
Date: 2023-02-11T09:50:25+03:00
New Revision: 89ba737bcf3444a6afe2f4ed75ce957029380267

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

LOG: [clang] Mark CWG2165 as N/A

[[ https://wg21.link/p1787 | P1787 ]]: "CWG2165 is resolved by removing the 
conflicting definition of it in [basic.scope]."
Wording: [basic.namespace]/p1 changed and [basic.scope.declarative] removed 
entirely

Reviewed By: #clang-language-wg, cor3ntin

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

Added: 


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

Removed: 




diff  --git a/clang/test/CXX/drs/dr21xx.cpp b/clang/test/CXX/drs/dr21xx.cpp
index 7e74590213376..d8cf3ac9f7eda 100644
--- a/clang/test/CXX/drs/dr21xx.cpp
+++ b/clang/test/CXX/drs/dr21xx.cpp
@@ -127,6 +127,8 @@ namespace dr2157 { // dr2157: 11
 #endif
 }
 
+// dr2165: na
+
 namespace dr2170 { // dr2170: 9
 #if __cplusplus >= 201103L
   void f() {

diff  --git a/clang/www/cxx_dr_status.html b/clang/www/cxx_dr_status.html
index dbd4e34816f98..39e5a64d571f1 100755
--- a/clang/www/cxx_dr_status.html
+++ b/clang/www/cxx_dr_status.html
@@ -12797,7 +12797,7 @@ C++ defect report implementation 
status
 https://wg21.link/cwg2165;>2165
 CD6
 Namespaces, declarative regions, and translation units
-Unknown
+N/A
   
   
 https://wg21.link/cwg2166;>2166



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

[PATCH] D142893: [NFC] Class for building MultilibSet

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: clang/include/clang/Driver/MultilibBuilder.h:117
+  /// Add an optional Multilib segment
+  MultilibSetBuilder (const MultilibBuilder );
+

Use `camelCase` for new function names.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142893

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

[clang] 5eaaf8f - Revert "[clang] Mark CWG2165 as N/A"

[Vlad Serebrennikov via cfe-commits]

Author: Vlad Serebrennikov
Date: 2023-02-11T09:48:40+03:00
New Revision: 5eaaf8f18093740200ffed76b32884ad9cfec12e

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

LOG: Revert "[clang] Mark CWG2165 as N/A"

This reverts commit d0e24f0c97ecf4f4e72604adcae5cd4c6b02cb48.

Added: 


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

Removed: 




diff  --git a/clang/test/CXX/drs/dr21xx.cpp b/clang/test/CXX/drs/dr21xx.cpp
index d8cf3ac9f7eda..7e74590213376 100644
--- a/clang/test/CXX/drs/dr21xx.cpp
+++ b/clang/test/CXX/drs/dr21xx.cpp
@@ -127,8 +127,6 @@ namespace dr2157 { // dr2157: 11
 #endif
 }
 
-// dr2165: na
-
 namespace dr2170 { // dr2170: 9
 #if __cplusplus >= 201103L
   void f() {

diff  --git a/clang/www/cxx_dr_status.html b/clang/www/cxx_dr_status.html
index 39e5a64d571f1..dbd4e34816f98 100755
--- a/clang/www/cxx_dr_status.html
+++ b/clang/www/cxx_dr_status.html
@@ -12797,7 +12797,7 @@ C++ defect report implementation 
status
 https://wg21.link/cwg2165;>2165
 CD6
 Namespaces, declarative regions, and translation units
-N/A
+Unknown
   
   
 https://wg21.link/cwg2166;>2166



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

[PATCH] D142717: [clang] Mark CWG2165 as N/A

[Vlad Serebrennikov 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 rGd0e24f0c97ec: [clang] Mark CWG2165 as N/A (authored by 
Endill).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142717

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


Index: clang/www/cxx_dr_status.html
===
--- clang/www/cxx_dr_status.html
+++ clang/www/cxx_dr_status.html
@@ -12797,7 +12797,7 @@
 https://wg21.link/cwg2165;>2165
 CD6
 Namespaces, declarative regions, and translation units
-Unknown
+N/A
   
   
 https://wg21.link/cwg2166;>2166
Index: clang/test/CXX/drs/dr21xx.cpp
===
--- clang/test/CXX/drs/dr21xx.cpp
+++ clang/test/CXX/drs/dr21xx.cpp
@@ -127,6 +127,8 @@
 #endif
 }
 
+// dr2165: na
+
 namespace dr2170 { // dr2170: 9
 #if __cplusplus >= 201103L
   void f() {


Index: clang/www/cxx_dr_status.html
===
--- clang/www/cxx_dr_status.html
+++ clang/www/cxx_dr_status.html
@@ -12797,7 +12797,7 @@
 https://wg21.link/cwg2165;>2165
 CD6
 Namespaces, declarative regions, and translation units
-Unknown
+N/A
   
   
 https://wg21.link/cwg2166;>2166
Index: clang/test/CXX/drs/dr21xx.cpp
===
--- clang/test/CXX/drs/dr21xx.cpp
+++ clang/test/CXX/drs/dr21xx.cpp
@@ -127,6 +127,8 @@
 #endif
 }
 
+// dr2165: na
+
 namespace dr2170 { // dr2170: 9
 #if __cplusplus >= 201103L
   void f() {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D142986: Enable multilib.yaml in the BareMetal ToolChain

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:167
+  std::vector ArgsFlags = TC.getMultiSelectionFlags(Args);
+
+  if (!Result.Multilibs.parse(*MB.get())) {

delete blank line



Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:169
+  if (!Result.Multilibs.parse(*MB.get())) {
+return false;
+  }

https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements



Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:193
+  if (D.getVFS().exists(MultilibPath)) {
+return std::string(SysRootDir);
+  }

https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements



Comment at: clang/test/Driver/baremetal-multilib.cpp:1
+// REQUIRES: shell
+// UNSUPPORTED: system-windows

This C++ source file is empty excluding comments. Just name it 
`baremetal-multilib.yaml`.

Note: if you need extra files, check out `split-file`



Comment at: clang/test/Driver/baremetal-multilib.cpp:14
+// RUN:   | FileCheck %s
+// CHECK: "{{.*}}clang{{.*}}" "-cc1" "-triple" 
"thumbv8m.main-none-unknown-eabihf"
+// CHECK-SAME: "-internal-isystem" 
"{{.*}}/baremetal_multilib/bin/../lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/include/c++/v1"

With `-cc1` CHECK lines, remove `clang{{.*}}` before `-cc1`, then remove 
`-no-canonical-prefixes`. See my prior commits in this area.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142986

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

[clang] d0e24f0 - [clang] Mark CWG2165 as N/A

[Vlad Serebrennikov via cfe-commits]

Author: Vlad Serebrennikov
Date: 2023-02-11T09:46:18+03:00
New Revision: d0e24f0c97ecf4f4e72604adcae5cd4c6b02cb48

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

LOG: [clang] Mark CWG2165 as N/A

[[ https://wg21.link/p1787 | P1787 ]]: "CWG2165 is resolved by removing the 
conflicting definition of it in [basic.scope]."
Wording: [basic.namespace]/p1 changed and [basic.scope.declarative] removed 
entirely

Reviewed By: #clang-language-wg, cor3ntin

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

Added: 


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

Removed: 




diff  --git a/clang/test/CXX/drs/dr21xx.cpp b/clang/test/CXX/drs/dr21xx.cpp
index 7e74590213376..d8cf3ac9f7eda 100644
--- a/clang/test/CXX/drs/dr21xx.cpp
+++ b/clang/test/CXX/drs/dr21xx.cpp
@@ -127,6 +127,8 @@ namespace dr2157 { // dr2157: 11
 #endif
 }
 
+// dr2165: na
+
 namespace dr2170 { // dr2170: 9
 #if __cplusplus >= 201103L
   void f() {

diff  --git a/clang/www/cxx_dr_status.html b/clang/www/cxx_dr_status.html
index dbd4e34816f98..39e5a64d571f1 100755
--- a/clang/www/cxx_dr_status.html
+++ b/clang/www/cxx_dr_status.html
@@ -12797,7 +12797,7 @@ C++ defect report implementation 
status
 https://wg21.link/cwg2165;>2165
 CD6
 Namespaces, declarative regions, and translation units
-Unknown
+N/A
   
   
 https://wg21.link/cwg2166;>2166



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

[PATCH] D142932: [NFC] Multilib YAML parsing

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

Adding new APIs is usually not considered `NFC`. Just remove the tag.




Comment at: clang/lib/Driver/Multilib.cpp:115
+if (!StringRef(M.Regex).starts_with("^")) {
+  RegexString.insert(RegexString.begin(), '^');
+}

https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements



Comment at: clang/lib/Driver/Multilib.cpp:118
+if (!StringRef(M.Regex).ends_with("$")) {
+  RegexString.push_back('$');
+}

https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements



Comment at: clang/lib/Driver/Multilib.cpp:134
+
+struct MultilibSerialization {
+  std::string Dir;

anonymous namespace



Comment at: clang/lib/Driver/Multilib.cpp:139
+
+struct MultilibSetSerialization {
+  std::vector Multilibs;

anonymous namespace


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142932

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

[PATCH] D143587: [Docs] Multilib design

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: clang/docs/Multilib.rst:41
+
+The available libraries can be hard-coded in clang. Typically this is done
+using the ``MultilibBuilder`` interface. There are many examples of this in

`s/clang/Clang/`



Comment at: clang/docs/Multilib.rst:42
+The available libraries can be hard-coded in clang. Typically this is done
+using the ``MultilibBuilder`` interface. There are many examples of this in
+``Gnu.cpp``.

Where is `MultilibBuilder`?



Comment at: clang/docs/Multilib.rst:43
+using the ``MultilibBuilder`` interface. There are many examples of this in
+``Gnu.cpp``.
+The remainder of this document will not focus on this type of multilib.

`lib/Driver/ToolChains/Gnu.cpp`



Comment at: clang/docs/Multilib.rst:162
+
+  # This defines the minimum version of Clang required to use this file.
+  # It is required to be present.

Generally the comments in this example feel verbose. Consider changing some 
sentences with briefer but equivalent wording.

For example, "It is required to be present." is repeated several times. It can 
be combined with a previous sentence like "This is required and ..." or "This 
required key defines ..."



Comment at: clang/docs/Multilib.rst:229
+
+  # Example of noMatchFlags - set hasFPU if mfpu=none *doesn't* match.
+  - regex: mfpu=none

I think `Example of noMatchFlags - ` is verbose.



Comment at: clang/docs/Multilib.rst:237
+
+Stable API
+--

What does "API" refer to? A function defined in llvm-project/clang/lib?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143587

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

[PATCH] D143806: [Clang][Test] Add llvm-lto, llvm-lto2 and llvm-profdata to the tool substitutions list

[Lu Weining via Phabricator via cfe-commits]

SixWeining created this revision.
SixWeining added reviewers: dblaikie, jansvoboda11.
Herald added a subscriber: inglorion.
Herald added a project: All.
SixWeining requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Similar to issue fixed in D107155 , some lit 
tests invoke `llvm-lto`,
`llvm-lto2` and `llvm-profdata` without going through the substitution
system. While the test runner correctly picks up these binaries from
the build directory, it doesn't print its absolute path. When copying
the invocations when reproducing test failures, this can result in
`command not found: llvm-lto` or other erros (caused by using wrong
version of the tool).

This patch adds these tools to the `tools` variable in
`clang/test/lit.cfg.py` which will then call add_tool_substitutions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143806

Files:
  clang/test/lit.cfg.py


Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -61,6 +61,7 @@
 tools = [
 'apinotes-test', 'c-index-test', 'clang-diff', 'clang-format', 
'clang-repl', 'clang-offload-packager',
 'clang-tblgen', 'clang-scan-deps', 'opt', 'llvm-ifs', 'yaml2obj', 
'clang-linker-wrapper',
+'llvm-lto', 'llvm-lto2', 'llvm-profdata',
 ToolSubst('%clang_extdef_map', command=FindTool(
 'clang-extdef-mapping'), unresolved='ignore'),
 ]


Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -61,6 +61,7 @@
 tools = [
 'apinotes-test', 'c-index-test', 'clang-diff', 'clang-format', 'clang-repl', 'clang-offload-packager',
 'clang-tblgen', 'clang-scan-deps', 'opt', 'llvm-ifs', 'yaml2obj', 'clang-linker-wrapper',
+'llvm-lto', 'llvm-lto2', 'llvm-profdata',
 ToolSubst('%clang_extdef_map', command=FindTool(
 'clang-extdef-mapping'), unresolved='ignore'),
 ]
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143418: [libclang] Add API to set preferred temp dir path

[Igor Kushnir via Phabricator via cfe-commits]

vedgy added a comment.

In D143418#4118905 , @aaron.ballman 
wrote:

> I don't think "tries hard" is a good enough guarantee for where files are 
> placed. I'm not comfortable with the security posture of that approach as it 
> could potentially leak sensitive information (try to override the temp 
> directory to something that's chroot jailed, get sensitive files showing up 
> in the system temp directory anyway).

That's why the function's documentation explicitly doesn't guarantee anything. 
It should be safe to assume that security-sensitive users would at least read 
the documentation. If this function and potential future function like it are 
named specifically, a responsible security use case wouldn't be better off. The 
only safety advantage would be to those who don't bother reading the 
documentation. But why should we care much about such hypothetical careless 
security needs?

>> Does the multithreading issue mean that `clang_parseTranslationUnit_Impl()` 
>> can be called in a non-main thread and thus concurrently with 
>> `clang_CXIndex_setPreferredTempDirPath()`?
>
> Yes. However, I don't think that situation is officially supported (it's more 
> that we don't want to knowingly make it harder to support in the future).

All right. Let's do it via a new constructor then. Unfortunately, supporting 
different `CXIndexOptions` struct sizes/versions would complicate the libclang 
implementation and the libclang user code. But the alternative of adding a new 
constructor function each time can either grow to a large number of function 
parameters unneeded by most users or to an exponential number of overloads that 
support different usage requirements.

How about including existing options, which //should// be set in constructor, 
in the initial struct version and deprecating the corresponding setters?

  typedef struct CXIndexOptions {
uint32_t size; // sizeof(struct CIndexOptions), used for option versioning
unsigned globalOptions;
const char *preferredTempDirPath;
const char *invocationEmissionPath;
  } CXIndexOptions;

The naming of struct data members is inconsistent in libclang's Index.h. They 
start with a lower-case letter in about half of the structs. Which naming 
scheme should the members of the new struct use?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143418

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

[PATCH] D143665: [Clang][RISCV] Guard vector int64, float32, float64 with semantic analysis

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: clang/lib/Sema/Sema.cpp:2049
 
-if (Ty->isVectorFloat16Type() &&
-!Context.getTargetInfo().hasVectorFloat16Support()) {
+if ((Ty->isVectorInt64Type() &&
+ !Context.getTargetInfo().hasVectorInt64Support()) ||

eopXD wrote:
> > Overall it might be cleaner to call S.Context.getTargetInfo().hasFeature( 
> > from RISCV-V specific code in Sema instead of trying to define a generic 
> > interface.
> 
> If so, we will have something like:
> 
> ```
> if (Ty->isRVVInt64Type() && !Context.getTargetInfo().hasFeature("zve64x")) {
>   Diag(Loc, diag::err_riscv_type_requires_extension, FD) << Ty << "zve64x";
> }
> ```
> 
> I don't have a preference here, if this matches your expectation, I will 
> update the revision this way.
I'm ok with what you did the Zvfh patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143665

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

[PATCH] D143657: [Clang][RISCV] Guard vector float16 type correctly with semantic analysis

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: clang/lib/Sema/Sema.cpp:2052
+  Diag(Loc, diag::err_riscv_type_requires_extension, FD)
+  << Ty << "experimental-zvfh";
+}

experimental- is an internal naming scheme. "experimental-" is not used in 
-march so it should be in the error message.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143657

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

[PATCH] D137309: [clang] Added Swift support for RISCV

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:10555
 namespace {
-class RISCVABIInfo : public DefaultABIInfo {
+class RISCVABIInfo : public SwiftABIInfo {
 private:

SwiftABIInfo doesn't inherit from ABIInfo and hasn't since August last year. 
D130394


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137309

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

[PATCH] D137527: [C++20] [Modules] [ClangScanDeps] Add ClangScanDeps support for C++20 Named Modules in P1689 format (2/4)

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

In D137527#4117675 , @uabelho wrote:

> Hi,
>
> There seems to be something funny going on with the
>
>   ClangScanDeps/P1689.cppm
>
> testcase added in this patch.
>
> It fails randomly for me on top of tree (4ad8f7a189570 
> ).
> Roughly 1 in 10 runs fail for me.
> E.g. with a crash like
>
>   Exit Code: 2
>   
>   Command Output (stderr):
>   --
>   PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
> and include the crash backtrace.
>   #0 0x004ef8b8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
> (/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x4ef8b8)
>   #1 0x004ed5ae llvm::sys::RunSignalHandlers() 
> (/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x4ed5ae)
>   #2 0x004f0096 SignalHandler(int) Signals.cpp:0:0
>   #3 0x7f6518263630 __restore_rt sigaction.c:0:0
>   #4 0x00474f40 P1689Deps::addSourcePathsToRequires() crtstuff.c:0:0
>   #5 0x004666d1 P1689Deps::printDependencies(llvm::raw_ostream&) 
> crtstuff.c:0:0
>   #6 0x0046204a main 
> (/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x46204a)
>   #7 0x7f6515996555 __libc_start_main (/lib64/libc.so.6+0x22555)
>   #8 0x0045fcad _start 
> (/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x45fcad)
>   FileCheck error: '' is empty.
>   FileCheck command line:  
> /repo/uabelho/main-github/llvm/build-all/bin/FileCheck 
> /repo/uabelho/main-github/llvm/build-all/tools/clang/test/ClangScanDeps/Output/P1689.cppm.tmp/Checks.cpp
>  
> -DPREFIX=/repo/uabelho/main-github/llvm/build-all/tools/clang/test/ClangScanDeps/Output/P1689.cppm.tmp
>   
>   --
>   
>   
>   
>   Failed Tests (1):
> Clang :: ClangScanDeps/P1689.cppm
>
> or
>
>   Exit Code: 2
>   
>   Command Output (stderr):
>   --
>   PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
> and include the crash backtrace.
>#0 0x004ef8b8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
> (/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x4ef8b8)
>#1 0x004ed5ae llvm::sys::RunSignalHandlers() 
> (/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x4ed5ae)
>#2 0x004f0096 SignalHandler(int) Signals.cpp:0:0
>#3 0x7f422b33e630 __restore_rt sigaction.c:0:0
>#4 0x7f4228a85387 raise (/lib64/libc.so.6+0x36387)
>#5 0x7f4228a86a78 abort (/lib64/libc.so.6+0x37a78)
>#6 0x7f4228ac7f67 __libc_message (/lib64/libc.so.6+0x78f67)
>#7 0x7f4228ad0329 _int_free malloc.c:0:0
>#8 0x0047e7ef void 
> std::vector std::allocator>::_M_realloc_insert  
> const&>(__gnu_cxx::__normal_iterator  std::vector std::allocator>>, 
> clang::tooling::dependencies::P1689Rule const&) 
> (/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x47e7ef)
>#9 0x0047cea1 std::_Function_handler main::$_1>::_M_invoke(std::_Any_data const&) ClangScanDeps.cpp:0:0
>   #10 0x0047ba3c std::_Function_handler llvm::ThreadPool::createTaskAndFuture(std::function ()>)::'lambda'()>::_M_invoke(std::_Any_data const&) crtstuff.c:0:0
>   #11 0x004b73e9 
> llvm::ThreadPool::processTasks(llvm::ThreadPoolTaskGroup*) 
> (/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps+0x4b73e9)
>   #12 0x004b8358 void* 
> llvm::thread::ThreadProxy>(void*)
>  ThreadPool.cpp:0:0
>   #13 0x7f422b336ea5 start_thread pthread_create.c:0:0
>   #14 0x7f4228b4db0d clone (/lib64/libc.so.6+0xfeb0d)
>   FileCheck error: '' is empty.
>   FileCheck command line:  
> /repo/uabelho/main-github/llvm/build-all/bin/FileCheck 
> /repo/uabelho/main-github/llvm/build-all/tools/clang/test/ClangScanDeps/Output/P1689.cppm.tmp/Checks.cpp
>  
> -DPREFIX=/repo/uabelho/main-github/llvm/build-all/tools/clang/test/ClangScanDeps/Output/P1689.cppm.tmp
>   
>   --
>   
>   
>   
>   Failed Tests (1):
> Clang :: ClangScanDeps/P1689.cppm
>
> but I've also seen things like
>
>   *** Error in 
> `/repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps': corrupted 
> size vs. prev_size: 0x7faf74000fc0 ***
>   === Backtrace: =
>   /lib64/libc.so.6(+0x7f474)[0x7fafa1ffa474]
>   /lib64/libc.so.6(+0x8156b)[0x7fafa1ffc56b]
>   /repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps[0x47e7ef]
>   /repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps[0x47cea1]
>   /repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps[0x47ba3c]
>   /repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps[0x4b73e9]
>   /repo/uabelho/main-github/llvm/build-all/bin/clang-scan-deps[0x4b8358]
>   /lib64/libpthread.so.0(+0x7ea5)[0x7fafa4862ea5]
>   /lib64/libc.so.6(clone+0x6d)[0x7fafa2079b0d]
>   === Memory map: 
>   

[PATCH] D143803: [clang][alias|ifunc]: Add a diagnostic for mangled names

[Dhruv Chawla via Phabricator via cfe-commits]

0xdc03 added a comment.

Note that as it stands currently, this patch cannot be committed because the 
test `clang/test/SemaCXX/externc-ifunc-resolver.cpp` fails to run. The contents 
of the test are as follows:

  // RUN: %clang_cc1 -emit-llvm-only -triple x86_64-linux-gnu -verify %s
  
  extern "C" {
  __attribute__((used)) static void *resolve_foo() { return 0; }
  namespace NS {
  __attribute__((used)) static void *resolve_foo() { return 0; }
  } // namespace NS
  
  // FIXME: This diagnostic is pretty confusing, the issue is that the existence
  // of the two functions suppresses the 'alias' creation, and thus the ifunc
  // resolution via the alias as well. In the future we should probably find
  // some way to improve this diagnostic (likely by diagnosing when we decide
  // this case suppresses alias creation).
  __attribute__((ifunc("resolve_foo"))) void foo(); // expected-error{{ifunc 
must point to a defined function}}
  }

The error that I get is as follows:

  Command Output (stderr):
  --
  + : 'RUN: at line 1'
  + /mnt/entschuldigung/LLVM/llvm-main/build-release/bin/clang -cc1 
-internal-isystem 
/mnt/entschuldigung/LLVM/llvm-main/build-release/lib/clang/17/include 
-nostdsysteminc -emit-llvm-only -triple x86_64-linux-gnu -verify 
/mnt/entschuldigung/LLVM/llvm-main/clang/test/SemaCXX/externc-ifunc-resolver.cpp
  error: 'note' diagnostics seen but not expected:
File 
/mnt/entschuldigung/LLVM/llvm-main/clang/test/SemaCXX/externc-ifunc-resolver.cpp
 Line 14: 'resolve_foo' exists as a mangled name, did you mean to use 
'_ZL11resolve_foov'?
File 
/mnt/entschuldigung/LLVM/llvm-main/clang/test/SemaCXX/externc-ifunc-resolver.cpp
 Line 14: 'resolve_foo' exists as a mangled name, did you mean to use 
'_ZN2NSL11resolve_fooEv'?
  2 errors generated.
  
  --

which confuses me because an `extern "C"` block is not supposed to mangle any 
names, right? Appreciate any inputs on this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143803

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

[PATCH] D139168: [C++20] [Modules] [ClangScanDeps] Enable to print make-style dependency file within P1689 format (4/4)

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

In D139168#4119190 , @vvereschaka 
wrote:

> @ChuanqiXu,
>
> would you provide a complete rollback for the changes and fix the 
> `C1689.cppm` test failures on the builders
>
> - 
> https://lab.llvm.org/buildbot/#/builders/119/builds/11935/steps/9/logs/FAIL__Clang__P1689_cppm
> - 
> https://lab.llvm.org/buildbot/#/builders/60/builds/10655/steps/9/logs/FAIL__Clang__P1689_cppm

The failure should be fixed by https://reviews.llvm.org/D143749, which disables 
the test in windows. (Because the inconsistent slash direction in linux and 
windows)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139168

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

[PATCH] D137309: [clang] Added Swift support for RISCV

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:10557
 private:
+  DefaultABIInfo defaultInfo;
   // Size of the integer ('x') registers in bits.

Huh? This is unused.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:10601
+bool asReturnValue) const override {
+return occupiesMoreThan(CGT, scalars, /*total*/ 4);
+  }

The argument's called maxAllRegisters?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137309

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

[PATCH] D143803: [clang][alias|ifunc]: Add a diagnostic for mangled names

[Dhruv Chawla via Phabricator via cfe-commits]

0xdc03 created this revision.
Herald added a subscriber: jeroen.dobbelaere.
Herald added a project: All.
0xdc03 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

When an alias or ifunc attribute refers to a function name that is
mangled, a diagnostic is emitted to suggest the mangled name as a
replacement for the given function name for every matching name in the
current TU.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143803

Files:
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/alias.cpp
  clang/test/CodeGen/attr-ifunc.cpp


Index: clang/test/CodeGen/attr-ifunc.cpp
===
--- /dev/null
+++ clang/test/CodeGen/attr-ifunc.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple x86_64-linux -fsyntax-only -verify -emit-llvm-only 
%s
+
+void *f1_ifunc(void) { return nullptr; }
+void f1(void) __attribute__((ifunc("f1_ifunc")));
+// expected-error@-1 {{ifunc must point to a defined function}}
+// expected-note@-2 {{exists as a mangled name}}
+
+void *f6_resolver_resolver(void) { return 0; }
+void *f6_resolver(void) __attribute__((ifunc("f6_resolver_resolver")));
+// expected-error@-1 {{ifunc must point to a defined function}}
+// expected-note@-2 {{exists as a mangled name}}
+void f6(void) __attribute__((ifunc("f6_resolver")));
+// expected-error@-1 {{ifunc must point to a defined function}}
+// expected-note@-2 {{exists as a mangled name}}
Index: clang/test/CodeGen/alias.cpp
===
--- /dev/null
+++ clang/test/CodeGen/alias.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple x86_64-linux -fsyntax-only -verify -emit-llvm-only 
%s
+
+void *f1_ifunc(void) { return nullptr; }
+void f1(void) __attribute__((alias("f1_ifunc")));
+// expected-error@-1 {{alias must point to a defined variable or function}}
+// expected-note@-2 {{exists as a mangled name}}
+
+void *f6_resolver_resolver(void) { return 0; }
+void *f6_resolver(void) __attribute__((alias("f6_resolver_resolver")));
+// expected-error@-1 {{alias must point to a defined variable or function}}
+// expected-note@-2 {{exists as a mangled name}}
+void f6(void) __attribute__((alias("f6_resolver")));
+// expected-error@-1 {{alias must point to a defined variable or function}}
+// expected-note@-2 {{exists as a mangled name}}
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -341,7 +341,8 @@
 static bool checkAliasedGlobal(DiagnosticsEngine ,
SourceLocation Location, bool IsIFunc,
const llvm::GlobalValue *Alias,
-   const llvm::GlobalValue *) {
+   const llvm::GlobalValue *,
+   const llvm::MapVector 
) {
   GV = getAliasedGlobal(Alias);
   if (!GV) {
 Diags.Report(Location, diag::err_cyclic_alias) << IsIFunc;
@@ -350,6 +351,16 @@
 
   if (GV->isDeclaration()) {
 Diags.Report(Location, diag::err_alias_to_undefined) << IsIFunc << IsIFunc;
+// Provide a note if the given function is not found and exists as a
+// mangled name
+for (const auto &[Decl, Name] : MangledDeclNames) {
+  if (const auto *ND = dyn_cast(Decl.getDecl())) {
+if (ND->getName() == GV->getName()) {
+   Diags.Report(Location, diag::note_alias_requires_mangled_name)
+   << GV->getName() << Name;
+}
+  }
+}
 return false;
   }
 
@@ -390,7 +401,8 @@
 StringRef MangledName = getMangledName(GD);
 llvm::GlobalValue *Alias = GetGlobalValue(MangledName);
 const llvm::GlobalValue *GV = nullptr;
-if (!checkAliasedGlobal(Diags, Location, IsIFunc, Alias, GV)) {
+if (!checkAliasedGlobal(Diags, Location, IsIFunc, Alias, GV,
+MangledDeclNames)) {
   Error = true;
   continue;
 }
Index: clang/include/clang/Basic/DiagnosticFrontendKinds.td
===
--- clang/include/clang/Basic/DiagnosticFrontendKinds.td
+++ clang/include/clang/Basic/DiagnosticFrontendKinds.td
@@ -278,6 +278,8 @@
 def err_alias_to_undefined : Error<
   "%select{alias|ifunc}0 must point to a defined "
   "%select{variable or |}1function">;
+def note_alias_requires_mangled_name : Note<
+  "'%0' exists as a mangled name, did you mean to use '%1'?">;
 def warn_alias_to_weak_alias : Warning<
   "%select{alias|ifunc}2 will always resolve to %0 even if weak definition of "
   "%1 is overridden">,


Index: clang/test/CodeGen/attr-ifunc.cpp
===
--- /dev/null
+++ clang/test/CodeGen/attr-ifunc.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple x86_64-linux -fsyntax-only 

[PATCH] D138546: Clangd: Preserve target flags in system includes extractor

[Christopher Sauer via Phabricator via cfe-commits]

cpsauer added a comment.

@kadircet, friendly check in, since I got reminded of this: How would you like 
to proceed from here?


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

https://reviews.llvm.org/D138546

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

[PATCH] D143691: Fix clang-formats IncludeCategory to match the documentation

[Fabian Keßler via Phabricator via cfe-commits]

Febbe added a comment.

I think I am done, and you can review it now.

With the latest changes, SortPriority is no longer required to match Priority, 
it can always be 0, since Priority is now used in the sorting algorithm.
This is what the documentation tends to depict:

"and #includes are sorted first according to increasing category number and 
then alphabetically within each category."
" There is a third and optional field SortPriority which can used while 
IncludeBlocks = IBS_Regroup to define the priority in which #includes should be 
ordered."


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143691

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

[PATCH] D143691: Fix clang-formats IncludeCategory to match the documentation

[Fabian Keßler via Phabricator via cfe-commits]

Febbe updated this revision to Diff 496650.
Febbe added a comment.

Added priority to the sorting algorithm.
This prevents unwanted splits and weird resorts of groups with the same 
priority, but with different and overlapping (other groups) SortPriority.
The new system can now be understood as Primary.SecondaryPriority instead of:

sort by SecondPriority + bucket By PrimaryPriority


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143691

Files:
  clang/lib/Format/Format.cpp
  clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
  clang/lib/Tooling/Inclusions/IncludeStyle.cpp
  clang/unittests/Format/SortIncludesTest.cpp

Index: clang/unittests/Format/SortIncludesTest.cpp
===
--- clang/unittests/Format/SortIncludesTest.cpp
+++ clang/unittests/Format/SortIncludesTest.cpp
@@ -87,7 +87,7 @@
 TEST_F(SortIncludesTest, SortedIncludesUsingSortPriorityAttribute) {
   FmtStyle.IncludeStyle.IncludeBlocks = tooling::IncludeStyle::IBS_Regroup;
   FmtStyle.IncludeStyle.IncludeCategories = {
-  {"^", 1, 0, false},
+  {"^", 1, 1, false},
   {"^", 1, 1, false},
   {"^ a.priv.h && a.h
+  // E.g. a_test.cpp -> a_test.h && a.h
+  // Maybe add a "//clang-format pragma: not_main" to remove false positives
+
+  // Recognize all possible main #include's with a matching basename as main
+  // include.
   EXPECT_EQ("#include \"a.h\"\n"
+"#include \"llvm/a.h\"\n"
 "#include \"b.h\"\n"
-"#include \"c.h\"\n"
-"#include \"llvm/a.h\"\n",
+"#include \"c.h\"\n",
 sort("#include \"b.h\"\n"
  "#include \"a.h\"\n"
  "#include \"c.h\"\n"
@@ -645,8 +652,9 @@
  "a.h"));
 
   Style.IncludeBlocks = clang::tooling::IncludeStyle::IBS_Regroup;
-  Style.IncludeCategories = {
-  {"^\"", 1, 0, false}, {"^<.*\\.h>$", 2, 0, false}, {"^<", 3, 0, false}};
+  Style.IncludeCategories = {{"^\"", 1, 1, false}, //
+ {"^<.*\\.h>$", 2, 2, false},
+ {"^<", 3, 3, false}};
 
   StringRef UnsortedCode = "#include \"qt.h\"\n"
"#include \n"
@@ -695,11 +703,11 @@
 
 TEST_F(SortIncludesTest, SupportOptionalCaseSensitiveMachting) {
   Style.IncludeBlocks = clang::tooling::IncludeStyle::IBS_Regroup;
-  Style.IncludeCategories = {{"^\"", 1, 0, false},
- {"^<.*\\.h>$", 2, 0, false},
- {"^", 3, 0, false},
- {"^", 4, 0, false},
- {"^<", 5, 0, false}};
+  Style.IncludeCategories = {{"^\"", 1, 1, false},
+ {"^<.*\\.h>$", 2, 2, false},
+ {"^", 3, 3, false},
+ {"^", 4, 4, false},
+ {"^<", 5, 5, false}};
 
   StringRef UnsortedCode = "#include \n"
"#include \"qt.h\"\n"
@@ -744,8 +752,8 @@
 }
 
 TEST_F(SortIncludesTest, NegativePriorities) {
-  Style.IncludeCategories = {{".*important_os_header.*", -1, 0, false},
- {".*", 1, 0, false}};
+  Style.IncludeCategories = {{".*important_os_header.*", -1, -1, false},
+ {".*", 1, 1, false}};
   EXPECT_EQ("#include \"important_os_header.h\"\n"
 "#include \"c_main.h\"\n"
 "#include \"a_other.h\"\n",
@@ -765,8 +773,8 @@
 }
 
 TEST_F(SortIncludesTest, PriorityGroupsAreSeparatedWhenRegroupping) {
-  Style.IncludeCategories = {{".*important_os_header.*", -1, 0, false},
- {".*", 1, 0, false}};
+  Style.IncludeCategories = {{".*important_os_header.*", -1, -1, false},
+ {".*", 1, 1, false}};
   Style.IncludeBlocks = tooling::IncludeStyle::IBS_Regroup;
 
   EXPECT_EQ("#include \"important_os_header.h\"\n"
Index: clang/lib/Tooling/Inclusions/IncludeStyle.cpp
===
--- clang/lib/Tooling/Inclusions/IncludeStyle.cpp
+++ clang/lib/Tooling/Inclusions/IncludeStyle.cpp
@@ -15,9 +15,9 @@
 
 void MappingTraits::mapping(
 IO , IncludeStyle::IncludeCategory ) {
-  IO.mapOptional("Regex", Category.Regex);
-  IO.mapOptional("Priority", Category.Priority);
-  IO.mapOptional("SortPriority", Category.SortPriority);
+  IO.mapRequired("Regex", Category.Regex);
+  IO.mapRequired("Priority", Category.Priority);
+  IO.mapOptional("SortPriority", Category.SortPriority, Category.Priority);
   IO.mapOptional("CaseSensitive", Category.RegexIsCaseSensitive);
 }
 
Index: clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
===
--- clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
+++ clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
@@ -12,6 +12,7 @@
 #include "clang/Lex/Lexer.h"
 #include 

[PATCH] D139798: [clang-repl] Support compound statement as a top-level statement.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

ping


Repository:
  rC Clang

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

https://reviews.llvm.org/D139798

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

[PATCH] D143691: Fix clang-formats IncludeCategory to match the documentation

[Fabian Keßler via Phabricator via cfe-commits]

Febbe updated this revision to Diff 496647.
Febbe added a comment.

Fixed the Unit Tests

- rewritten one test, which made the assumption, that there can be only one 
main header.
  - it now asserts, that all matching headers are considered as main header.
- replaced initialisations of `IncludeCategories.SortPriority` to zero  with 
the value from `IncludeCategories.Priority`
  - the previous approach to set the SortPriority when it's 0 to Priority, 
instead of initializing it directly as intended had several drawbacks:
- values of 0 were not possible and resulted in weird behav.
- when a main include was matched by another matcher, it got annother 
sortpriority than 0.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143691

Files:
  clang/lib/Format/Format.cpp
  clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
  clang/lib/Tooling/Inclusions/IncludeStyle.cpp
  clang/unittests/Format/SortIncludesTest.cpp

Index: clang/unittests/Format/SortIncludesTest.cpp
===
--- clang/unittests/Format/SortIncludesTest.cpp
+++ clang/unittests/Format/SortIncludesTest.cpp
@@ -87,7 +87,7 @@
 TEST_F(SortIncludesTest, SortedIncludesUsingSortPriorityAttribute) {
   FmtStyle.IncludeStyle.IncludeBlocks = tooling::IncludeStyle::IBS_Regroup;
   FmtStyle.IncludeStyle.IncludeCategories = {
-  {"^", 1, 0, false},
+  {"^", 1, 1, false},
   {"^", 1, 1, false},
   {"^ a.priv.h && a.h
+  // E.g. a_test.cpp -> a_test.h && a.h
+  // Maybe add a "//clang-format pragma: not_main" to remove false positives
+
+  // Recognize all possible main #include's with a matching basename as main
+  // include.
   EXPECT_EQ("#include \"a.h\"\n"
+"#include \"llvm/a.h\"\n"
 "#include \"b.h\"\n"
-"#include \"c.h\"\n"
-"#include \"llvm/a.h\"\n",
+"#include \"c.h\"\n",
 sort("#include \"b.h\"\n"
  "#include \"a.h\"\n"
  "#include \"c.h\"\n"
@@ -645,8 +652,9 @@
  "a.h"));
 
   Style.IncludeBlocks = clang::tooling::IncludeStyle::IBS_Regroup;
-  Style.IncludeCategories = {
-  {"^\"", 1, 0, false}, {"^<.*\\.h>$", 2, 0, false}, {"^<", 3, 0, false}};
+  Style.IncludeCategories = {{"^\"", 1, 1, false}, //
+ {"^<.*\\.h>$", 2, 2, false},
+ {"^<", 3, 3, false}};
 
   StringRef UnsortedCode = "#include \"qt.h\"\n"
"#include \n"
@@ -695,11 +703,11 @@
 
 TEST_F(SortIncludesTest, SupportOptionalCaseSensitiveMachting) {
   Style.IncludeBlocks = clang::tooling::IncludeStyle::IBS_Regroup;
-  Style.IncludeCategories = {{"^\"", 1, 0, false},
- {"^<.*\\.h>$", 2, 0, false},
- {"^", 3, 0, false},
- {"^", 4, 0, false},
- {"^<", 5, 0, false}};
+  Style.IncludeCategories = {{"^\"", 1, 1, false},
+ {"^<.*\\.h>$", 2, 2, false},
+ {"^", 3, 3, false},
+ {"^", 4, 4, false},
+ {"^<", 5, 5, false}};
 
   StringRef UnsortedCode = "#include \n"
"#include \"qt.h\"\n"
@@ -744,8 +752,8 @@
 }
 
 TEST_F(SortIncludesTest, NegativePriorities) {
-  Style.IncludeCategories = {{".*important_os_header.*", -1, 0, false},
- {".*", 1, 0, false}};
+  Style.IncludeCategories = {{".*important_os_header.*", -1, -1, false},
+ {".*", 1, 1, false}};
   EXPECT_EQ("#include \"important_os_header.h\"\n"
 "#include \"c_main.h\"\n"
 "#include \"a_other.h\"\n",
@@ -765,8 +773,8 @@
 }
 
 TEST_F(SortIncludesTest, PriorityGroupsAreSeparatedWhenRegroupping) {
-  Style.IncludeCategories = {{".*important_os_header.*", -1, 0, false},
- {".*", 1, 0, false}};
+  Style.IncludeCategories = {{".*important_os_header.*", -1, -1, false},
+ {".*", 1, 1, false}};
   Style.IncludeBlocks = tooling::IncludeStyle::IBS_Regroup;
 
   EXPECT_EQ("#include \"important_os_header.h\"\n"
Index: clang/lib/Tooling/Inclusions/IncludeStyle.cpp
===
--- clang/lib/Tooling/Inclusions/IncludeStyle.cpp
+++ clang/lib/Tooling/Inclusions/IncludeStyle.cpp
@@ -15,9 +15,9 @@
 
 void MappingTraits::mapping(
 IO , IncludeStyle::IncludeCategory ) {
-  IO.mapOptional("Regex", Category.Regex);
-  IO.mapOptional("Priority", Category.Priority);
-  IO.mapOptional("SortPriority", Category.SortPriority);
+  IO.mapRequired("Regex", Category.Regex);
+  IO.mapRequired("Priority", Category.Priority);
+  IO.mapOptional("SortPriority", Category.SortPriority, Category.Priority);
   IO.mapOptional("CaseSensitive", Category.RegexIsCaseSensitive);
 }
 
Index: 

[PATCH] D137458: [clang] Add __decay as a builtin template

[Christopher Di Bella via Phabricator via cfe-commits]

cjdb added subscribers: aaron.ballman, cjdb.
cjdb added a comment.

In D137458#3909343 , @troyj wrote:

>> Also, it would be nice to have some numbers for the 'measurably faster' 
>> claim :)
>
> Sure. Here's an example of a library change that started using builtins for 
> `__make_integer_seq` and `__type_pack_element` 
> https://github.com/facebook/fatal/commit/58102a3f7e66ad122d7d3335c446399b09d5085e
>  where there was a 1.8% speedup for a file that spent 70 seconds in the front 
> end. It also reduced the peak memory usage of the front end by 0.5%. We have 
> reason to believe that a `__decay` builtin would produce similar benefit. 
> Unfortunately, all of the intrinsics in https://reviews.llvm.org/D116203 were 
> implemented with parentheses syntax instead of as builtin templates, which 
> makes it more difficult. Ideally, we'd like to see all of these implemented 
> as builtin templates, but `__decay` is the first one that we're proposing.
>
> I'm not familiar with the mangling issue that you mentioned. I'll look into 
> it more.

Is there a reason that parentheses are insufficient? @aaron.ballman and I 
talked about whether or not using angle-brackets would be a better option at 
one point and concluded that there wasn't any benefit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137458

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

[PATCH] D142907: LangRef: Add "dynamic" option to "denormal-fp-math"

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

In D142907#4119339 , @andrew.w.kaylor 
wrote:

> In general, it seems like the denormal mode should be considered part of the 
> floating point environment (though as far as I know the C standard, at least, 
> doesn't document it as such).

There’s no standardization of denormal flushing. OpenCL defines a flag for it 
but doesn’t really specify what it really means.

> If it were considered part of the floating point environment, the LLVM rules 
> would tell us we could assume the default setting, which I'd assume to be 
> IEEE, and it would only be legal to change this mode in strict mode.

It is. The attribute is informative of the default mode. If we really wanted, a 
similar attribute could declare the assumed rounding mode if we really wanted 
for the function. It doesn’t imply you can change it dynamically, just that it 
should be in that mode before the function executes.

> Do you need to do something with the inliner to handle the case where 
> functions with different denormal modes are inlined into one another? We 
> don't seem to handle that case correctly now 
> (https://godbolt.org/z/PEsWaMEq6), but with the dynamic mode we could handle 
> it without blocking inlining completely.

This patch fixed some bugs in the inlining to make it more conservative in 
undefined looking cases. The inlining of dynamic functions fully works


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

https://reviews.llvm.org/D142907

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

[PATCH] D143794: [Fuchsia] Add FUCHSIA_ENABLE_LLDB option.

[Daniel Thornburgh via Phabricator via cfe-commits]

mysterymath created this revision.
mysterymath added a reviewer: phosek.
Herald added a subscriber: abrachet.
Herald added a project: All.
mysterymath requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This CMake option builds/installs LLDB as part of the Fuchsia toolchain.
Once this is better supported, the effects of this will be inlined into
the toolchain cache file.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143794

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -4,7 +4,7 @@
 
 set(PACKAGE_VENDOR Fuchsia CACHE STRING "")
 
-set(LLVM_ENABLE_PROJECTS "bolt;clang;clang-tools-extra;lld;llvm;polly" CACHE 
STRING "")
+set(_FUCHSIA_ENABLE_PROJECTS "bolt;clang;clang-tools-extra;lld;llvm;polly")
 set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING 
"")
 
 set(LLVM_ENABLE_BACKTRACES OFF CACHE BOOL "")
@@ -321,7 +321,7 @@
   scan-build-py
   CACHE STRING "")
 
-set(LLVM_DISTRIBUTION_COMPONENTS
+set(_FUCHSIA_DISTRIBUTION_COMPONENTS
   clang
   lld
   clang-apply-replacements
@@ -338,3 +338,12 @@
   runtimes
   ${LLVM_TOOLCHAIN_TOOLS}
   CACHE STRING "")
+
+set(FUCHSIA_ENABLE_LLDB OFF CACHE BOOL "Enable LLDB")
+if(FUCHSIA_ENABLE_LLDB)
+  list(APPEND _FUCHSIA_ENABLE_PROJECTS "lldb")
+  list(APPEND _FUCHSIA_DISTRIBUTION_COMPONENTS "lldb")
+endif()
+
+set(LLVM_ENABLE_PROJECTS ${_FUCHSIA_ENABLE_PROJECTS} CACHE STRING "")
+set(LLVM_DISTRIBUTION_COMPONENTS ${_FUCHSIA_DISTRIBUTION_COMPONENTS} CACHE 
STRING "")


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -4,7 +4,7 @@
 
 set(PACKAGE_VENDOR Fuchsia CACHE STRING "")
 
-set(LLVM_ENABLE_PROJECTS "bolt;clang;clang-tools-extra;lld;llvm;polly" CACHE STRING "")
+set(_FUCHSIA_ENABLE_PROJECTS "bolt;clang;clang-tools-extra;lld;llvm;polly")
 set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "")
 
 set(LLVM_ENABLE_BACKTRACES OFF CACHE BOOL "")
@@ -321,7 +321,7 @@
   scan-build-py
   CACHE STRING "")
 
-set(LLVM_DISTRIBUTION_COMPONENTS
+set(_FUCHSIA_DISTRIBUTION_COMPONENTS
   clang
   lld
   clang-apply-replacements
@@ -338,3 +338,12 @@
   runtimes
   ${LLVM_TOOLCHAIN_TOOLS}
   CACHE STRING "")
+
+set(FUCHSIA_ENABLE_LLDB OFF CACHE BOOL "Enable LLDB")
+if(FUCHSIA_ENABLE_LLDB)
+  list(APPEND _FUCHSIA_ENABLE_PROJECTS "lldb")
+  list(APPEND _FUCHSIA_DISTRIBUTION_COMPONENTS "lldb")
+endif()
+
+set(LLVM_ENABLE_PROJECTS ${_FUCHSIA_ENABLE_PROJECTS} CACHE STRING "")
+set(LLVM_DISTRIBUTION_COMPONENTS ${_FUCHSIA_DISTRIBUTION_COMPONENTS} CACHE STRING "")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143501: [clang][DebugInfo] lldb: Use preferred name's type when emitting DW_AT_names

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a subscriber: probinson.
dblaikie added a comment.

In D143501#4116200 , @Michael137 
wrote:

>> I'd recommend a possible long-term solution would be simplified template 
>> names (so we don't have to worry about encoding this in the `DW_AT_name` 
>> anyway) and a "DW_AT_LLVM_preferred_name" or similar attribute on a type 
>> that refers to the typedef that is the preferred name. This would generalize 
>> further than only appearing in template names - the type of a variable 
>> inside a template would also gain the beneficial naming (eg: 
>> `template void f1(T t) { }` - as it stands, the type of the 
>> variable `t` must be `std::basic_string> `DW_TAG_class_type` for `std::basic_string> attribute on it, then a debugger could helpfully render the type by its 
>> preferred alias instead)
>
> That could be a neat solution. I probably asked this before, but what's the 
> timeline with switching it on by default (if such plan is in the works at 
> all)?

I haven't especially planned that - though given it's been picked up by Fuschia 
and Chromium (at least in some build modes), and we got gdb and lldb mostly 
fixed, maybe it's worth considering. Defaulting on for lldb might be easier 
than for gdb (gdb has some outstanding index bugs with it). But generally I 
figure you Apple folks tend to be the ones who have more investment in what the 
lldb tuning should cover, or not?

If you folks want to try turning it on & we could see about turning it on by 
default for lldb tuning?

>> Alternatively, I suppose, the DWARF emission could just look at the 
>> preferred name and use that as the `DW_AT_type` in all cases anyway? Avoids 
>> needing a new attribute, etc, though would be a bit quirky in its own way.
>
> This is how I first thought of implementing it, but ran into some circular 
> dependency quirks and started working on this patch instead. Could take a 
> second stab at doing so if that's the preference. Would be nice to not have 
> this behind a tuning

yeah, happy to help with pointers, etc.

I think /maybe/ we had some design principle that DWARF features wouldn't be 
solely controlled by debugger tuning, the tuning only indicates defaults but 
tehy can be controlled by flags? Not sure if I'm remembering that quite right, 
though - maybe @probinson remembers more of that?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143501

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

[PATCH] D143664: [SanitizerBinaryMetadata] Support ignore list

[Marco Elver via Phabricator via cfe-commits]

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



Comment at: clang/test/CodeGen/sanitize-metadata-ignorelist.c:11
+// ALLOW-SAME: () local_unnamed_addr #[[ATTR0:[0-9]+]] !pcsections !5 {
+// ALLOW-NEXT:  entry:
+// ALLOW-NEXT:[[TMP0:%.*]] = atomicrmw add ptr @y, i32 1 monotonic, align 
4, !pcsections !7

chapuni wrote:
> It should match if it is unnamed.
Thanks for the report. %clang and %clang_cc1 behave differently with +Assert 
and -Assert. I switched to %clang_cc1 which is consistent.

https://reviews.llvm.org/rGdac423bd5718


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143664

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

[clang] dac423b - [SanitizerBinaryMetadata] Fix ignorelist test with -Assert

[Marco Elver via cfe-commits]

Author: Marco Elver
Date: 2023-02-11T00:33:13+01:00
New Revision: dac423bd571858a85f3b388904392f0e55421d7d

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

LOG: [SanitizerBinaryMetadata] Fix ignorelist test with -Assert

%clang and %clang_cc1 have different behaviour, and with -Assert %clang
seems to not match +Assert behaviour. Fix it by switching to %clang_cc1
for the test.

Fixes: 421215b919d0 ("[SanitizerBinaryMetadata] Support ignore list")

Added: 


Modified: 
clang/test/CodeGen/sanitize-metadata-ignorelist.c

Removed: 




diff  --git a/clang/test/CodeGen/sanitize-metadata-ignorelist.c 
b/clang/test/CodeGen/sanitize-metadata-ignorelist.c
index 1458b681672c..b5656fd0781d 100644
--- a/clang/test/CodeGen/sanitize-metadata-ignorelist.c
+++ b/clang/test/CodeGen/sanitize-metadata-ignorelist.c
@@ -1,15 +1,15 @@
-// RUN: %clang -O -fexperimental-sanitize-metadata=all -target 
x86_64-gnu-linux -x c -S -emit-llvm %s -o - | FileCheck %s 
--check-prefixes=ALLOW
+// RUN: %clang_cc1 -O -fexperimental-sanitize-metadata=atomics -triple 
x86_64-gnu-linux -x c -S -emit-llvm %s -o - | FileCheck %s 
--check-prefixes=ALLOW
 // RUN: echo "fun:foo" > %t.fun
-// RUN: %clang -O -fexperimental-sanitize-metadata=all 
-fexperimental-sanitize-metadata-ignorelist=%t.fun -target x86_64-gnu-linux -x 
c -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=FUN
+// RUN: %clang_cc1 -O -fexperimental-sanitize-metadata=atomics 
-fexperimental-sanitize-metadata-ignorelist=%t.fun -triple x86_64-gnu-linux -x 
c -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=FUN
 // RUN: echo "src:*sanitize-metadata-ignorelist.c" > %t.src
-// RUN: %clang -O -fexperimental-sanitize-metadata=all 
-fexperimental-sanitize-metadata-ignorelist=%t.src -target x86_64-gnu-linux -x 
c -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=SRC
+// RUN: %clang_cc1 -O -fexperimental-sanitize-metadata=atomics 
-fexperimental-sanitize-metadata-ignorelist=%t.src -triple x86_64-gnu-linux -x 
c -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=SRC
 
 int y;
 
 // ALLOW-LABEL: define {{[^@]+}}@foo
-// ALLOW-SAME: () local_unnamed_addr #[[ATTR0:[0-9]+]] !pcsections !5 {
+// ALLOW-SAME: () local_unnamed_addr #[[ATTR0:[0-9]+]] !pcsections !2 {
 // ALLOW-NEXT:  entry:
-// ALLOW-NEXT:[[TMP0:%.*]] = atomicrmw add ptr @y, i32 1 monotonic, align 
4, !pcsections !7
+// ALLOW-NEXT:[[TMP0:%.*]] = atomicrmw add ptr @y, i32 1 monotonic, align 
4, !pcsections !4
 // ALLOW-NEXT:ret void
 //
 // FUN-LABEL: define {{[^@]+}}@foo
@@ -29,15 +29,15 @@ void foo() {
 }
 
 // ALLOW-LABEL: define {{[^@]+}}@bar
-// ALLOW-SAME: () local_unnamed_addr #[[ATTR0]] !pcsections !5 {
+// ALLOW-SAME: () local_unnamed_addr #[[ATTR0]] !pcsections !2 {
 // ALLOW-NEXT:  entry:
-// ALLOW-NEXT:[[TMP0:%.*]] = atomicrmw add ptr @y, i32 2 monotonic, align 
4, !pcsections !7
+// ALLOW-NEXT:[[TMP0:%.*]] = atomicrmw add ptr @y, i32 2 monotonic, align 
4, !pcsections !4
 // ALLOW-NEXT:ret void
 //
 // FUN-LABEL: define {{[^@]+}}@bar
-// FUN-SAME: () local_unnamed_addr #[[ATTR0]] !pcsections !5 {
+// FUN-SAME: () local_unnamed_addr #[[ATTR0]] !pcsections !2 {
 // FUN-NEXT:  entry:
-// FUN-NEXT:[[TMP0:%.*]] = atomicrmw add ptr @y, i32 2 monotonic, align 4, 
!pcsections !7
+// FUN-NEXT:[[TMP0:%.*]] = atomicrmw add ptr @y, i32 2 monotonic, align 4, 
!pcsections !4
 // FUN-NEXT:ret void
 //
 // SRC-LABEL: define {{[^@]+}}@bar



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

[PATCH] D143781: [Clang][LLVM] Enable __arithmetic_fence and fprotect-parens on AArch64

[Alexander Shaposhnikov via Phabricator via cfe-commits]

alexander-shaposhnikov created this revision.
alexander-shaposhnikov added reviewers: efriedma, aaron.ballman, mibintc.
alexander-shaposhnikov created this object with visibility "All Users".
Herald added a subscriber: kristof.beyls.
Herald added a project: All.
alexander-shaposhnikov requested review of this revision.
Herald added projects: clang, LLVM.
Herald added a subscriber: cfe-commits.

Enable __arithmetic_fence and fprotect-parens on AArch64  (introduced in 
https://reviews.llvm.org/D100118)

Test plan: ninja check-all


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143781

Files:
  clang/lib/Basic/Targets/AArch64.h
  clang/test/AST/arithmetic-fence-builtin.c
  clang/test/CodeGen/arithmetic-fence-builtin.c
  llvm/test/CodeGen/AArch64/arithmetic_fence.ll

Index: llvm/test/CodeGen/AArch64/arithmetic_fence.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/arithmetic_fence.ll
@@ -0,0 +1,129 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=aarch64-none-linux-gnu -mattr=-neon -fp-contract=fast | FileCheck %s --check-prefix=Aarch64
+; RUN: llc < %s -mtriple=aarch64-none-linux-gnu -mattr=+neon -fp-contract=fast | FileCheck %s --check-prefix=Aarch64-Neon
+
+define float @f1(float %a, float %b, float %c) {
+; Aarch64-LABEL: f1:
+; Aarch64:   // %bb.0:
+; Aarch64-NEXT:fmadd s0, s1, s0, s2
+; Aarch64-NEXT:ret
+;
+; Aarch64-Neon-LABEL: f1:
+; Aarch64-Neon:   // %bb.0:
+; Aarch64-Neon-NEXT:fmadd s0, s1, s0, s2
+; Aarch64-Neon-NEXT:ret
+  %mul = fmul fast float %b, %a
+  %add = fadd fast float %mul, %c
+  ret float %add
+}
+
+define float @f2(float %a, float %b, float %c) {
+; Aarch64-LABEL: f2:
+; Aarch64:   // %bb.0:
+; Aarch64-NEXT:fmul s0, s1, s0
+; Aarch64-NEXT://ARITH_FENCE
+; Aarch64-NEXT:fadd s0, s0, s2
+; Aarch64-NEXT:ret
+;
+; Aarch64-Neon-LABEL: f2:
+; Aarch64-Neon:   // %bb.0:
+; Aarch64-Neon-NEXT:fmul s0, s1, s0
+; Aarch64-Neon-NEXT://ARITH_FENCE
+; Aarch64-Neon-NEXT:fadd s0, s0, s2
+; Aarch64-Neon-NEXT:ret
+  %mul = fmul fast float %b, %a
+  %tmp = call float @llvm.arithmetic.fence.f32(float %mul)
+  %add = fadd fast float %tmp, %c
+  ret float %add
+}
+
+define double @f3(double %a) {
+; Aarch64-LABEL: f3:
+; Aarch64:   // %bb.0:
+; Aarch64-NEXT:fmov d1, #4.
+; Aarch64-NEXT:fmul d0, d0, d1
+; Aarch64-NEXT:ret
+;
+; Aarch64-Neon-LABEL: f3:
+; Aarch64-Neon:   // %bb.0:
+; Aarch64-Neon-NEXT:fmov d1, #4.
+; Aarch64-Neon-NEXT:fmul d0, d0, d1
+; Aarch64-Neon-NEXT:ret
+  %1 = fadd fast double %a, %a
+  %2 = fadd fast double %a, %a
+  %3 = fadd fast double %1, %2
+  ret double %3
+}
+
+define double @f4(double %a) {
+; Aarch64-LABEL: f4:
+; Aarch64:   // %bb.0:
+; Aarch64-NEXT:fadd d0, d0, d0
+; Aarch64-NEXT:fmov d1, d0
+; Aarch64-NEXT://ARITH_FENCE
+; Aarch64-NEXT:fadd d0, d1, d0
+; Aarch64-NEXT:ret
+;
+; Aarch64-Neon-LABEL: f4:
+; Aarch64-Neon:   // %bb.0:
+; Aarch64-Neon-NEXT:fadd d0, d0, d0
+; Aarch64-Neon-NEXT:fmov d1, d0
+; Aarch64-Neon-NEXT://ARITH_FENCE
+; Aarch64-Neon-NEXT:fadd d0, d1, d0
+; Aarch64-Neon-NEXT:ret
+  %1 = fadd fast double %a, %a
+  %t = call double @llvm.arithmetic.fence.f64(double %1)
+  %2 = fadd fast double %a, %a
+  %3 = fadd fast double %t, %2
+  ret double %3
+}
+
+define <2 x float> @f5(<2 x float> %a) {
+; Aarch64-LABEL: f5:
+; Aarch64:   // %bb.0:
+; Aarch64-NEXT:fmov s2, #4.
+; Aarch64-NEXT:fmul s0, s0, s2
+; Aarch64-NEXT:fmul s1, s1, s2
+; Aarch64-NEXT:ret
+;
+; Aarch64-Neon-LABEL: f5:
+; Aarch64-Neon:   // %bb.0:
+; Aarch64-Neon-NEXT:fmov v1.2s, #4.
+; Aarch64-Neon-NEXT:fmul v0.2s, v0.2s, v1.2s
+; Aarch64-Neon-NEXT:ret
+  %1 = fadd fast <2 x float> %a, %a
+  %2 = fadd fast <2 x float> %a, %a
+  %3 = fadd fast <2 x float> %1, %2
+  ret <2 x float> %3
+}
+
+define <2 x float> @f6(<2 x float> %a) {
+; Aarch64-LABEL: f6:
+; Aarch64:   // %bb.0:
+; Aarch64-NEXT:fadd s0, s0, s0
+; Aarch64-NEXT:fadd s1, s1, s1
+; Aarch64-NEXT:fmov s2, s1
+; Aarch64-NEXT:fmov s3, s0
+; Aarch64-NEXT://ARITH_FENCE
+; Aarch64-NEXT://ARITH_FENCE
+; Aarch64-NEXT:fadd s0, s3, s0
+; Aarch64-NEXT:fadd s1, s2, s1
+; Aarch64-NEXT:ret
+;
+; Aarch64-Neon-LABEL: f6:
+; Aarch64-Neon:   // %bb.0:
+; Aarch64-Neon-NEXT:fadd v0.2s, v0.2s, v0.2s
+; Aarch64-Neon-NEXT:fmov d1, d0
+; Aarch64-Neon-NEXT://ARITH_FENCE
+; Aarch64-Neon-NEXT:fadd v0.2s, v1.2s, v0.2s
+; Aarch64-Neon-NEXT:ret
+  %1 = fadd fast <2 x float> %a, %a
+  %t = call <2 x float> @llvm.arithmetic.fence.v2f32(<2 x float> %1)
+  %2 = fadd fast <2 x float> %a, %a
+  %3 = fadd fast <2 x float> %t, %2
+  ret <2 x float> %3
+}
+
+declare float @llvm.arithmetic.fence.f32(float)
+declare double @llvm.arithmetic.fence.f64(double)
+declare <2 x 

[clang] 043550e - [Driver] Stop stack use after free

[Alex Brachet via cfe-commits]

Author: Alex Brachet
Date: 2023-02-10T22:42:12Z
New Revision: 043550e33509fb3179cfcd6516e8d93240553582

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

LOG: [Driver] Stop stack use after free

In reality this would have always been fine because main's
stack frame will always be live when another thread is
executing the cc1_reproducer_main. But ASan and HWASan
were upset

Added: 


Modified: 
clang/tools/driver/driver.cpp

Removed: 




diff  --git a/clang/tools/driver/driver.cpp b/clang/tools/driver/driver.cpp
index 52d391fc6971..3ec2bcc0bd75 100644
--- a/clang/tools/driver/driver.cpp
+++ b/clang/tools/driver/driver.cpp
@@ -537,7 +537,7 @@ int clang_main(int Argc, char **Argv, const 
llvm::ToolContext ) {
 return 1;
 
   if (!UseNewCC1Process) {
-TheDriver.CC1Main = [](SmallVectorImpl ) {
+TheDriver.CC1Main = [ToolContext](SmallVectorImpl ) {
   return ExecuteCC1Tool(ArgV, ToolContext);
 };
 // Ensure the CC1Command actually catches cc1 crashes



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

[libunwind] 0751fc6 - [libunwind] On Darwin, add a callback-based lookup scheme for JIT'd unwind info.

[Lang Hames via cfe-commits]

Author: Lang Hames
Date: 2023-02-10T14:36:25-08:00
New Revision: 0751fc68b976d25dd3041217dad16622cf151cd6

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

LOG: [libunwind] On Darwin, add a callback-based lookup scheme for JIT'd unwind 
info.

This commit adds support for a new callback-based lookup scheme for unwind
info that was inspired by the `_dyld_find_unwind_info_sections` SPI that
libunwind uses to find unwind-info in non-JIT'd frames. From
llvm-project/libunwind/src/AddressSpace.hpp:

```
struct dyld_unwind_sections {
  const struct mach_header*   mh;
  const void* dwarf_section;
  uintptr_t   dwarf_section_length;
  const void* compact_unwind_section;
  uintptr_t   compact_unwind_section_length;
};

extern bool _dyld_find_unwind_sections(void *, dyld_unwind_sections *);
```

During unwinding libunwind calls `_dyld_find_unwind_sections` to both find
unwind section addresses and identify the subarchitecture for frames (via the
MachO-header pointed to by the mh field).

This commit introduces two new libunwind SPI functions:

```
struct unw_dynamic_unwind_sections {
  unw_word_t dso_base;
  unw_word_t dwarf_section;
  size_t dwarf_section_length;
  unw_word_t compact_unwind_section;
  size_t compact_unwind_section_length;
};

typedef int (*unw_find_dynamic_unwind_sections)(
unw_word_t addr, struct unw_dynamic_unwind_sections *info);

// Returns UNW_ESUCCESS if successfully registered, UNW_EINVAL for duplicate
// registrations, and UNW_ENOMEM to indicate too many registrations.
extern int __unw_add_find_dynamic_unwind_sections(
unw_find_dynamic_unwind_sections find_dynamic_unwind_sections);

// Returns UNW_ESUCCESS if successfully deregistered, UNW_EINVAL to indicate
// no such registration.
extern int __unw_remove_find_dynamic_unwind_sections(
unw_find_dynamic_unwind_sections find_dynamic_unwind_sections);
```

These can be used to register and deregister callbacks that have a similar
signature to `_dyld_find_unwind_sections`. During unwinding if
`_dyld_find_unwind_sections` returns false (indicating that no frame info
was found by dyld) then registered callbacks are run in registration order until
either the unwind info is found or the end of the list is reached.

With this commit, and by implementing the find-unwind-info callback in the ORC
runtime in LLVM, we (1) enable support for registering JIT'd compact-unwind info
with libunwind*, (2) provide a way to identify the subarchitecture for each 
frame
(by returning a pointer to a JIT'd MachO header), and (3) delegate tracking of
unwind info to the callback, which may be able to implement more efficient
address-based lookup than libunwind.

* JITLink does not process or register compact unwind info yet, so this patch
  does not fully enable compact unwind info in ORC, it simply provides some
  necessary plumbing. JITLink support for compact unwind should land some time
  in the LLVM 17 development cycle.

Reviewed By: pete

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

Added: 


Modified: 
libunwind/src/AddressSpace.hpp
libunwind/src/libunwind.cpp
libunwind/src/libunwind_ext.h

Removed: 




diff  --git a/libunwind/src/AddressSpace.hpp b/libunwind/src/AddressSpace.hpp
index 26d289068b38c..1abbc82254687 100644
--- a/libunwind/src/AddressSpace.hpp
+++ b/libunwind/src/AddressSpace.hpp
@@ -66,6 +66,10 @@ char *getFuncNameFromTBTable(uintptr_t pc, uint16_t ,
   // In 10.7.0 or later, libSystem.dylib implements this function.
   extern "C" bool _dyld_find_unwind_sections(void *, dyld_unwind_sections *);
 
+namespace libunwind {
+  bool findDynamicUnwindSections(void *, unw_dynamic_unwind_sections *);
+}
+
 #elif defined(_LIBUNWIND_SUPPORT_DWARF_UNWIND) && 
defined(_LIBUNWIND_IS_BAREMETAL)
 
 // When statically linked on bare-metal, the symbols for the EH table are 
looked
@@ -497,6 +501,22 @@ inline bool LocalAddressSpace::findUnwindSections(pint_t 
targetAddr,
 info.compact_unwind_section_length = 
(size_t)dyldInfo.compact_unwind_section_length;
 return true;
   }
+
+  unw_dynamic_unwind_sections dynamicUnwindSectionInfo;
+  if (findDynamicUnwindSections((void *)targetAddr,
+)) {
+info.dso_base = dynamicUnwindSectionInfo.dso_base;
+#if defined(_LIBUNWIND_SUPPORT_DWARF_UNWIND)
+info.dwarf_section = (uintptr_t)dynamicUnwindSectionInfo.dwarf_section;
+info.dwarf_section_length = dynamicUnwindSectionInfo.dwarf_section_length;
+#endif
+info.compact_unwind_section =
+(uintptr_t)dynamicUnwindSectionInfo.compact_unwind_section;
+info.compact_unwind_section_length =
+dynamicUnwindSectionInfo.compact_unwind_section_length;
+return true;
+  }
+
 #elif 

[PATCH] D142939: Fix handling of -> calls for modernize-use-emplace

[Peter Wolf via Phabricator via cfe-commits]

BigPeet added a comment.

Thank you very much.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142939

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

[PATCH] D143768: [Clang] Add options to disable direct linking of arch tools

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

Like I said, the difference between these dependencies and something like 
`libxml2` or `libz` is that the presence of the libraries doesn't guard any 
features. We can build the application both ways, the only difference is 
runtime cost if we don't link the library directly and a more annoying 
development environment. For the `amdgpu-arch` and `nvptx-arch` it might be 
easier to just always `dlopen` them to avoid this conversation entirely. So I'm 
just not sure if it's worth the extra effort to configure something that's 
fundamentally optional.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143768

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

[PATCH] D143664: [SanitizerBinaryMetadata] Support ignore list

[NAKAMURA Takumi via Phabricator via cfe-commits]

chapuni added a comment.

The test `sanitize-metadata-ignorelist.c` fails in -Asserts.




Comment at: clang/test/CodeGen/sanitize-metadata-ignorelist.c:11
+// ALLOW-SAME: () local_unnamed_addr #[[ATTR0:[0-9]+]] !pcsections !5 {
+// ALLOW-NEXT:  entry:
+// ALLOW-NEXT:[[TMP0:%.*]] = atomicrmw add ptr @y, i32 1 monotonic, align 
4, !pcsections !7

It should match if it is unnamed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143664

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

[PATCH] D142907: LangRef: Add "dynamic" option to "denormal-fp-math"

[Andy Kaylor via Phabricator via cfe-commits]

andrew.w.kaylor added a comment.

In general, it seems like the denormal mode should be considered part of the 
floating point environment (though as far as I know the C standard, at least, 
doesn't document it as such). If it were considered part of the floating point 
environment, the LLVM rules would tell us we could assume the default setting, 
which I'd assume to be IEEE, and it would only be legal to change this mode in 
strict mode. However, for your use case preserving the behavior of fpclass 
seems like what users would want, even in fast-math modes. In this sense, this 
is a lot like the problem we have with preserving isnan() behavior when 
fast-math is enabled. Our rules allow it, but it's not what most people would 
want.

I think the new denormal mode is a good addition.

Do you need to do something with the inliner to handle the case where functions 
with different denormal modes are inlined into one another? We don't seem to 
handle that case correctly now (https://godbolt.org/z/PEsWaMEq6), but with the 
dynamic mode we could handle it without blocking inlining completely.


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

https://reviews.llvm.org/D142907

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

[PATCH] D143768: [Clang] Add options to disable direct linking of arch tools

[Aaron Siddhartha Mondal via Phabricator via cfe-commits]

aaronmondal added a comment.

This would also allow e.g. the ROCm packages to `FORCE_ON` hsa and enjoy the 
benefits of the LLVM configuration 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143768

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

[PATCH] D143768: [Clang] Add options to disable direct linking of arch tools

[Aaron Siddhartha Mondal via Phabricator via cfe-commits]

aaronmondal added a comment.

Fun fact I now know that libxml2 also struggles with this 

The following would roughly be how zlib and others handle it:

  if (CLANG_ENABLE_HSA)
  
if (CLANG_ENABLE_HSA STREQUAL FORCE_ON)
  find_package(hsa-runtime... REQUIRED)
else()
  find_package (hsa-runtime...)
endif()
  
if (hsa-runtime_FOUND)
  # TODO: Some hsa sanity check, executed during configuration.
  # If check passes, `HAVE_HSA` is set.
  if (CLANG_ENABLE_HSA STREQUAL FORCE_ON AND NOT HAVE_HSA)
message(FATAL_ERROR "Failed to configure HSA.")
  endif()
endif()
  
set(CLANG_ENABLE_HSA "${HAVE_HSA}")
  
  else()
set(CLANG_ENABLE_HSA 0)
  endif()

Then we could remove `__have_include` and could directly check for 
`CLANG_ENABLE_HSA` during compile time.

  #ifdef CLANG_HAVE_HSA
  #include "hsa/hsa.h"
  #endif

Since HSA is used by both OpenMP and the amdgpu-arch plugin, I think it would 
make sense to not call it `CLANG_ENABLE_HSA` but instead use `LLVM_ENABLE_HSA` 
and just put it `llvm/cmake/config-ix.cmake` (where I took the above code from).

@jhuber6 This doesn't consider the "DYNAMIC_..." macros. Do you think an 
approach like this, if worked out a bit more, could work?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143768

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

[clang] 3e57aa3 - [llvm-driver] Reinvoke clang as described by llvm driver extra args

[Alex Brachet via cfe-commits]

Author: Alex Brachet
Date: 2023-02-10T19:42:32Z
New Revision: 3e57aa304f15a0821e5bcc90bd346529fed6658d

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

LOG: [llvm-driver] Reinvoke clang as described by llvm driver extra args

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

Added: 


Modified: 
clang/include/clang/Driver/Driver.h
clang/include/clang/Driver/Job.h
clang/lib/Driver/Driver.cpp
clang/lib/Driver/Job.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Analysis/scan-build/lit.local.cfg
clang/test/CodeGen/debug-info-codeview-buildinfo.c
clang/test/Driver/check-time-trace.cpp
clang/tools/driver/cc1gen_reproducer_main.cpp
clang/tools/driver/driver.cpp
clang/tools/scan-build/libexec/ccc-analyzer
llvm/cmake/modules/llvm-driver-template.cpp.in
llvm/include/llvm/Support/LLVMDriver.h
llvm/lib/Support/Path.cpp
llvm/lib/Support/Unix/Path.inc
llvm/lib/Support/Windows/Path.inc
llvm/tools/llvm-driver/llvm-driver.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Driver.h 
b/clang/include/clang/Driver/Driver.h
index 4bbb113b6cf59..c9136ec4ae690 100644
--- a/clang/include/clang/Driver/Driver.h
+++ b/clang/include/clang/Driver/Driver.h
@@ -21,6 +21,7 @@
 #include "clang/Driver/Types.h"
 #include "clang/Driver/Util.h"
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/STLFunctionalExtras.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Option/Arg.h"
@@ -261,7 +262,8 @@ class Driver {
   /// When the clangDriver lib is used through clang.exe, this provides a
   /// shortcut for executing the -cc1 command-line directly, in the same
   /// process.
-  typedef int (*CC1ToolFunc)(SmallVectorImpl );
+  using CC1ToolFunc =
+  llvm::function_ref )>;
   CC1ToolFunc CC1Main = nullptr;
 
 private:
@@ -286,6 +288,12 @@ class Driver {
   /// Arguments originated from command line.
   std::unique_ptr CLOptions;
 
+  /// If this is non-null, the driver will prepend this argument before
+  /// reinvoking clang. This is useful for the llvm-driver where clang's
+  /// realpath will be to the llvm binary and not clang, so it must pass
+  /// "clang" as it's first argument.
+  const char *PrependArg;
+
   /// Whether to check that input files exist when constructing compilation
   /// jobs.
   unsigned CheckInputsExist : 1;
@@ -383,6 +391,9 @@ class Driver {
   bool getProbePrecompiled() const { return ProbePrecompiled; }
   void setProbePrecompiled(bool Value) { ProbePrecompiled = Value; }
 
+  const char *getPrependArg() const { return PrependArg; }
+  void setPrependArg(const char *Value) { PrependArg = Value; }
+
   void setTargetAndMode(const ParsedClangName ) { ClangNameParts = TM; }
 
   const std::string () { return DriverTitle; }

diff  --git a/clang/include/clang/Driver/Job.h 
b/clang/include/clang/Driver/Job.h
index e3fa92d6ad5fd..e866679dc1a91 100644
--- a/clang/include/clang/Driver/Job.h
+++ b/clang/include/clang/Driver/Job.h
@@ -116,6 +116,9 @@ class Command {
   /// The executable to run.
   const char *Executable;
 
+  /// Optional argument to prepend.
+  const char *PrependArg;
+
   /// The list of program arguments (not including the implicit first
   /// argument, which will be the executable).
   llvm::opt::ArgStringList Arguments;
@@ -169,7 +172,8 @@ class Command {
   Command(const Action , const Tool ,
   ResponseFileSupport ResponseSupport, const char *Executable,
   const llvm::opt::ArgStringList , ArrayRef 
Inputs,
-  ArrayRef Outputs = std::nullopt);
+  ArrayRef Outputs = std::nullopt,
+  const char *PrependArg = nullptr);
   // FIXME: This really shouldn't be copyable, but is currently copied in some
   // error handling in Driver::generateCompilationDiagnostics.
   Command(const Command &) = default;
@@ -242,7 +246,8 @@ class CC1Command : public Command {
  ResponseFileSupport ResponseSupport, const char *Executable,
  const llvm::opt::ArgStringList ,
  ArrayRef Inputs,
- ArrayRef Outputs = std::nullopt);
+ ArrayRef Outputs = std::nullopt,
+ const char *PrependArg = nullptr);
 
   void Print(llvm::raw_ostream , const char *Terminator, bool Quote,
  CrashReportInfo *CrashInfo = nullptr) const override;

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 8d8bd55cabae6..0567441225d0c 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -200,7 +200,7 @@ Driver::Driver(StringRef ClangExecutable, StringRef 
TargetTriple,
   DriverTitle(Title), CCCPrintBindings(false), CCPrintOptions(false),
   CCLogDiagnostics(false), CCGenDiagnostics(false),
   CCPrintProcessStats(false), 

[PATCH] D137800: [llvm-driver] Reinvoke clang as described by llvm driver extra args

[Alex Brachet via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
abrachet marked 2 inline comments as done.
Closed by commit rG3e57aa304f15: [llvm-driver] Reinvoke clang as described by 
llvm driver extra args (authored by abrachet).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D137800?vs=492622=496573#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137800

Files:
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Job.h
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/Job.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Analysis/scan-build/lit.local.cfg
  clang/test/CodeGen/debug-info-codeview-buildinfo.c
  clang/test/Driver/check-time-trace.cpp
  clang/tools/driver/cc1gen_reproducer_main.cpp
  clang/tools/driver/driver.cpp
  clang/tools/scan-build/libexec/ccc-analyzer
  llvm/cmake/modules/llvm-driver-template.cpp.in
  llvm/include/llvm/Support/LLVMDriver.h
  llvm/lib/Support/Path.cpp
  llvm/lib/Support/Unix/Path.inc
  llvm/lib/Support/Windows/Path.inc
  llvm/tools/llvm-driver/llvm-driver.cpp

Index: llvm/tools/llvm-driver/llvm-driver.cpp
===
--- llvm/tools/llvm-driver/llvm-driver.cpp
+++ llvm/tools/llvm-driver/llvm-driver.cpp
@@ -36,7 +36,7 @@
<< "OPTIONS:\n\n  --help - Display this message";
 }
 
-static int findTool(int Argc, char **Argv) {
+static int findTool(int Argc, char **Argv, const char *Argv0) {
   if (!Argc) {
 printHelpMessage();
 return 1;
@@ -62,21 +62,22 @@
 return false;
   };
 
+  auto MakeDriverArgs = [=]() -> llvm::ToolContext {
+if (ToolName != Argv0)
+  return {Argv0, ToolName.data(), true};
+return {Argv0, sys::path::filename(Argv0).data(), false};
+  };
+
 #define LLVM_DRIVER_TOOL(tool, entry)  \
   if (Is(tool))\
-return entry##_main(Argc, Argv, {});
+return entry##_main(Argc, Argv, MakeDriverArgs());
 #include "LLVMDriverTools.def"
 
   if (Is("llvm"))
-return findTool(Argc - 1, Argv + 1);
+return findTool(Argc - 1, Argv + 1, Argv0);
 
   printHelpMessage();
   return 1;
 }
 
-extern bool IsLLVMDriver;
-
-int main(int Argc, char **Argv) {
-  IsLLVMDriver = true;
-  return findTool(Argc, Argv);
-}
+int main(int Argc, char **Argv) { return findTool(Argc, Argv, Argv[0]); }
Index: llvm/lib/Support/Windows/Path.inc
===
--- llvm/lib/Support/Windows/Path.inc
+++ llvm/lib/Support/Windows/Path.inc
@@ -130,7 +130,7 @@
 
 const file_t kInvalidFile = INVALID_HANDLE_VALUE;
 
-std::string getMainExecutableImpl(const char *argv0, void *MainExecAddr) {
+std::string getMainExecutable(const char *argv0, void *MainExecAddr) {
   SmallVector PathName;
   PathName.resize_for_overwrite(PathName.capacity());
   DWORD Size = ::GetModuleFileNameW(NULL, PathName.data(), PathName.size());
Index: llvm/lib/Support/Unix/Path.inc
===
--- llvm/lib/Support/Unix/Path.inc
+++ llvm/lib/Support/Unix/Path.inc
@@ -190,7 +190,7 @@
 
 /// GetMainExecutable - Return the path to the main executable, given the
 /// value of argv[0] from program startup.
-std::string getMainExecutableImpl(const char *argv0, void *MainAddr) {
+std::string getMainExecutable(const char *argv0, void *MainAddr) {
 #if defined(__APPLE__)
   // On OS X the executable path is saved to the stack by dyld. Reading it
   // from there is much faster than calling dladdr, especially for large
Index: llvm/lib/Support/Path.cpp
===
--- llvm/lib/Support/Path.cpp
+++ llvm/lib/Support/Path.cpp
@@ -1202,18 +1202,10 @@
 #include "Windows/Path.inc"
 #endif
 
-bool IsLLVMDriver = false;
-
 namespace llvm {
 namespace sys {
 namespace fs {
 
-std::string getMainExecutable(const char *Argv0, void *MainAddr) {
-  if (IsLLVMDriver)
-return sys::path::stem(Argv0).str();
-  return getMainExecutableImpl(Argv0, MainAddr);
-}
-
 TempFile::TempFile(StringRef Name, int FD)
 : TmpName(std::string(Name)), FD(FD) {}
 TempFile::TempFile(TempFile &) { *this = std::move(Other); }
Index: llvm/include/llvm/Support/LLVMDriver.h
===
--- llvm/include/llvm/Support/LLVMDriver.h
+++ llvm/include/llvm/Support/LLVMDriver.h
@@ -9,9 +9,20 @@
 #ifndef LLVM_SUPPORT_LLVMDRIVER_H
 #define LLVM_SUPPORT_LLVMDRIVER_H
 
+#include "llvm/ADT/SmallVector.h"
+
 namespace llvm {
 
-struct ToolContext {};
+struct ToolContext {
+  const char *Path;
+  const char *PrependArg;
+  // PrependArg will be added unconditionally by the llvm-driver, but
+  // NeedsPrependArg will be 

[clang] 1f173a0 - [llvm-driver] Pass extra arguments to tools

[Alex Brachet via cfe-commits]

Author: Alex Brachet
Date: 2023-02-10T19:42:32Z
New Revision: 1f173a0653e7f0c3800033edfa16ffe4c35cde85

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

LOG: [llvm-driver] Pass extra arguments to tools

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

Added: 
llvm/include/llvm/Support/LLVMDriver.h

Modified: 
clang/tools/driver/driver.cpp
lld/tools/lld/lld.cpp
llvm/cmake/modules/llvm-driver-template.cpp.in
llvm/tools/dsymutil/CMakeLists.txt
llvm/tools/dsymutil/dsymutil.cpp
llvm/tools/llvm-ar/llvm-ar.cpp
llvm/tools/llvm-cxxfilt/llvm-cxxfilt.cpp
llvm/tools/llvm-driver/llvm-driver.cpp
llvm/tools/llvm-ifs/llvm-ifs.cpp
llvm/tools/llvm-lipo/llvm-lipo.cpp
llvm/tools/llvm-mt/llvm-mt.cpp
llvm/tools/llvm-nm/llvm-nm.cpp
llvm/tools/llvm-objcopy/llvm-objcopy.cpp
llvm/tools/llvm-profdata/llvm-profdata.cpp
llvm/tools/llvm-rc/llvm-rc.cpp
llvm/tools/llvm-readobj/llvm-readobj.cpp
llvm/tools/llvm-size/llvm-size.cpp

Removed: 




diff  --git a/clang/tools/driver/driver.cpp b/clang/tools/driver/driver.cpp
index 59d9ac0ff54db..7124742795501 100644
--- a/clang/tools/driver/driver.cpp
+++ b/clang/tools/driver/driver.cpp
@@ -37,6 +37,7 @@
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/InitLLVM.h"
+#include "llvm/Support/LLVMDriver.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/PrettyStackTrace.h"
 #include "llvm/Support/Process.h"
@@ -369,7 +370,7 @@ static int ExecuteCC1Tool(SmallVectorImpl 
) {
   return 1;
 }
 
-int clang_main(int Argc, char **Argv) {
+int clang_main(int Argc, char **Argv, const llvm::ToolContext &) {
   noteBottomOfStack();
   llvm::InitLLVM X(Argc, Argv);
   llvm::setBugReportMsg("PLEASE submit a bug report to " BUG_REPORT_URL

diff  --git a/lld/tools/lld/lld.cpp b/lld/tools/lld/lld.cpp
index 3600afedddb6d..292fd9d0f9c61 100644
--- a/lld/tools/lld/lld.cpp
+++ b/lld/tools/lld/lld.cpp
@@ -36,6 +36,7 @@
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/CrashRecoveryContext.h"
 #include "llvm/Support/InitLLVM.h"
+#include "llvm/Support/LLVMDriver.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/PluginLoader.h"
 #include "llvm/Support/Process.h"
@@ -214,7 +215,7 @@ static unsigned inTestVerbosity() {
   return v;
 }
 
-int lld_main(int argc, char **argv) {
+int lld_main(int argc, char **argv, const llvm::ToolContext &) {
   InitLLVM x(argc, argv);
   sys::Process::UseANSIEscapeCodes(true);
 

diff  --git a/llvm/cmake/modules/llvm-driver-template.cpp.in 
b/llvm/cmake/modules/llvm-driver-template.cpp.in
index 2164fb00d168f..a828b6dadfbde 100644
--- a/llvm/cmake/modules/llvm-driver-template.cpp.in
+++ b/llvm/cmake/modules/llvm-driver-template.cpp.in
@@ -6,6 +6,9 @@
 //
 
//===--===//
 
-int @TOOL_NAME@_main(int argc, char **argv);
+#include "llvm/Support/LLVMDriver.h"
+#include "llvm/ADT/ArrayRef.h"
 
-int main(int argc, char **argv) { return @TOOL_NAME@_main(argc, argv); }
+int @TOOL_NAME@_main(int argc, char **, const llvm::ToolContext &);
+
+int main(int argc, char **argv) { return @TOOL_NAME@_main(argc, argv, {}); }

diff  --git a/llvm/include/llvm/Support/LLVMDriver.h 
b/llvm/include/llvm/Support/LLVMDriver.h
new file mode 100644
index 0..1e00c056ec4d1
--- /dev/null
+++ b/llvm/include/llvm/Support/LLVMDriver.h
@@ -0,0 +1,18 @@
+//===- LLVMDriver.h -*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_SUPPORT_LLVMDRIVER_H
+#define LLVM_SUPPORT_LLVMDRIVER_H
+
+namespace llvm {
+
+struct ToolContext {};
+
+} // namespace llvm
+
+#endif

diff  --git a/llvm/tools/dsymutil/CMakeLists.txt 
b/llvm/tools/dsymutil/CMakeLists.txt
index ae92e3fd62671..37290d962454f 100644
--- a/llvm/tools/dsymutil/CMakeLists.txt
+++ b/llvm/tools/dsymutil/CMakeLists.txt
@@ -41,4 +41,4 @@ if(APPLE)
   target_link_libraries(dsymutil PRIVATE "-framework CoreFoundation")
 endif(APPLE)
 
-target_link_libraries(dsymutil PRIVATE ${LLVM_ATOMIC_LIB})
+# target_link_libraries(dsymutil PRIVATE ${LLVM_ATOMIC_LIB})

diff  --git a/llvm/tools/dsymutil/dsymutil.cpp 
b/llvm/tools/dsymutil/dsymutil.cpp
index 2a3a2c6613702..1c11297f940a6 100644
--- a/llvm/tools/dsymutil/dsymutil.cpp
+++ b/llvm/tools/dsymutil/dsymutil.cpp
@@ -36,6 +36,7 @@
 #include "llvm/Support/FileCollector.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/InitLLVM.h"
+#include 

[PATCH] D137799: [llvm-driver] Pass extra arguments to tools

[Alex Brachet 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 rG1f173a0653e7: [llvm-driver] Pass extra arguments to tools 
(authored by abrachet).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D137799?vs=481161=496572#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137799

Files:
  clang/tools/driver/driver.cpp
  lld/tools/lld/lld.cpp
  llvm/cmake/modules/llvm-driver-template.cpp.in
  llvm/include/llvm/Support/LLVMDriver.h
  llvm/tools/dsymutil/CMakeLists.txt
  llvm/tools/dsymutil/dsymutil.cpp
  llvm/tools/llvm-ar/llvm-ar.cpp
  llvm/tools/llvm-cxxfilt/llvm-cxxfilt.cpp
  llvm/tools/llvm-driver/llvm-driver.cpp
  llvm/tools/llvm-ifs/llvm-ifs.cpp
  llvm/tools/llvm-lipo/llvm-lipo.cpp
  llvm/tools/llvm-mt/llvm-mt.cpp
  llvm/tools/llvm-nm/llvm-nm.cpp
  llvm/tools/llvm-objcopy/llvm-objcopy.cpp
  llvm/tools/llvm-profdata/llvm-profdata.cpp
  llvm/tools/llvm-rc/llvm-rc.cpp
  llvm/tools/llvm-readobj/llvm-readobj.cpp
  llvm/tools/llvm-size/llvm-size.cpp

Index: llvm/tools/llvm-size/llvm-size.cpp
===
--- llvm/tools/llvm-size/llvm-size.cpp
+++ llvm/tools/llvm-size/llvm-size.cpp
@@ -26,6 +26,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Format.h"
 #include "llvm/Support/InitLLVM.h"
+#include "llvm/Support/LLVMDriver.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/WithColor.h"
 #include "llvm/Support/raw_ostream.h"
@@ -869,7 +870,7 @@
  << "(TOTALS)\n";
 }
 
-int llvm_size_main(int argc, char **argv) {
+int llvm_size_main(int argc, char **argv, const llvm::ToolContext &) {
   InitLLVM X(argc, argv);
   BumpPtrAllocator A;
   StringSaver Saver(A);
Index: llvm/tools/llvm-readobj/llvm-readobj.cpp
===
--- llvm/tools/llvm-readobj/llvm-readobj.cpp
+++ llvm/tools/llvm-readobj/llvm-readobj.cpp
@@ -43,6 +43,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/InitLLVM.h"
+#include "llvm/Support/LLVMDriver.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/ScopedPrinter.h"
 #include "llvm/Support/WithColor.h"
@@ -632,7 +633,7 @@
   return std::make_unique(fouts());
 }
 
-int llvm_readobj_main(int argc, char **argv) {
+int llvm_readobj_main(int argc, char **argv, const llvm::ToolContext &) {
   InitLLVM X(argc, argv);
   BumpPtrAllocator A;
   StringSaver Saver(A);
Index: llvm/tools/llvm-rc/llvm-rc.cpp
===
--- llvm/tools/llvm-rc/llvm-rc.cpp
+++ llvm/tools/llvm-rc/llvm-rc.cpp
@@ -25,6 +25,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/FileUtilities.h"
 #include "llvm/Support/InitLLVM.h"
+#include "llvm/Support/LLVMDriver.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/PrettyStackTrace.h"
@@ -734,7 +735,7 @@
 
 } // anonymous namespace
 
-int llvm_rc_main(int Argc, char **Argv) {
+int llvm_rc_main(int Argc, char **Argv, const llvm::ToolContext &) {
   InitLLVM X(Argc, Argv);
   ExitOnErr.setBanner("llvm-rc: ");
 
Index: llvm/tools/llvm-profdata/llvm-profdata.cpp
===
--- llvm/tools/llvm-profdata/llvm-profdata.cpp
+++ llvm/tools/llvm-profdata/llvm-profdata.cpp
@@ -30,6 +30,7 @@
 #include "llvm/Support/Format.h"
 #include "llvm/Support/FormattedStream.h"
 #include "llvm/Support/InitLLVM.h"
+#include "llvm/Support/LLVMDriver.h"
 #include "llvm/Support/MD5.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Path.h"
@@ -2988,7 +2989,8 @@
   return showMemProfProfile(Filename, ProfiledBinary, SFormat, OS);
 }
 
-int llvm_profdata_main(int argc, char **argvNonConst) {
+int llvm_profdata_main(int argc, char **argvNonConst,
+   const llvm::ToolContext &) {
   const char **argv = const_cast(argvNonConst);
   InitLLVM X(argc, argv);
 
Index: llvm/tools/llvm-objcopy/llvm-objcopy.cpp
===
--- llvm/tools/llvm-objcopy/llvm-objcopy.cpp
+++ llvm/tools/llvm-objcopy/llvm-objcopy.cpp
@@ -43,6 +43,7 @@
 #include "llvm/Support/ErrorOr.h"
 #include "llvm/Support/FileUtilities.h"
 #include "llvm/Support/InitLLVM.h"
+#include "llvm/Support/LLVMDriver.h"
 #include "llvm/Support/Memory.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Process.h"
@@ -223,7 +224,7 @@
   return Error::success();
 }
 
-int llvm_objcopy_main(int argc, char **argv) {
+int llvm_objcopy_main(int argc, char **argv, const llvm::ToolContext &) {
   InitLLVM X(argc, argv);
   ToolName = argv[0];
 
Index: llvm/tools/llvm-nm/llvm-nm.cpp
===
--- 

[PATCH] D139168: [C++20] [Modules] [ClangScanDeps] Enable to print make-style dependency file within P1689 format (4/4)

[Vlad Vereschaka via Phabricator via cfe-commits]

vvereschaka added a comment.

@ChuanqiXu,

would you provide a complete rollback for the changes and fix the `C1689.cppm` 
test failures on the builders

- 
https://lab.llvm.org/buildbot/#/builders/119/builds/11935/steps/9/logs/FAIL__Clang__P1689_cppm
- 
https://lab.llvm.org/buildbot/#/builders/60/builds/10655/steps/9/logs/FAIL__Clang__P1689_cppm


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139168

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

[PATCH] D143745: Make section attribute and -ffunction-sections play nicely

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

I'm not sure I understand the linker's mechanics here. Let me say some things 
and you can describe my misunderstanding.

- If the linker was going to discard all of section foo (in the current 
scheme), that means it had no reason to retain either f() or g(). In the new 
scheme, the net result would be the same, both f() and g() are dead and would 
be discarded. So, no behavior change.
- If the linker wanted to retain f(), but had no reason to retain g(), then in 
the current scheme it would retain all of section foo. In the new scheme it 
would retain f() but discard g(). This is the desired behavior change.

Is that second point the "surprising" behavior? Note that this change applies 
only to functions, not variables.

Yes, more testing is definitely a good thing.

If we do have to have an option, I suppose it could be something like:
`-ffunction-sections[=(default,all)]` where `-ffunction-sections` or 
`-ffunction-sections=default` will apply only to `.text` (or other default text 
section), while `-ffunction-sections=all` does what my patch says.


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

https://reviews.llvm.org/D143745

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

[PATCH] D142637: A slightly more concise AST dump :)

[Dani Ferreira Franco Moura 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 rG70acb3aab3a1: A slightly more concise AST dump :) (authored 
by merrymeerkat).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142637

Files:
  clang/include/clang/AST/ASTNodeTraverser.h
  clang/test/AST/ast-dump-attr-type.cpp
  clang/test/AST/ast-dump-types-json.cpp


Index: clang/test/AST/ast-dump-types-json.cpp
===
--- clang/test/AST/ast-dump-types-json.cpp
+++ clang/test/AST/ast-dump-types-json.cpp
@@ -203,32 +203,6 @@
 // CHECK-NEXT:]
 // CHECK-NEXT:   }
 // CHECK-NEXT:  ]
-// CHECK-NEXT: },
-// CHECK-NEXT: {
-// CHECK-NEXT:  "id": "0x{{.*}}",
-// CHECK-NEXT:  "kind": "ParenType",
-// CHECK-NEXT:  "type": {
-// CHECK-NEXT:   "qualType": "void ()"
-// CHECK-NEXT:  },
-// CHECK-NEXT:  "inner": [
-// CHECK-NEXT:   {
-// CHECK-NEXT:"id": "0x{{.*}}",
-// CHECK-NEXT:"kind": "FunctionProtoType",
-// CHECK-NEXT:"type": {
-// CHECK-NEXT: "qualType": "void ()"
-// CHECK-NEXT:},
-// CHECK-NEXT:"cc": "cdecl",
-// CHECK-NEXT:"inner": [
-// CHECK-NEXT: {
-// CHECK-NEXT:  "id": "0x{{.*}}",
-// CHECK-NEXT:  "kind": "BuiltinType",
-// CHECK-NEXT:  "type": {
-// CHECK-NEXT:   "qualType": "void"
-// CHECK-NEXT:  }
-// CHECK-NEXT: }
-// CHECK-NEXT:]
-// CHECK-NEXT:   }
-// CHECK-NEXT:  ]
 // CHECK-NEXT: }
 // CHECK-NEXT:]
 // CHECK-NEXT:   }
Index: clang/test/AST/ast-dump-attr-type.cpp
===
--- /dev/null
+++ clang/test/AST/ast-dump-attr-type.cpp
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -ast-dump %s | 
FileCheck %s
+
+int * _Nonnull x;
+using Ty = decltype(x);
+
+// CHECK: TypeAliasDecl 0x{{[^ ]*}}   col:7 Ty 
'decltype(x)':'int *'
+// CHECK-NEXT:  `-DecltypeType 0x{{[^ ]*}} 'decltype(x)' sugar
+// CHECK-NEXT: |-DeclRefExpr 0x{{[^ ]*}}  'int * _Nonnull':'int *' 
lvalue Var 0x{{[^ ]*}} 'x' 'int * _Nonnull':'int *' non_odr_use_unevaluated
+// CHECK-NEXT:`-AttributedType 0x{{[^ ]*}} 'int * _Nonnull' sugar
+// CHECK-NEXT:  `-PointerType 0x{{[^ ]*}} 'int *'
+// CHECK-NEXT:`-BuiltinType 0x{{[^ ]*}} 'int'
+// CHECK-NOT:   `-PointerType
+
+[[clang::address_space(3)]] int *y;
+using Ty1 = decltype(y);
+
+// CHECK: TypeAliasDecl 0x{{[^ ]*}}  col:7 Ty1 
'decltype(y)':'__attribute__((address_space(3))) int *'
+// CHECK-NEXT: `-DecltypeType 0x{{[^ ]*}} 'decltype(y)' sugar
+// CHECK-NEXT:   |-DeclRefExpr 0x{{[^ ]*}}  
'__attribute__((address_space(3))) int *' lvalue Var 0x{{[^ ]*}} 'y' 
'__attribute__((address_space(3))) int *' non_odr_use_unevaluated
+// CHECK-NEXT: `-PointerType 0x{{[^ ]*}} 
'__attribute__((address_space(3))) int *'
+// CHECK-NEXT:   `-AttributedType 0x{{[^ ]*}} 
'__attribute__((address_space(3))) int' sugar
+// CHECK-NEXT  |-BuiltinType 0x{{[^ ]*}} 'int'
+// CHECK-NEXT  `-QualType 0x{{[^ ]*}} 
'__attribute__((address_space(3))) int' __attribute__((address_space(3)))
+// CHECK-NEXT`-BuiltinType 0x{{[^ ]*}} 'int'
Index: clang/include/clang/AST/ASTNodeTraverser.h
===
--- clang/include/clang/AST/ASTNodeTraverser.h
+++ clang/include/clang/AST/ASTNodeTraverser.h
@@ -384,7 +384,8 @@
   }
   void VisitAttributedType(const AttributedType *T) {
 // FIXME: AttrKind
-Visit(T->getModifiedType());
+if (T->getModifiedType() != T->getEquivalentType())
+  Visit(T->getModifiedType());
   }
   void VisitBTFTagAttributedType(const BTFTagAttributedType *T) {
 Visit(T->getWrappedType());


Index: clang/test/AST/ast-dump-types-json.cpp
===
--- clang/test/AST/ast-dump-types-json.cpp
+++ clang/test/AST/ast-dump-types-json.cpp
@@ -203,32 +203,6 @@
 // CHECK-NEXT:]
 // CHECK-NEXT:   }
 // CHECK-NEXT:  ]
-// CHECK-NEXT: },
-// CHECK-NEXT: {
-// CHECK-NEXT:  "id": "0x{{.*}}",
-// CHECK-NEXT:  "kind": "ParenType",
-// CHECK-NEXT:  "type": {
-// CHECK-NEXT:   "qualType": "void ()"
-// CHECK-NEXT:  },
-// CHECK-NEXT:  "inner": [
-// CHECK-NEXT:   {
-// CHECK-NEXT:"id": "0x{{.*}}",
-// CHECK-NEXT:"kind": "FunctionProtoType",
-// CHECK-NEXT:"type": {
-// CHECK-NEXT: "qualType": "void ()"
-// CHECK-NEXT:},
-// CHECK-NEXT:"cc": "cdecl",
-// CHECK-NEXT:"inner": [

[clang] 70acb3a - A slightly more concise AST dump :)

[Dani Ferreira Franco Moura via cfe-commits]

Author: Dani Ferreira Franco Moura
Date: 2023-02-10T19:11:31Z
New Revision: 70acb3aab3a10eea802781f69c8336c21dce6d59

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

LOG: A slightly more concise AST dump :)

If the modifiedType and the minimally desugared type of an AttributedType are 
the same, then we do not need to show both in an AST dump.

Here, we change VisitAttributedType to only visit the modifiedType when it is 
different from the equivalentType (the minimally desugared type), because the 
latter is already visited by default.

Reviewed By: sammccall

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

Added: 
clang/test/AST/ast-dump-attr-type.cpp

Modified: 
clang/include/clang/AST/ASTNodeTraverser.h
clang/test/AST/ast-dump-types-json.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTNodeTraverser.h 
b/clang/include/clang/AST/ASTNodeTraverser.h
index a2c57aab89ebc..86a896740e910 100644
--- a/clang/include/clang/AST/ASTNodeTraverser.h
+++ b/clang/include/clang/AST/ASTNodeTraverser.h
@@ -384,7 +384,8 @@ class ASTNodeTraverser
   }
   void VisitAttributedType(const AttributedType *T) {
 // FIXME: AttrKind
-Visit(T->getModifiedType());
+if (T->getModifiedType() != T->getEquivalentType())
+  Visit(T->getModifiedType());
   }
   void VisitBTFTagAttributedType(const BTFTagAttributedType *T) {
 Visit(T->getWrappedType());

diff  --git a/clang/test/AST/ast-dump-attr-type.cpp 
b/clang/test/AST/ast-dump-attr-type.cpp
new file mode 100644
index 0..17e710ff72817
--- /dev/null
+++ b/clang/test/AST/ast-dump-attr-type.cpp
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -ast-dump %s | 
FileCheck %s
+
+int * _Nonnull x;
+using Ty = decltype(x);
+
+// CHECK: TypeAliasDecl 0x{{[^ ]*}}   col:7 Ty 
'decltype(x)':'int *'
+// CHECK-NEXT:  `-DecltypeType 0x{{[^ ]*}} 'decltype(x)' sugar
+// CHECK-NEXT: |-DeclRefExpr 0x{{[^ ]*}}  'int * _Nonnull':'int *' 
lvalue Var 0x{{[^ ]*}} 'x' 'int * _Nonnull':'int *' non_odr_use_unevaluated
+// CHECK-NEXT:`-AttributedType 0x{{[^ ]*}} 'int * _Nonnull' sugar
+// CHECK-NEXT:  `-PointerType 0x{{[^ ]*}} 'int *'
+// CHECK-NEXT:`-BuiltinType 0x{{[^ ]*}} 'int'
+// CHECK-NOT:   `-PointerType
+
+[[clang::address_space(3)]] int *y;
+using Ty1 = decltype(y);
+
+// CHECK: TypeAliasDecl 0x{{[^ ]*}}  col:7 Ty1 
'decltype(y)':'__attribute__((address_space(3))) int *'
+// CHECK-NEXT: `-DecltypeType 0x{{[^ ]*}} 'decltype(y)' sugar
+// CHECK-NEXT:   |-DeclRefExpr 0x{{[^ ]*}}  
'__attribute__((address_space(3))) int *' lvalue Var 0x{{[^ ]*}} 'y' 
'__attribute__((address_space(3))) int *' non_odr_use_unevaluated
+// CHECK-NEXT: `-PointerType 0x{{[^ ]*}} 
'__attribute__((address_space(3))) int *'
+// CHECK-NEXT:   `-AttributedType 0x{{[^ ]*}} 
'__attribute__((address_space(3))) int' sugar
+// CHECK-NEXT  |-BuiltinType 0x{{[^ ]*}} 'int'
+// CHECK-NEXT  `-QualType 0x{{[^ ]*}} 
'__attribute__((address_space(3))) int' __attribute__((address_space(3)))
+// CHECK-NEXT`-BuiltinType 0x{{[^ ]*}} 'int'

diff  --git a/clang/test/AST/ast-dump-types-json.cpp 
b/clang/test/AST/ast-dump-types-json.cpp
index 87cfaa241fbc7..0a92483fb1c7f 100644
--- a/clang/test/AST/ast-dump-types-json.cpp
+++ b/clang/test/AST/ast-dump-types-json.cpp
@@ -203,32 +203,6 @@ using ::TestUsingShadowDeclType;
 // CHECK-NEXT:]
 // CHECK-NEXT:   }
 // CHECK-NEXT:  ]
-// CHECK-NEXT: },
-// CHECK-NEXT: {
-// CHECK-NEXT:  "id": "0x{{.*}}",
-// CHECK-NEXT:  "kind": "ParenType",
-// CHECK-NEXT:  "type": {
-// CHECK-NEXT:   "qualType": "void ()"
-// CHECK-NEXT:  },
-// CHECK-NEXT:  "inner": [
-// CHECK-NEXT:   {
-// CHECK-NEXT:"id": "0x{{.*}}",
-// CHECK-NEXT:"kind": "FunctionProtoType",
-// CHECK-NEXT:"type": {
-// CHECK-NEXT: "qualType": "void ()"
-// CHECK-NEXT:},
-// CHECK-NEXT:"cc": "cdecl",
-// CHECK-NEXT:"inner": [
-// CHECK-NEXT: {
-// CHECK-NEXT:  "id": "0x{{.*}}",
-// CHECK-NEXT:  "kind": "BuiltinType",
-// CHECK-NEXT:  "type": {
-// CHECK-NEXT:   "qualType": "void"
-// CHECK-NEXT:  }
-// CHECK-NEXT: }
-// CHECK-NEXT:]
-// CHECK-NEXT:   }
-// CHECK-NEXT:  ]
 // CHECK-NEXT: }
 // CHECK-NEXT:]
 // CHECK-NEXT:   }



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

[PATCH] D122215: [WebAssembly] Initial support for reference type externref in clang

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

In D122215#4119038 , @vitalybuka 
wrote:

> In D122215#4118516 , @asb wrote:
>
>> @pmatos and I have tried and failed to reproduce the assert in the stage3 
>> msan build locally (both of us on separate machines, different 
>> environments). We've reached out to @vitalybuka via email for any help in 
>> reproducing, because we're somewhat stumped at the moment.
>
> I will try to reproduce on fresh VM and reply to you with details.

Thanks Vitaly - that would be really helpful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122215

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

[PATCH] D143375: clang-tidy: Count template constructors in modernize-use-default-member-init

[Oleg Smolsky via Phabricator via cfe-commits]

oleg.smolsky added a comment.

Nice!


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

https://reviews.llvm.org/D143375

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

[PATCH] D143768: [Clang] Add options to disable direct linking of arch tools

[Aaron Siddhartha Mondal via Phabricator via cfe-commits]

aaronmondal added a comment.

Ah yeah my bad 

Hmm somehow I keep getting confused by this. I'll check how other deps handle 
this, maybe there is a better way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143768

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

[PATCH] D143692: [clang][driver] Emit error when enabling emulated tls on unsupported architectures

[Paul Kirth via Phabricator via cfe-commits]

paulkirth updated this revision to Diff 496553.
paulkirth added a comment.

Address comments.

- improve FileCheck directive in test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143692

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/emulated-tls.cpp


Index: clang/test/Driver/emulated-tls.cpp
===
--- clang/test/Driver/emulated-tls.cpp
+++ clang/test/Driver/emulated-tls.cpp
@@ -29,6 +29,10 @@
 // RUN: %clang -### -target i686-pc-openbsd %s -femulated-tls 
-fno-emulated-tls 2>&1 \
 // RUN: | FileCheck -check-prefix=NOEMU %s
 
+// RUN: %clang -### --target=riscv64-linux-android %s -fno-emulated-tls 2>&1 \
+// RUN: | FileCheck -check-prefix=RISCV %s
+// RUN: %clang -### --target=riscv64-linux-android %s -fno-emulated-tls 
-femulated-tls 2>&1 \
+// RUN: | FileCheck -check-prefix=RISCV-ERROR %s
 
 // Default without -f[no-]emulated-tls, will be decided by the target triple.
 // DEFAULT-NOT: "-cc1" {{.*}}"-femulated-tls"
@@ -40,3 +44,6 @@
 
 // NOEMU: "-cc1" {{.*}}"-fno-emulated-tls"
 // NOEMU-NOT: "-cc1" {{.*}}"-femulated-tls"
+
+// RISCV-NOT: error: unsupported option '-fno-emulated-tls' for target 
'riscv64-unknown-linux-android'
+// RISCV-ERROR: error: unsupported option '-femulated-tls' for target 
'riscv64-unknown-linux-android'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6164,8 +6164,19 @@
   Args.AddLastArg(CmdArgs, options::OPT_femit_all_decls);
   Args.AddLastArg(CmdArgs, options::OPT_fheinous_gnu_extensions);
   Args.AddLastArg(CmdArgs, options::OPT_fdigraphs, options::OPT_fno_digraphs);
-  Args.AddLastArg(CmdArgs, options::OPT_femulated_tls,
-  options::OPT_fno_emulated_tls);
+
+  if (Arg *A = Args.getLastArg(options::OPT_femulated_tls,
+   options::OPT_fno_emulated_tls)) {
+// LLVM does not support Emulated TLS for some architectures, like RISCV
+// So issue an error to avoid subtle problems in codegen if the flags are
+// incompatible. see https://github.com/llvm/llvm-project/issues/59500
+if (!Triple.supportsEmulatedTLS() &&
+A->getOption().getID() == options::OPT_femulated_tls)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << A->getAsString(Args) << TripleStr;
+A->render(Args, CmdArgs);
+  }
+
   Args.AddLastArg(CmdArgs, options::OPT_fzero_call_used_regs_EQ);
 
   if (Arg *A = Args.getLastArg(options::OPT_fzero_call_used_regs_EQ)) {


Index: clang/test/Driver/emulated-tls.cpp
===
--- clang/test/Driver/emulated-tls.cpp
+++ clang/test/Driver/emulated-tls.cpp
@@ -29,6 +29,10 @@
 // RUN: %clang -### -target i686-pc-openbsd %s -femulated-tls -fno-emulated-tls 2>&1 \
 // RUN: | FileCheck -check-prefix=NOEMU %s
 
+// RUN: %clang -### --target=riscv64-linux-android %s -fno-emulated-tls 2>&1 \
+// RUN: | FileCheck -check-prefix=RISCV %s
+// RUN: %clang -### --target=riscv64-linux-android %s -fno-emulated-tls -femulated-tls 2>&1 \
+// RUN: | FileCheck -check-prefix=RISCV-ERROR %s
 
 // Default without -f[no-]emulated-tls, will be decided by the target triple.
 // DEFAULT-NOT: "-cc1" {{.*}}"-femulated-tls"
@@ -40,3 +44,6 @@
 
 // NOEMU: "-cc1" {{.*}}"-fno-emulated-tls"
 // NOEMU-NOT: "-cc1" {{.*}}"-femulated-tls"
+
+// RISCV-NOT: error: unsupported option '-fno-emulated-tls' for target 'riscv64-unknown-linux-android'
+// RISCV-ERROR: error: unsupported option '-femulated-tls' for target 'riscv64-unknown-linux-android'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6164,8 +6164,19 @@
   Args.AddLastArg(CmdArgs, options::OPT_femit_all_decls);
   Args.AddLastArg(CmdArgs, options::OPT_fheinous_gnu_extensions);
   Args.AddLastArg(CmdArgs, options::OPT_fdigraphs, options::OPT_fno_digraphs);
-  Args.AddLastArg(CmdArgs, options::OPT_femulated_tls,
-  options::OPT_fno_emulated_tls);
+
+  if (Arg *A = Args.getLastArg(options::OPT_femulated_tls,
+   options::OPT_fno_emulated_tls)) {
+// LLVM does not support Emulated TLS for some architectures, like RISCV
+// So issue an error to avoid subtle problems in codegen if the flags are
+// incompatible. see https://github.com/llvm/llvm-project/issues/59500
+if (!Triple.supportsEmulatedTLS() &&
+A->getOption().getID() == options::OPT_femulated_tls)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << A->getAsString(Args) << TripleStr;
+A->render(Args, CmdArgs);
+  }
+
   Args.AddLastArg(CmdArgs, options::OPT_fzero_call_used_regs_EQ);
 
   if (Arg *A = 

[PATCH] D142939: Fix handling of -> calls for modernize-use-emplace

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp added a comment.

Pushed, thanks for the contribution! I took the liberty of fixing the 
`std::vector` thing before pushing :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142939

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

[PATCH] D142939: Fix handling of -> calls for modernize-use-emplace

[Carlos Galvez via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa543d840ee0a: Fix handling of - calls for 
modernize-use-emplace (authored by BigPeet, committed by carlosgalvezp).

Changed prior to commit:
  https://reviews.llvm.org/D142939?vs=493756=496552#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142939

Files:
  clang-tools-extra/clang-tidy/modernize/UseEmplaceCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp
@@ -1334,3 +1334,90 @@
   v3.push_back({{0}});
   v3.push_back({{}});
 }
+
+void testWithPointerTypes() {
+  std::list l;
+  std::list* lp = 
+  std::stack s;
+  std::stack* sp;
+
+  lp->push_back(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_back instead of push_back [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_back(1, 2);
+  lp->push_front(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_front instead of push_front [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_front(1, 2);
+  sp->push(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace instead of push [modernize-use-emplace]
+  // CHECK-FIXES: sp->emplace(1, 2);
+
+  lp->push_back(Something{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_back instead of push_back [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_back(1, 2);
+  lp->push_front(Something{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_front instead of push_front [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_front(1, 2);
+  sp->push(Something{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace instead of push [modernize-use-emplace]
+  // CHECK-FIXES: sp->emplace(1, 2);
+
+  lp->push_back(Something());
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_back instead of push_back [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_back();
+  lp->push_front(Something());
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_front instead of push_front [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_front();
+  sp->push(Something());
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace instead of push [modernize-use-emplace]
+  // CHECK-FIXES: sp->emplace();
+
+  lp->push_back(Something{});
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_back instead of push_back [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_back();
+  lp->push_front(Something{});
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_front instead of push_front [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_front();
+  sp->push(Something{});
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace instead of push [modernize-use-emplace]
+  // CHECK-FIXES: sp->emplace();
+
+  lp->emplace_back(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: unnecessary temporary object created while calling emplace_back
+  // CHECK-FIXES: lp->emplace_back(1, 2);
+  lp->emplace_front(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: unnecessary temporary object created while calling emplace_front
+  // CHECK-FIXES: lp->emplace_front(1, 2);
+  sp->emplace(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: unnecessary temporary object created while calling emplace
+  // CHECK-FIXES: sp->emplace(1, 2);
+
+  lp->emplace_back(Something{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: unnecessary temporary object created while calling emplace_back
+  // CHECK-FIXES: lp->emplace_back(1, 2);
+  lp->emplace_front(Something{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: unnecessary temporary object created while calling emplace_front
+  // CHECK-FIXES: lp->emplace_front(1, 2);
+  sp->emplace(Something{1, 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: unnecessary temporary object created while calling emplace
+  // CHECK-FIXES: sp->emplace(1, 2);
+
+  lp->emplace_back(Something());
+  // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: unnecessary temporary object created while calling emplace_back
+  // CHECK-FIXES: lp->emplace_back();
+  lp->emplace_front(Something());
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: unnecessary temporary object created while calling emplace_front
+  // CHECK-FIXES: lp->emplace_front();
+  sp->emplace(Something());
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: unnecessary temporary object created while calling emplace
+  // CHECK-FIXES: sp->emplace();
+
+  lp->emplace_back(Something{});
+  // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: unnecessary temporary object created while calling 

[clang-tools-extra] a543d84 - Fix handling of -> calls for modernize-use-emplace

[Carlos Galvez via cfe-commits]

Author: BigPeet
Date: 2023-02-10T18:52:56Z
New Revision: a543d840ee0ac53ef9df70c0e2a996e1a222064b

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

LOG: Fix handling of -> calls for modernize-use-emplace

Fixes #55869

Reviewed By: njames93, nicovank

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/modernize/UseEmplaceCheck.cpp
clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/modernize/UseEmplaceCheck.cpp 
b/clang-tools-extra/clang-tidy/modernize/UseEmplaceCheck.cpp
index ccd07065d1573..554abcd900e32 100644
--- a/clang-tools-extra/clang-tidy/modernize/UseEmplaceCheck.cpp
+++ b/clang-tools-extra/clang-tidy/modernize/UseEmplaceCheck.cpp
@@ -80,6 +80,29 @@ AST_MATCHER(DeclRefExpr, hasExplicitTemplateArgs) {
   return Node.hasExplicitTemplateArgs();
 }
 
+// Helper Matcher which applies the given QualType Matcher either directly or 
by
+// resolving a pointer type to its pointee. Used to match v.push_back() as well
+// as p->push_back().
+auto hasTypeOrPointeeType(
+const ast_matchers::internal::Matcher ) {
+  return anyOf(hasType(TypeMatcher),
+   hasType(pointerType(pointee(TypeMatcher;
+}
+
+// Matches if the node has canonical type matching any of the given names.
+auto hasWantedType(llvm::ArrayRef TypeNames) {
+  return 
hasCanonicalType(hasDeclaration(cxxRecordDecl(hasAnyName(TypeNames;
+}
+
+// Matches member call expressions of the named method on the listed container
+// types.
+auto cxxMemberCallExprOnContainer(
+StringRef MethodName, llvm::ArrayRef ContainerNames) {
+  return cxxMemberCallExpr(
+  hasDeclaration(functionDecl(hasName(MethodName))),
+  on(hasTypeOrPointeeType(hasWantedType(ContainerNames;
+}
+
 const auto DefaultContainersWithPushBack =
 "::std::vector; ::std::list; ::std::deque";
 const auto DefaultContainersWithPush =
@@ -130,27 +153,19 @@ void UseEmplaceCheck::registerMatchers(MatchFinder 
*Finder) {
   // because this requires special treatment (it could cause performance
   // regression)
   // + match for emplace calls that should be replaced with insertion
-  auto CallPushBack = cxxMemberCallExpr(
-  hasDeclaration(functionDecl(hasName("push_back"))),
-  on(hasType(hasCanonicalType(
-  
hasDeclaration(cxxRecordDecl(hasAnyName(ContainersWithPushBack)));
-
-  auto CallPush =
-  cxxMemberCallExpr(hasDeclaration(functionDecl(hasName("push"))),
-on(hasType(hasCanonicalType(hasDeclaration(
-cxxRecordDecl(hasAnyName(ContainersWithPush)));
-
-  auto CallPushFront = cxxMemberCallExpr(
-  hasDeclaration(functionDecl(hasName("push_front"))),
-  on(hasType(hasCanonicalType(hasDeclaration(
-  cxxRecordDecl(hasAnyName(ContainersWithPushFront)));
+  auto CallPushBack =
+  cxxMemberCallExprOnContainer("push_back", ContainersWithPushBack);
+  auto CallPush = cxxMemberCallExprOnContainer("push", ContainersWithPush);
+  auto CallPushFront =
+  cxxMemberCallExprOnContainer("push_front", ContainersWithPushFront);
 
   auto CallEmplacy = cxxMemberCallExpr(
   hasDeclaration(
   functionDecl(hasAnyNameIgnoringTemplates(EmplacyFunctions))),
-  on(hasType(hasCanonicalType(hasDeclaration(has(typedefNameDecl(
-  hasName("value_type"), hasType(type(hasUnqualifiedDesugaredType(
- recordType().bind("value_type")));
+  on(hasTypeOrPointeeType(hasCanonicalType(hasDeclaration(
+  has(typedefNameDecl(hasName("value_type"),
+  hasType(type(hasUnqualifiedDesugaredType(
+  recordType().bind("value_type")));
 
   // We can't replace push_backs of smart pointer because
   // if emplacement fails (f.e. bad_alloc in vector) we will have leak of

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp 
b/clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp
index 537263d988be3..a055b25798de0 100644
--- a/clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp
+++ b/clang-tools-extra/test/clang-tidy/checkers/modernize/use-emplace.cpp
@@ -1334,3 +1334,90 @@ void testBracedInitTemporaries() {
   v3.push_back({{0}});
   v3.push_back({{}});
 }
+
+void testWithPointerTypes() {
+  std::list l;
+  std::list* lp = 
+  std::stack s;
+  std::stack* sp;
+
+  lp->push_back(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use emplace_back instead of 
push_back [modernize-use-emplace]
+  // CHECK-FIXES: lp->emplace_back(1, 2);
+  lp->push_front(Something(1, 2));
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: 

[PATCH] D143624: Inlining: Run the legacy AlwaysInliner before the regular inliner.

[Dave Green via Phabricator via cfe-commits]

dmgreen added a comment.

> I’ll take a look, but this indicates to me that there’s something missing 
> from the vectoriser or later passes rather than a problem with the inliners 
> behaviour.

Sure. I'm not saying that this patch is wrong. I'm just saying that 
unfortunately it leads to some pretty large regressions. Hopefully we can 
figure out why and put fixes in place instead of just bodging the tests. 
Hopefully it's just some missing fold to get the code into the same form it was 
before, after all the inlining has happened.

I took a look at one of the other cases, it appears to be a pretty unfortunate 
case of the load order in loops leading to LSR not recognizing chains of 
instructions due to them being order with offsets [2,0,6,4,10,8,..], as opposed 
to the order they were in before [0,2,4,6,8,10...], which was an easier to 
reason about. https://godbolt.org/z/Grv64xoxW. I'm not sure exactly what the 
best way to fix that would be, without making other cases worse.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143624

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

[PATCH] D122215: [WebAssembly] Initial support for reference type externref in clang

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka added a comment.

In D122215#4118516 , @asb wrote:

> @pmatos and I have tried and failed to reproduce the assert in the stage3 
> msan build locally (both of us on separate machines, different environments). 
> We've reached out to @vitalybuka via email for any help in reproducing, 
> because we're somewhat stumped at the moment.

I will try to reproduce on fresh VM and reply to you with details.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122215

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

[PATCH] D143768: [Clang] Add options to disable direct linking of arch tools

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

In D143768#4119021 , @aaronmondal 
wrote:

> Does this address the case where we have HSA headers present on the system?
>
> Since this only seems to modify link time behavior, I think building with 
> this flag would still include "hsa/hsa.h" if they were present.

Those headers are guarded behind `#ifndef DYNAMIC_CUDA`. This is how we 
configure it to use the `dlopen` method, see the `target_compile_definitions` 
line. We used to use `__has_include` but it caused buildbots to fail for 
Windows cross compiling.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143768

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

[PATCH] D143768: [Clang] Add options to disable direct linking of arch tools

[Aaron Siddhartha Mondal via Phabricator via cfe-commits]

aaronmondal added a comment.

Does this address the case where we have HSA headers present on the system?

Since this only seems to modify link time behavior, I think building with this 
flag would still include "hsa/hsa.h" if they were present.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143768

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

[PATCH] D135341: [clang] adds `__reference_constructs_from_temporary`

[Louis Dionne via Phabricator via cfe-commits]

ldionne added a comment.

In D135341#4111884 , @cjdb wrote:

> In D135341#4111673 , @ldionne wrote:
>
>> I've been looking at implementing `reference_constructs_from_temporary` & 
>> friends and this would be sweet to have. Is this blocked on something 
>> specific?
>
> This trait should be ready to go, pending an LGTM. 
> `__reference_converts_from_temporary` is a different story, and someone else 
> might need to do this one if you need it in a timely fashion (but I'll be 
> happy to review it).

Sounds good! This naively looks good to me, but it would be nice if a Clang 
regular could take a look!




Comment at: clang/include/clang/Basic/DiagnosticCommonKinds.td:397
+def err_reserved_identifier_for_future_use : Error<
+  "%0 is a compiler-reserved identifier for a future feature">;
 }

cjdb wrote:
> ldionne wrote:
> > cjdb wrote:
> > > erichkeane wrote:
> > > > I don't think we should diagnose this for individual identifiers, I 
> > > > don't think this adds much value, and the identifier is already 
> > > > reserved for implementation use.  This implies we are going to diagnose 
> > > > ALL future reserved things, which we have no intention of doing.
> > > The motivation for this error is to ensure that standard library 
> > > implementations don't take this name (`__remove_cvref` and 
> > > `__is_null_pointer` had to get names that weren't a 1:1 mapping to their 
> > > library counterparts as a result).
> > Oh, just ask and we can rename ours! What do you want us to rename?
> Much appreciated! I think `__remove_cvref` had a libc++ conflict and 
> `__is_null_pointer` had a libstdc++ conflict, so it's not specific to one 
> library. I figured that it would be easier for backwards-compatibility 
> reasons to just rename them to something slightly more awkward, so that 
> previous versions of the stdlib don't spontaneously break for more recent 
> compilers. This is more of an issue when you're dealing with package managers 
> like apt, where some things depend on libc++-v$OLD, but there aren't any 
> restrictions on Clang's version (for example, I use nightly Clang on Ubuntu, 
> but apt notes that the Discord app has an older libc++ dependency).
> 
> After having let this sit for a few months, I don't really have strong 
> opinions on reserving `__std_trait` anymore, so I'll touch this up in the 
> morning.
I just checked and I think we define `__remove_cvref_t`, but not 
`__remove_cvref` (that probably changed in the last year). In the future, don't 
hesitate to ping us if we are using a name that Clang would like to use, we 
should almost always be able to quickly get out of your way!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135341

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

[PATCH] D143745: Make section attribute and -ffunction-sections play nicely

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

> [...] all functions with that attribute end up in a single section, defeating 
> the linker GC.

This can be made preciser.

Say we have

  __attribute__((section("foo"))) void f(i) {}
  __attribute__((section("foo"))) void g() {}

`f` and `g` don't use COMDAT, therefore they are in the same section `foo` in 
Clang and GCC (coarse-grained). This `foo` section is retained or discarded as 
a unit. Considering the whole link, a `foo` section in a translation unit can 
be discarded.

I suspect that some people may find the new behavior surprising, so an option 
is probably needed. Ideally inform GCC about this new toggle as well.

I think ThinLTO's `comdat nodeduplicate` handling is great. In D108879 
 I noted an interesting issue related to 
regular LTO. I haven't tested more scenarios about regular LTO. If you want to 
use it at scale, consider more testing.


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

https://reviews.llvm.org/D143745

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

[clang] 79a3803 - [ClangScanDeps] Add UNSUPPORTED: system-windows to test P1689.cppm

[Tom Weaver via cfe-commits]

Author: Tom Weaver
Date: 2023-02-10T18:29:41Z
New Revision: 79a3803bb2ccdd852436cd1653017a1159a12157

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

LOG: [ClangScanDeps] Add UNSUPPORTED: system-windows to test P1689.cppm

The revert of
  https://reviews.llvm.org/rG65f9719913eca9c7c72d1abf4eddab767abaebf6

removes a system-windows guard but does not remove the test causing windows
system failures. This patch adds back a guard to prevent further failures.

Added: 


Modified: 
clang/test/ClangScanDeps/P1689.cppm

Removed: 




diff  --git a/clang/test/ClangScanDeps/P1689.cppm 
b/clang/test/ClangScanDeps/P1689.cppm
index 22d7721c2e9bf..3329d1efbfa63 100644
--- a/clang/test/ClangScanDeps/P1689.cppm
+++ b/clang/test/ClangScanDeps/P1689.cppm
@@ -1,3 +1,5 @@
+// UNSUPPORTED: system-windows
+
 // RUN: rm -fr %t
 // RUN: mkdir -p %t
 // RUN: split-file %s %t



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

[PATCH] D143768: [Clang] Add options to disable direct linking of arch tools

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 created this revision.
jhuber6 added reviewers: aaronmondal, JonChesterfield, tra, jdoerfert, 
tianshilei1992.
Herald added subscribers: kosarev, mattd, asavonic, kerbowa, tpr, jvesely.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

We use the `nvptx-arch` and `amdgpu-arch` tools to identify the system's
installed GPUs. These are used across LLVM to handle setting up unit
tests and the `--offload-arch=native` option. This patch adds the
`CLANG_FORCE_DLOPEN_LIBCUDA` and `CLANG_FORCE_DLOPEN_LIBHSA` CMake
options to enable disabling these directly.

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143768

Files:
  clang/tools/amdgpu-arch/CMakeLists.txt
  clang/tools/nvptx-arch/CMakeLists.txt


Index: clang/tools/nvptx-arch/CMakeLists.txt
===
--- clang/tools/nvptx-arch/CMakeLists.txt
+++ clang/tools/nvptx-arch/CMakeLists.txt
@@ -9,10 +9,12 @@
 set(LLVM_LINK_COMPONENTS Support)
 add_clang_tool(nvptx-arch NVPTXArch.cpp)
 
-find_package(CUDAToolkit QUIET)
+option(CLANG_FORCE_DLOPEN_LIBCUDA "Build with 'dlopened' libcuda" OFF)
 
 # If we found the CUDA library directly we just dynamically link against it.
-if(CUDAToolkit_FOUND AND NOT (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P EQUAL 
4))
+find_package(CUDAToolkit QUIET)
+if(CUDAToolkit_FOUND AND NOT
+   (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P EQUAL 4 OR 
CLANG_FORCE_DLOPEN_LIBCUDA))
   target_link_libraries(nvptx-arch PRIVATE CUDA::cuda_driver)
 else()
   target_compile_definitions(nvptx-arch PRIVATE "DYNAMIC_CUDA")
Index: clang/tools/amdgpu-arch/CMakeLists.txt
===
--- clang/tools/amdgpu-arch/CMakeLists.txt
+++ clang/tools/amdgpu-arch/CMakeLists.txt
@@ -10,9 +10,12 @@
 
 add_clang_tool(amdgpu-arch AMDGPUArch.cpp)
 
+option(CLANG_FORCE_DLOPEN_LIBHSA "Build with 'dlopened' libhsa" OFF)
+
 # If we find the HSA runtime we link with it directly.
 find_package(hsa-runtime64 QUIET 1.2.0 HINTS ${CMAKE_INSTALL_PREFIX} PATHS 
/opt/rocm)
-if(hsa-runtime64_FOUND AND NOT (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P 
EQUAL 4))
+if(hsa-runtime64_FOUND AND NOT
+   (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P EQUAL 4 OR 
CLANG_FORCE_DLOPEN_LIBHSA))
   set_target_properties(amdgpu-arch PROPERTIES INSTALL_RPATH_USE_LINK_PATH ON)
   target_link_libraries(amdgpu-arch PRIVATE hsa-runtime64::hsa-runtime64)
 else()


Index: clang/tools/nvptx-arch/CMakeLists.txt
===
--- clang/tools/nvptx-arch/CMakeLists.txt
+++ clang/tools/nvptx-arch/CMakeLists.txt
@@ -9,10 +9,12 @@
 set(LLVM_LINK_COMPONENTS Support)
 add_clang_tool(nvptx-arch NVPTXArch.cpp)
 
-find_package(CUDAToolkit QUIET)
+option(CLANG_FORCE_DLOPEN_LIBCUDA "Build with 'dlopened' libcuda" OFF)
 
 # If we found the CUDA library directly we just dynamically link against it.
-if(CUDAToolkit_FOUND AND NOT (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P EQUAL 4))
+find_package(CUDAToolkit QUIET)
+if(CUDAToolkit_FOUND AND NOT
+   (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P EQUAL 4 OR CLANG_FORCE_DLOPEN_LIBCUDA))
   target_link_libraries(nvptx-arch PRIVATE CUDA::cuda_driver)
 else()
   target_compile_definitions(nvptx-arch PRIVATE "DYNAMIC_CUDA")
Index: clang/tools/amdgpu-arch/CMakeLists.txt
===
--- clang/tools/amdgpu-arch/CMakeLists.txt
+++ clang/tools/amdgpu-arch/CMakeLists.txt
@@ -10,9 +10,12 @@
 
 add_clang_tool(amdgpu-arch AMDGPUArch.cpp)
 
+option(CLANG_FORCE_DLOPEN_LIBHSA "Build with 'dlopened' libhsa" OFF)
+
 # If we find the HSA runtime we link with it directly.
 find_package(hsa-runtime64 QUIET 1.2.0 HINTS ${CMAKE_INSTALL_PREFIX} PATHS /opt/rocm)
-if(hsa-runtime64_FOUND AND NOT (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P EQUAL 4))
+if(hsa-runtime64_FOUND AND NOT
+   (LLVM_BUILD_32_BITS OR CMAKE_SIZEOF_VOID_P EQUAL 4 OR CLANG_FORCE_DLOPEN_LIBHSA))
   set_target_properties(amdgpu-arch PROPERTIES INSTALL_RPATH_USE_LINK_PATH ON)
   target_link_libraries(amdgpu-arch PRIVATE hsa-runtime64::hsa-runtime64)
 else()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143692: [clang][driver] Emit error when enabling emulated tls on unsupported architectures

[Fangrui Song via Phabricator via cfe-commits]

MaskRay accepted this revision.
MaskRay added a comment.

With nits




Comment at: clang/test/Driver/emulated-tls.cpp:49
+// RISCV-NOT:  unsupported option '-fno-emulated-tls' for target 
'riscv64-unknown-linux-android'
+// RISCV-ERROR:  unsupported option '-femulated-tls' for target 
'riscv64-unknown-linux-android'

Prepend `error:`

For the `NOT` pattern, use `RISCV-NOT: error:` or change FileCheck to 
`FileCheck --implicit-check-not=error:`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143692

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

[PATCH] D143750: [clang-tidy] Clarify documention of `bugprone-unchecked-optional-access`.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
ymandel marked an inline comment as done.
Closed by commit rGe7e577f68421: [clang-tidy] Clarify documention of 
`bugprone-unchecked-optional-access`. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143750

Files:
  
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst


Index: 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
===
--- 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
+++ 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
@@ -8,16 +8,14 @@
 average clang-tidy check.
 
 This check identifies unsafe accesses to values contained in
-``std::optional``, ``absl::optional``, or ``base::std::optional``
-objects. Below we will refer to all these types collectively as
-``optional``.
+``std::optional``, ``absl::optional``, or ``base::Optional``
+objects. Below we will refer to all these types collectively as 
``optional``.
 
-An access to the value of an ``optional`` occurs when one of its
-``value``, ``operator*``, or ``operator->`` member functions is invoked.
-To align with common misconceptions, the check considers these member
-functions as equivalent, even though there are subtle differences
-related to exceptions versus undefined behavior. See
-go/optional-style-recommendations for more information on that topic.
+An access to the value of an ``optional`` occurs when one of its ``value``,
+``operator*``, or ``operator->`` member functions is invoked.  To align with
+common misconceptions, the check considers these member functions as 
equivalent,
+even though there are subtle differences related to exceptions versus undefined
+behavior. See *Additional notes*, below, for more information on this topic.
 
 An access to the value of an ``optional`` is considered safe if and only if
 code in the local scope (for example, a function body) ensures that the
@@ -273,3 +271,27 @@
 A future version will expand the scope to lambdas, following the rules
 outlined above. It is best to follow the same principles when using
 optionals in lambdas.
+
+Access with ``operator*()`` vs. ``value()``
+---
+
+Given that ``value()`` has well-defined behavior (either throwing an exception
+or terminating the program), why treat it the same as ``operator*()`` which
+causes undefined behavior (UB)? That is, why is it considered unsafe to access
+an optional with ``value()``, if it's not provably populated with a value?  For
+that matter, why is ``CHECK()`` followed by ``operator*()`` any better than
+``value()``, given that they are semantically equivalent (on configurations 
that
+disable exceptions)?
+
+The answer is that we assume most users do not realize the difference between
+``value()`` and ``operator*()``. Shifting to ``operator*()`` and some form of
+explicit value-presence check or explicit program termination has two
+advantages:
+
+  * Readability. The check, and any potential side effects like program
+shutdown, are very clear in the code. Separating access from checks can
+actually make the checks more obvious.
+
+  * Performance. A single check can cover many or even all accesses within
+scope. This gives the user the best of both worlds -- the safety of a
+dynamic check, but without incurring redundant costs.


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
@@ -8,16 +8,14 @@
 average clang-tidy check.
 
 This check identifies unsafe accesses to values contained in
-``std::optional``, ``absl::optional``, or ``base::std::optional``
-objects. Below we will refer to all these types collectively as
-``optional``.
+``std::optional``, ``absl::optional``, or ``base::Optional``
+objects. Below we will refer to all these types collectively as ``optional``.
 
-An access to the value of an ``optional`` occurs when one of its
-``value``, ``operator*``, or ``operator->`` member functions is invoked.
-To align with common misconceptions, the check considers these member
-functions as equivalent, even though there are subtle differences
-related to exceptions versus undefined behavior. See
-go/optional-style-recommendations for more information on that topic.
+An access to the value of an ``optional`` occurs when one of its ``value``,
+``operator*``, or ``operator->`` member functions is invoked.  To align with
+common misconceptions, the check considers these member functions as 

[clang-tools-extra] e7e577f - [clang-tidy] Clarify documention of `bugprone-unchecked-optional-access`.

[Yitzhak Mandelbaum via cfe-commits]

Author: Yitzhak Mandelbaum
Date: 2023-02-10T18:15:21Z
New Revision: e7e577f6842135faaf2c960c7a4e69c71836dc0a

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

LOG: [clang-tidy] Clarify documention of `bugprone-unchecked-optional-access`.

Removes a reference to google-internal document and expands the relevant 
material in place.

Fixes: #60633.

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

Added: 


Modified: 

clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst

Removed: 




diff  --git 
a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
 
b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
index 256cb6d05e254..ddb43a3dac98b 100644
--- 
a/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
+++ 
b/clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
@@ -8,16 +8,14 @@ results. Therefore, it may be more resource intensive (RAM, 
CPU) than the
 average clang-tidy check.
 
 This check identifies unsafe accesses to values contained in
-``std::optional``, ``absl::optional``, or ``base::std::optional``
-objects. Below we will refer to all these types collectively as
-``optional``.
+``std::optional``, ``absl::optional``, or ``base::Optional``
+objects. Below we will refer to all these types collectively as 
``optional``.
 
-An access to the value of an ``optional`` occurs when one of its
-``value``, ``operator*``, or ``operator->`` member functions is invoked.
-To align with common misconceptions, the check considers these member
-functions as equivalent, even though there are subtle 
diff erences
-related to exceptions versus undefined behavior. See
-go/optional-style-recommendations for more information on that topic.
+An access to the value of an ``optional`` occurs when one of its ``value``,
+``operator*``, or ``operator->`` member functions is invoked.  To align with
+common misconceptions, the check considers these member functions as 
equivalent,
+even though there are subtle 
diff erences related to exceptions versus undefined
+behavior. See *Additional notes*, below, for more information on this topic.
 
 An access to the value of an ``optional`` is considered safe if and only if
 code in the local scope (for example, a function body) ensures that the
@@ -273,3 +271,27 @@ The check does not currently report unsafe optional 
accesses in lambdas.
 A future version will expand the scope to lambdas, following the rules
 outlined above. It is best to follow the same principles when using
 optionals in lambdas.
+
+Access with ``operator*()`` vs. ``value()``
+---
+
+Given that ``value()`` has well-defined behavior (either throwing an exception
+or terminating the program), why treat it the same as ``operator*()`` which
+causes undefined behavior (UB)? That is, why is it considered unsafe to access
+an optional with ``value()``, if it's not provably populated with a value?  For
+that matter, why is ``CHECK()`` followed by ``operator*()`` any better than
+``value()``, given that they are semantically equivalent (on configurations 
that
+disable exceptions)?
+
+The answer is that we assume most users do not realize the 
diff erence between
+``value()`` and ``operator*()``. Shifting to ``operator*()`` and some form of
+explicit value-presence check or explicit program termination has two
+advantages:
+
+  * Readability. The check, and any potential side effects like program
+shutdown, are very clear in the code. Separating access from checks can
+actually make the checks more obvious.
+
+  * Performance. A single check can cover many or even all accesses within
+scope. This gives the user the best of both worlds -- the safety of a
+dynamic check, but without incurring redundant costs.



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

[PATCH] D143059: [NFC] Enable selecting multiple multilibs

[Michael Platings via Phabricator via cfe-commits]

michaelplatings updated this revision to Diff 496538.
michaelplatings added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143059

Files:
  clang/include/clang/Driver/Multilib.h
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/Multilib.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/BareMetal.cpp
  clang/lib/Driver/ToolChains/CSKYToolChain.cpp
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Gnu.h
  clang/lib/Driver/ToolChains/Hexagon.cpp
  clang/lib/Driver/ToolChains/Hurd.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/lib/Driver/ToolChains/MipsLinux.cpp
  clang/lib/Driver/ToolChains/RISCVToolchain.cpp
  clang/test/Driver/fuchsia.cpp
  clang/unittests/Driver/MultilibBuilderTest.cpp
  clang/unittests/Driver/MultilibTest.cpp

Index: clang/unittests/Driver/MultilibTest.cpp
===
--- clang/unittests/Driver/MultilibTest.cpp
+++ clang/unittests/Driver/MultilibTest.cpp
@@ -154,18 +154,18 @@
   Multilib("/bar", {}, {}, {"+bar"}),
   });
   Multilib::flag_set Flags1 = {"+foo", "-bar"};
-  Multilib Selection1;
+  llvm::SmallVector Selection1;
   ASSERT_TRUE(MS.select(Flags1, Selection1))
   << "Flag set was {\"+foo\"}, but selection not found";
-  ASSERT_TRUE(Selection1.gccSuffix() == "/foo")
-  << "Selection picked " << Selection1 << " which was not expected";
+  ASSERT_TRUE(Selection1.back().gccSuffix() == "/foo")
+  << "Selection picked " << Selection1.back() << " which was not expected";
 
   Multilib::flag_set Flags2 = {"+foo", "+bar"};
-  Multilib Selection2;
+  llvm::SmallVector Selection2;
   ASSERT_TRUE(MS.select(Flags2, Selection2))
   << "Flag set was {\"+bar\"}, but selection not found";
-  ASSERT_TRUE(Selection2.gccSuffix() == "/bar")
-  << "Selection picked " << Selection2 << " which was not expected";
+  ASSERT_TRUE(Selection2.back().gccSuffix() == "/bar")
+  << "Selection picked " << Selection2.back() << " which was not expected";
 }
 
 TEST(MultilibTest, SelectMultiple) {
@@ -173,17 +173,17 @@
   Multilib("/a", {}, {}, {"x"}),
   Multilib("/b", {}, {}, {"y"}),
   });
-  std::vector Selection;
+  llvm::SmallVector Selection;
 
-  Selection = MS.select({"x"});
+  ASSERT_TRUE(MS.select({"x"}, Selection));
   ASSERT_EQ(1u, Selection.size());
   EXPECT_EQ("/a", Selection[0].gccSuffix());
 
-  Selection = MS.select({"y"});
+  ASSERT_TRUE(MS.select({"y"}, Selection));
   ASSERT_EQ(1u, Selection.size());
   EXPECT_EQ("/b", Selection[0].gccSuffix());
 
-  Selection = MS.select({"y", "x"});
+  ASSERT_TRUE(MS.select({"y", "x"}, Selection));
   ASSERT_EQ(2u, Selection.size());
   EXPECT_EQ("/a", Selection[0].gccSuffix());
   EXPECT_EQ("/b", Selection[1].gccSuffix());
@@ -382,7 +382,7 @@
 
 TEST(MultilibTest, SelectSoft) {
   MultilibSet MS;
-  Multilib Selected;
+  llvm::SmallVector Selected;
   ASSERT_TRUE(parse(MS, YAML_PREAMBLE R"(
 variants:
 - dir: s
@@ -401,7 +401,7 @@
 
 TEST(MultilibTest, SelectSoftFP) {
   MultilibSet MS;
-  Multilib Selected;
+  llvm::SmallVector Selected;
   ASSERT_TRUE(parse(MS, YAML_PREAMBLE R"(
 variants:
 - dir: f
@@ -417,7 +417,7 @@
   // If hard float is all that's available then select that only if compiling
   // with hard float.
   MultilibSet MS;
-  Multilib Selected;
+  llvm::SmallVector Selected;
   ASSERT_TRUE(parse(MS, YAML_PREAMBLE R"(
 variants:
 - dir: h
@@ -431,7 +431,7 @@
 
 TEST(MultilibTest, SelectFloatABI) {
   MultilibSet MS;
-  Multilib Selected;
+  llvm::SmallVector Selected;
   ASSERT_TRUE(parse(MS, YAML_PREAMBLE R"(
 variants:
 - dir: s
@@ -452,18 +452,18 @@
   noMatchFlags: [hasfp]
 )"));
   MS.select({"mfloat-abi=soft"}, Selected);
-  EXPECT_EQ("/s", Selected.gccSuffix());
+  EXPECT_EQ("/s", Selected.back().gccSuffix());
   MS.select({"mfloat-abi=softfp"}, Selected);
-  EXPECT_EQ("/f", Selected.gccSuffix());
+  EXPECT_EQ("/f", Selected.back().gccSuffix());
   MS.select({"mfloat-abi=hard"}, Selected);
-  EXPECT_EQ("/h", Selected.gccSuffix());
+  EXPECT_EQ("/h", Selected.back().gccSuffix());
 }
 
 TEST(MultilibTest, SelectFloatABIReversed) {
   // If soft is specified after softfp then softfp will never be
   // selected because soft is compatible with softfp and last wins.
   MultilibSet MS;
-  Multilib Selected;
+  llvm::SmallVector Selected;
   ASSERT_TRUE(parse(MS, YAML_PREAMBLE R"(
 variants:
 - dir: h
@@ -484,11 +484,11 @@
   noMatchFlags: [hasfp]
 )"));
   MS.select({"mfloat-abi=soft"}, Selected);
-  EXPECT_EQ("/s", Selected.gccSuffix());
+  EXPECT_EQ("/s", Selected.back().gccSuffix());
   MS.select({"mfloat-abi=softfp"}, Selected);
-  EXPECT_EQ("/s", Selected.gccSuffix());
+  EXPECT_EQ("/s", Selected.back().gccSuffix());
   MS.select({"mfloat-abi=hard"}, Selected);
-  EXPECT_EQ("/h", Selected.gccSuffix());
+  EXPECT_EQ("/h", 

[PATCH] D142986: Enable multilib.yaml in the BareMetal ToolChain

[Michael Platings via Phabricator via cfe-commits]

michaelplatings updated this revision to Diff 496537.
michaelplatings added a comment.

Add clangMinimumVersion


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142986

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.h
  clang/lib/Driver/ToolChains/BareMetal.cpp
  clang/test/Driver/Inputs/baremetal_multilib/multilib.yaml
  clang/test/Driver/baremetal-multilib.cpp
  clang/test/Driver/baremetal.cpp

Index: clang/test/Driver/baremetal.cpp
===
--- clang/test/Driver/baremetal.cpp
+++ clang/test/Driver/baremetal.cpp
@@ -118,9 +118,9 @@
 // Verify that the bare metal driver does not include any host system paths:
 // CHECK-AARCH64-NO-HOST-INC: InstalledDir: [[INSTALLEDDIR:.+]]
 // CHECK-AARCH64-NO-HOST-INC: "-resource-dir" "[[RESOURCE:[^"]+]]"
-// CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[INSTALLEDDIR]]{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+}}aarch64-none-elf{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
+// CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[INSTALLEDDIR]]{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+[^"]*}}include{{[/\\]+}}c++{{[/\\]+}}v1"
 // CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[RESOURCE]]{{[/\\]+}}include"
-// CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[INSTALLEDDIR]]{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+}}aarch64-none-elf{{[/\\]+}}include"
+// CHECK-AARCH64-NO-HOST-INC-SAME: "-internal-isystem" "[[INSTALLEDDIR]]{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+[^"]*}}include"
 
 // RUN: %clang %s -### --target=riscv64-unknown-elf -o %t.out -L some/directory/user/asked/for \
 // RUN: --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf 2>&1 \
Index: clang/test/Driver/baremetal-multilib.cpp
===
--- /dev/null
+++ clang/test/Driver/baremetal-multilib.cpp
@@ -0,0 +1,45 @@
+// REQUIRES: shell
+// UNSUPPORTED: system-windows
+
+// RUN: rm -rf %T/baremetal_multilib
+// RUN: mkdir -p %T/baremetal_multilib/bin
+// RUN: mkdir -p %T/baremetal_multilib/lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/lib
+// RUN: touch %T/baremetal_multilib/lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/lib/libclang_rt.builtins.a
+// RUN: ln -s %clang %T/baremetal_multilib/bin/clang
+// RUN: ln -s %S/Inputs/baremetal_multilib/multilib.yaml %T/baremetal_multilib/lib/clang-runtimes/multilib.yaml
+
+// RUN: %T/baremetal_multilib/bin/clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=thumbv8m.main-none-eabihf --sysroot= \
+// RUN:   | FileCheck %s
+// CHECK: "{{.*}}clang{{.*}}" "-cc1" "-triple" "thumbv8m.main-none-unknown-eabihf"
+// CHECK-SAME: "-internal-isystem" "{{.*}}/baremetal_multilib/bin/../lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/include/c++/v1"
+// CHECK-SAME: "-internal-isystem" "{{.*}}/baremetal_multilib/bin/../lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/include"
+// CHECK-SAME: "-x" "c++" "{{.*}}/baremetal-multilib.cpp"
+// CHECK-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
+// CHECK-SAME: "-L{{.*}}/baremetal_multilib/bin/../lib/clang-runtimes/arm-none-eabi/thumb/v8-m.main/fp/lib"
+// CHECK-SAME: "-lc" "-lm" "-lclang_rt.builtins"
+// CHECK-SAME: "-o" "{{.*}}.o"
+
+// RUN: %T/baremetal_multilib/bin/clang -no-canonical-prefixes -print-multi-directory 2>&1 \
+// RUN: --target=thumbv8m.main-none-eabihf --sysroot= \
+// RUN:   | FileCheck --check-prefix=CHECK-PRINT-MULTI-DIRECTORY %s
+// CHECK-PRINT-MULTI-DIRECTORY: arm-none-eabi/thumb/v8-m.main/fp
+
+// RUN: %T/baremetal_multilib/bin/clang -no-canonical-prefixes -print-multi-lib 2>&1 \
+// RUN: --target=arm-none-eabi --sysroot= \
+// RUN:   | FileCheck --check-prefix=CHECK-PRINT-MULTI-LIB %s
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v6-m/nofp;@-target=thumbv6m-none-eabi@mfloat-abi=soft
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v7-m/nofp;@-target=thumbv7m-none-eabi@mfloat-abi=soft
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v7e-m/nofp;@-target=thumbv7em-none-eabi@mfloat-abi=soft@mfpu=none
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v8-m.main/nofp;@-target=arm-none-eabi@mfloat-abi=soft@march=armv8m.main+nofp
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v8.1-m.main/nofp/nomve;@-target=arm-none-eabi@mfloat-abi=soft@march=armv8.1m.main+nofp+nomve
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v7e-m/fpv4_sp_d16;@-target=thumbv7em-none-eabihf@mfpu=fpv4-sp-d16
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v7e-m/fpv5_d16;@-target=thumbv7em-none-eabihf@mfpu=fpv5-d16
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v8-m.main/fp;@-target=thumbv8m.main-none-eabihf
+// CHECK-PRINT-MULTI-LIB: arm-none-eabi/thumb/v8.1-m.main/fp;@-target=thumbv8.1m.main-none-eabihf
+// 

[PATCH] D143418: [libclang] Add API to set preferred temp dir path

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D143418#4117246 , @vedgy wrote:

> In D143418#4116290 , @aaron.ballman 
> wrote:
>
>>> So how about a more sincere general solution: setPreferredTempDirPath()? 
>>> The documentation would say that libclang tries its best to place temporary 
>>> files into the specified directory, but some might end up in the system 
>>> temporary directory instead.
>>
>> I don't think those semantics are reasonable. "Tries its best" is fine for 
>> things that are heuristic based, like deciding when to do an analysis cut 
>> point, but is too non-deterministic for something like "where do files get 
>> placed". I think it's reasonable that we either:
>>
>> 1. expose an option to say "I prefer preambles to be put in this directory" 
>> for libclang, or
>> 2. expose an option to say "I prefer using this directory over the temp 
>> directory for all files" for libclang,
>>
>> I thought we agreed that #2 is too high of risk because it requires auditing 
>> libclang for all the places it decides to put something into the temp 
>> directory, and so we were going with #1 and doing it as part of the cindex 
>> constructor so that users cannot run into the surprise issues 
>> (multithreading, files changing location mid-run) with an independent setter.
>
> This revision implements #2, but warns about possible imperfections of the 
> implementation.

I don't think "tries hard" is a good enough guarantee for where files are 
placed. I'm not comfortable with the security posture of that approach as it 
could potentially leak sensitive information (try to override the temp 
directory to something that's chroot jailed, get sensitive files showing up in 
the system temp directory anyway).

> In D139774#4066519 , @dblaikie 
> wrote:
>
>> In D139774#4065753 , 
>> @aaron.ballman wrote:
>>
>>> From a design perspective, my preference is to not add new APIs at the file 
>>> system support layer in LLVM to override the temporary directory but 
>>> instead allow individual components to override the decision where to put 
>>> files. Overriding a system directory at the LLVM support level feels 
>>> unclean to me because 1) threading concerns (mostly related to lock 
>>> performance), 2) consistency concerns (put files in temp directory, 
>>> override temp directory, put additional files in the new directory), 3) 
>>> principle of least surprise. To me, the LLVM layer is responsible for 
>>> interfacing with the system and asking for the system temp directory should 
>>> get you the same answer as querying for that from the OS directly.
>>
>> I've mixed feelings about this, but yeah, I guess the issues with global 
>> state are pretty undesirable. I don't worry too much about (2) - doesn't 
>> feel too problematic to me (for any individual file, presumably the 
>> implementation recorded the name of the file if they were going to access it 
>> again - so still be using the old path if necessary).
>>
>> But, yeah, lack of any "system" abstraction that could be passed into all 
>> the various LLVM/MC/AST contexts to swap out the implementation limits the 
>> options a bit to more ad-hoc/case-by-case solutions. I feel like that's not 
>> a great solution to KDevelop's general problem, though - they're dealing 
>> with one particularly big file, but it doesn't feel very principled to me to 
>> fix that one compared to all the other (albeit smaller) temp files & maybe 
>> at some point in the future some bigger temp files are created elsewhere...
>
> Based on this comment and on current preamble storage path code, I thought 
> files-changing-location-mid-run should not be a problem.
>
> Does the multithreading issue mean that `clang_parseTranslationUnit_Impl()` 
> can be called in a non-main thread and thus concurrently with 
> `clang_CXIndex_setPreferredTempDirPath()`?

Yes. However, I don't think that situation is officially supported (it's more 
that we don't want to knowingly make it harder to support in the future).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143418

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

[PATCH] D143763: [Clang] Add clangMinimumVersion to multilib.yaml

[Michael Platings via Phabricator via cfe-commits]

michaelplatings created this revision.
michaelplatings added a reviewer: peter.smith.
Herald added a subscriber: dmgreen.
Herald added a project: All.
michaelplatings requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

This avoids a potential source of subtle errors if an older version of
Clang were to be used with a multilib.yaml that requires a newer Clang
to work correctly.

This feature is comparable to CMake's cmake_minimum_required.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143763

Files:
  clang/lib/Driver/Multilib.cpp
  clang/unittests/Driver/MultilibTest.cpp

Index: clang/unittests/Driver/MultilibTest.cpp
===
--- clang/unittests/Driver/MultilibTest.cpp
+++ clang/unittests/Driver/MultilibTest.cpp
@@ -13,6 +13,7 @@
 #include "clang/Driver/Multilib.h"
 #include "../../lib/Driver/ToolChains/CommonArgs.h"
 #include "clang/Basic/LLVM.h"
+#include "clang/Basic/Version.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSwitch.h"
@@ -197,20 +198,80 @@
   );
 }
 
+static bool parse(MultilibSet , std::string ,
+  const std::string ) {
+  return MS.parse(llvm::MemoryBufferRef(Data, "TEST"), diagnosticCallback,
+  );
+}
+
 static bool parse(MultilibSet , const char *Data) {
   return MS.parse(llvm::MemoryBufferRef(Data, "TEST"));
 }
 
+#define _STRINGIFY(x) #x
+#define STRINGIFY(x) _STRINGIFY(x)
+// Avoid using MULTILIB_CLANG_VERSION in case it has extra non-numeric parts.
+#define MULTILIB_CLANG_VERSION \
+  STRINGIFY(CLANG_VERSION_MAJOR)   \
+  "." STRINGIFY(CLANG_VERSION_MINOR) "." STRINGIFY(CLANG_VERSION_PATCHLEVEL)
+#define YAML_PREAMBLE "clangMinimumVersion: " MULTILIB_CLANG_VERSION "\n"
+
 TEST(MultilibTest, ParseInvalid) {
   std::string Diagnostic;
 
   MultilibSet MS;
 
-  EXPECT_FALSE(parse(MS, Diagnostic, "{}"));
-  EXPECT_TRUE(StringRef(Diagnostic).contains("missing required key 'variants'"))
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+variants: []
+)"));
+  EXPECT_TRUE(StringRef(Diagnostic)
+  .contains("missing required key 'clangMinimumVersion'"))
   << Diagnostic;
 
+  // Require all 3 major.minor.patch version components
   EXPECT_FALSE(parse(MS, Diagnostic, R"(
+clangMinimumVersion: )" STRINGIFY(CLANG_VERSION_MAJOR) R"(.0
+variants: []
+)"));
+  EXPECT_TRUE(StringRef(Diagnostic)
+  .contains("not a valid version string \"" STRINGIFY(
+  CLANG_VERSION_MAJOR) ".0\""))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+clangMinimumVersion: )" MULTILIB_CLANG_VERSION R"(a
+variants: []
+)"));
+  EXPECT_TRUE(
+  StringRef(Diagnostic)
+  .contains("not a valid version string \"" MULTILIB_CLANG_VERSION
+"a\""))
+  << Diagnostic;
+
+  // Reject configurations that require a later clang version
+  EXPECT_FALSE(parse(MS, Diagnostic,
+ R"(
+clangMinimumVersion: )" + std::to_string(CLANG_VERSION_MAJOR + 1) +
+ R"(.0.0
+variants: []
+)"));
+  EXPECT_TRUE(StringRef(Diagnostic)
+  .contains("clang version " MULTILIB_CLANG_VERSION
+" is less than clangMinimumVersion: " +
+std::to_string(CLANG_VERSION_MAJOR + 1) + ".0.0"))
+  << Diagnostic;
+
+  // but accept configurations that only need an earlier clang version
+  EXPECT_TRUE(parse(MS, Diagnostic, R"(
+clangMinimumVersion: 16.0.0
+variants: []
+)")) << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, YAML_PREAMBLE));
+  EXPECT_TRUE(StringRef(Diagnostic).contains("missing required key 'variants'"))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, YAML_PREAMBLE R"(
 variants:
 - dir: /abc
   flags: []
@@ -219,7 +280,7 @@
   EXPECT_TRUE(StringRef(Diagnostic).contains("paths must be relative"))
   << Diagnostic;
 
-  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+  EXPECT_FALSE(parse(MS, Diagnostic, YAML_PREAMBLE R"(
 variants:
 - flags: []
   printArgs: []
@@ -227,7 +288,7 @@
   EXPECT_TRUE(StringRef(Diagnostic).contains("missing required key 'dir'"))
   << Diagnostic;
 
-  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+  EXPECT_FALSE(parse(MS, Diagnostic, YAML_PREAMBLE R"(
 variants:
 - dir: .
   printArgs: []
@@ -235,7 +296,7 @@
   EXPECT_TRUE(StringRef(Diagnostic).contains("missing required key 'flags'"))
   << Diagnostic;
 
-  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+  EXPECT_FALSE(parse(MS, Diagnostic, YAML_PREAMBLE R"(
 variants:
 - dir: .
   flags: []
@@ -244,7 +305,7 @@
   StringRef(Diagnostic).contains("missing required key 'printArgs'"))
   << Diagnostic;
 
-  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+  EXPECT_FALSE(parse(MS, Diagnostic, YAML_PREAMBLE R"(
 variants: []
 flagMap:
 

[PATCH] D142932: [NFC] Multilib YAML parsing

[Michael Platings via Phabricator via cfe-commits]

michaelplatings updated this revision to Diff 496534.
michaelplatings added a comment.

Make "variants" required


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142932

Files:
  clang/include/clang/Driver/Multilib.h
  clang/lib/Driver/Multilib.cpp
  clang/unittests/Driver/MultilibTest.cpp

Index: clang/unittests/Driver/MultilibTest.cpp
===
--- clang/unittests/Driver/MultilibTest.cpp
+++ clang/unittests/Driver/MultilibTest.cpp
@@ -187,3 +187,347 @@
   EXPECT_EQ("/a", Selection[0].gccSuffix());
   EXPECT_EQ("/b", Selection[1].gccSuffix());
 }
+
+static void diagnosticCallback(const llvm::SMDiagnostic , void *Out) {
+  *reinterpret_cast(Out) = D.getMessage();
+}
+
+static bool parse(MultilibSet , std::string , const char *Data) {
+  return MS.parse(llvm::MemoryBufferRef(Data, "TEST"), diagnosticCallback,
+  );
+}
+
+static bool parse(MultilibSet , const char *Data) {
+  return MS.parse(llvm::MemoryBufferRef(Data, "TEST"));
+}
+
+TEST(MultilibTest, ParseInvalid) {
+  std::string Diagnostic;
+
+  MultilibSet MS;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, "{}"));
+  EXPECT_TRUE(StringRef(Diagnostic).contains("missing required key 'variants'"))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+variants:
+- dir: /abc
+  flags: []
+  printArgs: []
+)"));
+  EXPECT_TRUE(StringRef(Diagnostic).contains("paths must be relative"))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+variants:
+- flags: []
+  printArgs: []
+)"));
+  EXPECT_TRUE(StringRef(Diagnostic).contains("missing required key 'dir'"))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+variants:
+- dir: .
+  printArgs: []
+)"));
+  EXPECT_TRUE(StringRef(Diagnostic).contains("missing required key 'flags'"))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+variants:
+- dir: .
+  flags: []
+)"));
+  EXPECT_TRUE(
+  StringRef(Diagnostic).contains("missing required key 'printArgs'"))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+variants: []
+flagMap:
+- regex: abc
+)"));
+  EXPECT_TRUE(
+  StringRef(Diagnostic)
+  .contains("value required for 'matchFlags' or 'noMatchFlags'"))
+  << Diagnostic;
+
+  EXPECT_FALSE(parse(MS, Diagnostic, R"(
+variants: []
+flagMap:
+- dir: .
+  regex: '('
+  printArgs: []
+
+)"));
+  EXPECT_TRUE(StringRef(Diagnostic).contains("parentheses not balanced"))
+  << Diagnostic;
+}
+
+TEST(MultilibTest, Parse) {
+  MultilibSet MS;
+  EXPECT_TRUE(parse(MS, R"(
+variants:
+- dir: .
+  flags: []
+  printArgs: []
+)"));
+  EXPECT_EQ(1U, MS.size());
+  EXPECT_EQ("", MS.begin()->gccSuffix());
+
+  EXPECT_TRUE(parse(MS, R"(
+variants:
+- dir: abc
+  flags: []
+  printArgs: []
+)"));
+  EXPECT_EQ(1U, MS.size());
+  EXPECT_EQ("/abc", MS.begin()->gccSuffix());
+
+  EXPECT_TRUE(parse(MS, R"(
+variants:
+- dir: pqr
+  flags: []
+  printArgs: [-mfloat-abi=soft]
+)"));
+  EXPECT_EQ(1U, MS.size());
+  EXPECT_EQ("/pqr", MS.begin()->gccSuffix());
+  EXPECT_EQ(std::vector({"-mfloat-abi=soft"}),
+MS.begin()->getPrintArgs());
+
+  EXPECT_TRUE(parse(MS, R"(
+variants:
+- dir: pqr
+  flags: []
+  printArgs: [-mfloat-abi=soft, -fno-exceptions]
+)"));
+  EXPECT_EQ(1U, MS.size());
+  EXPECT_EQ(std::vector({"-mfloat-abi=soft", "-fno-exceptions"}),
+MS.begin()->getPrintArgs());
+
+  EXPECT_TRUE(parse(MS, R"(
+variants:
+- dir: a
+  flags: []
+  printArgs: []
+- dir: b
+  flags: []
+  printArgs: []
+)"));
+  EXPECT_EQ(2U, MS.size());
+}
+
+TEST(MultilibTest, SelectSoft) {
+  MultilibSet MS;
+  Multilib Selected;
+  ASSERT_TRUE(parse(MS, R"(
+variants:
+- dir: s
+  flags: [softabi]
+  printArgs: []
+flagMap:
+- regex: mfloat-abi=soft
+  matchFlags: [softabi]
+- regex: mfloat-abi=softfp
+  matchFlags: [softabi]
+)"));
+  EXPECT_TRUE(MS.select({"mfloat-abi=soft"}, Selected));
+  EXPECT_TRUE(MS.select({"mfloat-abi=softfp"}, Selected));
+  EXPECT_FALSE(MS.select({"mfloat-abi=hard"}, Selected));
+}
+
+TEST(MultilibTest, SelectSoftFP) {
+  MultilibSet MS;
+  Multilib Selected;
+  ASSERT_TRUE(parse(MS, R"(
+variants:
+- dir: f
+  flags: [mfloat-abi=softfp]
+  printArgs: []
+)"));
+  EXPECT_FALSE(MS.select({"mfloat-abi=soft"}, Selected));
+  EXPECT_TRUE(MS.select({"mfloat-abi=softfp"}, Selected));
+  EXPECT_FALSE(MS.select({"mfloat-abi=hard"}, Selected));
+}
+
+TEST(MultilibTest, SelectHard) {
+  // If hard float is all that's available then select that only if compiling
+  // with hard float.
+  MultilibSet MS;
+  Multilib Selected;
+  ASSERT_TRUE(parse(MS, R"(
+variants:
+- dir: h
+  flags: [mfloat-abi=hard]
+  printArgs: []
+)"));
+  EXPECT_FALSE(MS.select({"mfloat-abi=soft"}, Selected));
+  EXPECT_FALSE(MS.select({"mfloat-abi=softfp"}, Selected));
+  EXPECT_TRUE(MS.select({"mfloat-abi=hard"}, Selected));
+}
+
+TEST(MultilibTest, SelectFloatABI) {
+  MultilibSet MS;
+  

[PATCH] D143587: [Docs] Multilib design

[Michael Platings via Phabricator via cfe-commits]

michaelplatings updated this revision to Diff 496533.
michaelplatings added a comment.

Tweak multilib.yaml spec slightly


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143587

Files:
  clang/docs/Multilib.rst
  clang/docs/index.rst

Index: clang/docs/index.rst
===
--- clang/docs/index.rst
+++ clang/docs/index.rst
@@ -100,6 +100,7 @@
CodeOwners
InternalsManual
DriverInternals
+   Multilib
OffloadingDesign
PCHInternals
ItaniumMangleAbiTags
Index: clang/docs/Multilib.rst
===
--- /dev/null
+++ clang/docs/Multilib.rst
@@ -0,0 +1,321 @@
+
+Multilib
+
+
+Introduction
+
+
+This document describes how multilib is implemented in Clang.
+
+What is multilib and why might you care?
+If you're :doc:`cross compiling` then you can't use native
+system headers and libraries. To address this, you can use a combination of
+``--sysroot``, ``-isystem`` and ``-L`` options to point clang at suitable
+directories for your target.
+However, when there are many possible directories to choose from, it's not
+necessarily obvious which one to pick.
+Multilib allows a toolchain designer to imbue the toolchain with the ability to
+pick a suitable directory automatically, based on the options the user provides
+to clang. For example, if the user specifies
+``--target=arm-none-eabi -mcpu=cortex-m4`` the toolchain can choose a directory
+containing headers and libraries suitable for Armv7E-M, because it knows that's
+a suitable architecture for Arm Cortex-M4.
+Multilib can also choose between libraries for the same architecture based on
+other options. For example if the user specifies ``-fno-exceptions`` then a
+toolchain could select libraries built without exception support, thereby
+reducing the size of the resulting binary.
+
+Design
+==
+
+Clang supports GCC's ``-print-multi-lib`` and ``-print-multi-directory``
+options. These are described in
+`GCC Developer Options `_.
+
+There are two ways to configure multilib in Clang: hard-coded or via a
+configuration file.
+
+Hard-coded Multilib
+===
+
+The available libraries can be hard-coded in clang. Typically this is done
+using the ``MultilibBuilder`` interface. There are many examples of this in
+``Gnu.cpp``.
+The remainder of this document will not focus on this type of multilib.
+
+Multilib via configuration file
+===
+
+Some clang toolchains support loading multilib configuration from a
+``multilib.yaml`` configuration file.
+
+A ``multilib.yaml`` configuration file specifies which multilib variants are
+available, their relative location, what compilation options were used to build
+them, and the criteria by which they are selected.
+
+Multilib processing
+===
+
+Clang goes through the following steps to use multilib from a configuration
+file:
+#. Convert command line arguments to flags. Clang can accept the same
+   information via different arguments - for example,
+   ``--target=arm-none-eabi -march=armv7-m`` and
+   ``--target=armv7m-none-eabi`` are equivalent. Clang can also accept many
+   independent pieces of information within a single flag - for example
+   ``-march=armv8.1m.main+fp+mve`` specifies the architecture and two
+   extensions in a single command line argument.
+   To make it easier for the multilib system, clang converts the command line
+   arguments into a standard set of simpler "flags". In many cases these flags
+   will look like a command line argument with the leading ``-`` stripped off,
+   but where a suitable form for the flag doesn't exist in command line
+   arguments then its form will be different. For example, an Arm architecture
+   extension is represented like ``march=+mve`` since there's no way to specify
+   it in isolation in a command line argument.
+   To see what flags are emitted for a given set of command line arguments, use
+   the ``-print-multi-selection-flags-experimental`` command line argument
+   along with the rest of the arguments you want to use.
+#. Load ``multilib.yaml`` from sysroot.
+#. Generate additional flags. ``multilib.yaml`` contains a ``flagMap`` section,
+   which specifies how to generate additional flags based on the flags derived
+   from command line arguments. Flags are matched using regular expressions.
+   These regular expressions shall use the POSIX extended regular expression
+   syntax.
+#. Match flags against multilib variants. If the generated flags are a superset
+   of the flags specified for a multilib variant then the variant is considered
+   a match.
+   If more than one variant matches then a toolchain may opt to either use only
+   the *last* matching multilib variant, or may use all matching 

[PATCH] D143692: [clang][driver] Emit error when enabling emulated tls on unsupported architectures

[Paul Kirth via Phabricator via cfe-commits]

paulkirth updated this revision to Diff 496529.
paulkirth added a comment.

Rebase on parent revision


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143692

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/emulated-tls.cpp


Index: clang/test/Driver/emulated-tls.cpp
===
--- clang/test/Driver/emulated-tls.cpp
+++ clang/test/Driver/emulated-tls.cpp
@@ -29,6 +29,10 @@
 // RUN: %clang -### -target i686-pc-openbsd %s -femulated-tls 
-fno-emulated-tls 2>&1 \
 // RUN: | FileCheck -check-prefix=NOEMU %s
 
+// RUN: %clang -### --target=riscv64-linux-android %s -fno-emulated-tls 2>&1 \
+// RUN: | FileCheck -check-prefix=RISCV %s
+// RUN: %clang -### --target=riscv64-linux-android %s -fno-emulated-tls 
-femulated-tls 2>&1 \
+// RUN: | FileCheck -check-prefix=RISCV-ERROR %s
 
 // Default without -f[no-]emulated-tls, will be decided by the target triple.
 // DEFAULT-NOT: "-cc1" {{.*}}"-femulated-tls"
@@ -40,3 +44,6 @@
 
 // NOEMU: "-cc1" {{.*}}"-fno-emulated-tls"
 // NOEMU-NOT: "-cc1" {{.*}}"-femulated-tls"
+
+// RISCV-NOT:  unsupported option '-fno-emulated-tls' for target 
'riscv64-unknown-linux-android'
+// RISCV-ERROR:  unsupported option '-femulated-tls' for target 
'riscv64-unknown-linux-android'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6164,8 +6164,19 @@
   Args.AddLastArg(CmdArgs, options::OPT_femit_all_decls);
   Args.AddLastArg(CmdArgs, options::OPT_fheinous_gnu_extensions);
   Args.AddLastArg(CmdArgs, options::OPT_fdigraphs, options::OPT_fno_digraphs);
-  Args.AddLastArg(CmdArgs, options::OPT_femulated_tls,
-  options::OPT_fno_emulated_tls);
+
+  if (Arg *A = Args.getLastArg(options::OPT_femulated_tls,
+   options::OPT_fno_emulated_tls)) {
+// LLVM does not support Emulated TLS for some architectures, like RISCV
+// So issue an error to avoid subtle problems in codegen if the flags are
+// incompatible. see https://github.com/llvm/llvm-project/issues/59500
+if (!Triple.supportsEmulatedTLS() &&
+A->getOption().getID() == options::OPT_femulated_tls)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << A->getAsString(Args) << TripleStr;
+A->render(Args, CmdArgs);
+  }
+
   Args.AddLastArg(CmdArgs, options::OPT_fzero_call_used_regs_EQ);
 
   if (Arg *A = Args.getLastArg(options::OPT_fzero_call_used_regs_EQ)) {


Index: clang/test/Driver/emulated-tls.cpp
===
--- clang/test/Driver/emulated-tls.cpp
+++ clang/test/Driver/emulated-tls.cpp
@@ -29,6 +29,10 @@
 // RUN: %clang -### -target i686-pc-openbsd %s -femulated-tls -fno-emulated-tls 2>&1 \
 // RUN: | FileCheck -check-prefix=NOEMU %s
 
+// RUN: %clang -### --target=riscv64-linux-android %s -fno-emulated-tls 2>&1 \
+// RUN: | FileCheck -check-prefix=RISCV %s
+// RUN: %clang -### --target=riscv64-linux-android %s -fno-emulated-tls -femulated-tls 2>&1 \
+// RUN: | FileCheck -check-prefix=RISCV-ERROR %s
 
 // Default without -f[no-]emulated-tls, will be decided by the target triple.
 // DEFAULT-NOT: "-cc1" {{.*}}"-femulated-tls"
@@ -40,3 +44,6 @@
 
 // NOEMU: "-cc1" {{.*}}"-fno-emulated-tls"
 // NOEMU-NOT: "-cc1" {{.*}}"-femulated-tls"
+
+// RISCV-NOT:  unsupported option '-fno-emulated-tls' for target 'riscv64-unknown-linux-android'
+// RISCV-ERROR:  unsupported option '-femulated-tls' for target 'riscv64-unknown-linux-android'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6164,8 +6164,19 @@
   Args.AddLastArg(CmdArgs, options::OPT_femit_all_decls);
   Args.AddLastArg(CmdArgs, options::OPT_fheinous_gnu_extensions);
   Args.AddLastArg(CmdArgs, options::OPT_fdigraphs, options::OPT_fno_digraphs);
-  Args.AddLastArg(CmdArgs, options::OPT_femulated_tls,
-  options::OPT_fno_emulated_tls);
+
+  if (Arg *A = Args.getLastArg(options::OPT_femulated_tls,
+   options::OPT_fno_emulated_tls)) {
+// LLVM does not support Emulated TLS for some architectures, like RISCV
+// So issue an error to avoid subtle problems in codegen if the flags are
+// incompatible. see https://github.com/llvm/llvm-project/issues/59500
+if (!Triple.supportsEmulatedTLS() &&
+A->getOption().getID() == options::OPT_femulated_tls)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << A->getAsString(Args) << TripleStr;
+A->render(Args, CmdArgs);
+  }
+
   Args.AddLastArg(CmdArgs, options::OPT_fzero_call_used_regs_EQ);
 
   if (Arg *A = Args.getLastArg(options::OPT_fzero_call_used_regs_EQ)) {

[PATCH] D143755: [clang-format] Add a space between an overloaded operator and '>'

[Igor Kushnir via Phabricator via cfe-commits]

vedgy added a comment.

Hi @owenpan. Thank you for fixing this bug!
Have you noticed this paragraph in my bug report?

> I believe `clang_getTypeSpelling()`, or more likely `QualType::print()` used 
> by it, should insert a tab character between such tokens to pretty-print 
> compilable code. The tab character is preferable to the space character here, 
> because the users may rely on the fact that pretty-printed binary operators 
> are surrounded by spaces to distinguish them from angle brackets.

KDevelop parses the result of `clang_getTypeSpelling()` when libclang API is 
lacking. Since this recent commit 

 KDevelop's parsing relies on the empirical fact that only operators are 
surrounded by spaces to distinguish them from angle brackets. Does this 
revision introduce angle brackets surrounded by spaces? Can tab characters be 
used instead? If not, do you know how else such angle brackets can be 
distinguished from operators?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143755

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

[PATCH] D143750: [clang-tidy] Clarify documention of `bugprone-unchecked-optional-access`.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

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



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst:278
+
+Given that ``value()`` has well-defined program termination behavior, why treat
+it the same as ``operator*()`` which causes undefined behavior (UB)? That is,

xazax.hun wrote:
> Strictly speaking, `value` on an empty optional will not terminate the 
> program. It will raise an exception that can be handled.
> 
> (Of course, at Google, exceptions are banned so termination is right in that 
> context.)
Right! Updated to mention both possibilities. Thx


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143750

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

[PATCH] D143750: [clang-tidy] Clarify documention of `bugprone-unchecked-optional-access`.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

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

address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143750

Files:
  
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst


Index: 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
===
--- 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
+++ 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
@@ -8,16 +8,14 @@
 average clang-tidy check.
 
 This check identifies unsafe accesses to values contained in
-``std::optional``, ``absl::optional``, or ``base::std::optional``
-objects. Below we will refer to all these types collectively as
-``optional``.
+``std::optional``, ``absl::optional``, or ``base::Optional``
+objects. Below we will refer to all these types collectively as 
``optional``.
 
-An access to the value of an ``optional`` occurs when one of its
-``value``, ``operator*``, or ``operator->`` member functions is invoked.
-To align with common misconceptions, the check considers these member
-functions as equivalent, even though there are subtle differences
-related to exceptions versus undefined behavior. See
-go/optional-style-recommendations for more information on that topic.
+An access to the value of an ``optional`` occurs when one of its ``value``,
+``operator*``, or ``operator->`` member functions is invoked.  To align with
+common misconceptions, the check considers these member functions as 
equivalent,
+even though there are subtle differences related to exceptions versus undefined
+behavior. See *Additional notes*, below, for more information on this topic.
 
 An access to the value of an ``optional`` is considered safe if and only if
 code in the local scope (for example, a function body) ensures that the
@@ -273,3 +271,27 @@
 A future version will expand the scope to lambdas, following the rules
 outlined above. It is best to follow the same principles when using
 optionals in lambdas.
+
+Access with ``operator*()`` vs. ``value()``
+---
+
+Given that ``value()`` has well-defined behavior (either throwing an exception
+or terminating the program), why treat it the same as ``operator*()`` which
+causes undefined behavior (UB)? That is, why is it considered unsafe to access
+an optional with ``value()``, if it's not provably populated with a value?  For
+that matter, why is ``CHECK()`` followed by ``operator*()`` any better than
+``value()``, given that they are semantically equivalent (on configurations 
that
+disable exceptions)?
+
+The answer is that we assume most users do not realize the difference between
+``value()`` and ``operator*()``. Shifting to ``operator*()`` and some form of
+explicit value-presence check or explicit program termination has two
+advantages:
+
+  * Readability. The check, and any potential side effects like program
+shutdown, are very clear in the code. Separating access from checks can
+actually make the checks more obvious.
+
+  * Performance. A single check can cover many or even all accesses within
+scope. This gives the user the best of both worlds -- the safety of a
+dynamic check, but without incurring redundant costs.


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
@@ -8,16 +8,14 @@
 average clang-tidy check.
 
 This check identifies unsafe accesses to values contained in
-``std::optional``, ``absl::optional``, or ``base::std::optional``
-objects. Below we will refer to all these types collectively as
-``optional``.
+``std::optional``, ``absl::optional``, or ``base::Optional``
+objects. Below we will refer to all these types collectively as ``optional``.
 
-An access to the value of an ``optional`` occurs when one of its
-``value``, ``operator*``, or ``operator->`` member functions is invoked.
-To align with common misconceptions, the check considers these member
-functions as equivalent, even though there are subtle differences
-related to exceptions versus undefined behavior. See
-go/optional-style-recommendations for more information on that topic.
+An access to the value of an ``optional`` occurs when one of its ``value``,
+``operator*``, or ``operator->`` member functions is invoked.  To align with
+common misconceptions, the check considers these member functions as equivalent,
+even though there are subtle differences related to exceptions versus undefined
+behavior. See *Additional notes*, below, for more information on this topic.
 
 An access to the value of an 

[PATCH] D143750: [clang-tidy] Clarify documention of `bugprone-unchecked-optional-access`.

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

xazax.hun added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst:278
+
+Given that ``value()`` has well-defined program termination behavior, why treat
+it the same as ``operator*()`` which causes undefined behavior (UB)? That is,

Strictly speaking, `value` on an empty optional will not terminate the program. 
It will raise an exception that can be handled.

(Of course, at Google, exceptions are banned so termination is right in that 
context.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143750

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

[PATCH] D143755: [clang-format] Add a space between an overloaded operator and '>'

[Owen Pan via Phabricator via cfe-commits]

owenpan created this revision.
owenpan added reviewers: MyDeveloperDay, HazardyKnusperkeks, rymiel.
owenpan added a project: clang-format.
Herald added a project: All.
owenpan requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The token annotator doesn't annotate the template opener and closer as such if 
they enclose an overloaded operator. This causes the space between the operator 
and the closer to be removed, resulting
in invalid C++ code.

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143755

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
@@ -574,6 +574,72 @@
   EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_OverloadedOperatorLParen);
 }
 
+TEST_F(TokenAnnotatorTest, OverloadedOperatorInTemplate) {
+  struct {
+const char *Text;
+tok::TokenKind Kind;
+  } Operators[] = {{"+", tok::plus},
+   {"-", tok::minus},
+   // FIXME:
+   // {"*", tok::star},
+   {"/", tok::slash},
+   {"%", tok::percent},
+   {"^", tok::caret},
+   // FIXME:
+   // {"&", tok::amp},
+   {"|", tok::pipe},
+   {"~", tok::tilde},
+   {"!", tok::exclaim},
+   {"=", tok::equal},
+   // FIXME:
+   // {"<", tok::less},
+   {">", tok::greater},
+   {"+=", tok::plusequal},
+   {"-=", tok::minusequal},
+   {"*=", tok::starequal},
+   {"/=", tok::slashequal},
+   {"%=", tok::percentequal},
+   {"^=", tok::caretequal},
+   {"&=", tok::ampequal},
+   {"|=", tok::pipeequal},
+   // FIXME:
+   // {"<<", tok::lessless},
+   // {">>", tok::greatergreater},
+   {">>=", tok::greatergreaterequal},
+   {"<<=", tok::lesslessequal},
+   {"==", tok::equalequal},
+   {"!=", tok::exclaimequal},
+   {"<=", tok::lessequal},
+   {">=", tok::greaterequal},
+   {"<=>", tok::spaceship},
+   {"&&", tok::ampamp},
+   {"||", tok::pipepipe},
+   {"++", tok::plusplus},
+   {"--", tok::minusminus},
+   {",", tok::comma},
+   {"->*", tok::arrowstar},
+   {"->", tok::arrow}};
+
+  for (const auto  : Operators) {
+std::string Input("C< ");
+Input += Operator.Text;
+Input += " > a;";
+auto Tokens = annotate(std::string(Input));
+ASSERT_EQ(Tokens.size(), 9u) << Tokens;
+EXPECT_TOKEN(Tokens[1], tok::less, TT_TemplateOpener);
+EXPECT_TOKEN(Tokens[4], Operator.Kind, TT_OverloadedOperator);
+EXPECT_TOKEN(Tokens[5], tok::greater, TT_TemplateCloser);
+  }
+
+  auto Tokens = annotate("C<< > lt;");
+  ASSERT_EQ(Tokens.size(), 12u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[4], tok::less, TT_OverloadedOperator);
+  EXPECT_TOKEN(Tokens[5], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[7], tok::greater, TT_TemplateCloser);
+  EXPECT_TOKEN(Tokens[8], tok::greater, TT_TemplateCloser);
+}
+
 TEST_F(TokenAnnotatorTest, UnderstandsRequiresClausesAndConcepts) {
   auto Tokens = annotate("template \n"
  "concept C = (Foo && Bar) && (Bar && Baz);");
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -10663,6 +10663,14 @@
   verifyFormat("foo() { ::operator new(n * sizeof(foo)); }");
 }
 
+TEST_F(FormatTest, SpaceBeforeTemplateCloser) {
+  verifyFormat("C< > minus;");
+  verifyFormat("C<> > gt;");
+  verifyFormat("C<>= > ge;");
+  verifyFormat("C<<= > le;");
+  verifyFormat("C<< > lt;");
+}
+
 TEST_F(FormatTest, UnderstandsFunctionRefQualification) {
   verifyFormat("void A::b() && {}");
   verifyFormat("void A::b() && noexcept {}");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -1219,9 +1219,14 @@
  !CurrentToken->isOneOf(tok::l_paren, tok::semi, tok::r_paren)) {
 if (CurrentToken->isOneOf(tok::star, tok::amp))
   CurrentToken->setType(TT_PointerOrReference);
-consumeToken();
+if 

[PATCH] D143522: [AMDGPU] Set a data layout entry for buffer descriptors (addrspace 7)

[Krzysztof Drewniak via Phabricator via cfe-commits]

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

Apparently clang has its own copy of this data layout.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143522

Files:
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/test/CodeGen/target-data.c
  clang/test/CodeGenOpenCL/amdgpu-env-amdgcn.cl
  llvm/lib/IR/AutoUpgrade.cpp
  llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp
  
llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-non-integral-address-spaces.ll
  llvm/test/CodeGen/AMDGPU/addrspacecast-captured.ll
  llvm/test/CodeGen/AMDGPU/annotate-kernel-features-hsa.ll
  llvm/test/CodeGen/AMDGPU/cgp-addressing-modes.ll
  llvm/test/CodeGen/AMDGPU/force-alwaysinline-lds-global-address.ll
  llvm/test/CodeGen/AMDGPU/loop-idiom.ll
  llvm/test/CodeGen/AMDGPU/mdt-preserving-crash.ll
  llvm/test/CodeGen/AMDGPU/noop-shader-O0.ll
  llvm/test/CodeGen/AMDGPU/nullptr-addrspace-7-tmp.ll
  llvm/test/CodeGen/AMDGPU/nullptr.ll
  llvm/test/CodeGen/AMDGPU/promote-alloca-lifetime.ll
  llvm/test/CodeGen/AMDGPU/promote-alloca-to-lds-select.ll
  llvm/test/CodeGen/AMDGPU/sgpr-copy-local-cse.ll
  llvm/test/CodeGen/AMDGPU/unroll.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/adaptive_constant_global_redzones.ll
  llvm/test/Instrumentation/AddressSanitizer/AMDGPU/adaptive_global_redzones.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/asan_do_not_instrument_lds.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/asan_do_not_instrument_scratch.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/asan_instrument_constant_address_space.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/asan_instrument_generic_address_space.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/asan_instrument_global_address_space.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/global_metadata_addrspacecasts.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/no_redzones_in_lds_globals.ll
  
llvm/test/Instrumentation/AddressSanitizer/AMDGPU/no_redzones_in_scratch_globals.ll
  llvm/test/Transforms/AlignmentFromAssumptions/amdgpu-crash.ll
  llvm/test/Transforms/AtomicExpand/AMDGPU/expand-atomic-i16.ll
  llvm/test/Transforms/EarlyCSE/AMDGPU/memrealtime.ll
  llvm/test/Transforms/IndVarSimplify/AMDGPU/no-widen-to-i64.ll
  llvm/test/Transforms/InferAddressSpaces/AMDGPU/noop-ptrint-pair.ll
  llvm/test/Transforms/InferAddressSpaces/AMDGPU/ptrmask.ll
  llvm/test/Transforms/InferAddressSpaces/X86/noop-ptrint-pair.ll
  llvm/test/Transforms/Inline/AMDGPU/amdgpu-inline-alloca-argument.ll
  llvm/test/Transforms/InstCombine/AMDGPU/memcpy-from-constant.ll
  llvm/test/Transforms/InstCombine/alloca-in-non-alloca-as.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/aa-metadata.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/adjust-alloca-alignment.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/complex-index.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/extended-index.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/gep-bitcast.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/insertion-point.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/interleaved-mayalias-store.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/invariant-load.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/merge-stores-private.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/merge-stores.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/merge-vectors.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/missing-alignment.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/multiple_tails.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/no-implicit-float.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/optnone.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/pointer-elements.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/selects-inseltpoison.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/selects.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/store_with_aliasing_load.ll
  llvm/test/Transforms/LoadStoreVectorizer/AMDGPU/weird-type-accesses.ll
  llvm/test/Transforms/LoopLoadElim/pr46854-adress-spaces.ll
  llvm/test/Transforms/LoopStrengthReduce/AMDGPU/atomics.ll
  
llvm/test/Transforms/LoopStrengthReduce/AMDGPU/different-addrspace-addressing-mode-loops.ll
  llvm/test/Transforms/LoopStrengthReduce/AMDGPU/lsr-invalid-ptr-extend.ll
  llvm/test/Transforms/LoopStrengthReduce/AMDGPU/lsr-postinc-pos-addrspace.ll
  llvm/test/Transforms/LoopStrengthReduce/AMDGPU/preserve-addrspace-assert.ll
  llvm/test/Transforms/OpenMP/attributor_pointer_offset_crash.ll
  llvm/test/Transforms/OpenMP/spmdization_constant_prop.ll
  llvm/test/Transforms/OpenMP/values_in_offload_arrays.alloca.ll
  
llvm/test/Transforms/SLPVectorizer/AMDGPU/address-space-ptr-sze-gep-index-assert.ll
  llvm/test/Transforms/VectorCombine/AMDGPU/as-transition-inseltpoison.ll

[PATCH] D143751: [clang][analyzer][NFC] Refactor code of StdLibraryFunctionsChecker.

[Balázs Kéri via Phabricator via cfe-commits]

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

The code was difficult to maintain (big internal class definitions
with long inline functions, other functions of the same class at
different location far away, irregular ordering of classes and
function definitions). It is now improved to some extent.
New functions are added to RangeConstraint to remove code repetition,
these are useful for planned new features too.
Comments are improved.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143751

Files:
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp

Index: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -68,6 +68,19 @@
   /// to us. If he doesn't, he performs additional invalidations.
   enum InvalidationKind { NoEvalCall, EvalCallAsPure };
 
+  /// Given a range, should the argument stay inside or outside this range?
+  enum RangeKind { OutOfRange, WithinRange };
+
+  static RangeKind negateKind(RangeKind K) {
+switch (K) {
+case OutOfRange:
+  return WithinRange;
+case WithinRange:
+  return OutOfRange;
+}
+llvm_unreachable("Unknown range kind");
+  }
+
   // The universal integral type to use in value range descriptions.
   // Unsigned to make sure overflows are well-defined.
   typedef uint64_t RangeInt;
@@ -82,9 +95,11 @@
   /// ArgNo in CallExpr and CallEvent is defined as Unsigned, but
   /// obviously uint32_t should be enough for all practical purposes.
   typedef uint32_t ArgNo;
+  /// Special argument number for specifying the return value.
   static const ArgNo Ret;
 
   using DescString = SmallString<96>;
+
   /// Returns the string representation of an argument index.
   /// E.g.: (1) -> '1st arg', (2) - > '2nd arg'
   static SmallString<8> getArgDesc(ArgNo);
@@ -102,10 +117,12 @@
   class ValueConstraint;
 
   // Pointer to the ValueConstraint. We need a copyable, polymorphic and
-  // default initialize able type (vector needs that). A raw pointer was good,
+  // default initializable type (vector needs that). A raw pointer was good,
   // however, we cannot default initialize that. unique_ptr makes the Summary
   // class non-copyable, therefore not an option. Releasing the copyability
   // requirement would render the initialization of the Summary map infeasible.
+  // A new value constraint is created furthermore by the negate functionality
+  // of the constraint and returned as pointer.
   using ValueConstraintPtr = std::shared_ptr;
 
   /// Polymorphic base class that represents a constraint on a given argument
@@ -122,35 +139,12 @@
   public:
 ValueConstraint(ArgNo ArgN) : ArgN(ArgN) {}
 virtual ~ValueConstraint() {}
+
 /// Apply the effects of the constraint on the given program state. If null
 /// is returned then the constraint is not feasible.
 virtual ProgramStateRef apply(ProgramStateRef State, const CallEvent ,
   const Summary ,
   CheckerContext ) const = 0;
-virtual ValueConstraintPtr negate() const {
-  llvm_unreachable("Not implemented");
-};
-
-/// Check whether the constraint is malformed or not. It is malformed if the
-/// specified argument has a mismatch with the given FunctionDecl (e.g. the
-/// arg number is out-of-range of the function's argument list).
-bool checkValidity(const FunctionDecl *FD) const {
-  const bool ValidArg = ArgN == Ret || ArgN < FD->getNumParams();
-  assert(ValidArg && "Arg out of range!");
-  if (!ValidArg)
-return false;
-  // Subclasses may further refine the validation.
-  return checkSpecificValidity(FD);
-}
-ArgNo getArgNo() const { return ArgN; }
-
-/// Return those arguments that should be tracked when we report a bug. By
-/// default it is the argument that is constrained, however, in some special
-/// cases we need to track other arguments as well. E.g. a buffer size might
-/// be encoded in another argument.
-virtual std::vector getArgsToTrack() const { return {ArgN}; }
-
-virtual StringRef getName() const = 0;
 
 /// Represents that in which context do we require a description of the
 /// constraint.
@@ -158,6 +152,8 @@
   /// The constraint is violated.
   Violation,
   /// We assume that the constraint is satisfied.
+  /// This can be used when a precondition is satisfied, or when a 

[PATCH] D143624: Inlining: Run the legacy AlwaysInliner before the regular inliner.

[Amara Emerson via Phabricator via cfe-commits]

aemerson added a comment.

In D143624#4118341 , @dmgreen wrote:

>> It’s not clear from the original commit message why the test is related to 
>> inlining order? It seems entirely testing vectorization cost model which 
>> should be insensitive to these kind of changes, right?
>
> It's a phase ordering test - it's testing the entire pipeline including all 
> the inlining and simplification that needs to happen :)
>
> You can run update_test_checks of the file to see the differences. I believe 
> the inlining causes differences in the code that then cause different vector 
> factors to be chosen. I can try to add a similar test for the other case that 
> got worse, if they are similar.

I’ll take a look, but this indicates to me that there’s something missing from 
the vectoriser or later passes rather than a problem with the inliners 
behaviour.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143624

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

[PATCH] D143750: [clang-tidy] Clarify documention of `bugprone-unchecked-optional-access`.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel created this revision.
ymandel added reviewers: xazax.hun, gribozavr2, sgatev.
Herald added a subscriber: rnkovacs.
Herald added a reviewer: njames93.
Herald added a project: All.
ymandel requested review of this revision.
Herald added a project: clang-tools-extra.

Removes a reference to google-internal document and expands the relevant 
material in place.

Fixes #60633.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143750

Files:
  
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst


Index: 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
===
--- 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
+++ 
clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
@@ -8,16 +8,14 @@
 average clang-tidy check.
 
 This check identifies unsafe accesses to values contained in
-``std::optional``, ``absl::optional``, or ``base::std::optional``
-objects. Below we will refer to all these types collectively as
-``optional``.
+``std::optional``, ``absl::optional``, or ``base::Optional``
+objects. Below we will refer to all these types collectively as 
``optional``.
 
-An access to the value of an ``optional`` occurs when one of its
-``value``, ``operator*``, or ``operator->`` member functions is invoked.
-To align with common misconceptions, the check considers these member
-functions as equivalent, even though there are subtle differences
-related to exceptions versus undefined behavior. See
-go/optional-style-recommendations for more information on that topic.
+An access to the value of an ``optional`` occurs when one of its ``value``,
+``operator*``, or ``operator->`` member functions is invoked.  To align with
+common misconceptions, the check considers these member functions as 
equivalent,
+even though there are subtle differences related to exceptions versus undefined
+behavior. See *Additional notes*, below, for more information on this topic.
 
 An access to the value of an ``optional`` is considered safe if and only if
 code in the local scope (for example, a function body) ensures that the
@@ -273,3 +271,26 @@
 A future version will expand the scope to lambdas, following the rules
 outlined above. It is best to follow the same principles when using
 optionals in lambdas.
+
+Access with ``operator*()`` vs. ``value()``
+---
+
+Given that ``value()`` has well-defined program termination behavior, why treat
+it the same as ``operator*()`` which causes undefined behavior (UB)? That is,
+why is it considered unsafe to access an optional with ``value()``, if it's not
+provably populated with a value?  For that matter, why is ``CHECK()`` followed
+by ``operator*()`` any better than ``value()``, given that they are 
semantically
+equivalent (on configurations that disable exceptions)?
+
+The answer is that we assume most users do not realize the difference between
+``value()`` and ``operator*()``. Shifting to ``operator*()`` and some form of
+explicit value-presence check or explicit program termination has two
+advantages:
+
+  * Readability. The check, and any potential side effects like program
+shutdown, are very clear in the code. Separating access from checks can
+actually make the checks more obvious.
+
+  * Performance. A single check can cover many or even all accesses within
+scope. This gives the user the best of both worlds -- the safety of a
+dynamic check, but without incurring redundant costs.


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone/unchecked-optional-access.rst
@@ -8,16 +8,14 @@
 average clang-tidy check.
 
 This check identifies unsafe accesses to values contained in
-``std::optional``, ``absl::optional``, or ``base::std::optional``
-objects. Below we will refer to all these types collectively as
-``optional``.
+``std::optional``, ``absl::optional``, or ``base::Optional``
+objects. Below we will refer to all these types collectively as ``optional``.
 
-An access to the value of an ``optional`` occurs when one of its
-``value``, ``operator*``, or ``operator->`` member functions is invoked.
-To align with common misconceptions, the check considers these member
-functions as equivalent, even though there are subtle differences
-related to exceptions versus undefined behavior. See
-go/optional-style-recommendations for more information on that topic.
+An access to the value of an ``optional`` occurs when one of its ``value``,
+``operator*``, or ``operator->`` member functions is invoked.  To align with
+common misconceptions, the check considers these member functions as equivalent,
+even though 

[PATCH] D137527: [C++20] [Modules] [ClangScanDeps] Add ClangScanDeps support for C++20 Named Modules in P1689 format (2/4)

[Tom Weaver via Phabricator via cfe-commits]

TWeaver added a comment.

@thakis @ChuanqiXu I have a revision up for review here 
https://reviews.llvm.org/D143749 that adds back the UNSUPPORTED: system-windows 
that was reverted in https://reviews.llvm.org/D139168


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137527

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

[PATCH] D122215: [WebAssembly] Initial support for reference type externref in clang

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

@pmatos and I have tried and failed to reproduce the assert in the stage3 msan 
build locally (both of us on separate machines, different environments). We've 
reached out to @vitalybuka via email for any help in reproducing, because we're 
somewhat stumped at the moment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122215

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

[PATCH] D143509: Move the BySpelling map to IncludeStructure.

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

oh forgot to mention, could you also please add some tests into 
llvm-project/clang-tools-extra/clangd/unittests/HeadersTests.cpp ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143509

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

[PATCH] D143509: Move the BySpelling map to IncludeStructure.

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: clang-tools-extra/clangd/Headers.cpp:76
+Out->MainFileIncludesBySpelling.try_emplace(Inc.Written)
+.first->second.push_back(static_cast(*Inc.HeaderID));
   }

right now we're only storing "resolved" includes from the main file and not 
all, this is creating a discrepancy between the view one gets through 
`MainFileIncludes` and through this map.
in addition to that only storing `HeaderID` gets the job done for 
IncludeCleaner, but won't really help anyone that wants to match main file 
includes apart from that (there's no easy way to go from a `HeaderID` to an 
`Inclusion`).

so instead of storing the `HeaderID` in the map values, we can actually store 
indexes into `MainFileIncludes`. later on during the lookup, we can build a 
`SmallVector` that contains pointers to the relevant includes. 
WDYT?



Comment at: clang-tools-extra/clangd/Headers.h:166
+  llvm::SmallVector
+  lookupHeaderIDsBySpelling(llvm::StringRef Spelling) const {
+return MainFileIncludesBySpelling.lookup(Spelling);

what about renaming `lookupHeaderIDsBySpelling` to 
`mainFileIncludesWithSpelling`. with a comment explaining `Returns includes 
inside the main file with the given Spelling. Spelling should include brackets 
or quotes, e.g. `.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143509

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

[PATCH] D142101: [clang] [extract-api] Don't crash for category in libclang APIs

[Daniel Grumberg 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 rG7da2d644e039: [clang] [extract-api] Dont crash for 
category in libclang APIs (authored by dang).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142101

Files:
  clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
  clang/test/Index/extract-api-cursor.m

Index: clang/test/Index/extract-api-cursor.m
===
--- clang/test/Index/extract-api-cursor.m
+++ clang/test/Index/extract-api-cursor.m
@@ -25,6 +25,12 @@
 - (void)derivedMethodWithValue:(id)value;
 @end
 
+/// This won't show up in docs because we can't serialize it
+@interface Derived ()
+/// Derived method in category docs, won't show up either.
+- (void)derivedMethodInCategory;
+@end
+
 // RUN: c-index-test -single-symbol-sgfs local %s | FileCheck %s
 
 // Checking for Foo
@@ -53,7 +59,7 @@
 
 // Checking for baseProperty
 // CHECK-NEXT: "parentContexts":[{"kind":"objective-c.class","name":"Base","usr":"c:objc(cs)Base"}]
-// CHECK-SAME:"relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
+// CHECK-SAME: "relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
 // CHECK-SAME: "isSystem":false
 // CHECK-SAME: "usr":"c:@S@Foo"}]
 // CHECK-SAME: "relationships":[{"kind":"memberOf","source":"c:objc(cs)Base(py)baseProperty","target":"c:objc(cs)Base"
@@ -63,7 +69,7 @@
 
 // Checking for baseMethodWithArg
 // CHECK-NEXT: "parentContexts":[{"kind":"objective-c.class","name":"Base","usr":"c:objc(cs)Base"}]
-// CHECK-SAME:"relatedSymbols":[]
+// CHECK-SAME: "relatedSymbols":[]
 // CHECK-SAME: "relationships":[{"kind":"memberOf","source":"c:objc(cs)Base(im)baseMethodWithArg:","target":"c:objc(cs)Base"
 // CHECK-SAME: "text":"Base method docs"
 // CHECK-SAME: "kind":{"displayName":"Instance Method","identifier":"objective-c.method"}
@@ -79,7 +85,7 @@
 
 // Checking for protocolProperty
 // CHECK-NEXT: "parentContexts":[{"kind":"objective-c.protocol","name":"Protocol","usr":"c:objc(pl)Protocol"}]
-// CHECK-SAME:"relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
+// CHECK-SAME: "relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
 // CHECK-SAME: "isSystem":false
 // CHECK-SAME: "usr":"c:@S@Foo"}]
 // CHECK-SAME: "relationships":[{"kind":"memberOf","source":"c:objc(pl)Protocol(py)protocolProperty","target":"c:objc(pl)Protocol"
@@ -89,7 +95,7 @@
 
 // Checking for Derived
 // CHECK-NEXT: "parentContexts":[]
-// CHECK-SAME:"relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
+// CHECK-SAME: "relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
 // CHECK-SAME: "isSystem":false
 // CHECK-SAME: "usr":"c:objc(cs)Base"}]
 // CHECK-SAME: "relationships":[{"kind":"inheritsFrom","source":"c:objc(cs)Derived","target":"c:objc(cs)Base"
@@ -99,8 +105,11 @@
 
 // Checking for derivedMethodWithValue
 // CHECK-NEXT: "parentContexts":[{"kind":"objective-c.class","name":"Derived","usr":"c:objc(cs)Derived"}]
-// CHECK-SAME:"relatedSymbols":[]
+// CHECK-SAME: "relatedSymbols":[]
 // CHECK-SAME: "relationships":[{"kind":"memberOf","source":"c:objc(cs)Derived(im)derivedMethodWithValue:","target":"c:objc(cs)Derived"
 // CHECK-SAME: "text":"Derived method docs"
 // CHECK-SAME: "kind":{"displayName":"Instance Method","identifier":"objective-c.method"}
 // CHECK-SAME: "title":"derivedMethodWithValue:"
+
+// CHECK-NOT: This won't show up in docs because we can't serialize it
+// CHECK-NOT: Derived method in category docs, won't show up either.
Index: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
===
--- clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
+++ clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
@@ -487,6 +487,7 @@
   SmallVector ReverseComponenents;
   ReverseComponenents.emplace_back(Record.USR, Record.Name, Record.getKind());
   const auto *CurrentParent = 
+  bool FailedToFindParent = false;
   while (CurrentParent && !CurrentParent->empty()) {
 PathComponent CurrentParentComponent(CurrentParent->ParentUSR,
  CurrentParent->ParentName,
@@ -509,8 +510,10 @@
 
 // The parent record doesn't exist which means the symbol shouldn't be
 // treated as part of the current product.
-if (!ParentRecord)
-  return true;
+if (!ParentRecord) {
+  FailedToFindParent = true;
+  break;
+}
 
 ReverseComponenents.push_back(std::move(CurrentParentComponent));
 CurrentParent = >ParentInformation;
@@ -519,8 +522,9 @@
   for (const auto  : reverse(ReverseComponenents))
 ComponentTransformer(PC);
 
-  return false;
+  return FailedToFindParent;
 }
+
 Object 

[clang] 7da2d64 - [clang] [extract-api] Don't crash for category in libclang APIs

[Daniel Grumberg via cfe-commits]

Author: Daniel Grumberg
Date: 2023-02-10T16:30:19Z
New Revision: 7da2d644e0398be39e188ea6eacab2a942e0fa7e

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

LOG: [clang] [extract-api] Don't crash for category in libclang APIs

Remove failure conditions for categories in libclang and return empty
content instead.

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

Added: 


Modified: 
clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
clang/test/Index/extract-api-cursor.m

Removed: 




diff  --git a/clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp 
b/clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
index 01e9b37d26802..8beb01697bc2e 100644
--- a/clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
+++ b/clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
@@ -487,6 +487,7 @@ bool generatePathComponents(
   SmallVector ReverseComponenents;
   ReverseComponenents.emplace_back(Record.USR, Record.Name, Record.getKind());
   const auto *CurrentParent = 
+  bool FailedToFindParent = false;
   while (CurrentParent && !CurrentParent->empty()) {
 PathComponent CurrentParentComponent(CurrentParent->ParentUSR,
  CurrentParent->ParentName,
@@ -509,8 +510,10 @@ bool generatePathComponents(
 
 // The parent record doesn't exist which means the symbol shouldn't be
 // treated as part of the current product.
-if (!ParentRecord)
-  return true;
+if (!ParentRecord) {
+  FailedToFindParent = true;
+  break;
+}
 
 ReverseComponenents.push_back(std::move(CurrentParentComponent));
 CurrentParent = >ParentInformation;
@@ -519,8 +522,9 @@ bool generatePathComponents(
   for (const auto  : reverse(ReverseComponenents))
 ComponentTransformer(PC);
 
-  return false;
+  return FailedToFindParent;
 }
+
 Object serializeParentContext(const PathComponent , Language Lang) {
   Object ParentContextElem;
   ParentContextElem["usr"] = PC.USR;
@@ -533,12 +537,15 @@ template 
 Array generateParentContexts(const RecordTy , const APISet ,
  Language Lang) {
   Array ParentContexts;
-  if (generatePathComponents(
-  Record, API, [Lang, ](const PathComponent ) {
-ParentContexts.push_back(serializeParentContext(PC, Lang));
-  }))
-ParentContexts.clear();
-  ParentContexts.pop_back();
+  generatePathComponents(Record, API,
+ [Lang, ](const PathComponent ) {
+   ParentContexts.push_back(
+   serializeParentContext(PC, Lang));
+ });
+
+  // The last component would be the record itself so let's remove it.
+  if (!ParentContexts.empty())
+ParentContexts.pop_back();
 
   return ParentContexts;
 }
@@ -865,6 +872,9 @@ SymbolGraphSerializer::serializeSingleSymbolSGF(StringRef 
USR,
   if (!Record)
 return {};
 
+  if (isa(Record))
+return {};
+
   Object Root;
   APIIgnoresList EmptyIgnores;
   SymbolGraphSerializer Serializer(API, EmptyIgnores,

diff  --git a/clang/test/Index/extract-api-cursor.m 
b/clang/test/Index/extract-api-cursor.m
index a462c115826c1..078f2f52e215c 100644
--- a/clang/test/Index/extract-api-cursor.m
+++ b/clang/test/Index/extract-api-cursor.m
@@ -25,6 +25,12 @@ @interface Derived: Base
 - (void)derivedMethodWithValue:(id)value;
 @end
 
+/// This won't show up in docs because we can't serialize it
+@interface Derived ()
+/// Derived method in category docs, won't show up either.
+- (void)derivedMethodInCategory;
+@end
+
 // RUN: c-index-test -single-symbol-sgfs local %s | FileCheck %s
 
 // Checking for Foo
@@ -53,7 +59,7 @@ - (void)derivedMethodWithValue:(id)value;
 
 // Checking for baseProperty
 // CHECK-NEXT: 
"parentContexts":[{"kind":"objective-c.class","name":"Base","usr":"c:objc(cs)Base"}]
-// 
CHECK-SAME:"relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
+// CHECK-SAME: 
"relatedSymbols":[{"accessLevel":"public","declarationLanguage":"objective-c"
 // CHECK-SAME: "isSystem":false
 // CHECK-SAME: "usr":"c:@S@Foo"}]
 // CHECK-SAME: 
"relationships":[{"kind":"memberOf","source":"c:objc(cs)Base(py)baseProperty","target":"c:objc(cs)Base"
@@ -63,7 +69,7 @@ - (void)derivedMethodWithValue:(id)value;
 
 // Checking for baseMethodWithArg
 // CHECK-NEXT: 
"parentContexts":[{"kind":"objective-c.class","name":"Base","usr":"c:objc(cs)Base"}]
-// CHECK-SAME:"relatedSymbols":[]
+// CHECK-SAME: "relatedSymbols":[]
 // CHECK-SAME: 
"relationships":[{"kind":"memberOf","source":"c:objc(cs)Base(im)baseMethodWithArg:","target":"c:objc(cs)Base"
 // CHECK-SAME: "text":"Base method docs"
 // CHECK-SAME: "kind":{"displayName":"Instance 
Method","identifier":"objective-c.method"}
@@ 

[PATCH] D143745: Make section attribute and -ffunction-sections play nicely

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

This works in my simple test cases, but I'm not 100% sure it's (a) the best 
place to do this, or (b) the only place that needs to do this.
Really we should guarantee that `comdat any` wins over `comdat nodeduplicate` 
in all cases.


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

https://reviews.llvm.org/D143745

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

[PATCH] D143745: Make section attribute and -ffunction-sections play nicely

[Paul Robinson via Phabricator via cfe-commits]

probinson created this revision.
probinson added reviewers: rjmccall, MaskRay.
Herald added a project: All.
probinson requested review of this revision.

People use -ffunction-sections to put each function into its own
object-file section; this makes linker garbage-collection simpler.
However, if there's an explicit __attribute__((section("name"))
on the function, all functions with that attribute end up in a
single section, defeating the linker GC.

Use section groups to make these things work together.


https://reviews.llvm.org/D143745

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/section-attr-comdat.cpp


Index: clang/test/CodeGen/section-attr-comdat.cpp
===
--- /dev/null
+++ clang/test/CodeGen/section-attr-comdat.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -triple=x86_64-linux -emit-llvm  %s -o - | \
+// RUN: FileCheck %s --check-prefix=NOCOMDAT
+// RUN: %clang_cc1 -triple=x86_64-linux -emit-llvm -ffunction-sections %s -o - 
| \
+// RUN: FileCheck %s --check-prefix=COMDAT
+
+// template function = comdat always.
+template
+__attribute__((section("foo"))) T ftemplate(T a) { return a + 1; }
+__attribute__((section("foo"))) int fglobal(int a) { return ftemplate(a) + 2; }
+
+// NOCOMDAT-DAG: ${{.*}}ftemplate{{.*}} = comdat any
+// NOCOMDAT-DAG: define {{.*}}ftemplate{{.*}} section "foo" comdat {
+// NOCOMDAT-DAG: define {{.*}}fglobal{{.*}} section "foo" {
+
+// COMDAT-DAG: ${{.*}}ftemplate{{.*}} = comdat any
+// COMDAT-DAG: ${{.*}}fglobal{{.*}} = comdat nodeduplicate
+// COMDAT-DAG: define {{.*}}ftemplate{{.*}} section "foo" comdat {
+// COMDAT-DAG: define {{.*}}fglobal{{.*}} section "foo" comdat {
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -2293,6 +2293,18 @@
   if (auto *SA = D->getAttr())
 if (!D->getAttr())
   F->addFnAttr("implicit-section-name", SA->getName());
+  // If we have -ffunction-sections, and also an explicit section name,
+  // put the function into a section group so that various linker GC
+  // operations will still work with this function.
+  if (CodeGenOpts.FunctionSections && getTriple().supportsCOMDAT() &&
+  D->hasAttr()) {
+// Don't replace a real comdat.
+if (!F->getComdat()) {
+  llvm::Comdat *C = TheModule.getOrInsertComdat(F->getName());
+  C->setSelectionKind(llvm::Comdat::NoDeduplicate);
+  F->setComdat(C);
+}
+  }
 
   llvm::AttrBuilder Attrs(F->getContext());
   if (GetCPUAndFeaturesAttributes(GD, Attrs)) {


Index: clang/test/CodeGen/section-attr-comdat.cpp
===
--- /dev/null
+++ clang/test/CodeGen/section-attr-comdat.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -triple=x86_64-linux -emit-llvm  %s -o - | \
+// RUN: FileCheck %s --check-prefix=NOCOMDAT
+// RUN: %clang_cc1 -triple=x86_64-linux -emit-llvm -ffunction-sections %s -o - | \
+// RUN: FileCheck %s --check-prefix=COMDAT
+
+// template function = comdat always.
+template
+__attribute__((section("foo"))) T ftemplate(T a) { return a + 1; }
+__attribute__((section("foo"))) int fglobal(int a) { return ftemplate(a) + 2; }
+
+// NOCOMDAT-DAG: ${{.*}}ftemplate{{.*}} = comdat any
+// NOCOMDAT-DAG: define {{.*}}ftemplate{{.*}} section "foo" comdat {
+// NOCOMDAT-DAG: define {{.*}}fglobal{{.*}} section "foo" {
+
+// COMDAT-DAG: ${{.*}}ftemplate{{.*}} = comdat any
+// COMDAT-DAG: ${{.*}}fglobal{{.*}} = comdat nodeduplicate
+// COMDAT-DAG: define {{.*}}ftemplate{{.*}} section "foo" comdat {
+// COMDAT-DAG: define {{.*}}fglobal{{.*}} section "foo" comdat {
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -2293,6 +2293,18 @@
   if (auto *SA = D->getAttr())
 if (!D->getAttr())
   F->addFnAttr("implicit-section-name", SA->getName());
+  // If we have -ffunction-sections, and also an explicit section name,
+  // put the function into a section group so that various linker GC
+  // operations will still work with this function.
+  if (CodeGenOpts.FunctionSections && getTriple().supportsCOMDAT() &&
+  D->hasAttr()) {
+// Don't replace a real comdat.
+if (!F->getComdat()) {
+  llvm::Comdat *C = TheModule.getOrInsertComdat(F->getName());
+  C->setSelectionKind(llvm::Comdat::NoDeduplicate);
+  F->setComdat(C);
+}
+  }
 
   llvm::AttrBuilder Attrs(F->getContext());
   if (GetCPUAndFeaturesAttributes(GD, Attrs)) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143075: BareMetal ToolChain multilib layering

[Peter Smith via Phabricator via cfe-commits]

peter.smith added a comment.

No comments on the implementation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143075

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

[PATCH] D143587: [Docs] Multilib design

[Peter Smith via Phabricator via cfe-commits]

peter.smith added inline comments.



Comment at: clang/docs/Multilib.rst:125
+``-fno-exceptions`` multilib variant need only contain C++ libraries.
+
+Stability

Although implicit in the mechanism, is it worth highlighting that layered 
multib.yaml authors will need to make sure that the includes and the libraries 
in the layer need to be complete enough to mask any incompatibilities? 

For example if in the `-fno-exceptions` case there exists a library `libX.a` 
that is affected by `-fno-exceptions` but is present in the "Core directory" 
but not the layered no-exceptions directory then the exceptions libX.a will be 
selected.

/fp/libX.a (should have a noexcept variant in noexcept but multilib implementer 
gets it wrong!)
/fp/libY.a
/fp/lib/noexecpt/libY.a

execeptions is perhaps not the best example here as including a file with 
exceptions when the intention is `-fno-exceptions` is not optimal, but it will 
work. If there is layering for floating point calling conventions then a mix 
could result in a broken program.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143587

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