[PATCH] D119918: [CMake] Rename TARGET_TRIPLE to LLVM_TARGET_TRIPLE

[Fangrui Song via Phabricator via cfe-commits]

MaskRay accepted this revision.
MaskRay added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: JDevlieghere.

Looks great!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119918

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

[PATCH] D70401: [RISCV] Complete RV32E/ilp32e implementation

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

It's difficult to run llvm-test-suite in ilp32e abi in Linux. Because there are 
no workable environment such as runtime and kernel for ilp32e in GNU series 
tools.
And we can not run llvm-test-suite in baremental environment(NOT linux but elf 
triple). So I have a question about how to test llvm in elf triple and 
environment? Is there any test case llvm community normally uses and accepts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D119918: [CMake] Rename TARGET_TRIPLE to LLVM_TARGET_TRIPLE

[Petr Hosek via Phabricator via cfe-commits]

phosek created this revision.
phosek added reviewers: beanz, smeenai, ldionne, compnerd.
Herald added subscribers: ayermolo, sdasgup3, wenzhicui, wrengr, Chia-hungDuan, 
dcaballe, cota, teijeong, rdzhabarov, tatianashp, msifontes, jurahul, Kayjukh, 
grosul1, Joonsoo, liufengdb, aartbik, mgester, arpith-jacob, antiagainst, 
shauheen, rriddle, mehdi_amini, usaxena95, kadircet, arphaman, mgorny.
Herald added a reviewer: bollu.
Herald added a reviewer: rafauler.
Herald added a reviewer: Amir.
Herald added a reviewer: maksfb.
Herald added a project: Flang.
phosek requested review of this revision.
Herald added subscribers: cfe-commits, llvm-commits, lldb-commits, Sanitizers, 
yota9, stephenneuendorffer, nicolasvasilache, jdoerfert.
Herald added projects: clang, Sanitizers, LLDB, MLIR, LLVM, clang-tools-extra.

This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D119918

Files:
  bolt/test/Unit/lit.site.cfg.py.in
  bolt/test/lit.site.cfg.py.in
  clang-tools-extra/clangd/test/lit.site.cfg.py.in
  clang-tools-extra/test/Unit/lit.site.cfg.py.in
  clang-tools-extra/test/lit.site.cfg.py.in
  clang/cmake/caches/CrossWinToARMLinux.cmake
  clang/test/Unit/lit.site.cfg.py.in
  clang/test/lit.site.cfg.py.in
  clang/utils/perf-training/lit.site.cfg.in
  clang/utils/perf-training/order-files.lit.site.cfg.in
  compiler-rt/cmake/Modules/AddCompilerRT.cmake
  compiler-rt/cmake/Modules/CompilerRTMockLLVMCMakeConfig.cmake
  compiler-rt/cmake/Modules/CompilerRTUtils.cmake
  compiler-rt/lib/sanitizer_common/symbolizer/scripts/build_symbolizer.sh
  compiler-rt/test/fuzzer/lit.site.cfg.py.in
  compiler-rt/unittests/lit.common.unit.configured.in
  cross-project-tests/lit.site.cfg.py.in
  flang/test/NonGtestUnit/lit.site.cfg.py.in
  flang/test/Unit/lit.site.cfg.py.in
  lld/test/Unit/lit.site.cfg.py.in
  lld/test/lit.site.cfg.py.in
  lldb/test/API/lit.site.cfg.py.in
  lldb/test/CMakeLists.txt
  lldb/test/Shell/lit.site.cfg.py.in
  lldb/test/Unit/lit.site.cfg.py.in
  lldb/test/lit.site.cfg.py.in
  llvm/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/cmake/modules/CrossCompile.cmake
  llvm/cmake/modules/LLVMConfig.cmake.in
  llvm/runtimes/CMakeLists.txt
  llvm/test/lit.site.cfg.py.in
  llvm/utils/gn/secondary/clang-tools-extra/clangd/test/BUILD.gn
  llvm/utils/gn/secondary/clang-tools-extra/test/BUILD.gn
  llvm/utils/gn/secondary/clang/test/BUILD.gn
  llvm/utils/gn/secondary/lld/test/BUILD.gn
  llvm/utils/gn/secondary/lldb/test/BUILD.gn
  llvm/utils/gn/secondary/llvm/test/BUILD.gn
  mlir/examples/standalone/test/lit.site.cfg.py.in
  mlir/test/lit.site.cfg.py.in
  polly/test/Unit/lit.site.cfg.in
  polly/test/lit.site.cfg.in

Index: polly/test/lit.site.cfg.in
===
--- polly/test/lit.site.cfg.in
+++ polly/test/lit.site.cfg.in
@@ -6,7 +6,7 @@
 config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
 config.polly_obj_root = "@POLLY_BINARY_DIR@"
 config.polly_lib_dir = "@POLLY_LIB_DIR@"
-config.target_triple = "@TARGET_TRIPLE@"
+config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.enable_gpgpu_codegen = "@GPU_CODEGEN@"
 config.llvm_polly_link_into_tools = "@LLVM_POLLY_LINK_INTO_TOOLS@"
 config.targets_to_build = "@TARGETS_TO_BUILD@"
@@ -15,7 +15,7 @@
 ## Check the current platform with regex
 import re
 EAT_ERR_ON_X86 = ' '
-if (re.match(r'^x86_64*', '@TARGET_TRIPLE@') == None) :
+if (re.match(r'^x86_64*', '@LLVM_TARGET_TRIPLE@') == None) :
   EAT_ERR_ON_X86 = '|| echo \"error is eaten\"'
 
 for arch in config.targets_to_build.split():
Index: polly/test/Unit/lit.site.cfg.in
===
--- polly/test/Unit/lit.site.cfg.in
+++ polly/test/Unit/lit.site.cfg.in
@@ -11,7 +11,7 @@
 config.polly_lib_dir = "@POLLY_LIB_DIR@"
 config.enable_shared = @ENABLE_SHARED@
 config.shlibdir = "@SHLIBDIR@"
-config.target_triple = "@TARGET_TRIPLE@"
+config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.enable_gpgpu_codegen = "@GPU_CODEGEN@"
 config.llvm_polly_link_into_tools = "@LLVM_POLLY_LINK_INTO_TOOLS@"
 config.has_unittests = @POLLY_GTEST_AVAIL@
Index: mlir/test/lit.site.cfg.py.in
===
--- mlir/test/lit.site.cfg.py.in
+++ mlir/test/lit.site.cfg.py.in
@@ -3,7 +3,7 @@
 import sys
 
 config.host_triple = "@LLVM_HOST_TRIPLE@"
-config.target_triple = "@TARGET_TRIPLE@"
+config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
Index: mlir/examples/standalone/test/lit.site.cfg.py.in
===
--- mlir/examples/standalone/test/lit.site.cfg.py.in
+++ mlir/examples/standalone/test/lit.site.cfg.py.in
@@ -3,7 +3,7 @@
 import sys
 
 config.host_triple = "@LLVM_HOST_TRIPLE@"
-config.target_triple = 

[PATCH] D70401: [RISCV] Complete RV32E/ilp32e implementation

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu commandeered this revision.
zixuan-wu added a reviewer: pcwang-thead.
zixuan-wu added a comment.

In D70401#3250049 , @khchen wrote:

> 2. Have you try to run llvm-test-suite with rv32e config on qemu?

It's difficult to run llvm-test-suite in ilp32e abi in Linux. Because there are 
no workable environment such as runtime and kernel for ilp32e in GNU series 
tools.
And we can not run llvm-test-suite in baremental environment(NOT linux but elf 
triple). So I have a question about how to test llvm in elf triple and 
environment? Is there any test case llvm community normally uses and accepts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D119893: [clang-format] Fixed handling of requires clauses followed by attributes

[Marek Kurdej via Phabricator via cfe-commits]

curdeius added a comment.

+1 to Arthur's comments.
Does it fix any of the recently created issues?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119893

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

[PATCH] D119711: Add asan support for MSVC debug runtimes

[Petr Mikhalitsyn via Phabricator via cfe-commits]

lo1ol added a comment.

Ok, I get current situation.

Sorry for my late answer. I made some investigation yesterday and compared msvc 
and clang versions of asan. In my tests msvc version seems more stable.

All my tests is written via catch2 framework (v2.13.8). So, first example is:

  #define CATCH_CONFIG_MAIN
  
  #include 
  
  #include 
  
  TEST_CASE( "kek" ) {
  for (int i=0; i < 10; ++i) {
  printf("lol ke\n");
  free(malloc(4472));
  }
  
  }

If compiles it via msvc version of asan, everything is ok:

  # copy  MSVC\14.29.30133\lib\x64 to Llvm\x64\lib\clang\12.0.0\lib\windows 
before
  $ clang-cl kek.cpp -I ..\Catch2\single_include /MT -fsanitize=address
  $ kek.exe
  lol ke
  lol ke
  lol ke
  lol ke
  lol ke
  lol ke
  lol ke
  lol ke
  lol ke
  lol ke
  
===
  test cases: 1 | 1 passed
  assertions: - none -

But version for clang's toolchain has strange behavior:

  # With original content of Llvm\x64\lib\clang\12.0.0\lib\windows
  $ clang-cl kek.cpp -I ..\Catch2\single_include /MT -fsanitize=address
  $ kek.exe
  lol ke
  lol ke
  lol ke
  lol ke
  lol ke
  
  
~~~
  
  
~~~
  
  
~~~
  
  
~~~
  
  
~~~
  ...

Nevertheless, I found some bug which presents inside both versions

  #define CATCH_CONFIG_MAIN
  
  #include 
  
  #include 
  #include 
  
  TEST_CASE( "kek" ) {
  auto result = std::async(std::launch::async, []() {
  std::cerr << "kek " << std::endl;
  });
  
  result.get();
  }

The output is same for both versions:

  $ clang-cl kek.cpp -I ..\Catch2\single_include /MT -fsanitize=address
  $ kek.exe
  
  
~~~
  
  
~~~
  
  
~~~
  
  
~~~
  ...

I don't have a time to discover a root of problem. But msvc's version of asan 
seems to me more stable and compatible with clang's asan. So, may be there is 
point to distribute same version of asan for both toolchains.

If you want, I may create an issue for founded bugs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119711

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

[PATCH] D119409: [C++20] [Modules] Remain variable's definition in module interface

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added inline comments.



Comment at: clang/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp:5
 // CHECK-DAG: @extern_var_exported = external {{(dso_local )?}}global
-// CHECK-DAG: @inline_var_exported = linkonce_odr {{(dso_local )?}}global
+// CHECK-DAG: @inline_var_exported = available_externally {{(dso_local 
)?}}global
 // CHECK-DAG: @const_var_exported = available_externally {{(dso_local 
)?}}constant i32 3,

dblaikie wrote:
> ChuanqiXu wrote:
> > ChuanqiXu wrote:
> > > urnathan wrote:
> > > > ChuanqiXu wrote:
> > > > > urnathan wrote:
> > > > > > ChuanqiXu wrote:
> > > > > > > urnathan wrote:
> > > > > > > > I don;t think this is correct.  That should still be a linkonce 
> > > > > > > > odr, otherwise you'll get conflicts with other module 
> > > > > > > > implementation units.
> > > > > > > It is still linkonce_odr in the module it get defined. See the 
> > > > > > > new added test case: inline-variable-in-module.cpp for example. 
> > > > > > > The attribute `available_externally` is equivalent to external 
> > > > > > > from the perspective of linker. See 
> > > > > > > https://llvm.org/docs/LangRef.html#linkage-types. According to 
> > > > > > > [dcl.inline]p7, inline variable attached to named module should 
> > > > > > > be defined in that domain. Note that the variable attached to 
> > > > > > > global module fragment and private module fragment shouldn't be 
> > > > > > > accessed outside the module, so it implies that all the variable 
> > > > > > > defined in the module could only be defined in the module unit 
> > > > > > > itself.
> > > > > > There's a couple of issues with this.  module.cppm is emitting a 
> > > > > > (linkonce) definition of inlne_var_exported, but only because it 
> > > > > > itself is ODR-using that variable.  If you take out the ODR-use in 
> > > > > > noninline_exported, there is no longer a symbol emitted.
> > > > > > 
> > > > > > But, even if you forced inline vars to be emitted in their 
> > > > > > defining-module's interface unit, that would be an ABI change.  
> > > > > > inline vars are emitted whereever ODR-used.  They have no fixed 
> > > > > > home TU.  Now, we could alter the ABI and allow interface units to 
> > > > > > define a home location for inline vars and similar entities (eg, 
> > > > > > vtables for keyless classes).  But we'd need buy-in from other 
> > > > > > compilers to do that.
> > > > > > 
> > > > > > FWIW such a discussion did come up early in implementing 
> > > > > > modules-ts, but we decided there was enough going on just getting 
> > > > > > the TS implemented.  I'm fine with revisiting that, but it is a 
> > > > > > more significant change.
> > > > > > 
> > > > > > And it wouldn't apply to (eg) templated variables, which of course 
> > > > > > could be instantiated anywhere.
> > > > > Oh, now the key point here is what the correct behavior is instead of 
> > > > > the patch. Let's discuss it first.
> > > > > 
> > > > > According to [[ http://eel.is/c++draft/dcl.inline#7 | [dcl.inline]p7 
> > > > > ]], 
> > > > > > If an inline function or variable that is attached to a named 
> > > > > > module is declared in a definition domain, it shall be defined in 
> > > > > > that domain.
> > > > > 
> > > > > I think the intention of the sentence is to define inline variable in 
> > > > > the module interface. So if it is required by the standard, I think 
> > > > > other compiler need to follow up. As I described in the summary, it 
> > > > > might be a difference between C++20 module and ModuleTS. Do you think 
> > > > > it is necessary to send the question to WG21? (I get the behavior 
> > > > > from reading the words. Maybe I misread or the word is not 
> > > > > intentional).
> > > > > 
> > > > > Maybe the ABI standard group need to discuss what the linkage should 
> > > > > be. Now it may be weak_odr or linkonce_odr. It depends on how we 
> > > > > compile the file. If we compile the .cppm file directly, it would be 
> > > > > linkonce_odr. And if we compile it to *.pcm file first, it would be 
> > > > > weak_odr. I have registered an issue for this: 
> > > > > https://github.com/llvm/llvm-project/issues/53838.
> > > > > Oh, now the key point here is what the correct behavior is instead of 
> > > > > the patch. Let's discuss it first.
> > > > > 
> > > > > According to [[ http://eel.is/c++draft/dcl.inline#7 | [dcl.inline]p7 
> > > > > ]], 
> > > > > > If an inline function or variable that is attached to a named 
> > > > > > module is declared in a definition domain, it shall be defined in 
> > > > > > that domain.
> > > > > 
> > > > > I think the intention of the sentence is to define inline variable in 
> > > > > the module interface. So if it is required by the standard, I think 
> > > > > other compiler need to follow up. As I described in the summary, it 
> > > > > might be a difference between C++20 module and ModuleTS. Do you think 
> > > > > it is necessary to send the question to 

[PATCH] D119409: [C++20] [Modules] Remain variable's definition in module interface

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: clang/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp:5
 // CHECK-DAG: @extern_var_exported = external {{(dso_local )?}}global
-// CHECK-DAG: @inline_var_exported = linkonce_odr {{(dso_local )?}}global
+// CHECK-DAG: @inline_var_exported = available_externally {{(dso_local 
)?}}global
 // CHECK-DAG: @const_var_exported = available_externally {{(dso_local 
)?}}constant i32 3,

ChuanqiXu wrote:
> ChuanqiXu wrote:
> > urnathan wrote:
> > > ChuanqiXu wrote:
> > > > urnathan wrote:
> > > > > ChuanqiXu wrote:
> > > > > > urnathan wrote:
> > > > > > > I don;t think this is correct.  That should still be a linkonce 
> > > > > > > odr, otherwise you'll get conflicts with other module 
> > > > > > > implementation units.
> > > > > > It is still linkonce_odr in the module it get defined. See the new 
> > > > > > added test case: inline-variable-in-module.cpp for example. The 
> > > > > > attribute `available_externally` is equivalent to external from the 
> > > > > > perspective of linker. See 
> > > > > > https://llvm.org/docs/LangRef.html#linkage-types. According to 
> > > > > > [dcl.inline]p7, inline variable attached to named module should be 
> > > > > > defined in that domain. Note that the variable attached to global 
> > > > > > module fragment and private module fragment shouldn't be accessed 
> > > > > > outside the module, so it implies that all the variable defined in 
> > > > > > the module could only be defined in the module unit itself.
> > > > > There's a couple of issues with this.  module.cppm is emitting a 
> > > > > (linkonce) definition of inlne_var_exported, but only because it 
> > > > > itself is ODR-using that variable.  If you take out the ODR-use in 
> > > > > noninline_exported, there is no longer a symbol emitted.
> > > > > 
> > > > > But, even if you forced inline vars to be emitted in their 
> > > > > defining-module's interface unit, that would be an ABI change.  
> > > > > inline vars are emitted whereever ODR-used.  They have no fixed home 
> > > > > TU.  Now, we could alter the ABI and allow interface units to define 
> > > > > a home location for inline vars and similar entities (eg, vtables for 
> > > > > keyless classes).  But we'd need buy-in from other compilers to do 
> > > > > that.
> > > > > 
> > > > > FWIW such a discussion did come up early in implementing modules-ts, 
> > > > > but we decided there was enough going on just getting the TS 
> > > > > implemented.  I'm fine with revisiting that, but it is a more 
> > > > > significant change.
> > > > > 
> > > > > And it wouldn't apply to (eg) templated variables, which of course 
> > > > > could be instantiated anywhere.
> > > > Oh, now the key point here is what the correct behavior is instead of 
> > > > the patch. Let's discuss it first.
> > > > 
> > > > According to [[ http://eel.is/c++draft/dcl.inline#7 | [dcl.inline]p7 
> > > > ]], 
> > > > > If an inline function or variable that is attached to a named module 
> > > > > is declared in a definition domain, it shall be defined in that 
> > > > > domain.
> > > > 
> > > > I think the intention of the sentence is to define inline variable in 
> > > > the module interface. So if it is required by the standard, I think 
> > > > other compiler need to follow up. As I described in the summary, it 
> > > > might be a difference between C++20 module and ModuleTS. Do you think 
> > > > it is necessary to send the question to WG21? (I get the behavior from 
> > > > reading the words. Maybe I misread or the word is not intentional).
> > > > 
> > > > Maybe the ABI standard group need to discuss what the linkage should 
> > > > be. Now it may be weak_odr or linkonce_odr. It depends on how we 
> > > > compile the file. If we compile the .cppm file directly, it would be 
> > > > linkonce_odr. And if we compile it to *.pcm file first, it would be 
> > > > weak_odr. I have registered an issue for this: 
> > > > https://github.com/llvm/llvm-project/issues/53838.
> > > > Oh, now the key point here is what the correct behavior is instead of 
> > > > the patch. Let's discuss it first.
> > > > 
> > > > According to [[ http://eel.is/c++draft/dcl.inline#7 | [dcl.inline]p7 
> > > > ]], 
> > > > > If an inline function or variable that is attached to a named module 
> > > > > is declared in a definition domain, it shall be defined in that 
> > > > > domain.
> > > > 
> > > > I think the intention of the sentence is to define inline variable in 
> > > > the module interface. So if it is required by the standard, I think 
> > > > other compiler need to follow up. As I described in the summary, it 
> > > > might be a difference between C++20 module and ModuleTS. Do you think 
> > > > it is necessary to send the question to WG21? (I get the behavior from 
> > > > reading the words. Maybe I misread or the word is not intentional).
> > > 
> > > You are reading more into the std than it says.  The std specifies what 
> 

[PATCH] D118034: [C++20] [Modules] Don't complain about duplicated default template argument across modules

[Chuanqi Xu via Phabricator via cfe-commits]

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

Address comment to check if the duplicated default template arguments are the 
same and add tests to address the negative cases.


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

https://reviews.llvm.org/D118034

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/Modules/Inputs/redundant-template-default-arg/foo.cppm
  clang/test/Modules/Inputs/redundant-template-default-arg/foo.h
  clang/test/Modules/Inputs/redundant-template-default-arg2/foo.cppm
  clang/test/Modules/Inputs/redundant-template-default-arg3/foo.cppm
  clang/test/Modules/Inputs/redundant-template-default-arg3/foo.h
  clang/test/Modules/Inputs/redundant-template-default-arg3/foo_bad.h
  clang/test/Modules/redundant-template-default-arg.cpp
  clang/test/Modules/redundant-template-default-arg2.cpp
  clang/test/Modules/redundant-template-default-arg3.cpp

Index: clang/test/Modules/redundant-template-default-arg3.cpp
===
--- /dev/null
+++ clang/test/Modules/redundant-template-default-arg3.cpp
@@ -0,0 +1,24 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: %clang_cc1  -std=c++20 %S/Inputs/redundant-template-default-arg3/foo.cppm -I%S/Inputs/redundant-template-default-arg3/. -emit-module-interface -o %t/foo.pcm
+// RUN: %clang_cc1  -fprebuilt-module-path=%t -std=c++20 %s -I%S/Inputs/redundant-template-default-arg3/. -fsyntax-only -verify
+
+import foo;
+#include "foo_bad.h"
+
+// expected-error@Inputs/redundant-template-default-arg3/foo_bad.h:1 {{template parameter default argument is inconsistent with previous definition}}
+// expected-note@Inputs/redundant-template-default-arg3/foo.h:1 {{previous default template argument defined in module foo.}}
+// expected-error@Inputs/redundant-template-default-arg3/foo_bad.h:4 {{template parameter default argument is inconsistent with previous definition}}
+// expected-note@Inputs/redundant-template-default-arg3/foo.h:4 {{previous default template argument defined in module foo.}}
+// expected-error@Inputs/redundant-template-default-arg3/foo_bad.h:10 {{template parameter default argument is inconsistent with previous definition}}
+// expected-note@Inputs/redundant-template-default-arg3/foo.h:10 {{previous default template argument defined in module foo.}}
+// expected-error@Inputs/redundant-template-default-arg3/foo_bad.h:17 {{template parameter default argument is inconsistent with previous definition}}
+// expected-note@Inputs/redundant-template-default-arg3/foo.h:13 {{previous default template argument defined in module foo.}}
+// expected-error@Inputs/redundant-template-default-arg3/foo_bad.h:23 {{template parameter default argument is inconsistent with previous definition}}
+// expected-note@Inputs/redundant-template-default-arg3/foo.h:16 {{previous default template argument defined in module foo.}}
+// expected-error@Inputs/redundant-template-default-arg3/foo_bad.h:27 {{template parameter default argument is inconsistent with previous definition}}
+// expected-note@Inputs/redundant-template-default-arg3/foo.h:20 {{previous default template argument defined in module foo.}}
+// expected-error@Inputs/redundant-template-default-arg3/foo_bad.h:31 {{template parameter default argument is inconsistent with previous definition}}
+// expected-note@Inputs/redundant-template-default-arg3/foo.h:24 {{previous default template argument defined in module foo.}}
+// expected-error@Inputs/redundant-template-default-arg3/foo_bad.h:34 {{template parameter default argument is inconsistent with previous definition}}
+// expected-note@Inputs/redundant-template-default-arg3/foo.h:27 {{previous default template argument defined in module foo.}}
Index: clang/test/Modules/redundant-template-default-arg2.cpp
===
--- /dev/null
+++ clang/test/Modules/redundant-template-default-arg2.cpp
@@ -0,0 +1,20 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: %clang_cc1  -std=c++20 %S/Inputs/redundant-template-default-arg2/foo.cppm -I%S/Inputs/redundant-template-default-arg2/. -emit-module-interface -o %t/foo.pcm
+// RUN: %clang_cc1  -fprebuilt-module-path=%t -std=c++20 %s -fsyntax-only -verify
+import foo;
+template 
+T v; // expected-error {{declaration of 'v' in the global module follows declaration in module foo}}
+ // expected-note@Inputs/redundant-template-default-arg2/foo.cppm:3 {{previous declaration is here}}
+
+template 
+int v2; // expected-error {{declaration of 'v2' in the global module follows declaration in module foo}}
+// expected-note@Inputs/redundant-template-default-arg2/foo.cppm:6 {{previous declaration is here}}
+
+template 
+class my_array {}; // expected-error {{redefinition of 'my_array'}}
+   // expected-note@Inputs/redundant-template-default-arg2/foo.cppm:9 {{previous definition is here}}
+
+template  typename C = 

[PATCH] D119686: [RISCV] Add the passthru operand for nomask vadc/vsbc/vmerge/vfmerge IR intrinsics.

[Zakk Chen via Phabricator via cfe-commits]

khchen updated this revision to Diff 409156.
khchen added a comment.

rebase and add more one test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119686

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vadc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmerge.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmerge.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vsbc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vadc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmerge.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmerge.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vsbc.c
  llvm/include/llvm/IR/IntrinsicsRISCV.td
  llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td
  llvm/test/CodeGen/RISCV/rvv/unmasked-tu.ll
  llvm/test/CodeGen/RISCV/rvv/vadc-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vadc-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfmerge.ll
  llvm/test/CodeGen/RISCV/rvv/vmerge-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vmerge-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vsbc-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vsbc-rv64.ll

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

[PATCH] D118253: [RISCV] Add the passthru operand for some RVV nomask unary and nullary intrinsics.

[Zakk Chen 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 rGe8973dd389e7: [RISCV] Add the passthru operand for some RVV 
nomask unary and nullary… (authored by khchen).

Changed prior to commit:
  https://reviews.llvm.org/D118253?vs=403269=409155#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118253

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfclass.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfcvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfncvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrec7.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrsqrt7.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfsqrt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwcvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vsext.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vzext.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfclass.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfcvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfncvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfrec7.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfrsqrt7.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfsqrt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwcvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vid.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/viota.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vsext.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vzext.c
  llvm/include/llvm/IR/IntrinsicsRISCV.td
  llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td
  llvm/test/CodeGen/RISCV/rvv/unmasked-tu.ll
  llvm/test/CodeGen/RISCV/rvv/vfclass.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-f-x.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-f-xu.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-rtz-x-f.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-rtz-xu-f.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-x-f.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-xu-f.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-f.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-x.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-xu.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rod-f-f.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rtz-x-f.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rtz-xu-f.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-x-f.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-xu-f.ll
  llvm/test/CodeGen/RISCV/rvv/vfrec7.ll
  llvm/test/CodeGen/RISCV/rvv/vfrsqrt7.ll
  llvm/test/CodeGen/RISCV/rvv/vfsqrt.ll
  llvm/test/CodeGen/RISCV/rvv/vfwcvt-f-f.ll
  llvm/test/CodeGen/RISCV/rvv/vfwcvt-f-x.ll
  llvm/test/CodeGen/RISCV/rvv/vfwcvt-f-xu.ll
  llvm/test/CodeGen/RISCV/rvv/vfwcvt-rtz-x-f.ll
  llvm/test/CodeGen/RISCV/rvv/vfwcvt-rtz-xu-f.ll
  llvm/test/CodeGen/RISCV/rvv/vfwcvt-x-f.ll
  llvm/test/CodeGen/RISCV/rvv/vfwcvt-xu-f.ll
  llvm/test/CodeGen/RISCV/rvv/vid.ll
  llvm/test/CodeGen/RISCV/rvv/viota.ll
  llvm/test/CodeGen/RISCV/rvv/vsetvli-insert-crossbb.mir
  llvm/test/CodeGen/RISCV/rvv/vsetvli-insert.mir
  llvm/test/CodeGen/RISCV/rvv/vsext-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vsext-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vzext-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vzext-rv64.ll

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

[PATCH] D119846: [NFC][MC] remove unused argument `MCRegisterInfo` in `MCCodeEmitter`

[Shao-Ce SUN via Phabricator via cfe-commits]

achieveartificialintelligence added a comment.

In D119846#3325334 , @skan wrote:

> @achieveartificialintelligence  Please explain why a patch is reverted in the 
> commit message next time.

OK, thanks for your guidance!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119846

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

[PATCH] D119846: [NFC][MC] remove unused argument `MCRegisterInfo` in `MCCodeEmitter`

[Kan Shengchen via Phabricator via cfe-commits]

skan added a comment.

@achieveartificialintelligence  Please explain why a patch is reverted in the 
commit message next time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119846

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

[PATCH] D119409: [C++20] [Modules] Remain variable's definition in module interface

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added inline comments.



Comment at: clang/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp:5
 // CHECK-DAG: @extern_var_exported = external {{(dso_local )?}}global
-// CHECK-DAG: @inline_var_exported = linkonce_odr {{(dso_local )?}}global
+// CHECK-DAG: @inline_var_exported = available_externally {{(dso_local 
)?}}global
 // CHECK-DAG: @const_var_exported = available_externally {{(dso_local 
)?}}constant i32 3,

ChuanqiXu wrote:
> urnathan wrote:
> > ChuanqiXu wrote:
> > > urnathan wrote:
> > > > ChuanqiXu wrote:
> > > > > urnathan wrote:
> > > > > > I don;t think this is correct.  That should still be a linkonce 
> > > > > > odr, otherwise you'll get conflicts with other module 
> > > > > > implementation units.
> > > > > It is still linkonce_odr in the module it get defined. See the new 
> > > > > added test case: inline-variable-in-module.cpp for example. The 
> > > > > attribute `available_externally` is equivalent to external from the 
> > > > > perspective of linker. See 
> > > > > https://llvm.org/docs/LangRef.html#linkage-types. According to 
> > > > > [dcl.inline]p7, inline variable attached to named module should be 
> > > > > defined in that domain. Note that the variable attached to global 
> > > > > module fragment and private module fragment shouldn't be accessed 
> > > > > outside the module, so it implies that all the variable defined in 
> > > > > the module could only be defined in the module unit itself.
> > > > There's a couple of issues with this.  module.cppm is emitting a 
> > > > (linkonce) definition of inlne_var_exported, but only because it itself 
> > > > is ODR-using that variable.  If you take out the ODR-use in 
> > > > noninline_exported, there is no longer a symbol emitted.
> > > > 
> > > > But, even if you forced inline vars to be emitted in their 
> > > > defining-module's interface unit, that would be an ABI change.  inline 
> > > > vars are emitted whereever ODR-used.  They have no fixed home TU.  Now, 
> > > > we could alter the ABI and allow interface units to define a home 
> > > > location for inline vars and similar entities (eg, vtables for keyless 
> > > > classes).  But we'd need buy-in from other compilers to do that.
> > > > 
> > > > FWIW such a discussion did come up early in implementing modules-ts, 
> > > > but we decided there was enough going on just getting the TS 
> > > > implemented.  I'm fine with revisiting that, but it is a more 
> > > > significant change.
> > > > 
> > > > And it wouldn't apply to (eg) templated variables, which of course 
> > > > could be instantiated anywhere.
> > > Oh, now the key point here is what the correct behavior is instead of the 
> > > patch. Let's discuss it first.
> > > 
> > > According to [[ http://eel.is/c++draft/dcl.inline#7 | [dcl.inline]p7 ]], 
> > > > If an inline function or variable that is attached to a named module is 
> > > > declared in a definition domain, it shall be defined in that domain.
> > > 
> > > I think the intention of the sentence is to define inline variable in the 
> > > module interface. So if it is required by the standard, I think other 
> > > compiler need to follow up. As I described in the summary, it might be a 
> > > difference between C++20 module and ModuleTS. Do you think it is 
> > > necessary to send the question to WG21? (I get the behavior from reading 
> > > the words. Maybe I misread or the word is not intentional).
> > > 
> > > Maybe the ABI standard group need to discuss what the linkage should be. 
> > > Now it may be weak_odr or linkonce_odr. It depends on how we compile the 
> > > file. If we compile the .cppm file directly, it would be linkonce_odr. 
> > > And if we compile it to *.pcm file first, it would be weak_odr. I have 
> > > registered an issue for this: 
> > > https://github.com/llvm/llvm-project/issues/53838.
> > > Oh, now the key point here is what the correct behavior is instead of the 
> > > patch. Let's discuss it first.
> > > 
> > > According to [[ http://eel.is/c++draft/dcl.inline#7 | [dcl.inline]p7 ]], 
> > > > If an inline function or variable that is attached to a named module is 
> > > > declared in a definition domain, it shall be defined in that domain.
> > > 
> > > I think the intention of the sentence is to define inline variable in the 
> > > module interface. So if it is required by the standard, I think other 
> > > compiler need to follow up. As I described in the summary, it might be a 
> > > difference between C++20 module and ModuleTS. Do you think it is 
> > > necessary to send the question to WG21? (I get the behavior from reading 
> > > the words. Maybe I misread or the word is not intentional).
> > 
> > You are reading more into the std than it says.  The std specifies what 
> > /source code/ is meaningful.  It says nothing about how a computation 
> > system might represent the program in another form.  Most of the latter, 
> > for ahead-of-time translation, is at the discretion of 

[PATCH] D119409: [C++20] [Modules] Remain variable's definition in module interface

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added inline comments.



Comment at: clang/test/CXX/modules-ts/basic/basic.def.odr/p4/module.cpp:5
 // CHECK-DAG: @extern_var_exported = external {{(dso_local )?}}global
-// CHECK-DAG: @inline_var_exported = linkonce_odr {{(dso_local )?}}global
+// CHECK-DAG: @inline_var_exported = available_externally {{(dso_local 
)?}}global
 // CHECK-DAG: @const_var_exported = available_externally {{(dso_local 
)?}}constant i32 3,

urnathan wrote:
> ChuanqiXu wrote:
> > urnathan wrote:
> > > ChuanqiXu wrote:
> > > > urnathan wrote:
> > > > > I don;t think this is correct.  That should still be a linkonce odr, 
> > > > > otherwise you'll get conflicts with other module implementation units.
> > > > It is still linkonce_odr in the module it get defined. See the new 
> > > > added test case: inline-variable-in-module.cpp for example. The 
> > > > attribute `available_externally` is equivalent to external from the 
> > > > perspective of linker. See 
> > > > https://llvm.org/docs/LangRef.html#linkage-types. According to 
> > > > [dcl.inline]p7, inline variable attached to named module should be 
> > > > defined in that domain. Note that the variable attached to global 
> > > > module fragment and private module fragment shouldn't be accessed 
> > > > outside the module, so it implies that all the variable defined in the 
> > > > module could only be defined in the module unit itself.
> > > There's a couple of issues with this.  module.cppm is emitting a 
> > > (linkonce) definition of inlne_var_exported, but only because it itself 
> > > is ODR-using that variable.  If you take out the ODR-use in 
> > > noninline_exported, there is no longer a symbol emitted.
> > > 
> > > But, even if you forced inline vars to be emitted in their 
> > > defining-module's interface unit, that would be an ABI change.  inline 
> > > vars are emitted whereever ODR-used.  They have no fixed home TU.  Now, 
> > > we could alter the ABI and allow interface units to define a home 
> > > location for inline vars and similar entities (eg, vtables for keyless 
> > > classes).  But we'd need buy-in from other compilers to do that.
> > > 
> > > FWIW such a discussion did come up early in implementing modules-ts, but 
> > > we decided there was enough going on just getting the TS implemented.  
> > > I'm fine with revisiting that, but it is a more significant change.
> > > 
> > > And it wouldn't apply to (eg) templated variables, which of course could 
> > > be instantiated anywhere.
> > Oh, now the key point here is what the correct behavior is instead of the 
> > patch. Let's discuss it first.
> > 
> > According to [[ http://eel.is/c++draft/dcl.inline#7 | [dcl.inline]p7 ]], 
> > > If an inline function or variable that is attached to a named module is 
> > > declared in a definition domain, it shall be defined in that domain.
> > 
> > I think the intention of the sentence is to define inline variable in the 
> > module interface. So if it is required by the standard, I think other 
> > compiler need to follow up. As I described in the summary, it might be a 
> > difference between C++20 module and ModuleTS. Do you think it is necessary 
> > to send the question to WG21? (I get the behavior from reading the words. 
> > Maybe I misread or the word is not intentional).
> > 
> > Maybe the ABI standard group need to discuss what the linkage should be. 
> > Now it may be weak_odr or linkonce_odr. It depends on how we compile the 
> > file. If we compile the .cppm file directly, it would be linkonce_odr. And 
> > if we compile it to *.pcm file first, it would be weak_odr. I have 
> > registered an issue for this: 
> > https://github.com/llvm/llvm-project/issues/53838.
> > Oh, now the key point here is what the correct behavior is instead of the 
> > patch. Let's discuss it first.
> > 
> > According to [[ http://eel.is/c++draft/dcl.inline#7 | [dcl.inline]p7 ]], 
> > > If an inline function or variable that is attached to a named module is 
> > > declared in a definition domain, it shall be defined in that domain.
> > 
> > I think the intention of the sentence is to define inline variable in the 
> > module interface. So if it is required by the standard, I think other 
> > compiler need to follow up. As I described in the summary, it might be a 
> > difference between C++20 module and ModuleTS. Do you think it is necessary 
> > to send the question to WG21? (I get the behavior from reading the words. 
> > Maybe I misread or the word is not intentional).
> 
> You are reading more into the std than it says.  The std specifies what 
> /source code/ is meaningful.  It says nothing about how a computation system 
> might represent the program in another form.  Most of the latter, for 
> ahead-of-time translation, is at the discretion of compiler implementors.  
> Part of that is the domain of the ABI, which specifies an interface to which 
> different compilers may target, and then have compatibility at the 
> object-file 

[PATCH] D117087: [C++20] [Coroutines] Implement return value optimization for get_return_object

[Chuanqi Xu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd30ca5e2e23f: [C++20] [Coroutines] Implement return value 
optimization for get_return_object (authored by ChuanqiXu).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117087

Files:
  clang/include/clang/AST/StmtCXX.h
  clang/lib/AST/StmtCXX.cpp
  clang/lib/CodeGen/CGCoroutine.cpp
  clang/lib/Sema/SemaCoroutine.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CodeGenCoroutines/coro-alloc-exp-namespace.cpp
  clang/test/CodeGenCoroutines/coro-alloc.cpp
  clang/test/CodeGenCoroutines/coro-gro-exp-namespace.cpp
  clang/test/CodeGenCoroutines/coro-gro-nrvo-exp-namespace.cpp
  clang/test/CodeGenCoroutines/coro-gro-nrvo.cpp
  clang/test/CodeGenCoroutines/coro-gro.cpp
  clang/test/CodeGenCoroutines/coro-gro2-exp-namespace.cpp
  clang/test/CodeGenCoroutines/coro-gro2.cpp
  clang/test/CodeGenCoroutines/coro-promise-dtor-exp-namespace.cpp
  clang/test/CodeGenCoroutines/coro-promise-dtor.cpp
  clang/test/SemaCXX/coroutine-no-move-ctor.cpp
  clang/test/SemaCXX/coroutines-exp-namespace.cpp
  clang/test/SemaCXX/coroutines.cpp

Index: clang/test/SemaCXX/coroutines.cpp
===
--- clang/test/SemaCXX/coroutines.cpp
+++ clang/test/SemaCXX/coroutines.cpp
@@ -929,7 +929,7 @@
 
 extern "C" int f(mismatch_gro_type_tag2) {
   // cxx2b-error@-1 {{cannot initialize return object of type 'int' with an rvalue of type 'void *'}}
-  // cxx14_20-error@-2 {{cannot initialize return object of type 'int' with an lvalue of type 'void *'}}
+  // cxx14_20-error@-2 {{cannot initialize return object of type 'int' with an rvalue of type 'void *'}}
   co_return; //expected-note {{function is a coroutine due to use of 'co_return' here}}
 }
 
Index: clang/test/SemaCXX/coroutines-exp-namespace.cpp
===
--- clang/test/SemaCXX/coroutines-exp-namespace.cpp
+++ clang/test/SemaCXX/coroutines-exp-namespace.cpp
@@ -939,7 +939,7 @@
 
 extern "C" int f(mismatch_gro_type_tag2) {
   // cxx2b-error@-1 {{cannot initialize return object of type 'int' with an rvalue of type 'void *'}}
-  // cxx14_20-error@-2 {{cannot initialize return object of type 'int' with an lvalue of type 'void *'}}
+  // cxx14_20-error@-2 {{cannot initialize return object of type 'int' with an rvalue of type 'void *'}}
   co_return; //expected-note {{function is a coroutine due to use of 'co_return' here}}
 }
 
Index: clang/test/SemaCXX/coroutine-no-move-ctor.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/coroutine-no-move-ctor.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -triple x86_64-apple-darwin9 %s -std=c++20 -fsyntax-only -verify
+// expected-no-diagnostics
+
+#include "Inputs/std-coroutine.h"
+
+class invoker {
+public:
+  class invoker_promise {
+  public:
+invoker get_return_object() { return invoker{}; }
+auto initial_suspend() { return std::suspend_never{}; }
+auto final_suspend() noexcept { return std::suspend_never{}; }
+void return_void() {}
+void unhandled_exception() {}
+  };
+  using promise_type = invoker_promise;
+  invoker() {}
+  invoker(const invoker &) = delete;
+  invoker =(const invoker &) = delete;
+  invoker(invoker &&) = delete;
+  invoker =(invoker &&) = delete;
+};
+
+invoker f() {
+  co_return;
+}
Index: clang/test/CodeGenCoroutines/coro-promise-dtor.cpp
===
--- clang/test/CodeGenCoroutines/coro-promise-dtor.cpp
+++ clang/test/CodeGenCoroutines/coro-promise-dtor.cpp
@@ -27,19 +27,8 @@
 }
 
 // CHECK-LABEL: define dso_local void @"?f@@YA?AUcoro_t@@XZ"(
-// CHECK:  %gro.active = alloca i1
-// CHECK:  store i1 false, i1* %gro.active
 
 // CHECK:  invoke noundef %"struct.coro_t::promise_type"* @"??0promise_type@coro_t@@QEAA@XZ"(
 // CHECK:  invoke void @"?get_return_object@promise_type@coro_t@@QEAA?AU2@XZ"(
-// CHECK:  store i1 true, i1* %gro.active
 
-// CHECK:  %[[IS_ACTIVE:.+]] = load i1, i1* %gro.active
-// CHECK:  br i1 %[[IS_ACTIVE]], label %[[CLEANUP1:.+]], label
-
-// CHECK: [[CLEANUP1]]:
-// CHECK:  %[[NRVO:.+]] = load i1, i1* %nrvo
-// CHECK:  br i1 %[[NRVO]], label %{{.+}}, label %[[DTOR:.+]]
-
-// CHECK: [[DTOR]]:
-// CHECK:  call void @"??1coro_t@@QEAA@XZ"(
+// CHECK:  call void @"??1promise_type@coro_t@@QEAA@XZ"
Index: clang/test/CodeGenCoroutines/coro-promise-dtor-exp-namespace.cpp
===
--- clang/test/CodeGenCoroutines/coro-promise-dtor-exp-namespace.cpp
+++ clang/test/CodeGenCoroutines/coro-promise-dtor-exp-namespace.cpp
@@ -31,19 +31,8 @@
 }
 
 // CHECK-LABEL: define dso_local void @"?f@@YA?AUcoro_t@@XZ"(
-// CHECK:  %gro.active = alloca i1
-// CHECK:  store i1 false, i1* %gro.active
 
 // CHECK:  invoke noundef %"struct.coro_t::promise_type"* 

[clang] d30ca5e - [C++20] [Coroutines] Implement return value optimization for get_return_object

[Chuanqi Xu via cfe-commits]

Author: Chuanqi Xu
Date: 2022-02-16T13:38:00+08:00
New Revision: d30ca5e2e23fe50dcd8d5d602bf7cfc61b4c1561

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

LOG: [C++20] [Coroutines] Implement return value optimization for 
get_return_object

This patch tries to implement RVO for coroutine's return object got from
get_return_object.
>From [dcl.fct.def.coroutine]/p7 we could know that the return value of
get_return_object is either a reference or a prvalue. So it makes sense
to do copy elision for the return value. The return object should be
constructed directly into the storage where they would otherwise be
copied/moved to.

Test Plan: folly, check-all

Reviewed By: junparser

Differential revision: https://reviews.llvm.org/D117087

Added: 
clang/test/CodeGenCoroutines/coro-gro2-exp-namespace.cpp
clang/test/CodeGenCoroutines/coro-gro2.cpp
clang/test/SemaCXX/coroutine-no-move-ctor.cpp

Modified: 
clang/include/clang/AST/StmtCXX.h
clang/lib/AST/StmtCXX.cpp
clang/lib/CodeGen/CGCoroutine.cpp
clang/lib/Sema/SemaCoroutine.cpp
clang/lib/Sema/TreeTransform.h
clang/test/CodeGenCoroutines/coro-alloc-exp-namespace.cpp
clang/test/CodeGenCoroutines/coro-alloc.cpp
clang/test/CodeGenCoroutines/coro-gro-exp-namespace.cpp
clang/test/CodeGenCoroutines/coro-gro.cpp
clang/test/CodeGenCoroutines/coro-promise-dtor-exp-namespace.cpp
clang/test/CodeGenCoroutines/coro-promise-dtor.cpp
clang/test/SemaCXX/coroutines-exp-namespace.cpp
clang/test/SemaCXX/coroutines.cpp

Removed: 
clang/test/CodeGenCoroutines/coro-gro-nrvo-exp-namespace.cpp
clang/test/CodeGenCoroutines/coro-gro-nrvo.cpp



diff  --git a/clang/include/clang/AST/StmtCXX.h 
b/clang/include/clang/AST/StmtCXX.h
index 4d1f3e8ef255c..5ccf6904048e3 100644
--- a/clang/include/clang/AST/StmtCXX.h
+++ b/clang/include/clang/AST/StmtCXX.h
@@ -327,7 +327,6 @@ class CoroutineBodyStmt final
 Allocate,  ///< Coroutine frame memory allocation.
 Deallocate,///< Coroutine frame memory deallocation.
 ReturnValue,   ///< Return value for thunk function: p.get_return_object().
-ResultDecl,///< Declaration holding the result of get_return_object.
 ReturnStmt,///< Return statement for the thunk function.
 ReturnStmtOnAllocFailure, ///< Return statement if allocation failed.
 FirstParamMove ///< First offset for move construction of parameter copies.
@@ -354,7 +353,6 @@ class CoroutineBodyStmt final
 Expr *Allocate = nullptr;
 Expr *Deallocate = nullptr;
 Expr *ReturnValue = nullptr;
-Stmt *ResultDecl = nullptr;
 Stmt *ReturnStmt = nullptr;
 Stmt *ReturnStmtOnAllocFailure = nullptr;
 ArrayRef ParamMoves;
@@ -409,7 +407,11 @@ class CoroutineBodyStmt final
   Expr *getReturnValueInit() const {
 return cast(getStoredStmts()[SubStmt::ReturnValue]);
   }
-  Stmt *getResultDecl() const { return getStoredStmts()[SubStmt::ResultDecl]; }
+  Expr *getReturnValue() const {
+assert(getReturnStmt());
+auto *RS = cast(getReturnStmt());
+return RS->getRetValue();
+  }
   Stmt *getReturnStmt() const { return getStoredStmts()[SubStmt::ReturnStmt]; }
   Stmt *getReturnStmtOnAllocFailure() const {
 return getStoredStmts()[SubStmt::ReturnStmtOnAllocFailure];

diff  --git a/clang/lib/AST/StmtCXX.cpp b/clang/lib/AST/StmtCXX.cpp
index 060d090fc06ac..33b0421ad1016 100644
--- a/clang/lib/AST/StmtCXX.cpp
+++ b/clang/lib/AST/StmtCXX.cpp
@@ -118,7 +118,6 @@ 
CoroutineBodyStmt::CoroutineBodyStmt(CoroutineBodyStmt::CtorArgs const )
   SubStmts[CoroutineBodyStmt::Allocate] = Args.Allocate;
   SubStmts[CoroutineBodyStmt::Deallocate] = Args.Deallocate;
   SubStmts[CoroutineBodyStmt::ReturnValue] = Args.ReturnValue;
-  SubStmts[CoroutineBodyStmt::ResultDecl] = Args.ResultDecl;
   SubStmts[CoroutineBodyStmt::ReturnStmt] = Args.ReturnStmt;
   SubStmts[CoroutineBodyStmt::ReturnStmtOnAllocFailure] =
   Args.ReturnStmtOnAllocFailure;

diff  --git a/clang/lib/CodeGen/CGCoroutine.cpp 
b/clang/lib/CodeGen/CGCoroutine.cpp
index c1763cbbc5a05..96696ebf2903c 100644
--- a/clang/lib/CodeGen/CGCoroutine.cpp
+++ b/clang/lib/CodeGen/CGCoroutine.cpp
@@ -465,72 +465,6 @@ struct CallCoroDelete final : public EHScopeStack::Cleanup 
{
 };
 }
 
-namespace {
-struct GetReturnObjectManager {
-  CodeGenFunction 
-  CGBuilderTy 
-  const CoroutineBodyStmt 
-
-  Address GroActiveFlag;
-  CodeGenFunction::AutoVarEmission GroEmission;
-
-  GetReturnObjectManager(CodeGenFunction , const CoroutineBodyStmt )
-  : CGF(CGF), Builder(CGF.Builder), S(S), 
GroActiveFlag(Address::invalid()),
-GroEmission(CodeGenFunction::AutoVarEmission::invalid()) {}
-
-  // The gro variable has to outlive coroutine frame and coroutine promise, 
but,
-  // it can only be initialized 

[clang] 9cc49c1 - Revert "[NFC][MC] remove unused argument `MCRegisterInfo` in `MCCodeEmitter`"

[Shao-Ce SUN via cfe-commits]

Author: Shao-Ce SUN
Date: 2022-02-16T11:57:49+08:00
New Revision: 9cc49c1951dcc4db594bf1f90755e16f89efd1ca

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

LOG: Revert "[NFC][MC] remove unused argument `MCRegisterInfo` in 
`MCCodeEmitter`"

This reverts commit fe25c06cc5bdc2ef9427309f8ec1434aad69dc7a.

Added: 


Modified: 
bolt/include/bolt/Core/BinaryContext.h
bolt/lib/Core/BinaryContext.cpp
clang/tools/driver/cc1as_main.cpp
llvm/include/llvm/MC/TargetRegistry.h
llvm/lib/CodeGen/LLVMTargetMachine.cpp
llvm/lib/DWARFLinker/DWARFStreamer.cpp
llvm/lib/Target/Lanai/MCTargetDesc/LanaiMCCodeEmitter.cpp
llvm/lib/Target/RISCV/MCTargetDesc/RISCVMCCodeEmitter.cpp
llvm/lib/Target/RISCV/MCTargetDesc/RISCVMCTargetDesc.h
llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp
llvm/lib/Target/X86/MCTargetDesc/X86MCTargetDesc.h
llvm/lib/Target/X86/X86AsmPrinter.cpp
llvm/tools/llvm-dwp/llvm-dwp.cpp
llvm/tools/llvm-exegesis/lib/LlvmState.cpp
llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp
llvm/tools/llvm-mc/llvm-mc.cpp
llvm/tools/llvm-mca/llvm-mca.cpp
llvm/tools/llvm-ml/llvm-ml.cpp
llvm/unittests/DebugInfo/DWARF/DWARFExpressionCopyBytesTest.cpp
llvm/unittests/DebugInfo/DWARF/DwarfGenerator.cpp
llvm/unittests/MC/DwarfLineTableHeaders.cpp
mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp

Removed: 




diff  --git a/bolt/include/bolt/Core/BinaryContext.h 
b/bolt/include/bolt/Core/BinaryContext.h
index aff770112be1c..c626af3a897d6 100644
--- a/bolt/include/bolt/Core/BinaryContext.h
+++ b/bolt/include/bolt/Core/BinaryContext.h
@@ -1192,14 +1192,14 @@ class BinaryContext {
   /*PIC=*/!HasFixedLoadAddress));
 MCEInstance.LocalCtx->setObjectFileInfo(MCEInstance.LocalMOFI.get());
 MCEInstance.MCE.reset(
-TheTarget->createMCCodeEmitter(*MII, *MCEInstance.LocalCtx));
+TheTarget->createMCCodeEmitter(*MII, *MRI, *MCEInstance.LocalCtx));
 return MCEInstance;
   }
 
   /// Creating MCStreamer instance.
   std::unique_ptr
   createStreamer(llvm::raw_pwrite_stream ) const {
-MCCodeEmitter *MCE = TheTarget->createMCCodeEmitter(*MII, *Ctx);
+MCCodeEmitter *MCE = TheTarget->createMCCodeEmitter(*MII, *MRI, *Ctx);
 MCAsmBackend *MAB =
 TheTarget->createMCAsmBackend(*STI, *MRI, MCTargetOptions());
 std::unique_ptr OW = MAB->createObjectWriter(OS);

diff  --git a/bolt/lib/Core/BinaryContext.cpp b/bolt/lib/Core/BinaryContext.cpp
index 36745580217ed..a197e59719adc 100644
--- a/bolt/lib/Core/BinaryContext.cpp
+++ b/bolt/lib/Core/BinaryContext.cpp
@@ -223,7 +223,7 @@ BinaryContext::createBinaryContext(const ObjectFile *File, 
bool IsPIC,
   InstructionPrinter->setPrintImmHex(true);
 
   std::unique_ptr MCE(
-  TheTarget->createMCCodeEmitter(*MII, *Ctx));
+  TheTarget->createMCCodeEmitter(*MII, *MRI, *Ctx));
 
   // Make sure we don't miss any output on core dumps.
   outs().SetUnbuffered();

diff  --git a/clang/tools/driver/cc1as_main.cpp 
b/clang/tools/driver/cc1as_main.cpp
index 26b4eb27a290a..6459d1534b39e 100644
--- a/clang/tools/driver/cc1as_main.cpp
+++ b/clang/tools/driver/cc1as_main.cpp
@@ -455,7 +455,7 @@ static bool ExecuteAssemblerImpl(AssemblerInvocation ,
 
 std::unique_ptr CE;
 if (Opts.ShowEncoding)
-  CE.reset(TheTarget->createMCCodeEmitter(*MCII, Ctx));
+  CE.reset(TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx));
 std::unique_ptr MAB(
 TheTarget->createMCAsmBackend(*STI, *MRI, MCOptions));
 
@@ -475,7 +475,7 @@ static bool ExecuteAssemblerImpl(AssemblerInvocation ,
 }
 
 std::unique_ptr CE(
-TheTarget->createMCCodeEmitter(*MCII, Ctx));
+TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx));
 std::unique_ptr MAB(
 TheTarget->createMCAsmBackend(*STI, *MRI, MCOptions));
 assert(MAB && "Unable to create asm backend!");

diff  --git a/llvm/include/llvm/MC/TargetRegistry.h 
b/llvm/include/llvm/MC/TargetRegistry.h
index 954f7d69b033d..6f6804aef30c1 100644
--- a/llvm/include/llvm/MC/TargetRegistry.h
+++ b/llvm/include/llvm/MC/TargetRegistry.h
@@ -175,6 +175,7 @@ class Target {
  const MCInstrInfo ,
  const MCRegisterInfo );
   using MCCodeEmitterCtorTy = MCCodeEmitter *(*)(const MCInstrInfo ,
+ const MCRegisterInfo ,
  MCContext );
   using ELFStreamerCtorTy =
   MCStreamer *(*)(const Triple , MCContext ,
@@ -505,10 +506,11 @@ class Target {
 
   /// createMCCodeEmitter - Create a target specific code emitter.
   MCCodeEmitter *createMCCodeEmitter(const 

[PATCH] D119846: [NFC][MC] remove unused argument `MCRegisterInfo` in `MCCodeEmitter`

[Shao-Ce SUN 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 rGfe25c06cc5bd: [NFC][MC] remove unused argument 
`MCRegisterInfo` in `MCCodeEmitter` (authored by achieveartificialintelligence).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119846

Files:
  bolt/include/bolt/Core/BinaryContext.h
  bolt/lib/Core/BinaryContext.cpp
  clang/tools/driver/cc1as_main.cpp
  llvm/include/llvm/MC/TargetRegistry.h
  llvm/lib/CodeGen/LLVMTargetMachine.cpp
  llvm/lib/DWARFLinker/DWARFStreamer.cpp
  llvm/lib/Target/Lanai/MCTargetDesc/LanaiMCCodeEmitter.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVMCCodeEmitter.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVMCTargetDesc.h
  llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp
  llvm/lib/Target/X86/MCTargetDesc/X86MCTargetDesc.h
  llvm/lib/Target/X86/X86AsmPrinter.cpp
  llvm/tools/llvm-dwp/llvm-dwp.cpp
  llvm/tools/llvm-exegesis/lib/LlvmState.cpp
  llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp
  llvm/tools/llvm-mc/llvm-mc.cpp
  llvm/tools/llvm-mca/llvm-mca.cpp
  llvm/tools/llvm-ml/llvm-ml.cpp
  llvm/unittests/DebugInfo/DWARF/DWARFExpressionCopyBytesTest.cpp
  llvm/unittests/DebugInfo/DWARF/DwarfGenerator.cpp
  llvm/unittests/MC/DwarfLineTableHeaders.cpp
  mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp

Index: mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp
===
--- mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp
+++ mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp
@@ -377,7 +377,7 @@
   std::unique_ptr mcStreamer;
   std::unique_ptr mcii(target->createMCInstrInfo());
 
-  llvm::MCCodeEmitter *ce = target->createMCCodeEmitter(*mcii, *mri, ctx);
+  llvm::MCCodeEmitter *ce = target->createMCCodeEmitter(*mcii, ctx);
   llvm::MCAsmBackend *mab = target->createMCAsmBackend(*sti, *mri, mcOptions);
   mcStreamer.reset(target->createMCObjectStreamer(
   triple, ctx, std::unique_ptr(mab),
Index: llvm/unittests/MC/DwarfLineTableHeaders.cpp
===
--- llvm/unittests/MC/DwarfLineTableHeaders.cpp
+++ llvm/unittests/MC/DwarfLineTableHeaders.cpp
@@ -77,8 +77,7 @@
 Res.Ctx->setObjectFileInfo(Res.MOFI.get());
 
 Res.MII.reset(TheTarget->createMCInstrInfo());
-MCCodeEmitter *MCE =
-TheTarget->createMCCodeEmitter(*Res.MII, *MRI, *Res.Ctx);
+MCCodeEmitter *MCE = TheTarget->createMCCodeEmitter(*Res.MII, *Res.Ctx);
 MCAsmBackend *MAB =
 TheTarget->createMCAsmBackend(*STI, *MRI, MCTargetOptions());
 std::unique_ptr OW = MAB->createObjectWriter(OS);
Index: llvm/unittests/DebugInfo/DWARF/DwarfGenerator.cpp
===
--- llvm/unittests/DebugInfo/DWARF/DwarfGenerator.cpp
+++ llvm/unittests/DebugInfo/DWARF/DwarfGenerator.cpp
@@ -464,7 +464,7 @@
   TLOF->Initialize(*MC, *TM);
   MC->setObjectFileInfo(TLOF);
 
-  MCE = TheTarget->createMCCodeEmitter(*MII, *MRI, *MC);
+  MCE = TheTarget->createMCCodeEmitter(*MII, *MC);
   if (!MCE)
 return make_error("no code emitter for target " + TripleName,
inconvertibleErrorCode());
Index: llvm/unittests/DebugInfo/DWARF/DWARFExpressionCopyBytesTest.cpp
===
--- llvm/unittests/DebugInfo/DWARF/DWARFExpressionCopyBytesTest.cpp
+++ llvm/unittests/DebugInfo/DWARF/DWARFExpressionCopyBytesTest.cpp
@@ -106,7 +106,7 @@
   Res.Ctx->setObjectFileInfo(Res.MOFI.get());
 
   Res.MII.reset(TheTarget->createMCInstrInfo());
-  MCCodeEmitter *MCE = TheTarget->createMCCodeEmitter(*Res.MII, *MRI, *Res.Ctx);
+  MCCodeEmitter *MCE = TheTarget->createMCCodeEmitter(*Res.MII, *Res.Ctx);
   MCAsmBackend *MAB =
   TheTarget->createMCAsmBackend(*STI, *MRI, MCTargetOptions());
   std::unique_ptr OW = MAB->createObjectWriter(OS);
Index: llvm/tools/llvm-ml/llvm-ml.cpp
===
--- llvm/tools/llvm-ml/llvm-ml.cpp
+++ llvm/tools/llvm-ml/llvm-ml.cpp
@@ -377,7 +377,7 @@
 // Set up the AsmStreamer.
 std::unique_ptr CE;
 if (InputArgs.hasArg(OPT_show_encoding))
-  CE.reset(TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx));
+  CE.reset(TheTarget->createMCCodeEmitter(*MCII, Ctx));
 
 std::unique_ptr MAB(
 TheTarget->createMCAsmBackend(*STI, *MRI, MCOptions));
@@ -395,7 +395,7 @@
   OS = BOS.get();
 }
 
-MCCodeEmitter *CE = TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx);
+MCCodeEmitter *CE = TheTarget->createMCCodeEmitter(*MCII, Ctx);
 MCAsmBackend *MAB = TheTarget->createMCAsmBackend(*STI, *MRI, MCOptions);
 Str.reset(TheTarget->createMCObjectStreamer(
 TheTriple, Ctx, std::unique_ptr(MAB),
Index: llvm/tools/llvm-mca/llvm-mca.cpp

[clang] 5d110ed - Revert "[NFC] Update new warning to test"

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2022-02-15T22:23:26-05:00
New Revision: 5d110ed4cd475b9b70bc9faecfe4f0767740c5a3

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

LOG: Revert "[NFC] Update new warning  to test"

This reverts commit 25cdf87b13eb990eb84d31211280f4b0d5d470b3.
125abb61f7ae reverted the patch.

It is incorrect to update this file when a flagless warning is added.
This test exists to make sure _all_ warnings are behind a flag.
The right fix is to put the new warning in a warning group (so that
it can be toggled with a flag), not to update the list here.

Added: 


Modified: 
clang/test/Misc/warning-flags.c

Removed: 




diff  --git a/clang/test/Misc/warning-flags.c b/clang/test/Misc/warning-flags.c
index 1b65af4c8e3e5..a9e0a784c5c81 100644
--- a/clang/test/Misc/warning-flags.c
+++ b/clang/test/Misc/warning-flags.c
@@ -18,7 +18,7 @@ This test serves two purposes:
 
 The list of warnings below should NEVER grow.  It should gradually shrink to 0.
 
-CHECK: Warnings without flags (68):
+CHECK: Warnings without flags (67):
 
 CHECK-NEXT:   ext_expected_semi_decl_list
 CHECK-NEXT:   ext_explicit_specialization_storage_class
@@ -65,7 +65,6 @@ CHECK-NEXT:   warn_missing_dependent_template_keyword
 CHECK-NEXT:   warn_missing_whitespace_after_macro_name
 CHECK-NEXT:   warn_mt_message
 CHECK-NEXT:   warn_no_constructor_for_refconst
-CHECK-NEXT:   warn_no_support_for_eval_method_source_on_m32
 CHECK-NEXT:   warn_not_compound_assign
 CHECK-NEXT:   warn_objc_property_copy_missing_on_block
 CHECK-NEXT:   warn_objc_protocol_qualifier_missing_id



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

[PATCH] D118586: [C++20][Modules] Initial handling for module partitions.

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

Oh, I did similar thing in our downstream version. I planned to show it in next 
few weeks. Now it looks I could only give up on it...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118586

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

[PATCH] D119846: [NFC][MC] remove unused argument `MCRegisterInfo` in `MCCodeEmitter`

[Kan Shengchen via Phabricator via cfe-commits]

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

`MCRegisterInfo` is not used b/c it can be got from `MCContext`. It makes sense 
to remove it in the parameters.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119846

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

[clang] 125abb6 - Revert "Add support for floating-point option `ffp-eval-method` and for"

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2022-02-15T22:02:25-05:00
New Revision: 125abb61f7ae52f9dbf4b82d5f90b70ef107fb62

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

LOG: Revert "Add support for floating-point option `ffp-eval-method` and for"

This reverts commit 4bafe65c2b2f1ce745894a509a6d80c87fb1c335.
Breaks at least Misc/warning-flags.c, see comments on
https://reviews.llvm.org/D109239

Added: 


Modified: 
clang/docs/LanguageExtensions.rst
clang/docs/UsersManual.rst
clang/include/clang/Basic/DiagnosticCommonKinds.td
clang/include/clang/Basic/DiagnosticLexKinds.td
clang/include/clang/Basic/FPOptions.def
clang/include/clang/Basic/LangOptions.def
clang/include/clang/Basic/LangOptions.h
clang/include/clang/Basic/TargetInfo.h
clang/include/clang/Driver/Options.td
clang/include/clang/Lex/Preprocessor.h
clang/include/clang/Parse/Parser.h
clang/include/clang/Sema/Sema.h
clang/lib/Basic/Targets/OSTargets.h
clang/lib/Basic/Targets/X86.h
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Frontend/InitPreprocessor.cpp
clang/lib/Lex/PPMacroExpansion.cpp
clang/lib/Parse/ParsePragma.cpp
clang/lib/Parse/ParseStmt.cpp
clang/lib/Sema/Sema.cpp
clang/lib/Sema/SemaAttr.cpp
clang/lib/Sema/SemaExpr.cpp
clang/test/CodeGen/fp-floatcontrol-pragma.cpp
clang/test/Preprocessor/init-aarch64.c
clang/test/Preprocessor/init-arm.c
clang/test/Preprocessor/init-mips.c
clang/test/Preprocessor/init-ppc.c
clang/test/Preprocessor/init-ppc64.c
clang/test/Preprocessor/init-s390x.c
clang/test/Preprocessor/init-v7k-compat.c
clang/test/Preprocessor/init-x86.c
clang/test/Preprocessor/init.c

Removed: 
clang/test/CodeGen/X86/32bit-behavior-no-eval.c
clang/test/CodeGen/X86/32bit-behavior.c
clang/test/CodeGen/X86/fp-eval-method.c
clang/test/CodeGen/flt_eval_macro.cpp
clang/test/Preprocessor/flt_eval_macro.cpp
clang/test/Sema/fp-eval-pragma.cpp
clang/test/Sema/x86-eval-method.c
clang/test/Sema/x86_64-eval-method.c



diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 5249d3f3f7930..f45d88092eb4a 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -3907,38 +3907,6 @@ A ``#pragma clang fp`` pragma may contain any number of 
options:
 ...
   }
 
-``#pragma clang fp eval_method`` allows floating-point behavior to be specified
-for a section of the source code. This pragma can appear at file or namespace
-scope, or at the start of a compound statement (excluding comments).
-The pragma is active within the scope of the compound statement.
-
-When ``pragma clang fp eval_method(source)`` is enabled, the section of code
-governed by the pragma behaves as though the command-line option
-``-ffp-eval-method=source`` is enabled. Rounds intermediate results to
-source-defined precision.
-
-When ``pragma clang fp eval_method(double)`` is enabled, the section of code
-governed by the pragma behaves as though the command-line option
-``-ffp-eval-method=double`` is enabled. Rounds intermediate results to
-``double`` precision.
-
-When ``pragma clang fp eval_method(extended)`` is enabled, the section of code
-governed by the pragma behaves as though the command-line option
-``-ffp-eval-method=extended`` is enabled. Rounds intermediate results to
-target-dependent ``long double`` precision. In Win32 programming, for instance,
-the long double data type maps to the double, 64-bit precision data type.
-
-The full syntax this pragma supports is
-``#pragma clang fp eval_method(source|double|extended)``.
-
-.. code-block:: c++
-
-  for(...) {
-// The compiler will use long double as the floating-point evaluation
-// method.
-#pragma clang fp eval_method(extended)
-a = b[i] * c[i] + e;
-  }
 
 The ``#pragma float_control`` pragma allows precise floating-point
 semantics and floating-point exception behavior to be specified

diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index 70fee29ab2a84..1df96296cb8ac 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1566,22 +1566,6 @@ Note that floating-point operations performed as part of 
constant initialization
* ``maytrap`` The compiler avoids transformations that may raise exceptions 
that would not have been raised by the original code. Constant folding 
performed by the compiler is exempt from this option.
* ``strict`` The compiler ensures that all transformations strictly 
preserve the floating point exception semantics of the original code.
 
-.. option:: -ffp-eval-method=
-
-   Specify the floating-point evaluation method for intermediate results within
-   a single expression of the code.
-
-   Valid values 

[PATCH] D112094: Add support for floating-point option `ffp-eval-method` and for `pragma clang fp eval_method`.

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.
Herald added a subscriber: pcwang-thead.

It looks this landed without being approved: 
https://github.com/llvm/llvm-project/commit/4bafe65c2b2f1ce745894a509a6d80c87fb1c335.

It broke the test. If we need to revert it, we need to revert 
https://github.com/llvm/llvm-project/commit/25cdf87b13eb990eb84d31211280f4b0d5d470b3
 too.


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

https://reviews.llvm.org/D112094

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

[PATCH] D119727: [RISCV] Add the policy operand for nomask vector Multiply-Add IR intrinsics.

[Monk Chiang via Phabricator via cfe-commits]

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

LGTM, Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119727

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

[clang] 25cdf87 - [NFC] Update new warning to test

[Chuanqi Xu via cfe-commits]

Author: Chuanqi Xu
Date: 2022-02-16T10:51:56+08:00
New Revision: 25cdf87b13eb990eb84d31211280f4b0d5d470b3

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

LOG: [NFC] Update new warning  to test

This tries to fix the broke test introduced in
4bafe65c2b2f1ce745894a509a6.

Added: 


Modified: 
clang/test/Misc/warning-flags.c

Removed: 




diff  --git a/clang/test/Misc/warning-flags.c b/clang/test/Misc/warning-flags.c
index a9e0a784c5c81..1b65af4c8e3e5 100644
--- a/clang/test/Misc/warning-flags.c
+++ b/clang/test/Misc/warning-flags.c
@@ -18,7 +18,7 @@ This test serves two purposes:
 
 The list of warnings below should NEVER grow.  It should gradually shrink to 0.
 
-CHECK: Warnings without flags (67):
+CHECK: Warnings without flags (68):
 
 CHECK-NEXT:   ext_expected_semi_decl_list
 CHECK-NEXT:   ext_explicit_specialization_storage_class
@@ -65,6 +65,7 @@ CHECK-NEXT:   warn_missing_dependent_template_keyword
 CHECK-NEXT:   warn_missing_whitespace_after_macro_name
 CHECK-NEXT:   warn_mt_message
 CHECK-NEXT:   warn_no_constructor_for_refconst
+CHECK-NEXT:   warn_no_support_for_eval_method_source_on_m32
 CHECK-NEXT:   warn_not_compound_assign
 CHECK-NEXT:   warn_objc_property_copy_missing_on_block
 CHECK-NEXT:   warn_objc_protocol_qualifier_missing_id



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

[PATCH] D118893: [C++20][Modules] Track valid import state.

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

BTW, I guess it would be helpful to add the index in the series in the title. 
Like `[C++20][Modules] Track valid import state (1/8)`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118893

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

[PATCH] D118893: [C++20][Modules] Track valid import state.

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1543
+def err_import_not_allowed_here : Error<
+  "imports must be contiguous and immediately follow the module declaration">;
+def err_import_in_global_fragment : Error<

urnathan wrote:
> iains wrote:
> > urnathan wrote:
> > > "imports must immediately follow a module declaration"?  (the contiguous 
> > > isn't adding anything IMHO)
> > um, maybe I need two diagnostics then - the "contiguous" aspect applies 
> > when imports are split by a non-import statement.
> > 
> > Selecting between the two case on the basis of a flag seems unproductive 
> > here.  Would two diagnostics seem more reasonable to you?
> > 
> I don't follow.  If the imports are split by a non-import, then the latter 
> ones don't immediately follow the module declaration.
The imports could exist in non-module unit. A example could be found at: 
http://eel.is/c++draft/basic.lookup.general#example-1. So the wording might not 
be accurate. I think we could refer to the wording in the standard [[ 
http://eel.is/c++draft/module.import#1 | [module.import]p1 ]]:

> In a module unit, all module-import-declarations and export-declarations 
> exporting module-import-declarations shall appear before all other 
> declarations in the declaration-seq of the translation-unit and of the 
> private-module-fragment (if any).

If I don't misread this, I think it implies that imports could not be the first 
decl in non-module unit.



Comment at: clang/test/Modules/cxx20-import-diagnostics-a.cpp:125
+
+#else
+#error "no MODE set"

It should be allowed to import a module in non-module unit. For example:
```
import std;
int main() {
std::cout << "Hello World.\n";
return 0;
}
```

I guess we lack a test for this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118893

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

[PATCH] D117989: [RISCV] Add the passthru operand for RVV nomask binary intrinsics.

[Zakk Chen 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 rGb7847199044e: [RISCV] Add the passthru operand for RVV 
nomask binary intrinsics. (authored by khchen).
Herald added a subscriber: qcolombet.

Changed prior to commit:
  https://reviews.llvm.org/D117989?vs=408696=409119#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117989

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/riscv-attr-builtin-alias.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vaadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vand.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vasub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfabs.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfneg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfsgnj.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfslide1down.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfslide1up.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmul-eew64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vnclip.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vncvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vneg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vnot.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vnsra.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vnsrl.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vor.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vrem.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vrgather.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vrsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vsadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vslide1down.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vslide1up.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vsll.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vsmul-eew64.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vsmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vsra.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vsrl.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vssra.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vssrl.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vssub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwcvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vxor.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vaadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vand.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vasub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfabs.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfneg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfrdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfrsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfsgnj.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfslide1down.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfslide1up.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmin.c
  

[PATCH] D117087: [C++20] [Coroutines] Implement return value optimization for get_return_object

[JunMa via Phabricator via cfe-commits]

junparser added inline comments.



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:654
+cast(Ret)->setRetValue(nullptr);
 EmitStmt(Ret);
+  }

ChuanqiXu wrote:
> junparser wrote:
> > I mean, remove the if statements here since the retuen expr is null.
> We couldn't. Since we need emit ret instruction if needed.
make sense to me.


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

https://reviews.llvm.org/D117087

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

[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

[Yuanfang Chen via Phabricator via cfe-commits]

ychen created this revision.
ychen added reviewers: hans, rnk, aganea, JDevlieghere, labath.
Herald added a subscriber: hiraditya.
ychen requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

The motivation is to enable the MSVC-style JMC instrumentation usable by a 
ELF-based
debugger. Since there is no prior experience implementing JMC feature for 
ELF-based
debugger, it might be better to just reuse existing MSVC-style JMC 
instrumentation.
For debuggers that support both ELF (like lldb), the JMC implementation 
might
be shared between ELF If this is found to inadequate, it is pretty 
low-cost
switching to alternatives.

Implementation:

- The '-fjmc' is already a driver and cc1 flag. Wire it up for ELF in the 
driver.
- Refactor the JMC instrumentation pass a little bit.
- The ELF handling is different from MSVC in two places:
  - the flag section name is ".just.my.code" instead of ".msvcjmc"
  - the way default function is provided: MSVC uses /alternatename; ELF uses 
weak function.

Based on D118428 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D119910

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/cl-options.c
  clang/test/Driver/clang_f_opts.c
  llvm/lib/CodeGen/JMCInstrumenter.cpp
  llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll
  llvm/test/Instrumentation/JustMyCode/jmc-instrument-x86.ll
  llvm/test/Instrumentation/JustMyCode/jmc-instrument.ll

Index: llvm/test/Instrumentation/JustMyCode/jmc-instrument-x86.ll
===
--- llvm/test/Instrumentation/JustMyCode/jmc-instrument-x86.ll
+++ llvm/test/Instrumentation/JustMyCode/jmc-instrument-x86.ll
@@ -11,12 +11,12 @@
 ; CHECK:   ret void
 ; CHECK: }
 
-; CHECK: declare x86_fastcallcc void @__CheckForDebuggerJustMyCode(i8* inreg noundef) unnamed_addr
-
 ; CHECK: define void @_JustMyCode_Default(i8* inreg noundef %0) unnamed_addr comdat {
 ; CHECK:   ret void
 ; CHECK: }
 
+; CHECK: declare x86_fastcallcc void @__CheckForDebuggerJustMyCode(i8* inreg noundef) unnamed_addr
+
 ; CHECK: !0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
 ; CHECK: !1 = distinct !DIGlobalVariable(name: "_A8764FDD_x@c", scope: !2, file: !3, type: !5, isLocal: true, isDefinition: true)
 ; CHECK: !2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "clang", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, globals: !4, splitDebugInlining: false, nameTableKind: None)
Index: llvm/test/Instrumentation/JustMyCode/jmc-instrument.ll
===
--- llvm/test/Instrumentation/JustMyCode/jmc-instrument.ll
+++ llvm/test/Instrumentation/JustMyCode/jmc-instrument.ll
@@ -6,8 +6,8 @@
 ; CHECK: $__JustMyCode_Default = comdat any
 
 ; CHECK: @"__E6EA670F_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", align 1, !dbg !0
-; CHECK: @"__A8764FDD_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", align 1, !dbg !5
 ; CHECK: @llvm.used = appending global [1 x i8*] [i8* bitcast (void (i8*)* @__JustMyCode_Default to i8*)], section "llvm.metadata"
+; CHECK: @"__A8764FDD_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", align 1, !dbg !5
 
 ; CHECK: define void @l1() !dbg !13 {
 ; CHECK:   call void @__CheckForDebuggerJustMyCode(i8* noundef @"__E6EA670F_x@c")
@@ -39,12 +39,12 @@
 ; CHECK:   ret void
 ; CHECK: }
 
-; CHECK: declare void @__CheckForDebuggerJustMyCode(i8* noundef) unnamed_addr
-
 ; CHECK: define void @__JustMyCode_Default(i8* noundef %0) unnamed_addr comdat {
 ; CHECK:   ret void
 ; CHECK: }
 
+; CHECK: declare void @__CheckForDebuggerJustMyCode(i8* noundef) unnamed_addr
+
 ; CHECK: !llvm.linker.options = !{!12}
 
 ; CHECK: !0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
Index: llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll
===
--- llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll
+++ llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll
@@ -1,78 +1,72 @@
-; REQUIRES: system-windows
-; RUN: opt -jmc-instrument -mtriple=x86_64-pc-windows-msvc  -S < %s | FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=aarch64-pc-windows-msvc -S < %s | FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=arm-pc-windows-msvc -S < %s | FileCheck %s
+; REQUIRES: system-linux
+; RUN: opt -jmc-instrument -mtriple=x86_64-unknown-linux-gnu  -S < %s | FileCheck %s
 
-; CHECK: $__JustMyCode_Default = comdat any
+; CHECK: @"__7DF23CF5_x@c" = internal unnamed_addr global i8 1, section ".just.my.code", align 1, !dbg !0
+; CHECK: @"__A85D9D03_x@c" = internal unnamed_addr global i8 1, section ".just.my.code", align 1, !dbg !5
 
-; CHECK: @"__E6EA670F_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", 

[PATCH] D119823: [Modules] Add module structure output to -module-file-info.

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added inline comments.



Comment at: clang/test/Modules/module-file-info-cxx20.cpp:26
+
+#if TU == 1
+

According to [[ 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1857r3.html | P1857R3 
]], it might not be good to add macro declarative before module declaration. 
Although clang didn't implement it and there are old test case uses this style, 
I think it might be better to split into files. @urnathan how do you think 
about this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119823

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

[PATCH] D119772: [clang] [NFC] More exhaustive tests for deducing void return types

[Chuanqi Xu via Phabricator via cfe-commits]

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

LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119772

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

[PATCH] D117087: [C++20] [Coroutines] Implement return value optimization for get_return_object

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added inline comments.



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:654
+cast(Ret)->setRetValue(nullptr);
 EmitStmt(Ret);
+  }

junparser wrote:
> I mean, remove the if statements here since the retuen expr is null.
We couldn't. Since we need emit ret instruction if needed.


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

https://reviews.llvm.org/D117087

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

[clang] 13b6f31 - Fix crash when deserializing a lambda expression in a decltype.

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2022-02-15T17:56:45-08:00
New Revision: 13b6f31548784452990da6dba555af8d7a061958

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

LOG: Fix crash when deserializing a lambda expression in a decltype.

Added: 
clang/test/PCH/cxx20-unevaluated-lambda.cpp

Modified: 
clang/lib/AST/StmtProfile.cpp

Removed: 




diff  --git a/clang/lib/AST/StmtProfile.cpp b/clang/lib/AST/StmtProfile.cpp
index 09853e0f0e497..b590f4a002638 100644
--- a/clang/lib/AST/StmtProfile.cpp
+++ b/clang/lib/AST/StmtProfile.cpp
@@ -38,6 +38,10 @@ namespace {
 
 void VisitStmt(const Stmt *S);
 
+void VisitStmtNoChildren(const Stmt *S) {
+  HandleStmtClass(S->getStmtClass());
+}
+
 virtual void HandleStmtClass(Stmt::StmtClass SC) = 0;
 
 #define STMT(Node, Base) void Visit##Node(const Node *S);
@@ -218,7 +222,7 @@ namespace {
 void StmtProfiler::VisitStmt(const Stmt *S) {
   assert(S && "Requires non-null Stmt pointer");
 
-  HandleStmtClass(S->getStmtClass());
+  VisitStmtNoChildren(S);
 
   for (const Stmt *SubStmt : S->children()) {
 if (SubStmt)
@@ -1945,7 +1949,11 @@ StmtProfiler::VisitCXXTemporaryObjectExpr(const 
CXXTemporaryObjectExpr *S) {
 
 void
 StmtProfiler::VisitLambdaExpr(const LambdaExpr *S) {
-  VisitExpr(S);
+  // Do not recursively visit the children of this expression. Profiling the
+  // body would result in unnecessary work, and is not safe to do during
+  // deserialization.
+  VisitStmtNoChildren(S);
+
   // C++20 [temp.over.link]p5:
   //   Two lambda-expressions are never considered equivalent.
   VisitDecl(S->getLambdaClass());

diff  --git a/clang/test/PCH/cxx20-unevaluated-lambda.cpp 
b/clang/test/PCH/cxx20-unevaluated-lambda.cpp
new file mode 100644
index 0..29af5e61c3307
--- /dev/null
+++ b/clang/test/PCH/cxx20-unevaluated-lambda.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -std=c++20 -include %s %s -o %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-pch %s -o %t
+// RUN: %clang_cc1 -std=c++20 -include-pch %t -verify %s
+
+// expected-no-diagnostics
+
+#ifndef HEADER
+#define HEADER
+
+template auto f() -> decltype([]{ return T(42); });
+
+#else /*included pch*/
+
+static_assert(decltype(f())()() == 42);
+
+#endif // HEADER



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

[PATCH] D119778: [clang] Add a note "deducing return type for 'foo'"

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

rsmith added inline comments.



Comment at: clang/lib/Sema/SemaStmt.cpp:3804-3809
+if (DAR != DAR_Succeeded) {
+  if (OrigResultType.getBeginLoc().isValid())
+Diag(OrigResultType.getBeginLoc(), diag::note_deducing_return_type_for)
+<< FD << OrigResultType.getSourceRange();
   return true;
+}

The approach of tacking a note onto the end of someone else's diagnostic is an 
antipattern and should be avoided in new code. For example, if `DeduceAutoType` 
produces an error (which is shown) then a warning (which is hidden), the note 
will be attached to the warning, and will not appear.

The right thing to do is to create a new kind of `CodeSynthesisContext` for 
this case and push that. Then we'll use the same logic as in template 
instantiation backtraces, and the note will get properly attached to the first 
emitted diagnostic within the context. This will also remove the need to track 
down all the different places that emit diagnostics (like we see below): you 
just push the context when you start doing the action you want to attach the 
note to and pop it when you're done. It'll also properly order the note with 
respect to other context notes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119778

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

[PATCH] D110663: [Driver] Support Debian multiarch style lib/clang/14.0.0/x86_64-linux-gnu runtime path and include/x86_64-linux-gnu/c++/v1 libc++ path

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

In D110663#3271084 , @MaskRay wrote:

> No worries! Thanks for the reply.
>
> I use Debian and want it to work well and support the 
> `-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=on` direction.
> Currently, `-DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-linux-gnu` (Debian style 
> multiarch triple, so no `-unknown` or `-pc`) does not work for libc++ and 
> some runtime libraries.

I believe this can be also addressed by changes to the CMake build without 
needing to change the driver. I have a series of patches and I'll try to send 
them for review in the next few days (I think those patches are desirable 
independently of which solution we ultimately choose).

> ---
>
> Here is `-DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-unknown-linux-gnu`:
>
>   cmake -GNinja -Hllvm -B/tmp/out/custom1 -DCMAKE_BUILD_TYPE=Release 
> -DCMAKE_CROSSCOMPILING=on -DCMAKE_INSTALL_PREFIX=/tmp/opt/aarch64 
> -DLLVM_TARGETS_TO_BUILD=AArch64 
> -DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-unknown-linux-gnu 
> -DLLVM_TARGET_ARCH=AArch64 -DLLVM_ENABLE_PROJECTS='clang;lld' 
> -DLLVM_ENABLE_RUNTIMES='compiler-rt;l
>   ibcxx;libcxxabi;libunwind'
>   ninja -C /tmp/out/custom1 lld cxx cxxabi unwind builtins
>   
>   /tmp/out/custom1/bin/clang++ -c -stdlib=libc++ a.cc; 
> /tmp/out/custom1/bin/clang++ -fuse-ld=lld 
> --dyld-prefix=/usr/aarch64-linux-gnu --unwindlib=libunwind 
> --rtlib=compiler-rt -nostdlib++ -pthread -static-libgcc a.o 
> -Wl,--push-state,-Bstatic,-lc++,-lc++abi,--pop-state,-rpath=/usr/aarch64-linux-gnu/lib
>  -ldl -o a  # works
>   ./a  # runs if you have binfmt_misc and qemu-aarch64-static
>
> If I change the CMake line to use 
> `-DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-linux-gnu` (to match Debian 
> `aarch64-linux-gnu-g++`), libc++ compiles do not work:
>
>   % /tmp/out/custom1/bin/clang++ -fuse-ld=lld 
> --dyld-prefix=/usr/aarch64-linux-gnu -Wl,-rpath=/usr/aarch64-linux-gnu/lib 
> a.cc -o a
>   % ./a  # works
>   
>   % /tmp/out/custom1/bin/clang++ -c -stdlib=libc++ a.cc
>   In file included from a.cc:1:
>   In file included from /tmp/out/custom1/bin/../include/c++/v1/stdio.h:101:
>   /tmp/out/custom1/bin/../include/c++/v1/__config:13:10: fatal error: 
> '__config_site' file not found
>   #include <__config_site>
>^~~
>   1 error generated.
>
> The issue is: `/tmp/out/custom1/include/aarch64-linux-gnu/c++/v1/` is not in 
> the search path.
>
> With this patch, the command will succeed. Here are the search paths for 
> includes and libraries:
>
>   % /tmp/out/custom1/bin/clang++ -fuse-ld=lld -stdlib=libc++ -v a.cc |& sed 
> -E 's/ "?-[iIL]/\n&/g'
>   clang version 14.0.0
>   Target: aarch64-unknown-linux-gnu
>   Thread model: posix
>   InstalledDir: /tmp/out/custom1/bin
>   Found candidate GCC installation: /usr/lib/gcc-cross/aarch64-linux-gnu/11
>   Selected GCC installation: /usr/lib/gcc-cross/aarch64-linux-gnu/11
>   Candidate multilib: .;@m64
>   Selected multilib: .;@m64
>"/tmp/out/custom1/bin/clang-14" -cc1 -triple aarch64-unknown-linux-gnu 
> -emit-obj -mrelax-all --mrelax-relocations -disable-free 
> -clear-ast-before-backend -disable-llvm-verifier -discard-value-names 
> -main-file-name a.cc -mrelocation-model static -mframe-pointer=non-leaf 
> -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases 
> -funwind-tables=2 -target-cpu generic -target-feature +neon -target-feature 
> +v8a -target-abi aapcs -fallow-half-arguments-and-returns -mllvm 
> -treat-scalable-fixed-error-as-warning -debugger-tuning=gdb -v 
> -fcoverage-compilation-dir=/tmp/c -resource-dir 
> /tmp/out/custom1/lib/clang/14.0.0
>-internal-isystem /tmp/out/custom1/bin/../include/aarch64-linux-gnu/c++/v1
>-internal-isystem /tmp/out/custom1/bin/../include/c++/v1
>-internal-isystem /tmp/out/custom1/lib/clang/14.0.0/include
>-internal-isystem /usr/local/include
>-internal-isystem 
> /usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/include
>-internal-externc-isystem /include
>-internal-externc-isystem /usr/include -fdeprecated-macro 
> -fdebug-compilation-dir=/tmp/c -ferror-limit 19 -fno-signed-char 
> -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -target-feature 
> +outline-atomics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/a-ffa089.o 
> -x c++ a.cc
>   clang -cc1 version 14.0.0 based upon LLVM 14.0.0git default target 
> aarch64-linux-gnu
>   ignoring nonexistent directory "/include"
>   #include "..." search starts here:
>   #include <...> search starts here:
>/tmp/out/custom1/bin/../include/aarch64-linux-gnu/c++/v1
>/tmp/out/custom1/bin/../include/c++/v1
>/tmp/out/custom1/lib/clang/14.0.0/include
>/usr/local/include
>
> /usr/lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/include
>/usr/include
>   End of search list.
>"/tmp/out/custom1/bin/ld.lld" -EL --eh-frame-hdr -m aarch64linux 
> -dynamic-linker /lib/ld-linux-aarch64.so.1 -o a.out 
> 

[PATCH] D119778: [clang] Add a note "deducing return type for 'foo'"

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added inline comments.



Comment at: clang/lib/Sema/SemaStmt.cpp:3805
+if (DAR != DAR_Succeeded) {
+  if (OrigResultType.getBeginLoc().isValid())
+Diag(OrigResultType.getBeginLoc(), diag::note_deducing_return_type_for)

> I am curious about the behavior if we removed the guard `if 
> (OrigResultType.getBeginLoc().isValid())`.

That caused the note to be emitted in some cases without a source location 
(similar to https://github.com/llvm/llvm-project/issues/29054 ). I admit I 
should check to make sure we have a test case for each of these four `if`s, 
though; I suspect we don't.
```
$ cat x.cpp
auto f = []() { return x; };

$ clang++ x.cpp
x.cpp:1:24: error: use of undeclared identifier 'x'
auto f = []() { return x; };
   ^
note: deducing return type for 'operator()'
1 error generated.
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119778

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

[PATCH] D119778: [clang] Add a note "deducing return type for 'foo'"

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone updated this revision to Diff 409095.
Quuxplusone added a comment.

Rebase; adjust more expected output in tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119778

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaStmt.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p2-1z.cpp
  clang/test/CXX/dcl/dcl.spec/dcl.type/dcl.spec.auto/p6.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.constr/non-function-templates.cpp
  clang/test/Sema/invalid-bitwidth-expr.mm
  clang/test/SemaCXX/cxx20-p0388-unbound-ary.cpp
  clang/test/SemaCXX/cxx2b-consteval-if.cpp
  clang/test/SemaCXX/deduced-return-type-cxx14.cpp
  clang/test/SemaCXX/deduced-return-void.cpp
  clang/test/SemaCXX/std-compare-cxx2a.cpp
  clang/test/SemaCXX/typo-correction-crash.cpp
  clang/test/SemaOpenCLCXX/template-astype.cl
  clang/test/SemaTemplate/concepts.cpp

Index: clang/test/SemaTemplate/concepts.cpp
===
--- clang/test/SemaTemplate/concepts.cpp
+++ clang/test/SemaTemplate/concepts.cpp
@@ -114,6 +114,7 @@
   }
   template void g5() {
 ([]() -> C auto{ // expected-error-re {{deduced type {{.*}} does not satisfy}}
+// expected-note@-1 {{deducing return type for 'operator()'}}
  return T();
  }(), ...);
   }
@@ -174,11 +175,17 @@
   template concept C = false; // expected-note 6 {{because 'false' evaluated to false}}
 
   C auto f1() { return void(); }   // expected-error {{deduced type 'void' does not satisfy 'C'}}
+   // expected-note@-1 {{deducing return type for 'f1'}}
   C auto f2() { return; }  // expected-error {{deduced type 'void' does not satisfy 'C'}}
+   // expected-note@-1 {{deducing return type for 'f2'}}
   C auto f3() {}   // expected-error {{deduced type 'void' does not satisfy 'C'}}
+   // expected-note@-1 {{deducing return type for 'f3'}}
   C decltype(auto) f4() { return void(); } // expected-error {{deduced type 'void' does not satisfy 'C'}}
+   // expected-note@-1 {{deducing return type for 'f4'}}
   C decltype(auto) f5() { return; }// expected-error {{deduced type 'void' does not satisfy 'C'}}
+   // expected-note@-1 {{deducing return type for 'f5'}}
   C decltype(auto) f6() {} // expected-error {{deduced type 'void' does not satisfy 'C'}}
+   // expected-note@-1 {{deducing return type for 'f6'}}
 
   void g() {
 f1();
Index: clang/test/SemaOpenCLCXX/template-astype.cl
===
--- clang/test/SemaOpenCLCXX/template-astype.cl
+++ clang/test/SemaOpenCLCXX/template-astype.cl
@@ -11,6 +11,7 @@
 
 auto neg_test_int(int x) { return templated_astype(x); }
 // expected-note@-1{{in instantiation of function template specialization 'templated_astype' requested here}}
+// expected-note@-2{{deducing return type for 'neg_test_int'}}
 
 auto test_short4(short4 x) { return templated_astype(x); }
 
Index: clang/test/SemaCXX/typo-correction-crash.cpp
===
--- clang/test/SemaCXX/typo-correction-crash.cpp
+++ clang/test/SemaCXX/typo-correction-crash.cpp
@@ -2,6 +2,7 @@
 auto check1() {
   return 1;
   return s; // expected-error {{use of undeclared identifier 's'}}
+// expected-note@-3 {{deducing return type for 'check1'}}
 }
 
 int test = 11; // expected-note 2 {{'test' declared here}}
@@ -9,6 +10,7 @@
   return "s";
   return tes; // expected-error {{use of undeclared identifier 'tes'; did you mean 'test'?}}
   // expected-error@-1 {{deduced as 'int' here but deduced as 'const char *' in earlier}}
+  // expected-note@-4 {{deducing return type for 'check2'}}
 }
 
 template  struct is_same { static constexpr bool value = false; };
Index: clang/test/SemaCXX/std-compare-cxx2a.cpp
===
--- clang/test/SemaCXX/std-compare-cxx2a.cpp
+++ clang/test/SemaCXX/std-compare-cxx2a.cpp
@@ -32,6 +32,7 @@
 auto compare_incomplete_test() {
   // expected-error@+1 {{incomplete type 'std::partial_ordering' where a complete type is required}}
   return (-1.2 <=> 123.0);
+  // expected-note@-3 {{deducing return type for 'compare_incomplete_test'}}
 }
 
 namespace std {
@@ -45,6 +46,7 @@
 auto missing_member_test() {
   // expected-error@+1 {{standard library implementation of 'std::partial_ordering' is not supported; member 'equivalent' is missing}}
   return (1.0 <=> 1.0);
+  // expected-note@-3 {{deducing return type for 'missing_member_test'}}
 }
 
 namespace std {
@@ -59,6 +61,7 @@
 auto 

[PATCH] D119184: [clang] [concepts] Check constrained-auto return types for void-returning functions

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone updated this revision to Diff 409090.
Quuxplusone added a comment.

Rebase; fix the clang-format nit; reinsert a missing `FD->setInvalidDecl()` 
that seemed to be causing crashes in Modules code under libcxx/test/ but 
otherwise doesn't seem to be tested in clang/test/ :(


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119184

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/test/SemaTemplate/concepts.cpp

Index: clang/test/SemaTemplate/concepts.cpp
===
--- clang/test/SemaTemplate/concepts.cpp
+++ clang/test/SemaTemplate/concepts.cpp
@@ -169,3 +169,23 @@
   template void f(T, U) = delete;
   void g() { f(0, 0); }
 }
+
+namespace PR49188 {
+  template concept C = false; // expected-note 6 {{because 'false' evaluated to false}}
+
+  C auto f1() { return void(); }   // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  C auto f2() { return; }  // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  C auto f3() {}   // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  C decltype(auto) f4() { return void(); } // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  C decltype(auto) f5() { return; }// expected-error {{deduced type 'void' does not satisfy 'C'}}
+  C decltype(auto) f6() {} // expected-error {{deduced type 'void' does not satisfy 'C'}}
+
+  void g() {
+f1();
+f2();
+f3();
+f4();
+f5();
+f6();
+  }
+}
Index: clang/lib/Sema/SemaStmt.cpp
===
--- clang/lib/Sema/SemaStmt.cpp
+++ clang/lib/Sema/SemaStmt.cpp
@@ -3590,7 +3590,8 @@
 
 AutoType *AT = CurCap->ReturnType->getContainedAutoType();
 assert(AT && "lost auto type from lambda return type");
-if (DeduceFunctionTypeFromReturnExpr(FD, ReturnLoc, RetValExp, AT)) {
+if (DeduceFunctionTypeFromReturnExpr(FD, ReturnLoc, RetValExp, AT,
+ /*HasReturnStmt=*/true)) {
   FD->setInvalidDecl();
   // FIXME: preserve the ill-formed return expression.
   return StmtError();
@@ -3761,9 +3762,9 @@
 /// C++1y [dcl.spec.auto]p6.
 bool Sema::DeduceFunctionTypeFromReturnExpr(FunctionDecl *FD,
 SourceLocation ReturnLoc,
-Expr *,
-AutoType *AT) {
-  // If this is the conversion function for a lambda, we choose to deduce it
+Expr *, const AutoType *AT,
+bool HasReturnStmt) {
+  // If this is the conversion function for a lambda, we choose to deduce its
   // type from the corresponding call operator, not from the synthesized return
   // statement within it. See Sema::DeduceReturnType.
   if (isLambdaConversionOperator(FD))
@@ -3808,19 +3809,26 @@
 LocalTypedefNameReferencer Referencer(*this);
 Referencer.TraverseType(RetExpr->getType());
   } else {
-//  In the case of a return with no operand, the initializer is considered
-//  to be void().
-//
-// Deduction here can only succeed if the return type is exactly 'cv auto'
-// or 'decltype(auto)', so just check for that case directly.
-if (!OrigResultType.getType()->getAs()) {
+// For a function with a deduced result type to return void,
+// the result type as written must be 'auto' or 'decltype(auto)',
+// possibly cv-qualified or constrained, but not ref-qualified.
+if (!FD->getReturnType()->getAs()) {
   Diag(ReturnLoc, diag::err_auto_fn_return_void_but_not_auto)
-<< OrigResultType.getType();
+  << OrigResultType.getType();
   return true;
 }
-// We always deduce U = void in this case.
-Deduced = SubstAutoType(OrigResultType.getType(), Context.VoidTy);
-if (Deduced.isNull())
+// In the case of a return with no operand, the initializer is considered
+// to be 'void()'.
+Expr *Dummy = new (Context) CXXScalarValueInitExpr(
+Context.VoidTy,
+Context.getTrivialTypeSourceInfo(Context.VoidTy, ReturnLoc), ReturnLoc);
+DeduceAutoResult DAR = DeduceAutoType(OrigResultType, Dummy, Deduced);
+
+if (DAR == DAR_Failed && !FD->isInvalidDecl())
+  Diag(ReturnLoc, diag::err_auto_fn_deduction_failure)
+  << OrigResultType.getType() << Dummy->getType();
+
+if (DAR != DAR_Succeeded)
   return true;
   }
 
@@ -3989,7 +3997,8 @@
   // trying to deduce its return type.
   // (Some return values may be needlessly wrapped in RecoveryExpr).
   if (FD->isInvalidDecl() ||
-  DeduceFunctionTypeFromReturnExpr(FD, ReturnLoc, RetValExp, AT)) {
+  

[PATCH] D110663: [Driver] Support Debian multiarch style lib/clang/14.0.0/x86_64-linux-gnu runtime path and include/x86_64-linux-gnu/c++/v1 libc++ path

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

I'm personally ignoring this review because quite honestly i was horrified of 
just how nonchalantly dismissive/accusative the reaction was to the problem i 
raised during the revert.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663

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

[PATCH] D119893: [clang-format] Fixed handling of requires clauses followed by attributes

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added inline comments.



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:3018-3019
   do {
+bool LambdaThisTimeAllowed = LambdaNextTimeAllowed;
+LambdaNextTimeAllowed = false;
+

Nit: For this pattern, consider `bool LambdaThisTimeAllowed = 
std::exchange(LambdaNextTimeAllowed, false);`



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:3102
+  LambdaNextTimeAllowed = true;
+  LLVM_FALLTHROUGH;
+case tok::numeric_constant:

This seems like an overuse of fallthrough; how about simply
```
LambdaNextTimeAllowed = true;
nextToken();
break;
```
?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119893

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

[PATCH] D110663: [Driver] Support Debian multiarch style lib/clang/14.0.0/x86_64-linux-gnu runtime path and include/x86_64-linux-gnu/c++/v1 libc++ path

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D110663#3324598 , @sylvestre.ledru 
wrote:

> Could you please stop with the pings? and chat directly ? (It seems that you 
> are colleagues?!)
>
> I would like to follow what is happening here but not get flooded.

(I don't mind if you/others review this as well, and honestly I don't know why 
it needs to take such a long time to proceed.)
It seems that other reviewers just hand off the review burden to phosek, but 
they can review this by themselves as well.

This is more a Linux distro thing, less related to Fuchsia. So technically you 
will be a good one, especially that the whole multiarch thing is related to 
Debian

Generally the guidance is one ping every week. The last ping has just 4 days, 
but if take the full history into account my ping frequency is much less 
frequent than once every week.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663

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

Re: [clang] 4bafe65 - Add support for floating-point option `ffp-eval-method` and for

[Roman Lebedev via cfe-commits]

Where was this reviewed?

On Wed, Feb 16, 2022 at 12:59 AM Zahira Ammarguellat via cfe-commits
 wrote:
>
>
> Author: Zahira Ammarguellat
> Date: 2022-02-15T13:59:27-08:00
> New Revision: 4bafe65c2b2f1ce745894a509a6d80c87fb1c335
>
> URL: 
> https://github.com/llvm/llvm-project/commit/4bafe65c2b2f1ce745894a509a6d80c87fb1c335
> DIFF: 
> https://github.com/llvm/llvm-project/commit/4bafe65c2b2f1ce745894a509a6d80c87fb1c335.diff
>
> LOG: Add support for floating-point option `ffp-eval-method` and for
> `pragma clang fp eval_method`.
>
> Added:
> clang/test/CodeGen/X86/32bit-behavior-no-eval.c
> clang/test/CodeGen/X86/32bit-behavior.c
> clang/test/CodeGen/X86/fp-eval-method.c
> clang/test/CodeGen/flt_eval_macro.cpp
> clang/test/Preprocessor/flt_eval_macro.cpp
> clang/test/Sema/fp-eval-pragma.cpp
> clang/test/Sema/x86-eval-method.c
> clang/test/Sema/x86_64-eval-method.c
>
> Modified:
> clang/docs/LanguageExtensions.rst
> clang/docs/UsersManual.rst
> clang/include/clang/Basic/DiagnosticCommonKinds.td
> clang/include/clang/Basic/DiagnosticLexKinds.td
> clang/include/clang/Basic/FPOptions.def
> clang/include/clang/Basic/LangOptions.def
> clang/include/clang/Basic/LangOptions.h
> clang/include/clang/Basic/TargetInfo.h
> clang/include/clang/Driver/Options.td
> clang/include/clang/Lex/Preprocessor.h
> clang/include/clang/Parse/Parser.h
> clang/include/clang/Sema/Sema.h
> clang/lib/Basic/Targets/OSTargets.h
> clang/lib/Basic/Targets/X86.h
> clang/lib/Driver/ToolChains/Clang.cpp
> clang/lib/Frontend/InitPreprocessor.cpp
> clang/lib/Lex/PPMacroExpansion.cpp
> clang/lib/Parse/ParsePragma.cpp
> clang/lib/Parse/ParseStmt.cpp
> clang/lib/Sema/Sema.cpp
> clang/lib/Sema/SemaAttr.cpp
> clang/lib/Sema/SemaExpr.cpp
> clang/test/CodeGen/fp-floatcontrol-pragma.cpp
> clang/test/Preprocessor/init-aarch64.c
> clang/test/Preprocessor/init-arm.c
> clang/test/Preprocessor/init-mips.c
> clang/test/Preprocessor/init-ppc.c
> clang/test/Preprocessor/init-ppc64.c
> clang/test/Preprocessor/init-s390x.c
> clang/test/Preprocessor/init-v7k-compat.c
> clang/test/Preprocessor/init-x86.c
> clang/test/Preprocessor/init.c
>
> Removed:
>
>
>
> 
> diff  --git a/clang/docs/LanguageExtensions.rst 
> b/clang/docs/LanguageExtensions.rst
> index f45d88092eb4a..5249d3f3f7930 100644
> --- a/clang/docs/LanguageExtensions.rst
> +++ b/clang/docs/LanguageExtensions.rst
> @@ -3907,6 +3907,38 @@ A ``#pragma clang fp`` pragma may contain any number 
> of options:
>  ...
>}
>
> +``#pragma clang fp eval_method`` allows floating-point behavior to be 
> specified
> +for a section of the source code. This pragma can appear at file or namespace
> +scope, or at the start of a compound statement (excluding comments).
> +The pragma is active within the scope of the compound statement.
> +
> +When ``pragma clang fp eval_method(source)`` is enabled, the section of code
> +governed by the pragma behaves as though the command-line option
> +``-ffp-eval-method=source`` is enabled. Rounds intermediate results to
> +source-defined precision.
> +
> +When ``pragma clang fp eval_method(double)`` is enabled, the section of code
> +governed by the pragma behaves as though the command-line option
> +``-ffp-eval-method=double`` is enabled. Rounds intermediate results to
> +``double`` precision.
> +
> +When ``pragma clang fp eval_method(extended)`` is enabled, the section of 
> code
> +governed by the pragma behaves as though the command-line option
> +``-ffp-eval-method=extended`` is enabled. Rounds intermediate results to
> +target-dependent ``long double`` precision. In Win32 programming, for 
> instance,
> +the long double data type maps to the double, 64-bit precision data type.
> +
> +The full syntax this pragma supports is
> +``#pragma clang fp eval_method(source|double|extended)``.
> +
> +.. code-block:: c++
> +
> +  for(...) {
> +// The compiler will use long double as the floating-point evaluation
> +// method.
> +#pragma clang fp eval_method(extended)
> +a = b[i] * c[i] + e;
> +  }
>
>  The ``#pragma float_control`` pragma allows precise floating-point
>  semantics and floating-point exception behavior to be specified
>
> diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
> index 1df96296cb8ac..70fee29ab2a84 100644
> --- a/clang/docs/UsersManual.rst
> +++ b/clang/docs/UsersManual.rst
> @@ -1566,6 +1566,22 @@ Note that floating-point operations performed as part 
> of constant initialization
> * ``maytrap`` The compiler avoids transformations that may raise 
> exceptions that would not have been raised by the original code. Constant 
> folding performed by the compiler is exempt from this option.
> * ``strict`` The compiler ensures that all transformations strictly 
> preserve the floating point 

[PATCH] D110663: [Driver] Support Debian multiarch style lib/clang/14.0.0/x86_64-linux-gnu runtime path and include/x86_64-linux-gnu/c++/v1 libc++ path

[Sylvestre Ledru via Phabricator via cfe-commits]

sylvestre.ledru added a comment.

Could you please stop with the pings? and chat directly ? (It seems that you 
are colleagues?!)

I would like to follow what is happening here but not get flooded.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663

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

[PATCH] D119178: Add support for generating debug-info for structured bindings of structs and arrays

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:4647
+const bool UsePointerValue) {
+  assert(CGM.getCodeGenOpts().hasReducedDebugInfo());
+  assert(!LexicalBlockStack.empty() && "Region stack mismatch, stack empty!");

aprantl wrote:
> do you need a 
> ```
>  if (DebugKind > codegenoptions::LimitedDebugInfo)
>   return
> ```
> 
> here?
That kind of check is only used in limited places, why would it apply here as 
let's say opposed to the `EmitDeclare` for `VarDecl` case?



Comment at: clang/test/CodeGenCXX/debug-info-structured-binding.cpp:3
+
+// CHECK: call void @llvm.dbg.declare(metadata %struct.A* %[[F:[0-9]+]], 
metadata ![[F:[0-9]+]], metadata !DIExpression())
+// CHECK: call void @llvm.dbg.declare(metadata %struct.A* %[[F:[0-9]+]], 
metadata ![[F:[0-9]+]], metadata !DIExpression(DW_OP_plus_uconst, [[F:[0-9]+]]))

aprantl wrote:
> We should check what F is, too, right?
Actually I should have used a different match, that was a mistake.


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

https://reviews.llvm.org/D119178

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

[PATCH] D119178: Add support for generating debug-info for structured bindings of structs and arrays

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik updated this revision to Diff 409056.
shafik marked 5 inline comments as done.
shafik added a comment.

Addressed comments on SmallVector size and fixed test.


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

https://reviews.llvm.org/D119178

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/test/CodeGenCXX/debug-info-structured-binding.cpp
  lldb/test/API/lang/cpp/structured-binding/Makefile
  lldb/test/API/lang/cpp/structured-binding/TestStructuredBinding.py
  lldb/test/API/lang/cpp/structured-binding/main.cpp

Index: lldb/test/API/lang/cpp/structured-binding/main.cpp
===
--- /dev/null
+++ lldb/test/API/lang/cpp/structured-binding/main.cpp
@@ -0,0 +1,69 @@
+// Structured binding in C++ can bind identifiers to subobjects of an object.
+//
+// There are three cases we need to test:
+// 1) arrays
+// 2) tuples like objects
+// 3) non-static data members
+//
+// They can also bind by copy, reference or rvalue reference.
+
+#include 
+
+struct A {
+  int x;
+  int y;
+};
+
+// We want to cover a mix of types and also different sizes to make sure we
+// hande the offsets correctly.
+struct MixedTypesAndSizesStruct {
+  A a;
+  char b1;
+  char b2;
+  short b3;
+  int b4;
+  char b5;
+};
+
+int main() {
+  MixedTypesAndSizesStruct b{{20, 30}, 'a', 'b', 50, 60, 'c'};
+
+  auto [a1, b1, c1, d1, e1, f1] = b;
+  auto &[a2, b2, c2, d2, e2, f2] = b;
+  auto &&[a3, b3, c3, d3, e3, f3] =
+  MixedTypesAndSizesStruct{{20, 30}, 'a', 'b', 50, 60, 'c'};
+
+  // Array with different sized types
+  char carr[]{'a', 'b', 'c'};
+  short sarr[]{11, 12, 13};
+  int iarr[]{22, 33, 44};
+
+  auto [carr_copy1, carr_copy2, carr_copy3] = carr;
+  auto [sarr_copy1, sarr_copy2, sarr_copy3] = sarr;
+  auto [iarr_copy1, iarr_copy2, iarr_copy3] = iarr;
+
+  auto &[carr_ref1, carr_ref2, carr_ref3] = carr;
+  auto &[sarr_ref1, sarr_ref2, sarr_ref3] = sarr;
+  auto &[iarr_ref1, iarr_ref2, iarr_ref3] = iarr;
+
+  auto &&[carr_rref1, carr_rref2, carr_rref3] = carr;
+  auto &&[sarr_rref1, sarr_rref2, sarr_rref3] = sarr;
+  auto &&[iarr_rref1, iarr_rref2, iarr_rref3] = iarr;
+
+  float x{4.0};
+  char y{'z'};
+  int z{10};
+
+  std::tuple tpl(x, y, z);
+  auto [tx1, ty1, tz1] = tpl;
+  auto &[tx2, ty2, tz2] = tpl;
+
+  return a1.x + b1 + c1 + d1 + e1 + f1 + a2.y + b2 + c2 + d2 + e2 + f2 + a3.x +
+ b3 + c3 + d3 + e3 + f3 + carr_copy1 + carr_copy2 + carr_copy3 +
+ sarr_copy1 + sarr_copy2 + sarr_copy3 + iarr_copy1 + iarr_copy2 +
+ iarr_copy3 + carr_ref1 + carr_ref2 + carr_ref3 + sarr_ref1 +
+ sarr_ref2 + sarr_ref3 + iarr_ref1 + iarr_ref2 + iarr_ref3 +
+ carr_rref1 + carr_rref2 + carr_rref3 + sarr_rref1 + sarr_rref2 +
+ sarr_rref3 + iarr_rref1 + iarr_rref2 + iarr_rref3 + tx1 + ty1 + tz1 +
+ tx2 + ty2 + tz2; // break here
+}
Index: lldb/test/API/lang/cpp/structured-binding/TestStructuredBinding.py
===
--- /dev/null
+++ lldb/test/API/lang/cpp/structured-binding/TestStructuredBinding.py
@@ -0,0 +1,84 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestStructuredBinding(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@skipIf(compiler="clang", compiler_version=['<', '14.0'])
+def test(self):
+self.build()
+lldbutil.run_to_source_breakpoint(self, "// break here", lldb.SBFileSpec("main.cpp"))
+
+self.expect_expr("a1", result_type="A",
+result_children=[ValueCheck(name="x", type="int"),
+ ValueCheck(name="y", type="int")])
+self.expect_expr("b1", result_type="char", result_value="'a'")
+self.expect_expr("c1", result_type="char", result_value="'b'")
+self.expect_expr("d1", result_type="short", result_value="50")
+self.expect_expr("e1", result_type="int", result_value="60")
+self.expect_expr("f1", result_type="char", result_value="'c'")
+
+self.expect_expr("a2", result_type="A",
+result_children=[ValueCheck(name="x", type="int"),
+ ValueCheck(name="y", type="int")])
+self.expect_expr("b2", result_type="char", result_value="'a'")
+self.expect_expr("c2", result_type="char", result_value="'b'")
+self.expect_expr("d2", result_type="short", result_value="50")
+self.expect_expr("e2", result_type="int", result_value="60")
+self.expect_expr("f2", result_type="char", result_value="'c'")
+
+self.expect_expr("a3", result_type="A",
+result_children=[ValueCheck(name="x", type="int"),
+ ValueCheck(name="y", type="int")])
+self.expect_expr("b3", result_type="char", result_value="'a'")
+self.expect_expr("c3", result_type="char", result_value="'b'")
+

[PATCH] D119893: [clang-format] Fixed handling of requires clauses followed by attributes

[Björn Schäpers via Phabricator via cfe-commits]

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

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D119893

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/TokenAnnotatorTest.cpp

Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -219,6 +219,20 @@
 "Namespace::Outer::Inner::Constant) {}");
   ASSERT_EQ(Tokens.size(), 24u) << Tokens;
   EXPECT_TOKEN(Tokens[7], tok::kw_requires, TT_RequiresClause);
+
+  Tokens = annotate("struct [[nodiscard]] zero_t {\n"
+"  template\n"
+"requires requires { number_zero_v; }\n"
+"  [[nodiscard]] constexpr operator T() const { "
+"return number_zero_v; }\n"
+"};");
+  ASSERT_EQ(Tokens.size(), 44u);
+  EXPECT_TOKEN(Tokens[13], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TOKEN(Tokens[14], tok::kw_requires, TT_RequiresExpression);
+  EXPECT_TOKEN(Tokens[15], tok::l_brace, TT_RequiresExpressionLBrace);
+  EXPECT_TOKEN(Tokens[21], tok::r_brace, TT_Unknown);
+  EXPECT_EQ(Tokens[21]->MatchingParen, Tokens[15]);
+  EXPECT_TRUE(Tokens[21]->ClosesRequiresClause);
 }
 
 TEST_F(TokenAnnotatorTest, UnderstandsRequiresExpressions) {
@@ -494,6 +508,35 @@
   NumberOfAdditionalRequiresClauseTokens = 14u;
   NumberOfTokensBeforeRequires = 5u;
 
+  ASSERT_EQ(BaseTokens.size(), NumberOfBaseTokens) << BaseTokens;
+  ASSERT_EQ(ConstrainedTokens.size(),
+NumberOfBaseTokens + NumberOfAdditionalRequiresClauseTokens)
+  << ConstrainedTokens;
+
+  for (auto I = 0u; I < NumberOfBaseTokens; ++I)
+if (I < NumberOfTokensBeforeRequires)
+  EXPECT_EQ(*BaseTokens[I], *ConstrainedTokens[I]) << I;
+else
+  EXPECT_EQ(*BaseTokens[I],
+*ConstrainedTokens[I + NumberOfAdditionalRequiresClauseTokens])
+  << I;
+
+  BaseTokens = annotate("struct [[nodiscard]] zero_t {\n"
+   "  template\n"
+   "  [[nodiscard]] constexpr operator T() const { "
+   "return number_zero_v; }\n"
+   "};");
+
+  ConstrainedTokens = annotate("struct [[nodiscard]] zero_t {\n"
+   "  template\n"
+   "requires requires { number_zero_v; }\n"
+   "  [[nodiscard]] constexpr operator T() const { "
+   "return number_zero_v; }\n"
+   "};");
+  NumberOfBaseTokens = 35u;
+  NumberOfAdditionalRequiresClauseTokens = 9u;
+  NumberOfTokensBeforeRequires = 13u;
+
   ASSERT_EQ(BaseTokens.size(), NumberOfBaseTokens) << BaseTokens;
   ASSERT_EQ(ConstrainedTokens.size(),
 NumberOfBaseTokens + NumberOfAdditionalRequiresClauseTokens)
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -3007,7 +3007,17 @@
 /// clause. It returns, when the parsing is complete, or the expression is
 /// incorrect.
 void UnwrappedLineParser::parseConstraintExpression() {
+  // The special handling for lambdas is needed since tryToParseLambda() eats a
+  // token and if a requires expression is the last part of a requires clause
+  // and followed by an attribute like [[nodiscard]] the ClosesRequiresClause is
+  // not set on the correct token. Thus we need to be aware if we even expect a
+  // lambda to be possible.
+  // template  requires requires { ... } [[nodiscard]] ...;
+  bool LambdaNextTimeAllowed = true;
   do {
+bool LambdaThisTimeAllowed = LambdaNextTimeAllowed;
+LambdaNextTimeAllowed = false;
+
 switch (FormatTok->Tok.getKind()) {
 case tok::kw_requires: {
   auto RequiresToken = FormatTok;
@@ -3021,7 +3031,7 @@
   break;
 
 case tok::l_square:
-  if (!tryToParseLambda())
+  if (!LambdaThisTimeAllowed || !tryToParseLambda())
 return;
   break;
 
@@ -3064,10 +3074,15 @@
 case tok::pipepipe:
   FormatTok->setType(TT_BinaryOperator);
   nextToken();
+  LambdaNextTimeAllowed = true;
+  break;
+
+case tok::comma:
+case tok::comment:
+  LambdaNextTimeAllowed = LambdaThisTimeAllowed;
+  nextToken();
   break;
 
-case tok::kw_true:
-case tok::kw_false:
 case tok::kw_sizeof:
 case tok::greater:
 case tok::greaterequal:
@@ -3082,11 +3097,13 @@
 case tok::minus:
 case tok::star:
 case tok::slash:
-case 

[PATCH] D110663: [Driver] Support Debian multiarch style lib/clang/14.0.0/x86_64-linux-gnu runtime path and include/x86_64-linux-gnu/c++/v1 libc++ path

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

Ping @phosek


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663

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

[clang] 4bafe65 - Add support for floating-point option `ffp-eval-method` and for

[Zahira Ammarguellat via cfe-commits]

Author: Zahira Ammarguellat
Date: 2022-02-15T13:59:27-08:00
New Revision: 4bafe65c2b2f1ce745894a509a6d80c87fb1c335

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

LOG: Add support for floating-point option `ffp-eval-method` and for
`pragma clang fp eval_method`.

Added: 
clang/test/CodeGen/X86/32bit-behavior-no-eval.c
clang/test/CodeGen/X86/32bit-behavior.c
clang/test/CodeGen/X86/fp-eval-method.c
clang/test/CodeGen/flt_eval_macro.cpp
clang/test/Preprocessor/flt_eval_macro.cpp
clang/test/Sema/fp-eval-pragma.cpp
clang/test/Sema/x86-eval-method.c
clang/test/Sema/x86_64-eval-method.c

Modified: 
clang/docs/LanguageExtensions.rst
clang/docs/UsersManual.rst
clang/include/clang/Basic/DiagnosticCommonKinds.td
clang/include/clang/Basic/DiagnosticLexKinds.td
clang/include/clang/Basic/FPOptions.def
clang/include/clang/Basic/LangOptions.def
clang/include/clang/Basic/LangOptions.h
clang/include/clang/Basic/TargetInfo.h
clang/include/clang/Driver/Options.td
clang/include/clang/Lex/Preprocessor.h
clang/include/clang/Parse/Parser.h
clang/include/clang/Sema/Sema.h
clang/lib/Basic/Targets/OSTargets.h
clang/lib/Basic/Targets/X86.h
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Frontend/InitPreprocessor.cpp
clang/lib/Lex/PPMacroExpansion.cpp
clang/lib/Parse/ParsePragma.cpp
clang/lib/Parse/ParseStmt.cpp
clang/lib/Sema/Sema.cpp
clang/lib/Sema/SemaAttr.cpp
clang/lib/Sema/SemaExpr.cpp
clang/test/CodeGen/fp-floatcontrol-pragma.cpp
clang/test/Preprocessor/init-aarch64.c
clang/test/Preprocessor/init-arm.c
clang/test/Preprocessor/init-mips.c
clang/test/Preprocessor/init-ppc.c
clang/test/Preprocessor/init-ppc64.c
clang/test/Preprocessor/init-s390x.c
clang/test/Preprocessor/init-v7k-compat.c
clang/test/Preprocessor/init-x86.c
clang/test/Preprocessor/init.c

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index f45d88092eb4a..5249d3f3f7930 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -3907,6 +3907,38 @@ A ``#pragma clang fp`` pragma may contain any number of 
options:
 ...
   }
 
+``#pragma clang fp eval_method`` allows floating-point behavior to be specified
+for a section of the source code. This pragma can appear at file or namespace
+scope, or at the start of a compound statement (excluding comments).
+The pragma is active within the scope of the compound statement.
+
+When ``pragma clang fp eval_method(source)`` is enabled, the section of code
+governed by the pragma behaves as though the command-line option
+``-ffp-eval-method=source`` is enabled. Rounds intermediate results to
+source-defined precision.
+
+When ``pragma clang fp eval_method(double)`` is enabled, the section of code
+governed by the pragma behaves as though the command-line option
+``-ffp-eval-method=double`` is enabled. Rounds intermediate results to
+``double`` precision.
+
+When ``pragma clang fp eval_method(extended)`` is enabled, the section of code
+governed by the pragma behaves as though the command-line option
+``-ffp-eval-method=extended`` is enabled. Rounds intermediate results to
+target-dependent ``long double`` precision. In Win32 programming, for instance,
+the long double data type maps to the double, 64-bit precision data type.
+
+The full syntax this pragma supports is
+``#pragma clang fp eval_method(source|double|extended)``.
+
+.. code-block:: c++
+
+  for(...) {
+// The compiler will use long double as the floating-point evaluation
+// method.
+#pragma clang fp eval_method(extended)
+a = b[i] * c[i] + e;
+  }
 
 The ``#pragma float_control`` pragma allows precise floating-point
 semantics and floating-point exception behavior to be specified

diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index 1df96296cb8ac..70fee29ab2a84 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1566,6 +1566,22 @@ Note that floating-point operations performed as part of 
constant initialization
* ``maytrap`` The compiler avoids transformations that may raise exceptions 
that would not have been raised by the original code. Constant folding 
performed by the compiler is exempt from this option.
* ``strict`` The compiler ensures that all transformations strictly 
preserve the floating point exception semantics of the original code.
 
+.. option:: -ffp-eval-method=
+
+   Specify the floating-point evaluation method for intermediate results within
+   a single expression of the code.
+
+   Valid values are: ``source``, ``double``, and ``extended``.
+   For 64-bit targets, the default value is ``source``. For 32-bit x86 

[PATCH] D118070: Make lld-link work in a non-MSVC shell

[Peter Kasting via Phabricator via cfe-commits]

pkasting updated this revision to Diff 409046.
pkasting added a comment.

Fix test failure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118070

Files:
  clang/docs/tools/clang-formatted-files.txt
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/lib/Driver/ToolChains/MSVC.h
  clang/lib/Driver/ToolChains/MSVCSetupApi.h
  lld/COFF/CMakeLists.txt
  lld/COFF/Driver.cpp
  lld/COFF/Driver.h
  lld/COFF/Options.td
  lld/COFF/SymbolTable.cpp
  lld/docs/ReleaseNotes.rst
  lld/test/COFF/winsysroot.test
  llvm/include/llvm/WindowsDriver/MSVCPaths.h
  llvm/include/llvm/WindowsDriver/MSVCSetupApi.h
  llvm/lib/CMakeLists.txt
  llvm/lib/WindowsDriver/CMakeLists.txt
  llvm/lib/WindowsDriver/MSVCPaths.cpp
  llvm/utils/gn/secondary/clang/lib/Driver/BUILD.gn
  llvm/utils/gn/secondary/lld/COFF/BUILD.gn
  llvm/utils/gn/secondary/llvm/lib/WindowsDriver/BUILD.gn

Index: llvm/utils/gn/secondary/llvm/lib/WindowsDriver/BUILD.gn
===
--- /dev/null
+++ llvm/utils/gn/secondary/llvm/lib/WindowsDriver/BUILD.gn
@@ -0,0 +1,8 @@
+static_library("WindowsDriver") {
+  output_name = "LLVMWindowsDriver"
+  deps = [
+"//llvm/lib/Option",
+"//llvm/lib/Support",
+  ]
+  sources = [ "MSVCPaths.cpp" ]
+}
Index: llvm/utils/gn/secondary/lld/COFF/BUILD.gn
===
--- llvm/utils/gn/secondary/lld/COFF/BUILD.gn
+++ llvm/utils/gn/secondary/lld/COFF/BUILD.gn
@@ -23,6 +23,7 @@
 "//llvm/lib/Support",
 "//llvm/lib/Target:TargetsToBuild",
 "//llvm/lib/ToolDrivers/llvm-lib:LibDriver",
+"//llvm/lib/WindowsDriver",
 "//llvm/lib/WindowsManifest",
   ]
   sources = [
Index: llvm/utils/gn/secondary/clang/lib/Driver/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/lib/Driver/BUILD.gn
+++ llvm/utils/gn/secondary/clang/lib/Driver/BUILD.gn
@@ -18,6 +18,7 @@
 "//llvm/lib/BinaryFormat",
 "//llvm/lib/Option",
 "//llvm/lib/Support",
+"//llvm/lib/WindowsDriver",
   ]
   public_deps = [
 # public_dep because public header Options.h includes generated Options.inc.
Index: llvm/lib/WindowsDriver/MSVCPaths.cpp
===
--- /dev/null
+++ llvm/lib/WindowsDriver/MSVCPaths.cpp
@@ -0,0 +1,710 @@
+//===-- MSVCPaths.cpp - MSVC path-parsing helpers -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/WindowsDriver/MSVCPaths.h"
+#include "llvm/ADT/Optional.h"
+#include "llvm/ADT/SmallString.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/Triple.h"
+#include "llvm/ADT/Twine.h"
+#include "llvm/Option/Arg.h"
+#include "llvm/Option/ArgList.h"
+#include "llvm/Support/ConvertUTF.h"
+#include "llvm/Support/Host.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/Process.h"
+#include "llvm/Support/Program.h"
+#include "llvm/Support/VersionTuple.h"
+#include "llvm/Support/VirtualFileSystem.h"
+#include 
+
+#ifdef _WIN32
+#define WIN32_LEAN_AND_MEAN
+#define NOGDI
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+#include 
+#endif
+
+#ifdef _MSC_VER
+// Don't support SetupApi on MinGW.
+#define USE_MSVC_SETUP_API
+
+// Make sure this comes before MSVCSetupApi.h
+#include 
+
+#include "llvm/Support/COM.h"
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wnon-virtual-dtor"
+#endif
+#include "llvm/WindowsDriver/MSVCSetupApi.h"
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
+_COM_SMARTPTR_TYPEDEF(ISetupConfiguration, __uuidof(ISetupConfiguration));
+_COM_SMARTPTR_TYPEDEF(ISetupConfiguration2, __uuidof(ISetupConfiguration2));
+_COM_SMARTPTR_TYPEDEF(ISetupHelper, __uuidof(ISetupHelper));
+_COM_SMARTPTR_TYPEDEF(IEnumSetupInstances, __uuidof(IEnumSetupInstances));
+_COM_SMARTPTR_TYPEDEF(ISetupInstance, __uuidof(ISetupInstance));
+_COM_SMARTPTR_TYPEDEF(ISetupInstance2, __uuidof(ISetupInstance2));
+#endif
+
+static std::string
+getHighestNumericTupleInDirectory(llvm::vfs::FileSystem ,
+  llvm::StringRef Directory) {
+  std::string Highest;
+  llvm::VersionTuple HighestTuple;
+
+  std::error_code EC;
+  for (llvm::vfs::directory_iterator DirIt = VFS.dir_begin(Directory, EC),
+ DirEnd;
+   !EC && DirIt != DirEnd; DirIt.increment(EC)) {
+auto Status = VFS.status(DirIt->path());
+if (!Status || !Status->isDirectory())
+  continue;
+llvm::StringRef CandidateName = llvm::sys::path::filename(DirIt->path());
+

[PATCH] D113738: [LTO] Allow passing -Os/-Oz as the optimization level

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks abandoned this revision.
aeubanks added a comment.

I posted an RFC a while back for basically removing size levels from 
optimization levels but never seriously looked into it: 
https://groups.google.com/g/llvm-dev/c/NrZsR8OZTts/m/P5t14TKaAQAJ


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113738

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

[PATCH] D119841: [OpenMP] Pass AMDGPU math libraries into the linker wrapper

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 409043.
jhuber6 added a comment.

Removing `-lm` semantics so it is linked by default. Also adding the flag to the
tested output.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119841

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/amdgpu-openmp-toolchain.c


Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -77,3 +77,6 @@
 
 // RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 -lm --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode %s 2>&1 
| FileCheck %s --check-prefix=CHECK-LIB-DEVICE
 // CHECK-LIB-DEVICE: 
{{.*}}llvm-link{{.*}}ocml.bc"{{.*}}ockl.bc"{{.*}}oclc_daz_opt_on.bc"{{.*}}oclc_unsafe_math_off.bc"{{.*}}oclc_finite_only_off.bc"{{.*}}oclc_correctly_rounded_sqrt_on.bc"{{.*}}oclc_wavefrontsize64_on.bc"{{.*}}oclc_isa_version_803.bc"
+
+// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 -lm --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode 
-fopenmp-new-driver %s 2>&1 | FileCheck %s --check-prefix=CHECK-LIB-DEVICE-NEW
+// CHECK-LIB-DEVICE-NEW: 
{{.*}}clang-linker-wrapper{{.*}}-target-library=amdgcn-amd-amdhsa-gfx803={{.*}}ocml.bc"{{.*}}ockl.bc"{{.*}}oclc_daz_opt_on.bc"{{.*}}oclc_unsafe_math_off.bc"{{.*}}oclc_finite_only_off.bc"{{.*}}oclc_correctly_rounded_sqrt_on.bc"{{.*}}oclc_wavefrontsize64_on.bc"{{.*}}oclc_isa_version_803.bc"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -8191,6 +8191,29 @@
 }
   }
 
+  // Get the AMDGPU math libraries.
+  // FIXME: This method is bad, remove once AMDGPU has a proper math library
+  // (see AMDGCN::OpenMPLinker::constructLLVMLinkCommand).
+  for (auto  : llvm::make_range(OpenMPTCRange.first, OpenMPTCRange.second)) {
+const ToolChain *TC = I.second;
+
+if (!TC->getTriple().isAMDGPU() || Args.hasArg(options::OPT_nogpulib))
+  continue;
+
+const ArgList  = C.getArgsForToolChain(TC, "", Action::OFK_OpenMP);
+StringRef Arch = TCArgs.getLastArgValue(options::OPT_march_EQ);
+const toolchains::ROCMToolChain RocmTC(TC->getDriver(), TC->getTriple(),
+   TCArgs);
+
+SmallVector BCLibs =
+RocmTC.getCommonDeviceLibNames(TCArgs, Arch.str());
+
+for (StringRef LibName : BCLibs)
+  CmdArgs.push_back(
+  Args.MakeArgString("-target-library=" + TC->getTripleString() + "-" +
+ Arch + "=" + LibName));
+  }
+
   if (D.isUsingLTO(/* IsOffload */ true)) {
 // Pass in target features for each toolchain.
 for (auto  :


Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -77,3 +77,6 @@
 
 // RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx803 -lm --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode %s 2>&1 | FileCheck %s --check-prefix=CHECK-LIB-DEVICE
 // CHECK-LIB-DEVICE: {{.*}}llvm-link{{.*}}ocml.bc"{{.*}}ockl.bc"{{.*}}oclc_daz_opt_on.bc"{{.*}}oclc_unsafe_math_off.bc"{{.*}}oclc_finite_only_off.bc"{{.*}}oclc_correctly_rounded_sqrt_on.bc"{{.*}}oclc_wavefrontsize64_on.bc"{{.*}}oclc_isa_version_803.bc"
+
+// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx803 -lm --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode -fopenmp-new-driver %s 2>&1 | FileCheck %s --check-prefix=CHECK-LIB-DEVICE-NEW
+// CHECK-LIB-DEVICE-NEW: {{.*}}clang-linker-wrapper{{.*}}-target-library=amdgcn-amd-amdhsa-gfx803={{.*}}ocml.bc"{{.*}}ockl.bc"{{.*}}oclc_daz_opt_on.bc"{{.*}}oclc_unsafe_math_off.bc"{{.*}}oclc_finite_only_off.bc"{{.*}}oclc_correctly_rounded_sqrt_on.bc"{{.*}}oclc_wavefrontsize64_on.bc"{{.*}}oclc_isa_version_803.bc"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -8191,6 +8191,29 @@
 }
   }
 
+  // Get the AMDGPU math libraries.
+  // FIXME: This method is bad, remove once AMDGPU has a proper math library
+  // (see AMDGCN::OpenMPLinker::constructLLVMLinkCommand).
+  for (auto  : llvm::make_range(OpenMPTCRange.first, OpenMPTCRange.second)) {
+const ToolChain *TC = I.second;
+
+if (!TC->getTriple().isAMDGPU() || Args.hasArg(options::OPT_nogpulib))

[PATCH] D119841: [OpenMP] Pass AMDGPU math libraries into the linker wrapper

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:8205
+if (llvm::find(LibraryArgs, "m") == LibraryArgs.end() && !D.CCCIsCXX())
+  continue;
+

JonChesterfield wrote:
> jhuber6 wrote:
> > jdoerfert wrote:
> > > I'd switch the conditions.
> > > 
> > > More importantly, does this require that the user passes -lm to the 
> > > linker invocation? I'm not convinced we should not always link these in.
> > Yes, would save some time assuming most codes are C++
> > 
> > So I figured I'd copy the same semantics of how `-lm` works where you need 
> > to specify it for C but not C++. We could just pass this in all the time, 
> > but since linking it in currently required `-lm` I copied that.
> re: always linking these libraries in, regardless of -lm, it's probably 
> better to link them by default and effectively ignore -lm.
> 
> I'd like to keep it guarded by -nogpulib or similar so that people can still 
> opt out of the rocm device library stack entirely.
Opting out of "optional" gpu libraries is fine. I want to avoid that one needs 
to add linking flags etc. for OpenMP. We link libdevice by default too, so this 
is no different (as both contain math function impl etc.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119841

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

[PATCH] D119792: [Clang] [P2025] Analyze only potential scopes for NRVO

[Evgeny Shulgin via Phabricator via cfe-commits]

Izaron added a comment.

In D119792#3324354 , @Quuxplusone 
wrote:

> I think it would be an extremely good idea to commit all 20 of these test 
> cases to clang/test/CodeGenCXX/, with their current behavior, as a 
> preliminary patch. Then, D119792  can more 
> clearly show (1) what behavior it's changing, (2) what behavior it's keeping 
> the same, and (3) the fact that it's not regressing any behavior.  Also, 
> you'll help future-maintainers by giving them some extra test cases that have 
> already been identified as interesting, even if you personally aren't 
> changing behavior related to those particular test cases.
>
> (I recently took the same tactic with D119772 
>  as a preliminary for D119184 
>  + D119778 
> , and it was very helpful, at least to me. 
> :))

That's a superb idea, thanks! I will soon add all the cases to 
`clang/test/CodeGenCXX/nrvo.cpp` in an isolated patch. It indeed will 
explicitly show improvements in future patches and prevent silent NRVO 
regression.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119792

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

[PATCH] D119651: [clang] Fix evaluation context type for consteval function calls in instantiations

[Evgeny Shulgin via Phabricator via cfe-commits]

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

I've added an assert that will prevent similar bugs. Let's look if we're good 
with this one?
Here is the list of eval contexts:
https://github.com/llvm/llvm-project/blob/87b218b42b14e392aa0363a413d440b77bf04bd4/clang/include/clang/Sema/Sema.h#L1191-L1239
Should we also check for `PotentiallyEvaluatedIfUsed` or it is too much?
Looks like only two eval contexts from the list may be evaluated in run-time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119651

Files:
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/SemaCXX/cxx2a-consteval.cpp


Index: clang/test/SemaCXX/cxx2a-consteval.cpp
===
--- clang/test/SemaCXX/cxx2a-consteval.cpp
+++ clang/test/SemaCXX/cxx2a-consteval.cpp
@@ -613,6 +613,24 @@
 
 } // namespace unevaluated
 
+namespace templated {
+
+consteval int f(int v) {
+  return v;
+}
+
+template 
+consteval int g(T a) {
+  // Previously this call was rejected due to incorrect evaluation context
+  // type in instantiations. Now we show that this call is OK.
+  int n = f(a);
+  return n;
+}
+
+static_assert(g(100) == 100);
+
+} // namespace templated
+
 namespace PR50779 {
 struct derp {
   int b = 0;
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -5326,8 +5326,13 @@
 Var->setImplicitlyInline();
 
   if (OldVar->getInit()) {
-EnterExpressionEvaluationContext Evaluated(
-*this, Sema::ExpressionEvaluationContext::PotentiallyEvaluated, Var);
+ExpressionEvaluationContext Context =
+ExpressionEvaluationContext::PotentiallyEvaluated;
+// If current context is constant evaluated, the variable initializer
+// context is also constant evaluated
+if (isConstantEvaluated())
+  Context = ExpressionEvaluationContext::ConstantEvaluated;
+EnterExpressionEvaluationContext Evaluated(*this, Context, Var);
 
 // Instantiate the initializer.
 ExprResult Init;
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -16637,6 +16637,11 @@
 ExpressionEvaluationContextRecord::ExpressionKind ExprContext) {
   ExprEvalContexts.emplace_back(NewContext, ExprCleanupObjects.size(), Cleanup,
 LambdaContextDecl, ExprContext);
+  assert(
+  !(ExprEvalContexts.back().Context ==
+ExpressionEvaluationContext::PotentiallyEvaluated &&
+ExprEvalContexts[ExprEvalContexts.size() - 2].isConstantEvaluated()) &&
+  "Can't have an evaluated context within an unevaluated context!");
 
   // Discarded statements and immediate contexts nested in other
   // discarded statements or immediate context are themselves


Index: clang/test/SemaCXX/cxx2a-consteval.cpp
===
--- clang/test/SemaCXX/cxx2a-consteval.cpp
+++ clang/test/SemaCXX/cxx2a-consteval.cpp
@@ -613,6 +613,24 @@
 
 } // namespace unevaluated
 
+namespace templated {
+
+consteval int f(int v) {
+  return v;
+}
+
+template 
+consteval int g(T a) {
+  // Previously this call was rejected due to incorrect evaluation context
+  // type in instantiations. Now we show that this call is OK.
+  int n = f(a);
+  return n;
+}
+
+static_assert(g(100) == 100);
+
+} // namespace templated
+
 namespace PR50779 {
 struct derp {
   int b = 0;
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -5326,8 +5326,13 @@
 Var->setImplicitlyInline();
 
   if (OldVar->getInit()) {
-EnterExpressionEvaluationContext Evaluated(
-*this, Sema::ExpressionEvaluationContext::PotentiallyEvaluated, Var);
+ExpressionEvaluationContext Context =
+ExpressionEvaluationContext::PotentiallyEvaluated;
+// If current context is constant evaluated, the variable initializer
+// context is also constant evaluated
+if (isConstantEvaluated())
+  Context = ExpressionEvaluationContext::ConstantEvaluated;
+EnterExpressionEvaluationContext Evaluated(*this, Context, Var);
 
 // Instantiate the initializer.
 ExprResult Init;
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -16637,6 +16637,11 @@
 ExpressionEvaluationContextRecord::ExpressionKind ExprContext) {
   ExprEvalContexts.emplace_back(NewContext, ExprCleanupObjects.size(), Cleanup,
  

[PATCH] D119841: [OpenMP] Pass AMDGPU math libraries into the linker wrapper

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

I'm not confident it's only attributes that we rely on mlink-builtin-bitcode 
patching up, that could be poor phrasing on my part.

Making the pipeline robust to underspecified IR input may be easier (and 
arguably more useful) than changing the rocm library to be compiled for a given 
target.




Comment at: clang/lib/Driver/ToolChains/Clang.cpp:8205
+if (llvm::find(LibraryArgs, "m") == LibraryArgs.end() && !D.CCCIsCXX())
+  continue;
+

jhuber6 wrote:
> jdoerfert wrote:
> > I'd switch the conditions.
> > 
> > More importantly, does this require that the user passes -lm to the linker 
> > invocation? I'm not convinced we should not always link these in.
> Yes, would save some time assuming most codes are C++
> 
> So I figured I'd copy the same semantics of how `-lm` works where you need to 
> specify it for C but not C++. We could just pass this in all the time, but 
> since linking it in currently required `-lm` I copied that.
re: always linking these libraries in, regardless of -lm, it's probably better 
to link them by default and effectively ignore -lm.

I'd like to keep it guarded by -nogpulib or similar so that people can still 
opt out of the rocm device library stack entirely.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119841

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

[PATCH] D118428: [clang-cl] Support the /JMC flag

[Yuanfang Chen via Phabricator via cfe-commits]

ychen added a comment.

In D118428#3312621 , @ychen wrote:

> In D118428#3312440 , @paulkirth 
> wrote:
>
>> Hi,
>>
>> We have two failing test cases on Fuchsia's clang canary builder on Windows 
>> x64.
>>
>> LLVM :: Instrumentation/JustMyCode/jmc-instrument-x86.ll 
>> LLVM :: Instrumentation/JustMyCode/jmc-instrument.ll
>>
>> First seen here: 
>> https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-windows-x64/b8822587673277278177/overview
>>
>> These are JustMyCode tests, added in this patch, and it appears these tests 
>> may need to be adjusted.
>>
>> You can find the full output in the linked builders, but here is a sample 
>> output from one of the tests. It seems to me like the lit file may just need 
>> to be adjusted slightly?
>>
>>   Script:
>>   --
>>   : 'RUN: at line 1';   c:\b\s\w\ir\x\w\staging\llvm_build\bin\opt.exe 
>> -jmc-instrument -S < 
>> C:\b\s\w\ir\x\w\llvm-llvm-project\llvm\test\Instrumentation\JustMyCode\jmc-instrument-x86.ll
>>  | c:\b\s\w\ir\x\w\staging\llvm_build\bin\filecheck.exe 
>> C:\b\s\w\ir\x\w\llvm-llvm-project\llvm\test\Instrumentation\JustMyCode\jmc-instrument-x86.ll
>>   --
>>   Exit Code: 1
>>   
>>   Command Output (stdout):
>>   --
>>   $ ":" "RUN: at line 1"
>>   $ "c:\b\s\w\ir\x\w\staging\llvm_build\bin\opt.exe" "-jmc-instrument" "-S"
>>   $ "c:\b\s\w\ir\x\w\staging\llvm_build\bin\filecheck.exe" 
>> "C:\b\s\w\ir\x\w\llvm-llvm-project\llvm\test\Instrumentation\JustMyCode\jmc-instrument-x86.ll"
>>   # command stderr:
>>   
>> C:\b\s\w\ir\x\w\llvm-llvm-project\llvm\test\Instrumentation\JustMyCode\jmc-instrument-x86.ll:5:10:
>>  error: CHECK: expected string not found in input
>>   ; CHECK: @"_A85D9D03_x@c" = internal unnamed_addr global i8 1, section 
>> ".msvcjmc", align 1, !dbg !0
>>^
>>   :6:34: note: scanning from here
>>   $_JustMyCode_Default = comdat any
>>^
>>   :8:1: note: possible intended match here
>>   @"_A8764FDD_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", 
>> align 1, !dbg !0
>>   ^
>>   
>>   Input file: 
>>   Check file: 
>> C:\b\s\w\ir\x\w\llvm-llvm-project\llvm\test\Instrumentation\JustMyCode\jmc-instrument-x86.ll
>>   
>>   -dump-input=help explains the following input dump.
>>   
>>   Input was:
>>   <<
>>  1: ; ModuleID = '' 
>>  2: source_filename = "" 
>>  3: target datalayout = 
>> "e-m:x-p:32:32-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32-a:0:32-S32"
>>  
>>  4: target triple = "i386-pc-windows-msvc" 
>>  5:  
>>  6: $_JustMyCode_Default = comdat any 
>>   check:5'0  X error: no match found
>>  7:  
>>   check:5'0 ~
>>  8: @"_A8764FDD_x@c" = internal unnamed_addr global i8 1, 
>> section ".msvcjmc", align 1, !dbg !0 
>>   check:5'0 
>> ~~~
>>   check:5'1 ?
>>possible intended match
>>  9: @llvm.used = appending global [1 x i8*] [i8* bitcast (void 
>> (i8*)* @_JustMyCode_Default to i8*)], section "llvm.metadata" 
>>   check:5'0 
>> ~
>> 10:  
>>   check:5'0 ~
>> 11: define void @w1() #0 !dbg !10 { 
>>   check:5'0 
>> 12:  call x86_fastcallcc void @__CheckForDebuggerJustMyCode(i8* 
>> inreg noundef @"_A8764FDD_x@c") 
>>   check:5'0 
>> 
>> 13:  ret void 
>>   check:5'0 ~~
>>  .
>>  .
>>  .
>>   >>
>>   
>>   error: command failed with exit status: 1
>>   
>>   --
>>
>> If fixing the test will take a long time, can you revert until one is ready?
>
> Reverted in b380a31de084a540cfa38 
> . 
> Thanks. I'll take a look.

Relanded in f927021410691bc261 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118428

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

[PATCH] D119207: [CUDA][SPIRV] Assign global address space to CUDA kernel arguments

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:10322
 ABIArgInfo SPIRVABIInfo::classifyKernelArgumentType(QualType Ty) const {
-  if (getContext().getLangOpts().HIP) {
+  if (getContext().getLangOpts().CUDAIsDevice) {
 // Coerce pointer arguments with default address space to CrossWorkGroup

shangwuyao wrote:
> jlebar wrote:
> > I am surprised by this change.  Is the language mode HIP only when 
> > compiling for device?  Or are you intentionally changing the behavior in 
> > HIP mode?
> > 
> > Same in SPIR.h
> We are targeting SPIRV so //I think// "compiling for device" is implied, I 
> will let others comment on this to see if the assumption is correct. So this 
> function can only be called when compiling for device, and won't be called 
> when compiling for host. 
> 
> Also tried compiling for device and host separately to see where exactly does 
> the code diverge (to make sure those two functions are not called when 
> compiling for host):
> 1. This `classifyKernelArgumentType()` function is called from [[ 
> https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CGCall.cpp#L774-L777
>  | here ]], which is only enabled when the calling convention is 
> `SPIR_KERNEL`. And when compiling for host, the calling convention is `C`.
> 
> 2. For the SPIR.h file, the `TargetInfo::adjust` function is called both when 
> compiling for host and for device, see [[ 
> https://github.com/llvm/llvm-project/blob/main/clang/lib/Basic/Targets/SPIR.h#L142-L157
>  | here ]], while the `setAddressSpaceMap` function is only called when 
> compiling for device (SPIRV).
> 
> In conclusion, those two functions won't be reached when compiling for host.
LGTM. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119207

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

[PATCH] D119792: [Clang] [P2025] Analyze only potential scopes for NRVO

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added a reviewer: mizvekov.
Quuxplusone added a comment.

The code is above my pay grade, but FWIW, I super support the intent of this 
patch! Let's get p2025 support into Clang! :)

> The collection of common cases contains 20 examples: §4.1. Examples. Here is 
> the current status of these examples:
>
> [OK] 13 out of 20 examples are working in Clang as expected.
> [FAIL] 13th example: should be considered separately (as part of fixing 
> consteval code)
> [FAIL] 14th example: should be considered separately (as I haven't looked yet 
> how CXXCatchStmt works).
> [FAIL] 18th example: is unfixable now because of Clang's architecture: my 
> comment on the issue.
> [OK with the patch] 7th, 8th, 11th, 15th example: are working with this patch.

I think it would be an extremely good idea to commit all 20 of these test cases 
to clang/test/CodeGenCXX/, with their current behavior, as a preliminary patch. 
Then, D119792  can more clearly show (1) what 
behavior it's changing, (2) what behavior it's keeping the same, and (3) the 
fact that it's not regressing any behavior.  Also, you'll help 
future-maintainers by giving them some extra test cases that have already been 
identified as interesting, even if you personally aren't changing behavior 
related to those particular test cases.

(I recently took the same tactic with D119772 
 as a preliminary for D119184 
 + D119778 
, and it was very helpful, at least to me. :))


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119792

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

[PATCH] D119597: [clang-format][NFC] Give State.Stack.back() a meaningful name

[Björn Schäpers via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8da319fe770b: [clang-format][NFC] Give State.Stack.back() a 
meaningful name (authored by HazardyKnusperkeks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119597

Files:
  clang/lib/Format/ContinuationIndenter.cpp

Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -263,9 +263,10 @@
   if (Style.Language == FormatStyle::LK_TextProto) {
 // We need this in order to deal with the bin packing of text fields at
 // global scope.
-State.Stack.back().AvoidBinPacking = true;
-State.Stack.back().BreakBeforeParameter = true;
-State.Stack.back().AlignColons = false;
+auto  = State.Stack.back();
+CurrentState.AvoidBinPacking = true;
+CurrentState.BreakBeforeParameter = true;
+CurrentState.AlignColons = false;
   }
 
   // The first token has already been indented and thus consumed.
@@ -276,8 +277,9 @@
 bool ContinuationIndenter::canBreak(const LineState ) {
   const FormatToken  = *State.NextToken;
   const FormatToken  = *Current.Previous;
+  const auto  = State.Stack.back();
   assert( == Current.Previous);
-  if (!Current.CanBreakBefore && !(State.Stack.back().BreakBeforeClosingBrace &&
+  if (!Current.CanBreakBefore && !(CurrentState.BreakBeforeClosingBrace &&
Current.closesBlockOrBlockTypeList(Style)))
 return false;
   // The opening "{" of a braced list has to be on the same line as the first
@@ -296,7 +298,7 @@
   State.LowestLevelOnLine < State.StartOfLineLevel &&
   State.LowestLevelOnLine < Current.NestingLevel)
 return false;
-  if (Current.isMemberAccess() && State.Stack.back().ContainsUnwrappedBuilder)
+  if (Current.isMemberAccess() && CurrentState.ContainsUnwrappedBuilder)
 return false;
 
   // Don't create a 'hanging' indent if there are multiple blocks in a single
@@ -316,18 +318,19 @@
   // If binary operators are moved to the next line (including commas for some
   // styles of constructor initializers), that's always ok.
   if (!Current.isOneOf(TT_BinaryOperator, tok::comma) &&
-  State.Stack.back().NoLineBreakInOperand)
+  CurrentState.NoLineBreakInOperand)
 return false;
 
   if (Previous.is(tok::l_square) && Previous.is(TT_ObjCMethodExpr))
 return false;
 
-  return !State.Stack.back().NoLineBreak;
+  return !CurrentState.NoLineBreak;
 }
 
 bool ContinuationIndenter::mustBreak(const LineState ) {
   const FormatToken  = *State.NextToken;
   const FormatToken  = *Current.Previous;
+  const auto  = State.Stack.back();
   if (Style.BraceWrapping.BeforeLambdaBody && Current.CanBreakBefore &&
   Current.is(TT_LambdaLBrace) && Previous.isNot(TT_LineComment)) {
 auto LambdaBodyLength = getLengthToMatchingParen(Current, State.Stack);
@@ -335,10 +338,10 @@
   }
   if (Current.MustBreakBefore || Current.is(TT_InlineASMColon))
 return true;
-  if (State.Stack.back().BreakBeforeClosingBrace &&
+  if (CurrentState.BreakBeforeClosingBrace &&
   Current.closesBlockOrBlockTypeList(Style))
 return true;
-  if (State.Stack.back().BreakBeforeClosingParen && Current.is(tok::r_paren))
+  if (CurrentState.BreakBeforeClosingParen && Current.is(tok::r_paren))
 return true;
   if (Previous.is(tok::semi) && State.LineContainsContinuedForLoopSection)
 return true;
@@ -349,7 +352,7 @@
 return true;
   // Avoid producing inconsistent states by requiring breaks where they are not
   // permitted for C# generic type constraints.
-  if (State.Stack.back().IsCSharpGenericTypeConstraint &&
+  if (CurrentState.IsCSharpGenericTypeConstraint &&
   Previous.isNot(TT_CSharpGenericTypeConstraintComma))
 return false;
   if ((startsNextParameter(Current, Style) || Previous.is(tok::semi) ||
@@ -364,10 +367,10 @@
 Previous.isNot(tok::question)) ||
(!Style.BreakBeforeTernaryOperators &&
 Previous.is(TT_ConditionalExpr))) &&
-  State.Stack.back().BreakBeforeParameter && !Current.isTrailingComment() &&
+  CurrentState.BreakBeforeParameter && !Current.isTrailingComment() &&
   !Current.isOneOf(tok::r_paren, tok::r_brace))
 return true;
-  if (State.Stack.back().IsChainedConditional &&
+  if (CurrentState.IsChainedConditional &&
   ((Style.BreakBeforeTernaryOperators && Current.is(TT_ConditionalExpr) &&
 Current.is(tok::colon)) ||
(!Style.BreakBeforeTernaryOperators && Previous.is(TT_ConditionalExpr) &&
@@ -389,7 +392,7 @@
   if (BreakConstructorInitializersToken.is(TT_CtorInitializerColon) &&
   (State.Column + State.Line->Last->TotalLength - Previous.TotalLength >
getColumnLimit(State) ||
-   State.Stack.back().BreakBeforeParameter) &&
+   

[PATCH] D113369: [clang-format] Extend SpaceBeforeParens for requires

[Björn Schäpers 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 rGb786a4aefeda: [clang-format] Extend SpaceBeforeParens for 
requires (authored by HazardyKnusperkeks).

Changed prior to commit:
  https://reviews.llvm.org/D113369?vs=406450=409013#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113369

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

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -15012,6 +15012,84 @@
   verifyFormat("X A::operator++();", SpaceAfterOverloadedOperator);
   verifyFormat("some_object.operator++();", SpaceAfterOverloadedOperator);
   verifyFormat("auto func() -> int;", SpaceAfterOverloadedOperator);
+
+  auto SpaceAfterRequires = getLLVMStyle();
+  SpaceAfterRequires.SpaceBeforeParens = FormatStyle::SBPO_Custom;
+  EXPECT_FALSE(
+  SpaceAfterRequires.SpaceBeforeParensOptions.AfterRequiresInClause);
+  EXPECT_FALSE(
+  SpaceAfterRequires.SpaceBeforeParensOptions.AfterRequiresInExpression);
+  verifyFormat("void f(auto x)\n"
+   "  requires requires(int i) { x + i; }\n"
+   "{}",
+   SpaceAfterRequires);
+  verifyFormat("void f(auto x)\n"
+   "  requires(requires(int i) { x + i; })\n"
+   "{}",
+   SpaceAfterRequires);
+  verifyFormat("if (requires(int i) { x + i; })\n"
+   "  return;",
+   SpaceAfterRequires);
+  verifyFormat("bool b = requires(int i) { x + i; };", SpaceAfterRequires);
+  verifyFormat("template \n"
+   "  requires(Foo)\n"
+   "class Bar;",
+   SpaceAfterRequires);
+
+  SpaceAfterRequires.SpaceBeforeParensOptions.AfterRequiresInClause = true;
+  verifyFormat("void f(auto x)\n"
+   "  requires requires(int i) { x + i; }\n"
+   "{}",
+   SpaceAfterRequires);
+  verifyFormat("void f(auto x)\n"
+   "  requires (requires(int i) { x + i; })\n"
+   "{}",
+   SpaceAfterRequires);
+  verifyFormat("if (requires(int i) { x + i; })\n"
+   "  return;",
+   SpaceAfterRequires);
+  verifyFormat("bool b = requires(int i) { x + i; };", SpaceAfterRequires);
+  verifyFormat("template \n"
+   "  requires (Foo)\n"
+   "class Bar;",
+   SpaceAfterRequires);
+
+  SpaceAfterRequires.SpaceBeforeParensOptions.AfterRequiresInClause = false;
+  SpaceAfterRequires.SpaceBeforeParensOptions.AfterRequiresInExpression = true;
+  verifyFormat("void f(auto x)\n"
+   "  requires requires (int i) { x + i; }\n"
+   "{}",
+   SpaceAfterRequires);
+  verifyFormat("void f(auto x)\n"
+   "  requires(requires (int i) { x + i; })\n"
+   "{}",
+   SpaceAfterRequires);
+  verifyFormat("if (requires (int i) { x + i; })\n"
+   "  return;",
+   SpaceAfterRequires);
+  verifyFormat("bool b = requires (int i) { x + i; };", SpaceAfterRequires);
+  verifyFormat("template \n"
+   "  requires(Foo)\n"
+   "class Bar;",
+   SpaceAfterRequires);
+
+  SpaceAfterRequires.SpaceBeforeParensOptions.AfterRequiresInClause = true;
+  verifyFormat("void f(auto x)\n"
+   "  requires requires (int i) { x + i; }\n"
+   "{}",
+   SpaceAfterRequires);
+  verifyFormat("void f(auto x)\n"
+   "  requires (requires (int i) { x + i; })\n"
+   "{}",
+   SpaceAfterRequires);
+  verifyFormat("if (requires (int i) { x + i; })\n"
+   "  return;",
+   SpaceAfterRequires);
+  verifyFormat("bool b = requires (int i) { x + i; };", SpaceAfterRequires);
+  verifyFormat("template \n"
+   "  requires (Foo)\n"
+   "class Bar;",
+   SpaceAfterRequires);
 }
 
 TEST_F(FormatTest, SpaceAfterLogicalNot) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3247,8 +3247,12 @@
   if (Right.is(tok::l_paren)) {
 if (Left.is(TT_TemplateCloser) && Right.isNot(TT_FunctionTypeLParen))
   return spaceRequiredBeforeParens(Right);
-if (Left.is(tok::kw_requires))
-  return spaceRequiredBeforeParens(Right);
+if (Left.isOneOf(TT_RequiresClause, TT_RequiresClauseInARequiresExpression))
+  return Style.SpaceBeforeParensOptions.AfterRequiresInClause ||
+ spaceRequiredBeforeParens(Right);
+if 

[PATCH] D119138: [clang-format] Further improve support for requires expressions

[Björn Schäpers via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGbcd1e4612f4f: [clang-format] Further improve support for 
requires expressions (authored by HazardyKnusperkeks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119138

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/lib/Format/UnwrappedLineParser.h
  clang/unittests/Format/TokenAnnotatorTest.cpp

Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -141,6 +141,9 @@
 "  { t.foo() };\n"
 "} && Bar && Baz;");
   ASSERT_EQ(Tokens.size(), 35u) << Tokens;
+  EXPECT_TOKEN(Tokens[8], tok::kw_requires, TT_RequiresExpression);
+  EXPECT_TOKEN(Tokens[9], tok::l_paren, TT_RequiresExpressionLParen);
+  EXPECT_TOKEN(Tokens[13], tok::l_brace, TT_RequiresExpressionLBrace);
   EXPECT_TOKEN(Tokens[23], tok::ampamp, TT_BinaryOperator);
   EXPECT_TOKEN(Tokens[28], tok::ampamp, TT_BinaryOperator);
 
@@ -148,6 +151,7 @@
 "requires C1 && (C21 || C22 && C2e) && C3\n"
 "struct Foo;");
   ASSERT_EQ(Tokens.size(), 36u) << Tokens;
+  EXPECT_TOKEN(Tokens[5], tok::kw_requires, TT_RequiresClause);
   EXPECT_TOKEN(Tokens[6], tok::identifier, TT_Unknown);
   EXPECT_EQ(Tokens[6]->FakeLParens.size(), 1u);
   EXPECT_TOKEN(Tokens[10], tok::ampamp, TT_BinaryOperator);
@@ -163,6 +167,7 @@
"requires (C1 && (C21 || C22 && C2e) && C3)\n"
"struct Foo;");
   ASSERT_EQ(Tokens.size(), 38u) << Tokens;
+  EXPECT_TOKEN(Tokens[5], tok::kw_requires, TT_RequiresClause);
   EXPECT_TOKEN(Tokens[7], tok::identifier, TT_Unknown);
   EXPECT_EQ(Tokens[7]->FakeLParens.size(), 1u);
   EXPECT_TOKEN(Tokens[11], tok::ampamp, TT_BinaryOperator);
@@ -173,6 +178,127 @@
   EXPECT_EQ(Tokens[32]->FakeRParens, 1u);
   EXPECT_TOKEN(Tokens[33], tok::r_paren, TT_Unknown);
   EXPECT_TRUE(Tokens[33]->ClosesRequiresClause);
+
+  Tokens = annotate("template \n"
+"void foo(T) noexcept requires Bar;");
+  ASSERT_EQ(Tokens.size(), 18u) << Tokens;
+  EXPECT_TOKEN(Tokens[11], tok::kw_requires, TT_RequiresClause);
+
+  Tokens = annotate("template \n"
+"struct S {\n"
+"  void foo() const requires Bar;\n"
+"  void bar() const & requires Baz;\n"
+"  void bar() && requires Baz2;\n"
+"  void baz() const & noexcept requires Baz;\n"
+"  void baz() && noexcept requires Baz2;\n"
+"};\n"
+"\n"
+"void S::bar() const & requires Baz { }");
+  ASSERT_EQ(Tokens.size(), 85u) << Tokens;
+  EXPECT_TOKEN(Tokens[13], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TOKEN(Tokens[25], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TOKEN(Tokens[36], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TOKEN(Tokens[49], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TOKEN(Tokens[61], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TOKEN(Tokens[77], tok::kw_requires, TT_RequiresClause);
+
+  Tokens = annotate("void Class::member() && requires(Constant) {}");
+  ASSERT_EQ(Tokens.size(), 14u) << Tokens;
+  EXPECT_TOKEN(Tokens[7], tok::kw_requires, TT_RequiresClause);
+
+  Tokens = annotate("void Class::member() && requires(Constant) {}");
+  ASSERT_EQ(Tokens.size(), 17u) << Tokens;
+  EXPECT_TOKEN(Tokens[7], tok::kw_requires, TT_RequiresClause);
+
+  Tokens =
+  annotate("void Class::member() && requires(Namespace::Constant) {}");
+  ASSERT_EQ(Tokens.size(), 19u) << Tokens;
+  EXPECT_TOKEN(Tokens[7], tok::kw_requires, TT_RequiresClause);
+
+  Tokens = annotate("void Class::member() && requires(typename "
+"Namespace::Outer::Inner::Constant) {}");
+  ASSERT_EQ(Tokens.size(), 24u) << Tokens;
+  EXPECT_TOKEN(Tokens[7], tok::kw_requires, TT_RequiresClause);
+}
+
+TEST_F(TokenAnnotatorTest, UnderstandsRequiresExpressions) {
+  auto Tokens = annotate("bool b = requires(int i) { i + 5; };");
+  ASSERT_EQ(Tokens.size(), 16u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::kw_requires, TT_RequiresExpression);
+  EXPECT_TOKEN(Tokens[4], tok::l_paren, TT_RequiresExpressionLParen);
+  EXPECT_TOKEN(Tokens[8], tok::l_brace, TT_RequiresExpressionLBrace);
+
+  Tokens = annotate("if (requires(int i) { i + 5; }) return;");
+  ASSERT_EQ(Tokens.size(), 17u) << Tokens;
+  EXPECT_TOKEN(Tokens[2], tok::kw_requires, TT_RequiresExpression);
+  EXPECT_TOKEN(Tokens[3], tok::l_paren, TT_RequiresExpressionLParen);
+  EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_RequiresExpressionLBrace);
+
+  Tokens = annotate("if (func() && requires(int i) { i + 5; }) return;");
+  ASSERT_EQ(Tokens.size(), 21u) << Tokens;
+  EXPECT_TOKEN(Tokens[6], tok::kw_requires, 

[clang] 8da319f - [clang-format][NFC] Give State.Stack.back() a meaningful name

[Björn Schäpers via cfe-commits]

Author: Björn Schäpers
Date: 2022-02-15T21:37:38+01:00
New Revision: 8da319fe770b21d342a534bf02d2b88fffe667cc

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

LOG: [clang-format][NFC] Give State.Stack.back() a meaningful name

Without that debugging was a hell for me.

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

Added: 


Modified: 
clang/lib/Format/ContinuationIndenter.cpp

Removed: 




diff  --git a/clang/lib/Format/ContinuationIndenter.cpp 
b/clang/lib/Format/ContinuationIndenter.cpp
index 23892be8e9e8..a49e0f307cef 100644
--- a/clang/lib/Format/ContinuationIndenter.cpp
+++ b/clang/lib/Format/ContinuationIndenter.cpp
@@ -263,9 +263,10 @@ LineState ContinuationIndenter::getInitialState(unsigned 
FirstIndent,
   if (Style.Language == FormatStyle::LK_TextProto) {
 // We need this in order to deal with the bin packing of text fields at
 // global scope.
-State.Stack.back().AvoidBinPacking = true;
-State.Stack.back().BreakBeforeParameter = true;
-State.Stack.back().AlignColons = false;
+auto  = State.Stack.back();
+CurrentState.AvoidBinPacking = true;
+CurrentState.BreakBeforeParameter = true;
+CurrentState.AlignColons = false;
   }
 
   // The first token has already been indented and thus consumed.
@@ -276,8 +277,9 @@ LineState ContinuationIndenter::getInitialState(unsigned 
FirstIndent,
 bool ContinuationIndenter::canBreak(const LineState ) {
   const FormatToken  = *State.NextToken;
   const FormatToken  = *Current.Previous;
+  const auto  = State.Stack.back();
   assert( == Current.Previous);
-  if (!Current.CanBreakBefore && !(State.Stack.back().BreakBeforeClosingBrace 
&&
+  if (!Current.CanBreakBefore && !(CurrentState.BreakBeforeClosingBrace &&
Current.closesBlockOrBlockTypeList(Style)))
 return false;
   // The opening "{" of a braced list has to be on the same line as the first
@@ -296,7 +298,7 @@ bool ContinuationIndenter::canBreak(const LineState ) 
{
   State.LowestLevelOnLine < State.StartOfLineLevel &&
   State.LowestLevelOnLine < Current.NestingLevel)
 return false;
-  if (Current.isMemberAccess() && State.Stack.back().ContainsUnwrappedBuilder)
+  if (Current.isMemberAccess() && CurrentState.ContainsUnwrappedBuilder)
 return false;
 
   // Don't create a 'hanging' indent if there are multiple blocks in a single
@@ -316,18 +318,19 @@ bool ContinuationIndenter::canBreak(const LineState 
) {
   // If binary operators are moved to the next line (including commas for some
   // styles of constructor initializers), that's always ok.
   if (!Current.isOneOf(TT_BinaryOperator, tok::comma) &&
-  State.Stack.back().NoLineBreakInOperand)
+  CurrentState.NoLineBreakInOperand)
 return false;
 
   if (Previous.is(tok::l_square) && Previous.is(TT_ObjCMethodExpr))
 return false;
 
-  return !State.Stack.back().NoLineBreak;
+  return !CurrentState.NoLineBreak;
 }
 
 bool ContinuationIndenter::mustBreak(const LineState ) {
   const FormatToken  = *State.NextToken;
   const FormatToken  = *Current.Previous;
+  const auto  = State.Stack.back();
   if (Style.BraceWrapping.BeforeLambdaBody && Current.CanBreakBefore &&
   Current.is(TT_LambdaLBrace) && Previous.isNot(TT_LineComment)) {
 auto LambdaBodyLength = getLengthToMatchingParen(Current, State.Stack);
@@ -335,10 +338,10 @@ bool ContinuationIndenter::mustBreak(const LineState 
) {
   }
   if (Current.MustBreakBefore || Current.is(TT_InlineASMColon))
 return true;
-  if (State.Stack.back().BreakBeforeClosingBrace &&
+  if (CurrentState.BreakBeforeClosingBrace &&
   Current.closesBlockOrBlockTypeList(Style))
 return true;
-  if (State.Stack.back().BreakBeforeClosingParen && Current.is(tok::r_paren))
+  if (CurrentState.BreakBeforeClosingParen && Current.is(tok::r_paren))
 return true;
   if (Previous.is(tok::semi) && State.LineContainsContinuedForLoopSection)
 return true;
@@ -349,7 +352,7 @@ bool ContinuationIndenter::mustBreak(const LineState 
) {
 return true;
   // Avoid producing inconsistent states by requiring breaks where they are not
   // permitted for C# generic type constraints.
-  if (State.Stack.back().IsCSharpGenericTypeConstraint &&
+  if (CurrentState.IsCSharpGenericTypeConstraint &&
   Previous.isNot(TT_CSharpGenericTypeConstraintComma))
 return false;
   if ((startsNextParameter(Current, Style) || Previous.is(tok::semi) ||
@@ -364,10 +367,10 @@ bool ContinuationIndenter::mustBreak(const LineState 
) {
 Previous.isNot(tok::question)) ||
(!Style.BreakBeforeTernaryOperators &&
 Previous.is(TT_ConditionalExpr))) &&
-  State.Stack.back().BreakBeforeParameter && !Current.isTrailingComment() 
&&
+  

[clang] b786a4a - [clang-format] Extend SpaceBeforeParens for requires

[Björn Schäpers via cfe-commits]

Author: Björn Schäpers
Date: 2022-02-15T21:37:36+01:00
New Revision: b786a4aefedaf68eb7710d9c01a18ad1d0c820b7

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

LOG: [clang-format] Extend SpaceBeforeParens for requires

We can now configure the space between requires and the following paren,
seperate for clauses and expressions.

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

Added: 


Modified: 
clang/docs/ClangFormatStyleOptions.rst
clang/include/clang/Format/Format.h
clang/lib/Format/Format.cpp
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index e89523d0e5676..8d6c80fb87e5a 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -4004,6 +4004,27 @@ the configuration (without a prefix: ``Auto``).
void operator++ (int a);vs.void operator++(int a);
object.operator++ (10);object.operator++(10);
 
+  * ``bool AfterRequiresInClause`` If ``true``, put space between requires 
keyword in a requires clause and
+opening parentheses, if there is one.
+
+.. code-block:: c++
+
+   true:  false:
+   templatevs.template
+   requires (A && B)requires(A && B)
+   ......
+
+  * ``bool AfterRequiresInExpression`` If ``true``, put space between requires 
keyword in a requires expression
+and opening parentheses.
+
+.. code-block:: c++
+
+   true:  false:
+   templatevs.template
+   concept C = requires (T t) {   concept C = requires(T t) {
+ ......
+   }  }
+
   * ``bool BeforeNonEmptyParentheses`` If ``true``, put a space before opening 
parentheses only if the
 parentheses are not empty.
 

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index 9d6df403230da..c86a700097160 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -3594,6 +3594,25 @@ struct FormatStyle {
 ///object.operator++ (10);object.operator++(10);
 /// \endcode
 bool AfterOverloadedOperator;
+/// If ``true``, put space between requires keyword in a requires clause 
and
+/// opening parentheses, if there is one.
+/// \code
+///true:  false:
+///templatevs.template
+///requires (A && B)requires(A && B)
+///......
+/// \endcode
+bool AfterRequiresInClause;
+/// If ``true``, put space between requires keyword in a requires 
expression
+/// and opening parentheses.
+/// \code
+///true:  false:
+///templatevs.template
+///concept C = requires (T t) {   concept C = requires(T t) {
+///  ......
+///}  }
+/// \endcode
+bool AfterRequiresInExpression;
 /// If ``true``, put a space before opening parentheses only if the
 /// parentheses are not empty.
 /// \code
@@ -3607,7 +3626,8 @@ struct FormatStyle {
 : AfterControlStatements(false), AfterForeachMacros(false),
   AfterFunctionDeclarationName(false),
   AfterFunctionDefinitionName(false), AfterIfMacros(false),
-  AfterOverloadedOperator(false), BeforeNonEmptyParentheses(false) {}
+  AfterOverloadedOperator(false), AfterRequiresInClause(false),
+  AfterRequiresInExpression(false), BeforeNonEmptyParentheses(false) {}
 
 bool operator==(const SpaceBeforeParensCustom ) const {
   return AfterControlStatements == Other.AfterControlStatements &&
@@ -3617,6 +3637,8 @@ struct FormatStyle {
  AfterFunctionDefinitionName == Other.AfterFunctionDefinitionName 
&&
  AfterIfMacros == Other.AfterIfMacros &&
  AfterOverloadedOperator == Other.AfterOverloadedOperator &&
+ AfterRequiresInClause == Other.AfterRequiresInClause &&
+ AfterRequiresInExpression == Other.AfterRequiresInExpression &&
  BeforeNonEmptyParentheses == Other.BeforeNonEmptyParentheses;
 }
   };

diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index 8aa12867c35f1..6acd850cac2cb 100644
--- a/clang/lib/Format/Format.cpp
+++ 

[clang] bcd1e46 - [clang-format] Further improve support for requires expressions

[Björn Schäpers via cfe-commits]

Author: Björn Schäpers
Date: 2022-02-15T21:37:35+01:00
New Revision: bcd1e4612f4fa2d12a51f0708c619ae3b2deaa2b

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

LOG: [clang-format] Further improve support for requires expressions

Detect requires expressions in more unusable contexts. This is far from
perfect, but currently we have no good metric to decide between a
requires expression and a trailing requires clause.

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

Added: 


Modified: 
clang/lib/Format/UnwrappedLineParser.cpp
clang/lib/Format/UnwrappedLineParser.h
clang/unittests/Format/TokenAnnotatorTest.cpp

Removed: 




diff  --git a/clang/lib/Format/UnwrappedLineParser.cpp 
b/clang/lib/Format/UnwrappedLineParser.cpp
index e2d5197988be6..25db8ee2e7549 100644
--- a/clang/lib/Format/UnwrappedLineParser.cpp
+++ b/clang/lib/Format/UnwrappedLineParser.cpp
@@ -40,6 +40,12 @@ class FormatTokenSource {
   // getNextToken().
   virtual FormatToken *peekNextToken() = 0;
 
+  // Returns the token that would be returned after the next N calls to
+  // getNextToken(). N needs to be greater than zero, and small enough that
+  // there are still tokens. Check for tok::eof with N-1 before calling it with
+  // N.
+  virtual FormatToken *peekNextToken(int N) = 0;
+
   // Returns whether we are at the end of the file.
   // This can be 
diff erent from whether getNextToken() returned an eof token
   // when the FormatTokenSource is a view on a part of the token stream.
@@ -137,6 +143,13 @@ class ScopedMacroState : public FormatTokenSource {
 return PreviousTokenSource->peekNextToken();
   }
 
+  FormatToken *peekNextToken(int N) override {
+assert(N > 0);
+if (eof())
+  return 
+return PreviousTokenSource->peekNextToken(N);
+  }
+
   bool isEOF() override { return PreviousTokenSource->isEOF(); }
 
   unsigned getPosition() override { return PreviousTokenSource->getPosition(); 
}
@@ -257,6 +270,16 @@ class IndexedTokenSource : public FormatTokenSource {
 return Tokens[Next];
   }
 
+  FormatToken *peekNextToken(int N) override {
+assert(N > 0);
+int Next = Position + N;
+LLVM_DEBUG({
+  llvm::dbgs() << "Peeking (+" << (N - 1) << ") ";
+  dbgToken(Next);
+});
+return Tokens[Next];
+  }
+
   bool isEOF() override { return Tokens[Position]->is(tok::eof); }
 
   unsigned getPosition() override {
@@ -1537,9 +1560,12 @@ void 
UnwrappedLineParser::parseStructuralElement(IfStmtKind *IfKind,
 case tok::kw_concept:
   parseConcept();
   return;
-case tok::kw_requires:
-  parseRequiresClause();
-  return;
+case tok::kw_requires: {
+  bool ParsedClause = parseRequires();
+  if (ParsedClause)
+return;
+  break;
+}
 case tok::kw_enum:
   // Ignore if this is part of "template is(tok::less)) {
@@ -2206,9 +2232,12 @@ void UnwrappedLineParser::parseParens(TokenType 
AmpAmpTokenType) {
   else
 nextToken();
   break;
-case tok::kw_requires:
-  parseRequiresExpression();
+case tok::kw_requires: {
+  auto RequiresToken = FormatTok;
+  nextToken();
+  parseRequiresExpression(RequiresToken);
   break;
+}
 case tok::ampamp:
   if (AmpAmpTokenType != TT_Unknown)
 FormatTok->setType(AmpAmpTokenType);
@@ -2783,28 +2812,163 @@ void UnwrappedLineParser::parseConcept() {
   addUnwrappedLine();
 }
 
+/// \brief Parses a requires, decides if it is a clause or an expression.
+/// \pre The current token has to be the requires keyword.
+/// \returns true if it parsed a clause.
+bool clang::format::UnwrappedLineParser::parseRequires() {
+  assert(FormatTok->Tok.is(tok::kw_requires) && "'requires' expected");
+  auto RequiresToken = FormatTok;
+
+  // We try to guess if it is a requires clause, or a requires expression. For
+  // that we first consume the keyword and check the next token.
+  nextToken();
+
+  switch (FormatTok->Tok.getKind()) {
+  case tok::l_brace:
+// This can only be an expression, never a clause.
+parseRequiresExpression(RequiresToken);
+return false;
+  case tok::l_paren:
+// Clauses and expression can start with a paren, it's unclear what we 
have.
+break;
+  default:
+// All other tokens can only be a clause.
+parseRequiresClause(RequiresToken);
+return true;
+  }
+
+  // Looking forward we would have to decide if there are function declaration
+  // like arguments to the requires expression:
+  // requires (T t) {
+  // Or there is a constraint expression for the requires clause:
+  // requires (C && ...
+
+  // But first let's look behind.
+  auto *PreviousNonComment = RequiresToken->getPreviousNonComment();
+
+  if (!PreviousNonComment ||
+  

[PATCH] D114714: [C++20][Modules] Add enumerations for partition modules and stream them.

[Nathan Sidwell via Phabricator via cfe-commits]

urnathan added inline comments.



Comment at: clang/include/clang/Basic/Module.h:109
 
-/// This is a C++ Modules TS module interface unit.
+/// This is a C++ Modules TS or C++20 module interface unit.
 ModuleInterfaceUnit,

iains wrote:
> urnathan wrote:
> > I think it's confusing to continue to refer to modules-ts modules at this 
> > point.  Is that really necessary?
> > The specific confusion here is that does 'ModuleInterfaceUnit' mean one of 
> > two different things depending on compilation mode, or is it a single thing 
> > with two different names?
> In this case, I re-used the enumeration since the modules-ts / c++20 modules 
> are disambiguated by the -fmodules-ts flag.
> 
> So, yes, the enum value does have two uses depending on compilation mode.  I 
> can amend the comment to try and make this clear, would that help?
> 
> I have been trying not to regress anything for modules-ts (and certainly for 
> clang modules) - if someone makes a decision to retire modules-ts then there 
> is probably a bunch of simplification that could be made.  
> 
> With the extra bit to represent the enumeration, we have more space so we 
> *could* have different names for the modules-ts/C++20 interfaces (although I 
> suspect that will just make more code at the use sites, and would prefer not 
> to go down that route).  
> 
IMHO 'modules-ts' is not a useful thing distinct from 'c++20 modules'.  The 
semantics of the TS itself were unclear or broken in places, and only resolved 
once things got into the std (via 1103/Atom).  I think the semantics of 
'-fmodules-ts' should be the module-specific semantics of C++20 as applied to 
whatever version of the std being selected (and I'd be fine making it 
Buyer-Beware for anything before C++20 anyway). 

But, if you don't want to bite that bullet right now, a clarifying note would 
be helpful.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114714

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

[PATCH] D119363: [clang] Add `ObjCProtocolLoc` to represent protocol references

[David Goldman via Phabricator via cfe-commits]

dgoldman added a comment.

In D119363#3324024 , @sammccall wrote:

> In D119363#3323867 , @dgoldman 
> wrote:
>
>> In D119363#3323778 , @sammccall 
>> wrote:
>>
>>> I'm a bit concerned about the parent map vs ASTMatchFinder's view being out 
>>> of sync: we'll have a ProtocolLoc node that has a parent but the parent 
>>> doesn't have the child.
>>>
>>> I'm not sure this breaks anything immediately, but I think we should also 
>>> make these nodes visible to matchers, even if there's no specific matcher 
>>> yet.
>>
>> Hmm I can try to do it - what do I need to modify to make them visible to 
>> matchers?
>
> I don't remember specifically, I think ASTMatchFinderImpl has a 
> RecursiveASTVisitor that you need to extend? I'm not sure actually how you 
> would observe these nodes cleanly without matchers (hacks like 
> `has(hasParent())` maybe?) So maybe it's best to ignore it in this patch and 
> add basic matchers in a next one

It looks like ASTMatchFinder.cpp has a `MatchASTVisitor` which I think is what 
you meant, but yeah I think it's probably best to do in a follow up unless you 
think it'll break something here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119363

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

[PATCH] D114714: [C++20][Modules] Add enumerations for partition modules and stream them.

[Iain Sandoe via Phabricator via cfe-commits]

iains added inline comments.



Comment at: clang/include/clang/Basic/Module.h:109
 
-/// This is a C++ Modules TS module interface unit.
+/// This is a C++ Modules TS or C++20 module interface unit.
 ModuleInterfaceUnit,

urnathan wrote:
> I think it's confusing to continue to refer to modules-ts modules at this 
> point.  Is that really necessary?
> The specific confusion here is that does 'ModuleInterfaceUnit' mean one of 
> two different things depending on compilation mode, or is it a single thing 
> with two different names?
In this case, I re-used the enumeration since the modules-ts / c++20 modules 
are disambiguated by the -fmodules-ts flag.

So, yes, the enum value does have two uses depending on compilation mode.  I 
can amend the comment to try and make this clear, would that help?

I have been trying not to regress anything for modules-ts (and certainly for 
clang modules) - if someone makes a decision to retire modules-ts then there is 
probably a bunch of simplification that could be made.  

With the extra bit to represent the enumeration, we have more space so we 
*could* have different names for the modules-ts/C++20 interfaces (although I 
suspect that will just make more code at the use sites, and would prefer not to 
go down that route).  




Comment at: clang/include/clang/Basic/Module.h:517-518
 
+  /// Is this a module partition.
+  /// ??? : make a bit and stream it?
+

urnathan wrote:
> ???
thanks, will remove this.



Comment at: clang/include/clang/Basic/Module.h:520
+
+  bool isPartition() const { return Name.find(':') != std::string::npos; }
+

urnathan wrote:
> isModulePartition?  
works for me, will do.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114714

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

[PATCH] D119363: [clang] Add `ObjCProtocolLoc` to represent protocol references

[David Goldman via Phabricator via cfe-commits]

dgoldman updated this revision to Diff 409005.
dgoldman marked 3 inline comments as done.
dgoldman added a comment.

Template fixes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119363

Files:
  clang/include/clang/AST/ASTFwd.h
  clang/include/clang/AST/ASTTypeTraits.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/TypeLoc.h
  clang/lib/AST/ASTTypeTraits.cpp
  clang/lib/AST/ParentMapContext.cpp
  clang/unittests/AST/RecursiveASTVisitorTest.cpp

Index: clang/unittests/AST/RecursiveASTVisitorTest.cpp
===
--- clang/unittests/AST/RecursiveASTVisitorTest.cpp
+++ clang/unittests/AST/RecursiveASTVisitorTest.cpp
@@ -60,6 +60,12 @@
   EndTraverseEnum,
   StartTraverseTypedefType,
   EndTraverseTypedefType,
+  StartTraverseObjCInterface,
+  EndTraverseObjCInterface,
+  StartTraverseObjCProtocol,
+  EndTraverseObjCProtocol,
+  StartTraverseObjCProtocolLoc,
+  EndTraverseObjCProtocolLoc,
 };
 
 class CollectInterestingEvents
@@ -97,18 +103,43 @@
 return Ret;
   }
 
+  bool TraverseObjCInterfaceDecl(ObjCInterfaceDecl *ID) {
+Events.push_back(VisitEvent::StartTraverseObjCInterface);
+bool Ret = RecursiveASTVisitor::TraverseObjCInterfaceDecl(ID);
+Events.push_back(VisitEvent::EndTraverseObjCInterface);
+
+return Ret;
+  }
+
+  bool TraverseObjCProtocolDecl(ObjCProtocolDecl *PD) {
+Events.push_back(VisitEvent::StartTraverseObjCProtocol);
+bool Ret = RecursiveASTVisitor::TraverseObjCProtocolDecl(PD);
+Events.push_back(VisitEvent::EndTraverseObjCProtocol);
+
+return Ret;
+  }
+
+  bool TraverseObjCProtocolLoc(ObjCProtocolLoc ProtocolLoc) {
+Events.push_back(VisitEvent::StartTraverseObjCProtocolLoc);
+bool Ret = RecursiveASTVisitor::TraverseObjCProtocolLoc(ProtocolLoc);
+Events.push_back(VisitEvent::EndTraverseObjCProtocolLoc);
+
+return Ret;
+  }
+
   std::vector takeEvents() && { return std::move(Events); }
 
 private:
   std::vector Events;
 };
 
-std::vector collectEvents(llvm::StringRef Code) {
+std::vector collectEvents(llvm::StringRef Code,
+  const Twine  = "input.cc") {
   CollectInterestingEvents Visitor;
   clang::tooling::runToolOnCode(
   std::make_unique(
   [&](clang::ASTContext ) { Visitor.TraverseAST(Ctx); }),
-  Code);
+  Code, FileName);
   return std::move(Visitor).takeEvents();
 }
 } // namespace
@@ -139,3 +170,28 @@
   VisitEvent::EndTraverseTypedefType,
   VisitEvent::EndTraverseEnum));
 }
+
+TEST(RecursiveASTVisitorTest, InterfaceDeclWithProtocols) {
+  // Check interface and its protocols are visited.
+  llvm::StringRef Code = R"cpp(
+  @protocol Foo
+  @end
+  @protocol Bar
+  @end
+
+  @interface SomeObject 
+  @end
+  )cpp";
+
+  EXPECT_THAT(collectEvents(Code, "input.m"),
+  ElementsAre(VisitEvent::StartTraverseObjCProtocol,
+  VisitEvent::EndTraverseObjCProtocol,
+  VisitEvent::StartTraverseObjCProtocol,
+  VisitEvent::EndTraverseObjCProtocol,
+  VisitEvent::StartTraverseObjCInterface,
+  VisitEvent::StartTraverseObjCProtocolLoc,
+  VisitEvent::EndTraverseObjCProtocolLoc,
+  VisitEvent::StartTraverseObjCProtocolLoc,
+  VisitEvent::EndTraverseObjCProtocolLoc,
+  VisitEvent::EndTraverseObjCInterface));
+}
Index: clang/lib/AST/ParentMapContext.cpp
===
--- clang/lib/AST/ParentMapContext.cpp
+++ clang/lib/AST/ParentMapContext.cpp
@@ -330,6 +330,9 @@
 DynTypedNode createDynTypedNode(const NestedNameSpecifierLoc ) {
   return DynTypedNode::create(Node);
 }
+template <> DynTypedNode createDynTypedNode(const ObjCProtocolLoc ) {
+  return DynTypedNode::create(Node);
+}
 /// @}
 
 /// A \c RecursiveASTVisitor that builds a map from nodes to their
@@ -398,11 +401,14 @@
 }
   }
 
+  template  static bool isNull(T Node) { return !Node; }
+  static bool isNull(ObjCProtocolLoc Node) { return false; }
+
   template 
   bool TraverseNode(T Node, MapNodeTy MapNode, BaseTraverseFn BaseTraverse,
 MapTy *Parents) {
-if (!Node)
+if (isNull(Node))
   return true;
 addParent(MapNode, Parents);
 ParentStack.push_back(createDynTypedNode(Node));
@@ -433,6 +439,12 @@
 AttrNode, AttrNode, [&] { return VisitorBase::TraverseAttr(AttrNode); },
 );
   }
+  bool TraverseObjCProtocolLoc(ObjCProtocolLoc ProtocolLocNode) {
+return TraverseNode(
+ProtocolLocNode, DynTypedNode::create(ProtocolLocNode),
+[&] { return VisitorBase::TraverseObjCProtocolLoc(ProtocolLocNode); },
+);
+  }
 
   // Using generic TraverseNode for Stmt would 

[PATCH] D118893: [C++20][Modules] Track valid import state.

[Nathan Sidwell via Phabricator via cfe-commits]

urnathan added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1543
+def err_import_not_allowed_here : Error<
+  "imports must be contiguous and immediately follow the module declaration">;
+def err_import_in_global_fragment : Error<

iains wrote:
> urnathan wrote:
> > "imports must immediately follow a module declaration"?  (the contiguous 
> > isn't adding anything IMHO)
> um, maybe I need two diagnostics then - the "contiguous" aspect applies when 
> imports are split by a non-import statement.
> 
> Selecting between the two case on the basis of a flag seems unproductive 
> here.  Would two diagnostics seem more reasonable to you?
> 
I don't follow.  If the imports are split by a non-import, then the latter ones 
don't immediately follow the module declaration.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118893

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

[PATCH] D119615: [CUDA][HIP] Do not promote constexpr var with non-constant initializer

[Yaxun Liu via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
yaxunl marked an inline comment as done.
Closed by commit rG73b22935a7a8: [CUDA][HIP] Do not promote constexpr var with 
non-constant initializer (authored by yaxunl).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D119615?vs=408145=409003#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119615

Files:
  clang/lib/Sema/SemaCUDA.cpp
  clang/test/SemaCUDA/constexpr-var.cu

Index: clang/test/SemaCUDA/constexpr-var.cu
===
--- /dev/null
+++ clang/test/SemaCUDA/constexpr-var.cu
@@ -0,0 +1,105 @@
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device -x hip %s \
+// RUN:   -fsyntax-only -verify
+// RUN: %clang_cc1 -triple x86_64 -x hip %s \
+// RUN:   -fsyntax-only -verify=host
+
+// host-no-diagnostics
+
+#include "Inputs/cuda.h"
+
+// Test constexpr var initialized with address of a const var.
+// Both are promoted to device side.
+
+namespace Test1 {
+const int a = 1;
+
+struct B {
+static constexpr const int *p = 
+__device__ static constexpr const int *const p2 = 
+};
+
+// Const variable 'a' is treated as __constant__ on device side,
+// therefore its address can be used as initializer for another
+// device variable.
+
+__device__ void f() {
+  int y = a;
+  constexpr const int *x = B::p;
+  constexpr const int *z = B::p2;
+}
+}
+
+// Test constexpr var initialized with address of a non-cost var.
+// Neither is promoted to device side.
+
+namespace Test2 {
+int a = 1;
+// expected-note@-1{{host variable declared here}}
+
+struct B {
+static constexpr int *const p = 
+// expected-note@-1{{const variable cannot be emitted on device side due to dynamic initialization}}
+};
+
+__device__ void f() {
+  int y = a;
+  // expected-error@-1{{reference to __host__ variable 'a' in __device__ function}}
+  const int *const *x = ::p;
+  // expected-error@-1{{reference to __host__ variable 'p' in __device__ function}}
+  // ToDo: use of non-promotable constexpr variable in device compilation should be treated as
+  // ODR-use and diagnosed.
+  const int *const z = B::p;
+}
+}
+
+// Test constexpr device var initialized with address of a non-const host var, __shared var,
+// __managed__ var, __device__ var, __constant__ var, texture var, surface var.
+
+namespace Test3 {
+struct textureReference {
+  int desc;
+};
+
+enum ReadMode {
+  ElementType = 0,
+  NormalizedFloat = 1
+};
+
+template 
+struct __attribute__((device_builtin_texture_type)) texture : public textureReference {
+};
+
+struct surfaceReference {
+  int desc;
+};
+
+template 
+struct __attribute__((device_builtin_surface_type)) surface : public surfaceReference {
+};
+
+// Partial specialization over `void`.
+template
+struct __attribute__((device_builtin_surface_type)) surface : public surfaceReference {
+};
+
+texture tex;
+surface surf;
+
+int a = 1;
+__shared__ int b;
+__managed__ int c = 1;
+__device__ int d = 1;
+__constant__ int e = 1;
+struct B {
+__device__ static constexpr int *const p1 = 
+// expected-error@-1{{dynamic initialization is not supported for __device__, __constant__, __shared__, and __managed__ variables}}
+__device__ static constexpr int *const p2 = 
+// expected-error@-1{{dynamic initialization is not supported for __device__, __constant__, __shared__, and __managed__ variables}}
+__device__ static constexpr int *const p3 = 
+// expected-error@-1{{dynamic initialization is not supported for __device__, __constant__, __shared__, and __managed__ variables}}
+__device__ static constexpr int *const p4 = 
+__device__ static constexpr int *const p5 = 
+__device__ static constexpr texture *const p6 = 
+__device__ static constexpr surface *const p7 = 
+};
+}
Index: clang/lib/Sema/SemaCUDA.cpp
===
--- clang/lib/Sema/SemaCUDA.cpp
+++ clang/lib/Sema/SemaCUDA.cpp
@@ -145,9 +145,11 @@
 Sema::CUDAVariableTarget Sema::IdentifyCUDATarget(const VarDecl *Var) {
   if (Var->hasAttr())
 return CVT_Unified;
-  if (Var->isConstexpr() && !hasExplicitAttr(Var))
-return CVT_Both;
-  if (Var->getType().isConstQualified() && Var->hasAttr() &&
+  // Only constexpr and const variabless with implicit constant attribute
+  // are emitted on both sides. Such variables are promoted to device side
+  // only if they have static constant intializers on device side.
+  if ((Var->isConstexpr() || Var->getType().isConstQualified()) &&
+  Var->hasAttr() &&
   !hasExplicitAttr(Var))
 return CVT_Both;
   if (Var->hasAttr() || Var->hasAttr() ||
@@ -718,9 +720,9 @@
   !VD->hasAttr() && !VD->hasAttr() &&
   (VD->isFileVarDecl() || VD->isStaticDataMember()) &&
   !IsDependentVar(VD) &&
-  

[clang] 73b2293 - [CUDA][HIP] Do not promote constexpr var with non-constant initializer

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2022-02-15T15:15:55-05:00
New Revision: 73b22935a7a863679021598db6a45fcfb62cd321

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

LOG: [CUDA][HIP] Do not promote constexpr var with non-constant initializer

constexpr var may be initialized with address of non-const variable.
In this case the initializer is not constant in device compilation.
This has been handled for const vars but not for constexpr vars.

This patch makes handling of const var and constexpr var
consistent.

Reviewed by: Artem Belevich

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

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

Added: 
clang/test/SemaCUDA/constexpr-var.cu

Modified: 
clang/lib/Sema/SemaCUDA.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaCUDA.cpp b/clang/lib/Sema/SemaCUDA.cpp
index efa38554bc83f..e4e34d687dd2b 100644
--- a/clang/lib/Sema/SemaCUDA.cpp
+++ b/clang/lib/Sema/SemaCUDA.cpp
@@ -145,9 +145,11 @@ Sema::CUDAFunctionTarget Sema::IdentifyCUDATarget(const 
FunctionDecl *D,
 Sema::CUDAVariableTarget Sema::IdentifyCUDATarget(const VarDecl *Var) {
   if (Var->hasAttr())
 return CVT_Unified;
-  if (Var->isConstexpr() && !hasExplicitAttr(Var))
-return CVT_Both;
-  if (Var->getType().isConstQualified() && Var->hasAttr() &&
+  // Only constexpr and const variabless with implicit constant attribute
+  // are emitted on both sides. Such variables are promoted to device side
+  // only if they have static constant intializers on device side.
+  if ((Var->isConstexpr() || Var->getType().isConstQualified()) &&
+  Var->hasAttr() &&
   !hasExplicitAttr(Var))
 return CVT_Both;
   if (Var->hasAttr() || Var->hasAttr() ||
@@ -718,9 +720,9 @@ void Sema::MaybeAddCUDAConstantAttr(VarDecl *VD) {
   !VD->hasAttr() && !VD->hasAttr() &&
   (VD->isFileVarDecl() || VD->isStaticDataMember()) &&
   !IsDependentVar(VD) &&
-  (VD->isConstexpr() || (VD->getType().isConstQualified() &&
- HasAllowedCUDADeviceStaticInitializer(
- *this, VD, CICK_DeviceOrConstant {
+  ((VD->isConstexpr() || VD->getType().isConstQualified()) &&
+   HasAllowedCUDADeviceStaticInitializer(*this, VD,
+ CICK_DeviceOrConstant))) {
 VD->addAttr(CUDAConstantAttr::CreateImplicit(getASTContext()));
   }
 }

diff  --git a/clang/test/SemaCUDA/constexpr-var.cu 
b/clang/test/SemaCUDA/constexpr-var.cu
new file mode 100644
index 0..a028ba8f6c1a1
--- /dev/null
+++ b/clang/test/SemaCUDA/constexpr-var.cu
@@ -0,0 +1,105 @@
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device -x hip %s \
+// RUN:   -fsyntax-only -verify
+// RUN: %clang_cc1 -triple x86_64 -x hip %s \
+// RUN:   -fsyntax-only -verify=host
+
+// host-no-diagnostics
+
+#include "Inputs/cuda.h"
+
+// Test constexpr var initialized with address of a const var.
+// Both are promoted to device side.
+
+namespace Test1 {
+const int a = 1;
+
+struct B {
+static constexpr const int *p = 
+__device__ static constexpr const int *const p2 = 
+};
+
+// Const variable 'a' is treated as __constant__ on device side,
+// therefore its address can be used as initializer for another
+// device variable.
+
+__device__ void f() {
+  int y = a;
+  constexpr const int *x = B::p;
+  constexpr const int *z = B::p2;
+}
+}
+
+// Test constexpr var initialized with address of a non-cost var.
+// Neither is promoted to device side.
+
+namespace Test2 {
+int a = 1;
+// expected-note@-1{{host variable declared here}}
+
+struct B {
+static constexpr int *const p = 
+// expected-note@-1{{const variable cannot be emitted on device side due 
to dynamic initialization}}
+};
+
+__device__ void f() {
+  int y = a;
+  // expected-error@-1{{reference to __host__ variable 'a' in __device__ 
function}}
+  const int *const *x = ::p;
+  // expected-error@-1{{reference to __host__ variable 'p' in __device__ 
function}}
+  // ToDo: use of non-promotable constexpr variable in device compilation 
should be treated as
+  // ODR-use and diagnosed.
+  const int *const z = B::p;
+}
+}
+
+// Test constexpr device var initialized with address of a non-const host var, 
__shared var,
+// __managed__ var, __device__ var, __constant__ var, texture var, surface var.
+
+namespace Test3 {
+struct textureReference {
+  int desc;
+};
+
+enum ReadMode {
+  ElementType = 0,
+  NormalizedFloat = 1
+};
+
+template 
+struct __attribute__((device_builtin_texture_type)) texture : public 
textureReference {
+};
+
+struct surfaceReference {
+  int desc;
+};
+
+template 
+struct __attribute__((device_builtin_surface_type)) surface : public 
surfaceReference {
+};
+
+// Partial specialization over `void`.
+template
+struct 

[PATCH] D119792: [Clang] [P2025] Analyze only potential scopes for NRVO

[Evgeny Shulgin via Phabricator via cfe-commits]

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

Fix Scope::dumpImpl with more precise log


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119792

Files:
  clang/include/clang/Sema/Scope.h
  clang/lib/Sema/Scope.cpp
  clang/test/CodeGenCXX/nrvo.cpp

Index: clang/test/CodeGenCXX/nrvo.cpp
===
--- clang/test/CodeGenCXX/nrvo.cpp
+++ clang/test/CodeGenCXX/nrvo.cpp
@@ -166,88 +166,19 @@
 
 // CHECK-LABEL: @_Z5test3b(
 // CHECK-NEXT:  entry:
-// CHECK-NEXT:[[X:%.*]] = alloca [[CLASS_X:%.*]], align 1
-// CHECK-NEXT:br i1 [[B:%.*]], label [[IF_THEN:%.*]], label [[IF_END:%.*]]
-// CHECK:   if.then:
 // CHECK-NEXT:call void @_ZN1XC1Ev(%class.X* noundef nonnull align 1 dereferenceable(1) [[AGG_RESULT:%.*]]) #[[ATTR5]]
-// CHECK-NEXT:br label [[RETURN:%.*]]
-// CHECK:   if.end:
-// CHECK-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[CLASS_X]], %class.X* [[X]], i32 0, i32 0
-// CHECK-NEXT:call void @llvm.lifetime.start.p0i8(i64 1, i8* nonnull [[TMP0]]) #[[ATTR5]]
-// CHECK-NEXT:call void @_ZN1XC1Ev(%class.X* noundef nonnull align 1 dereferenceable(1) [[X]]) #[[ATTR5]]
-// CHECK-NEXT:call void @_ZN1XC1ERKS_(%class.X* noundef nonnull align 1 dereferenceable(1) [[AGG_RESULT]], %class.X* noundef nonnull align 1 dereferenceable(1) [[X]]) #[[ATTR5]]
-// CHECK-NEXT:call void @_ZN1XD1Ev(%class.X* noundef nonnull align 1 dereferenceable(1) [[X]]) #[[ATTR5]]
-// CHECK-NEXT:call void @llvm.lifetime.end.p0i8(i64 1, i8* nonnull [[TMP0]]) #[[ATTR5]]
-// CHECK-NEXT:br label [[RETURN]]
-// CHECK:   return:
 // CHECK-NEXT:ret void
 //
-// CHECK-EH-03-LABEL: @_Z5test3b(
-// CHECK-EH-03-NEXT:  entry:
-// CHECK-EH-03-NEXT:[[X:%.*]] = alloca [[CLASS_X:%.*]], align 1
-// CHECK-EH-03-NEXT:br i1 [[B:%.*]], label [[IF_THEN:%.*]], label [[IF_END:%.*]]
-// CHECK-EH-03:   if.then:
-// CHECK-EH-03-NEXT:call void @_ZN1XC1Ev(%class.X* noundef nonnull align 1 dereferenceable(1) [[AGG_RESULT:%.*]])
-// CHECK-EH-03-NEXT:br label [[RETURN:%.*]]
-// CHECK-EH-03:   if.end:
-// CHECK-EH-03-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[CLASS_X]], %class.X* [[X]], i32 0, i32 0
-// CHECK-EH-03-NEXT:call void @llvm.lifetime.start.p0i8(i64 1, i8* nonnull [[TMP0]]) #[[ATTR7]]
-// CHECK-EH-03-NEXT:call void @_ZN1XC1Ev(%class.X* noundef nonnull align 1 dereferenceable(1) [[X]])
-// CHECK-EH-03-NEXT:invoke void @_ZN1XC1ERKS_(%class.X* noundef nonnull align 1 dereferenceable(1) [[AGG_RESULT]], %class.X* noundef nonnull align 1 dereferenceable(1) [[X]])
-// CHECK-EH-03-NEXT:to label [[INVOKE_CONT:%.*]] unwind label [[LPAD:%.*]]
-// CHECK-EH-03:   invoke.cont:
-// CHECK-EH-03-NEXT:call void @_ZN1XD1Ev(%class.X* noundef nonnull align 1 dereferenceable(1) [[X]])
-// CHECK-EH-03-NEXT:call void @llvm.lifetime.end.p0i8(i64 1, i8* nonnull [[TMP0]]) #[[ATTR7]]
-// CHECK-EH-03-NEXT:br label [[RETURN]]
-// CHECK-EH-03:   lpad:
-// CHECK-EH-03-NEXT:[[TMP1:%.*]] = landingpad { i8*, i32 }
-// CHECK-EH-03-NEXT:cleanup
-// CHECK-EH-03-NEXT:invoke void @_ZN1XD1Ev(%class.X* noundef nonnull align 1 dereferenceable(1) [[X]])
-// CHECK-EH-03-NEXT:to label [[INVOKE_CONT1:%.*]] unwind label [[TERMINATE_LPAD:%.*]]
-// CHECK-EH-03:   invoke.cont1:
-// CHECK-EH-03-NEXT:call void @llvm.lifetime.end.p0i8(i64 1, i8* nonnull [[TMP0]]) #[[ATTR7]]
-// CHECK-EH-03-NEXT:resume { i8*, i32 } [[TMP1]]
-// CHECK-EH-03:   return:
-// CHECK-EH-03-NEXT:ret void
-// CHECK-EH-03:   terminate.lpad:
-// CHECK-EH-03-NEXT:[[TMP2:%.*]] = landingpad { i8*, i32 }
-// CHECK-EH-03-NEXT:catch i8* null
-// CHECK-EH-03-NEXT:[[TMP3:%.*]] = extractvalue { i8*, i32 } [[TMP2]], 0
-// CHECK-EH-03-NEXT:call void @__clang_call_terminate(i8* [[TMP3]]) #[[ATTR8]]
-// CHECK-EH-03-NEXT:unreachable
-//
-// CHECK-EH-11-LABEL: @_Z5test3b(
-// CHECK-EH-11-NEXT:  entry:
-// CHECK-EH-11-NEXT:[[X:%.*]] = alloca [[CLASS_X:%.*]], align 1
-// CHECK-EH-11-NEXT:br i1 [[B:%.*]], label [[IF_THEN:%.*]], label [[IF_END:%.*]]
-// CHECK-EH-11:   if.then:
-// CHECK-EH-11-NEXT:call void @_ZN1XC1Ev(%class.X* noundef nonnull align 1 dereferenceable(1) [[AGG_RESULT:%.*]])
-// CHECK-EH-11-NEXT:br label [[RETURN:%.*]]
-// CHECK-EH-11:   if.end:
-// CHECK-EH-11-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[CLASS_X]], %class.X* [[X]], i32 0, i32 0
-// CHECK-EH-11-NEXT:call void @llvm.lifetime.start.p0i8(i64 1, i8* nonnull [[TMP0]]) #[[ATTR7]]
-// CHECK-EH-11-NEXT:call void @_ZN1XC1Ev(%class.X* noundef nonnull align 1 dereferenceable(1) [[X]])
-// CHECK-EH-11-NEXT:invoke void @_ZN1XC1ERKS_(%class.X* noundef nonnull align 1 dereferenceable(1) [[AGG_RESULT]], %class.X* noundef nonnull align 1 dereferenceable(1) [[X]])
-// CHECK-EH-11-NEXT:to label [[INVOKE_CONT:%.*]] 

[PATCH] D119613: [OpenMP] Add support for CPU offloading in new driver

[Joseph Huber via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG24ecafb41327: [OpenMP] Add support for CPU offloading in new 
driver (authored by jhuber6).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119613

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/openmp-offload.c
  clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp

Index: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -646,6 +646,83 @@
 }
 } // namespace amdgcn
 
+namespace generic {
+
+const char *getLDMOption(const llvm::Triple ) {
+  switch (T.getArch()) {
+  case llvm::Triple::x86:
+if (T.isOSIAMCU())
+  return "elf_iamcu";
+return "elf_i386";
+  case llvm::Triple::aarch64:
+return "aarch64linux";
+  case llvm::Triple::aarch64_be:
+return "aarch64linuxb";
+  case llvm::Triple::ppc64:
+return "elf64ppc";
+  case llvm::Triple::ppc64le:
+return "elf64lppc";
+  case llvm::Triple::x86_64:
+if (T.isX32())
+  return "elf32_x86_64";
+return "elf_x86_64";
+  case llvm::Triple::ve:
+return "elf64ve";
+  default:
+return nullptr;
+  }
+}
+
+Expected link(ArrayRef InputFiles, Triple TheTriple,
+   StringRef Arch) {
+  // Create a new file to write the linked device image to.
+  SmallString<128> TempFile;
+  if (Error Err = createOutputFile(sys::path::filename(ExecutableName) + "-" +
+   TheTriple.getArchName() + "-" + Arch,
+   "out", TempFile))
+return std::move(Err);
+
+  // Use the host linker to perform generic offloading. Use the same libraries
+  // and paths as the host application does.
+  SmallVector CmdArgs;
+  CmdArgs.push_back(LinkerUserPath);
+  CmdArgs.push_back("-m");
+  CmdArgs.push_back(getLDMOption(TheTriple));
+  CmdArgs.push_back("-shared");
+  for (auto AI = HostLinkerArgs.begin(), AE = HostLinkerArgs.end(); AI != AE;
+   ++AI) {
+StringRef Arg = *AI;
+if (Arg.startswith("-L"))
+  CmdArgs.push_back(Arg);
+else if (Arg.startswith("-l"))
+  CmdArgs.push_back(Arg);
+else if (Arg.startswith("--as-needed"))
+  CmdArgs.push_back(Arg);
+else if (Arg.startswith("--no-as-needed"))
+  CmdArgs.push_back(Arg);
+else if (Arg.startswith("-rpath")) {
+  CmdArgs.push_back(Arg);
+  CmdArgs.push_back(*(AI + 1));
+} else if (Arg.startswith("-dynamic-linker")) {
+  CmdArgs.push_back(Arg);
+  CmdArgs.push_back(*(AI + 1));
+}
+  }
+  CmdArgs.push_back("-Bsymbolic");
+  CmdArgs.push_back("-o");
+  CmdArgs.push_back(TempFile);
+
+  // Add extracted input files.
+  for (StringRef Input : InputFiles)
+CmdArgs.push_back(Input);
+
+  if (sys::ExecuteAndWait(LinkerUserPath, CmdArgs))
+return createStringError(inconvertibleErrorCode(), "'linker' failed");
+
+  return static_cast(TempFile);
+}
+} // namespace generic
+
 Expected linkDevice(ArrayRef InputFiles,
  Triple TheTriple, StringRef Arch) {
   switch (TheTriple.getArch()) {
@@ -656,7 +733,11 @@
 return amdgcn::link(InputFiles, TheTriple, Arch);
   case Triple::x86:
   case Triple::x86_64:
-// TODO: x86 linking support.
+  case Triple::aarch64:
+  case Triple::aarch64_be:
+  case Triple::ppc64:
+  case Triple::ppc64le:
+return generic::link(InputFiles, TheTriple, Arch);
   default:
 return createStringError(inconvertibleErrorCode(),
  TheTriple.getArchName() +
Index: clang/test/Driver/openmp-offload.c
===
--- clang/test/Driver/openmp-offload.c
+++ clang/test/Driver/openmp-offload.c
@@ -657,3 +657,9 @@
 // RUN:   | FileCheck -check-prefix=CHK-FOPENMP-IS-DEVICE %s
 
 // CHK-FOPENMP-IS-DEVICE: clang{{.*}} "-aux-triple" "powerpc64le-unknown-linux" {{.*}}"-fopenmp-is-device" "-fopenmp-host-ir-file-path" {{.*}}.c"
+
+/// Check arguments to the linker wrapper
+// RUN:   %clang -### -no-canonical-prefixes -target powerpc64le-linux -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -fopenmp-new-driver %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-NEW-DRIVER %s
+
+// CHK-NEW-DRIVER: clang-linker-wrapper{{.*}}"-host-triple" "powerpc64le-unknown-linux"{{.*}}--{{.*}}"-lomp"{{.*}}"-lomptarget"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -8200,14 +8200,19 @@
   ArgStringList FeatureArgs;
   TC->addClangTargetOptions(TCArgs, FeatureArgs, Action::OFK_OpenMP);
   auto FeatureIt = llvm::find(FeatureArgs, "-target-feature");
-  

[clang] 24ecafb - [OpenMP] Add support for CPU offloading in new driver

[Joseph Huber via cfe-commits]

Author: Joseph Huber
Date: 2022-02-15T15:05:30-05:00
New Revision: 24ecafb4132704db513d550f2edfe875d353287f

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

LOG: [OpenMP] Add support for CPU offloading in new driver

This patch adds support for linking CPU offloading applications in the
linker wrapper. We generate the necessary linking job using the host
linker's path and library arguments. This may not be true for more
complex offloading schemes, but this is sufficient for now.

Reviewed By: jdoerfert

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/openmp-offload.c
clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index f87ce3701136..945f62697779 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -8200,14 +8200,19 @@ void LinkerWrapper::ConstructJob(Compilation , const 
JobAction ,
   ArgStringList FeatureArgs;
   TC->addClangTargetOptions(TCArgs, FeatureArgs, Action::OFK_OpenMP);
   auto FeatureIt = llvm::find(FeatureArgs, "-target-feature");
-  CmdArgs.push_back(Args.MakeArgString(
-  "-target-feature=" + TC->getTripleString() + "=" + *(FeatureIt + 
1)));
+  if (FeatureIt != FeatureArgs.end())
+CmdArgs.push_back(
+Args.MakeArgString("-target-feature=" + TC->getTripleString() +
+   "=" + *(FeatureIt + 1)));
 }
 
 // Pass in the bitcode library to be linked during LTO.
 for (auto  :
  llvm::make_range(OpenMPTCRange.first, OpenMPTCRange.second)) {
   const ToolChain *TC = I.second;
+  if (!(TC->getTriple().isNVPTX() || TC->getTriple().isAMDGPU()))
+continue;
+
   const Driver  = TC->getDriver();
   const ArgList  = C.getArgsForToolChain(TC, "", 
Action::OFK_OpenMP);
   StringRef Arch = TCArgs.getLastArgValue(options::OPT_march_EQ);

diff  --git a/clang/test/Driver/openmp-offload.c 
b/clang/test/Driver/openmp-offload.c
index 699a31276d6f..424b484df99b 100644
--- a/clang/test/Driver/openmp-offload.c
+++ b/clang/test/Driver/openmp-offload.c
@@ -657,3 +657,9 @@
 // RUN:   | FileCheck -check-prefix=CHK-FOPENMP-IS-DEVICE %s
 
 // CHK-FOPENMP-IS-DEVICE: clang{{.*}} "-aux-triple" 
"powerpc64le-unknown-linux" {{.*}}"-fopenmp-is-device" 
"-fopenmp-host-ir-file-path" {{.*}}.c"
+
+/// Check arguments to the linker wrapper
+// RUN:   %clang -### -no-canonical-prefixes -target powerpc64le-linux 
-fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -fopenmp-new-driver 
%s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-NEW-DRIVER %s
+
+// CHK-NEW-DRIVER: clang-linker-wrapper{{.*}}"-host-triple" 
"powerpc64le-unknown-linux"{{.*}}--{{.*}}"-lomp"{{.*}}"-lomptarget"

diff  --git a/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp 
b/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
index 65c9a87edf3f..3e3506e05d74 100644
--- a/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ b/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -646,6 +646,83 @@ Expected link(ArrayRef 
InputFiles, Triple TheTriple,
 }
 } // namespace amdgcn
 
+namespace generic {
+
+const char *getLDMOption(const llvm::Triple ) {
+  switch (T.getArch()) {
+  case llvm::Triple::x86:
+if (T.isOSIAMCU())
+  return "elf_iamcu";
+return "elf_i386";
+  case llvm::Triple::aarch64:
+return "aarch64linux";
+  case llvm::Triple::aarch64_be:
+return "aarch64linuxb";
+  case llvm::Triple::ppc64:
+return "elf64ppc";
+  case llvm::Triple::ppc64le:
+return "elf64lppc";
+  case llvm::Triple::x86_64:
+if (T.isX32())
+  return "elf32_x86_64";
+return "elf_x86_64";
+  case llvm::Triple::ve:
+return "elf64ve";
+  default:
+return nullptr;
+  }
+}
+
+Expected link(ArrayRef InputFiles, Triple TheTriple,
+   StringRef Arch) {
+  // Create a new file to write the linked device image to.
+  SmallString<128> TempFile;
+  if (Error Err = createOutputFile(sys::path::filename(ExecutableName) + "-" +
+   TheTriple.getArchName() + "-" + Arch,
+   "out", TempFile))
+return std::move(Err);
+
+  // Use the host linker to perform generic offloading. Use the same libraries
+  // and paths as the host application does.
+  SmallVector CmdArgs;
+  CmdArgs.push_back(LinkerUserPath);
+  CmdArgs.push_back("-m");
+  CmdArgs.push_back(getLDMOption(TheTriple));
+  CmdArgs.push_back("-shared");
+  for (auto AI = HostLinkerArgs.begin(), AE = HostLinkerArgs.end(); AI != AE;
+   ++AI) {
+StringRef Arg = *AI;
+if 

[PATCH] D118893: [C++20][Modules] Track valid import state.

[Iain Sandoe via Phabricator via cfe-commits]

iains added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1543
+def err_import_not_allowed_here : Error<
+  "imports must be contiguous and immediately follow the module declaration">;
+def err_import_in_global_fragment : Error<

urnathan wrote:
> "imports must immediately follow a module declaration"?  (the contiguous 
> isn't adding anything IMHO)
um, maybe I need two diagnostics then - the "contiguous" aspect applies when 
imports are split by a non-import statement.

Selecting between the two case on the basis of a flag seems unproductive here.  
Would two diagnostics seem more reasonable to you?




Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1544-1547
+def err_import_in_global_fragment : Error<
+  "module%select{| partition}0 imports cannot be in the global module 
fragment">;
+def err_import_in_private_fragment : Error<
+  "module%select{| partition}0 imports cannot be in the private module 
fragment">;

urnathan wrote:
> You could I suppose have a single diagnostuc and select between global & 
> private?
good idea, I'll do that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118893

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

[PATCH] D119876: [nfc][codegen] Move RegisterBank[Info].h under CodeGen

[Mircea Trofin via Phabricator via cfe-commits]

mtrofin added inline comments.



Comment at: llvm/include/llvm/CodeGen/RegisterBankInfo.h:220
 : ID(ID), Cost(Cost), OperandsMapping(OperandsMapping),
-  NumOperands(NumOperands) {
-}
+  NumOperands(NumOperands) {}
 

ah - `clang-format` handled the moved file as a new file; but I'd say let's let 
it make these changes, they are goodness anyway (and small)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119876

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

[clang] 1ea3266 - DebugInfo: Don't simplify template names using _BitInt(N)

[David Blaikie via cfe-commits]

Author: David Blaikie
Date: 2022-02-15T11:58:40-08:00
New Revision: 1ea326634b582f5574e0b22b85e5b0c631b30dcf

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

LOG: DebugInfo: Don't simplify template names using _BitInt(N)

_BitInt(N) only encodes the byte size in DWARF, not the bit size, so
can't be reconstituted.

Added: 


Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp
clang/test/CodeGenCXX/debug-info-simple-template-names.cpp

cross-project-tests/debuginfo-tests/clang_llvm_roundtrip/simplified_template_names.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index d8ba5592ad478..91a8f278de5c4 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -5032,6 +5032,15 @@ struct ReconstitutableType : public 
RecursiveASTVisitor {
 Reconstitutable = false;
 return false;
   }
+  bool VisitType(Type *T) {
+// _BitInt(N) isn't reconstitutable because the bit width isn't encoded in
+// the DWARF, only the byte width.
+if (T->isBitIntType()) {
+  Reconstitutable = false;
+  return false;
+}
+return true;
+  }
   bool TraverseEnumType(EnumType *ET) {
 // Unnamed enums can't be reconstituted due to a lack of column info we
 // produce in the DWARF, so we can't get Clang's full name back.

diff  --git a/clang/test/CodeGenCXX/debug-info-simple-template-names.cpp 
b/clang/test/CodeGenCXX/debug-info-simple-template-names.cpp
index 06e83ea6f59eb..d20c9478c363d 100644
--- a/clang/test/CodeGenCXX/debug-info-simple-template-names.cpp
+++ b/clang/test/CodeGenCXX/debug-info-simple-template-names.cpp
@@ -105,4 +105,10 @@ void f() {
 
   f3();
   // CHECK: !DISubprogram(name: "_STNf3|",
+  
+  f1<_BitInt(3)>();
+  // CHECK: !DISubprogram(name: "f1<_BitInt(3)>",
+
+  f1();
+  // CHECK: !DISubprogram(name: "f1",
 }

diff  --git 
a/cross-project-tests/debuginfo-tests/clang_llvm_roundtrip/simplified_template_names.cpp
 
b/cross-project-tests/debuginfo-tests/clang_llvm_roundtrip/simplified_template_names.cpp
index 898b27ec0e479..ee429ef3b5798 100644
--- 
a/cross-project-tests/debuginfo-tests/clang_llvm_roundtrip/simplified_template_names.cpp
+++ 
b/cross-project-tests/debuginfo-tests/clang_llvm_roundtrip/simplified_template_names.cpp
@@ -316,6 +316,8 @@ int main() {
   f1();
   operator_not_really();
   t12 v4;
+  f1<_BitInt(3)>();
+  f1();
 }
 void t8::mem() {
   struct t7 { };



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

[PATCH] D119876: [nfc][codegen] Move RegisterBank[Info].h under CodeGen

[Mircea Trofin via Phabricator via cfe-commits]

mtrofin created this revision.
mtrofin added a reviewer: qcolombet.
Herald added subscribers: foad, frasercrmck, kerbowa, luismarques, apazos, 
sameer.abuasal, pengfei, s.egerton, Jim, jocewei, PkmX, the_o, brucehoult, 
MartinMosbeck, rogfer01, atanasyan, edward-jones, zzheng, jrtc27, niosHD, 
sabuasal, simoncook, johnrusso, rbar, asb, kbarton, hiraditya, nhaehnle, 
jvesely, nemanjai, sdardis, arsenm.
mtrofin requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, pcwang-thead, MaskRay.
Herald added projects: clang, LLVM.

This wraps up from D119053 . The 2 headers 
are moved as described,
fixed file headers and include guards, updated all files where the old
paths were detected (simple grep through the repo), and `clang-format`-ed it 
all.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D119876

Files:
  clang/docs/tools/clang-formatted-files.txt
  llvm/include/llvm/CodeGen/GlobalISel/InstructionSelectorImpl.h
  llvm/include/llvm/CodeGen/GlobalISel/RegBankSelect.h
  llvm/include/llvm/CodeGen/GlobalISel/RegisterBank.h
  llvm/include/llvm/CodeGen/GlobalISel/RegisterBankInfo.h
  llvm/include/llvm/CodeGen/MachineRegisterInfo.h
  llvm/include/llvm/CodeGen/RegisterBank.h
  llvm/include/llvm/CodeGen/RegisterBankInfo.h
  llvm/lib/CodeGen/GlobalISel/CombinerHelper.cpp
  llvm/lib/CodeGen/GlobalISel/RegBankSelect.cpp
  llvm/lib/CodeGen/GlobalISel/Utils.cpp
  llvm/lib/CodeGen/MIRParser/MIParser.cpp
  llvm/lib/CodeGen/MIRParser/MIRParser.cpp
  llvm/lib/CodeGen/MIRPrinter.cpp
  llvm/lib/CodeGen/MachineInstr.cpp
  llvm/lib/CodeGen/MachineVerifier.cpp
  llvm/lib/CodeGen/RegisterBank.cpp
  llvm/lib/CodeGen/RegisterBankInfo.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.cpp
  llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.h
  llvm/lib/Target/AMDGPU/AMDGPURegisterBankInfo.cpp
  llvm/lib/Target/AMDGPU/AMDGPURegisterBankInfo.h
  llvm/lib/Target/ARM/ARMRegisterBankInfo.cpp
  llvm/lib/Target/ARM/ARMRegisterBankInfo.h
  llvm/lib/Target/ARM/ARMSubtarget.h
  llvm/lib/Target/ARM/ARMTargetMachine.cpp
  llvm/lib/Target/M68k/GISel/M68kRegisterBankInfo.cpp
  llvm/lib/Target/M68k/GISel/M68kRegisterBankInfo.h
  llvm/lib/Target/M68k/M68kSubtarget.h
  llvm/lib/Target/Mips/MipsRegisterBankInfo.h
  llvm/lib/Target/Mips/MipsSubtarget.h
  llvm/lib/Target/PowerPC/GISel/PPCRegisterBankInfo.h
  llvm/lib/Target/PowerPC/PPCSubtarget.h
  llvm/lib/Target/RISCV/RISCVRegisterBankInfo.cpp
  llvm/lib/Target/RISCV/RISCVRegisterBankInfo.h
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/lib/Target/X86/X86InstructionSelector.cpp
  llvm/lib/Target/X86/X86RegisterBankInfo.cpp
  llvm/lib/Target/X86/X86RegisterBankInfo.h

Index: llvm/lib/Target/X86/X86RegisterBankInfo.h
===
--- llvm/lib/Target/X86/X86RegisterBankInfo.h
+++ llvm/lib/Target/X86/X86RegisterBankInfo.h
@@ -13,7 +13,7 @@
 #ifndef LLVM_LIB_TARGET_X86_X86REGISTERBANKINFO_H
 #define LLVM_LIB_TARGET_X86_X86REGISTERBANKINFO_H
 
-#include "llvm/CodeGen/GlobalISel/RegisterBankInfo.h"
+#include "llvm/CodeGen/RegisterBankInfo.h"
 
 #define GET_REGBANK_DECLARATIONS
 #include "X86GenRegisterBank.inc"
Index: llvm/lib/Target/X86/X86RegisterBankInfo.cpp
===
--- llvm/lib/Target/X86/X86RegisterBankInfo.cpp
+++ llvm/lib/Target/X86/X86RegisterBankInfo.cpp
@@ -12,9 +12,9 @@
 
 #include "X86RegisterBankInfo.h"
 #include "X86InstrInfo.h"
-#include "llvm/CodeGen/GlobalISel/RegisterBank.h"
-#include "llvm/CodeGen/GlobalISel/RegisterBankInfo.h"
 #include "llvm/CodeGen/MachineRegisterInfo.h"
+#include "llvm/CodeGen/RegisterBank.h"
+#include "llvm/CodeGen/RegisterBankInfo.h"
 #include "llvm/CodeGen/TargetRegisterInfo.h"
 
 #define GET_TARGET_REGBANK_IMPL
Index: llvm/lib/Target/X86/X86InstructionSelector.cpp
===
--- llvm/lib/Target/X86/X86InstructionSelector.cpp
+++ llvm/lib/Target/X86/X86InstructionSelector.cpp
@@ -21,7 +21,6 @@
 #include "X86TargetMachine.h"
 #include "llvm/CodeGen/GlobalISel/InstructionSelector.h"
 #include "llvm/CodeGen/GlobalISel/InstructionSelectorImpl.h"
-#include "llvm/CodeGen/GlobalISel/RegisterBank.h"
 #include "llvm/CodeGen/GlobalISel/Utils.h"
 #include "llvm/CodeGen/MachineBasicBlock.h"
 #include "llvm/CodeGen/MachineConstantPool.h"
@@ -31,6 +30,7 @@
 #include "llvm/CodeGen/MachineMemOperand.h"
 #include "llvm/CodeGen/MachineOperand.h"
 #include "llvm/CodeGen/MachineRegisterInfo.h"
+#include "llvm/CodeGen/RegisterBank.h"
 #include "llvm/CodeGen/TargetOpcodes.h"
 #include "llvm/CodeGen/TargetRegisterInfo.h"
 #include "llvm/IR/DataLayout.h"
Index: llvm/lib/Target/RISCV/RISCVSubtarget.h
===
--- llvm/lib/Target/RISCV/RISCVSubtarget.h
+++ llvm/lib/Target/RISCV/RISCVSubtarget.h
@@ -20,7 +20,7 @@
 #include 

[PATCH] D119841: [OpenMP] Pass AMDGPU math libraries into the linker wrapper

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:8195
+  // Get the AMDGPU math libraries.
+  // FIXME: This method is bad, remove once AMDGPU has a proper math library.
+  for (auto  : llvm::make_range(OpenMPTCRange.first, OpenMPTCRange.second)) {

jdoerfert wrote:
> jhuber6 wrote:
> > jdoerfert wrote:
> > > Can you elaborate on this comment, what's bad, how would the better 
> > > version look
> > It's explained in more detail where this is done for the AMDGPU ToolChain, 
> > e.g.
> > ```
> >   // This is not certain to work. The device libs added here, and 
> > passed to
> >   // llvm-link, are missing attributes that they expect to be inserted 
> > when
> >   // passed to mlink-builtin-bitcode. The amdgpu backend does not 
> > generate
> >   // conservatively correct code when attributes are missing, so this 
> > may
> >   // be the root cause of miscompilations. Passing via 
> > mlink-builtin-bitcode
> >   // ultimately hits 
> > CodeGenModule::addDefaultFunctionDefinitionAttributes
> >   // on each function, see D28538 for context.
> >   // Potential workarounds:
> >   //  - unconditionally link all of the device libs to every 
> > translation
> >   //unit in clang via mlink-builtin-bitcode
> >   //  - build a libm bitcode file as part of the DeviceRTL and 
> > explictly
> >   //mlink-builtin-bitcode the rocm device libs components at build 
> > time
> >   //  - drop this llvm-link fork in favour or some calls into LLVM, 
> > chosen
> >   //to do basically the same work as llvm-link but with that call 
> > first
> >   //  - write an opt pass that sets that on every function it sees and 
> > pipe
> >   //the device-libs bitcode through that on the way to this 
> > llvm-link
> > ```
> > Should I copy the gist here?
> Is it still relevant? We don't use llvm-link here, do we?
> 
> @arsenm, the backend is (almost) OK with the lack of attributes, is it not? 
Linking is done using LTO now, I don't know exactly how they merge bitcode 
compared to llvm-link but I'm assuming it's similar.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:8205
+if (llvm::find(LibraryArgs, "m") == LibraryArgs.end() && !D.CCCIsCXX())
+  continue;
+

jdoerfert wrote:
> I'd switch the conditions.
> 
> More importantly, does this require that the user passes -lm to the linker 
> invocation? I'm not convinced we should not always link these in.
Yes, would save some time assuming most codes are C++

So I figured I'd copy the same semantics of how `-lm` works where you need to 
specify it for C but not C++. We could just pass this in all the time, but 
since linking it in currently required `-lm` I copied that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119841

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

[PATCH] D119841: [OpenMP] Pass AMDGPU math libraries into the linker wrapper

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a subscriber: arsenm.
jdoerfert added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:8195
+  // Get the AMDGPU math libraries.
+  // FIXME: This method is bad, remove once AMDGPU has a proper math library.
+  for (auto  : llvm::make_range(OpenMPTCRange.first, OpenMPTCRange.second)) {

jhuber6 wrote:
> jdoerfert wrote:
> > Can you elaborate on this comment, what's bad, how would the better version 
> > look
> It's explained in more detail where this is done for the AMDGPU ToolChain, 
> e.g.
> ```
>   // This is not certain to work. The device libs added here, and passed 
> to
>   // llvm-link, are missing attributes that they expect to be inserted 
> when
>   // passed to mlink-builtin-bitcode. The amdgpu backend does not 
> generate
>   // conservatively correct code when attributes are missing, so this may 
>
>   // be the root cause of miscompilations. Passing via 
> mlink-builtin-bitcode
>   // ultimately hits 
> CodeGenModule::addDefaultFunctionDefinitionAttributes
>   // on each function, see D28538 for context.
>   // Potential workarounds:
>   //  - unconditionally link all of the device libs to every translation  
>   
>   //unit in clang via mlink-builtin-bitcode
>   //  - build a libm bitcode file as part of the DeviceRTL and explictly  
>   
>   //mlink-builtin-bitcode the rocm device libs components at build 
> time
>   //  - drop this llvm-link fork in favour or some calls into LLVM, 
> chosen
>   //to do basically the same work as llvm-link but with that call 
> first
>   //  - write an opt pass that sets that on every function it sees and 
> pipe
>   //the device-libs bitcode through that on the way to this llvm-link
> ```
> Should I copy the gist here?
Is it still relevant? We don't use llvm-link here, do we?

@arsenm, the backend is (almost) OK with the lack of attributes, is it not? 



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:8205
+if (llvm::find(LibraryArgs, "m") == LibraryArgs.end() && !D.CCCIsCXX())
+  continue;
+

I'd switch the conditions.

More importantly, does this require that the user passes -lm to the linker 
invocation? I'm not convinced we should not always link these in.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119841

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

[PATCH] D119363: [clang] Add `ObjCProtocolLoc` to represent protocol references

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D119363#3323867 , @dgoldman wrote:

> In D119363#3323778 , @sammccall 
> wrote:
>
>> I'm a bit concerned about the parent map vs ASTMatchFinder's view being out 
>> of sync: we'll have a ProtocolLoc node that has a parent but the parent 
>> doesn't have the child.
>>
>> I'm not sure this breaks anything immediately, but I think we should also 
>> make these nodes visible to matchers, even if there's no specific matcher 
>> yet.
>
> Hmm I can try to do it - what do I need to modify to make them visible to 
> matchers?

I don't remember specifically, I think ASTMatchFinderImpl has a 
RecursiveASTVisitor that you need to extend? I'm not sure actually how you 
would observe these nodes cleanly without matchers (hacks like 
`has(hasParent())` maybe?) So maybe it's best to ignore it in this patch and 
add basic matchers in a next one




Comment at: clang/include/clang/AST/TypeLoc.h:2611
+class ObjCProtocolLoc {
+  const ObjCProtocolDecl *Protocol = nullptr;
+  SourceLocation Loc = SourceLocation();

dgoldman wrote:
> sammccall wrote:
> > Also add a public `getLocation()` accessor for ProtocolLoc? (That returns 
> > SourceLocation)
> this was already there? did you want something else?
Nope sorry I'm just going blind it seems



Comment at: clang/include/clang/AST/TypeLoc.h:2617
+  : Protocol(protocol), Loc(loc) {}
+  const ObjCProtocolDecl *getProtocol() const { return Protocol; }
+  SourceLocation getLocation() const { return Loc; }

dgoldman wrote:
> sammccall wrote:
> > Return non-const pointer, matching other AST nodes. (But method should be 
> > const)
> Why - Is there a reason to make it mutable? TypeLoc's getTypePtr is const 
> (although this is a decl not a type).
A bunch of stuff operates on non-const nodes only, RecursiveASTVisitor for 
example.
And for whatever reason this is the convention, rather than a const+non-const 
variant of everything.

> TypeLoc's getTypePtr is const (although this is a decl not a type).

Yeah types are always const, this is related to the fact that they're interned 
so mutating them wouldn't make sense.



Comment at: clang/lib/AST/ParentMapContext.cpp:404
 
+  template bool isNull(T t) { return !t; }
+  template<> bool isNull(ObjCProtocolLoc t) { return false; }

t -> Node (case)



Comment at: clang/lib/AST/ParentMapContext.cpp:404
 
+  template bool isNull(T t) { return !t; }
+  template<> bool isNull(ObjCProtocolLoc t) { return false; }

sammccall wrote:
> t -> Node (case)
These should be `static` I think so they're not exposed



Comment at: clang/lib/AST/ParentMapContext.cpp:405
+  template bool isNull(T t) { return !t; }
+  template<> bool isNull(ObjCProtocolLoc t) { return false; }
+

No need for template<>, this can just be a normal function that forms an 
overload set along with the template


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119363

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

[PATCH] D119785: [clang-format] Fix formatting of struct-like records followed by variable declaration.

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks added inline comments.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:735
 // We don't merge short records.
-FormatToken *RecordTok = Line.First;
-// Skip record modifiers.
-while (RecordTok->Next &&
-   RecordTok->isOneOf(tok::kw_typedef, tok::kw_export,
-  Keywords.kw_declare, Keywords.kw_abstract,
-  tok::kw_default, Keywords.kw_override,
-  tok::kw_public, tok::kw_private,
-  tok::kw_protected, Keywords.kw_internal))
-  RecordTok = RecordTok->Next;
-if (RecordTok &&
-RecordTok->isOneOf(tok::kw_class, tok::kw_union, tok::kw_struct,
-   Keywords.kw_interface))
+if (isRecordLBrace(*Line.Last))
   return 0;

curdeius wrote:
> curdeius wrote:
> > MyDeveloperDay wrote:
> > > wow these are equivalent? do we need to worry about trailing comments?
> > > 
> > > ```
> > > public class A { /* comment */
> > > ```
> > Yes, before we were doing a poor man's scan skipping some (but not all) 
> > keywords (hence the bugs) that could appear before a record.
> > That was error-prone and redundant w.r.t. the parsing done in 
> > UnwrappedLineParser.
> > 
> > Anyway, good catch, I'll test what happens with comments.
> @MyDeveloperDay, do we want this (probably more coherent):
> ```
>   verifyFormat("struct A {};", AllowSimpleBracedStatements); // already tested
>   verifyFormat("struct A { /* comment */ };", AllowSimpleBracedStatements); 
> // added
> ```
> or this (current behaviour):
> ```
>   verifyFormat("struct A {};", AllowSimpleBracedStatements); // already tested
>   verifyFormat("struct A { /* comment */\n"
>"};", AllowSimpleBracedStatements); // added
> ```
> 
> (adapted from `TEST_F(FormatTest, FormatShortBracedStatements)`)
> @MyDeveloperDay, do we want this (probably more coherent):
> ```
>   verifyFormat("struct A {};", AllowSimpleBracedStatements); // already tested
>   verifyFormat("struct A { /* comment */ };", AllowSimpleBracedStatements); 
> // added
> ```
> or this (current behaviour):
> ```
>   verifyFormat("struct A {};", AllowSimpleBracedStatements); // already tested
>   verifyFormat("struct A { /* comment */\n"
>"};", AllowSimpleBracedStatements); // added
> ```
> 
> (adapted from `TEST_F(FormatTest, FormatShortBracedStatements)`)

Ideally I'd say depending on the input. It not dependent on that, the former.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119785

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

[PATCH] D119363: [clang] Add `ObjCProtocolLoc` to represent protocol references

[David Goldman via Phabricator via cfe-commits]

dgoldman added a comment.

In D119363#3323778 , @sammccall wrote:

> I'm a bit concerned about the parent map vs ASTMatchFinder's view being out 
> of sync: we'll have a ProtocolLoc node that has a parent but the parent 
> doesn't have the child.
>
> I'm not sure this breaks anything immediately, but I think we should also 
> make these nodes visible to matchers, even if there's no specific matcher yet.

Hmm I can try to do it - what do I need to modify to make them visible to 
matchers?




Comment at: clang/include/clang/AST/TypeLoc.h:2611
+class ObjCProtocolLoc {
+  const ObjCProtocolDecl *Protocol = nullptr;
+  SourceLocation Loc = SourceLocation();

sammccall wrote:
> Also add a public `getLocation()` accessor for ProtocolLoc? (That returns 
> SourceLocation)
this was already there? did you want something else?



Comment at: clang/include/clang/AST/TypeLoc.h:2617
+  : Protocol(protocol), Loc(loc) {}
+  const ObjCProtocolDecl *getProtocol() const { return Protocol; }
+  SourceLocation getLocation() const { return Loc; }

sammccall wrote:
> Return non-const pointer, matching other AST nodes. (But method should be 
> const)
Why - Is there a reason to make it mutable? TypeLoc's getTypePtr is const 
(although this is a decl not a type).



Comment at: clang/include/clang/AST/TypeLoc.h:2621
+  /// Evaluates true when this protocol loc is valid/non-empty.
+  explicit operator bool() const { return Protocol; }
+};

sammccall wrote:
> dgoldman wrote:
> > sammccall wrote:
> > > will we ever have invalid instances?
> > From what I can tell, nope. This is explicitly used here though: 
> > https://github.com/llvm/llvm-project/blob/ceb5dc55c2e395c085cd9d16c4152c5a1923d7e2/clang/lib/AST/ParentMapContext.cpp#L405
> > From what I can tell, nope. This is explicitly used here though: 
> > https://github.com/llvm/llvm-project/blob/ceb5dc55c2e395c085cd9d16c4152c5a1923d7e2/clang/lib/AST/ParentMapContext.cpp#L405
> 
> Well it's not used today, you're adding the use in this patch.
> 
> It can be solved in some other way, like pulling out an isNull template and 
> then overloading it for ProtocolLoc.
> I don't think we should add API surface to AST nodes to satisfy brittle 
> templates
Gotcha, I'm relatively new to templates but took a stab at isNull - LMK what 
you think/if there's a better way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119363

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

[PATCH] D119363: [clang] Add `ObjCProtocolLoc` to represent protocol references

[David Goldman via Phabricator via cfe-commits]

dgoldman updated this revision to Diff 408970.
dgoldman marked 4 inline comments as done.
dgoldman added a comment.

Template and variable casing fixes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119363

Files:
  clang/include/clang/AST/ASTFwd.h
  clang/include/clang/AST/ASTTypeTraits.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/TypeLoc.h
  clang/lib/AST/ASTTypeTraits.cpp
  clang/lib/AST/ParentMapContext.cpp
  clang/unittests/AST/RecursiveASTVisitorTest.cpp

Index: clang/unittests/AST/RecursiveASTVisitorTest.cpp
===
--- clang/unittests/AST/RecursiveASTVisitorTest.cpp
+++ clang/unittests/AST/RecursiveASTVisitorTest.cpp
@@ -60,6 +60,12 @@
   EndTraverseEnum,
   StartTraverseTypedefType,
   EndTraverseTypedefType,
+  StartTraverseObjCInterface,
+  EndTraverseObjCInterface,
+  StartTraverseObjCProtocol,
+  EndTraverseObjCProtocol,
+  StartTraverseObjCProtocolLoc,
+  EndTraverseObjCProtocolLoc,
 };
 
 class CollectInterestingEvents
@@ -97,18 +103,43 @@
 return Ret;
   }
 
+  bool TraverseObjCInterfaceDecl(ObjCInterfaceDecl *ID) {
+Events.push_back(VisitEvent::StartTraverseObjCInterface);
+bool Ret = RecursiveASTVisitor::TraverseObjCInterfaceDecl(ID);
+Events.push_back(VisitEvent::EndTraverseObjCInterface);
+
+return Ret;
+  }
+
+  bool TraverseObjCProtocolDecl(ObjCProtocolDecl *PD) {
+Events.push_back(VisitEvent::StartTraverseObjCProtocol);
+bool Ret = RecursiveASTVisitor::TraverseObjCProtocolDecl(PD);
+Events.push_back(VisitEvent::EndTraverseObjCProtocol);
+
+return Ret;
+  }
+
+  bool TraverseObjCProtocolLoc(ObjCProtocolLoc ProtocolLoc) {
+Events.push_back(VisitEvent::StartTraverseObjCProtocolLoc);
+bool Ret = RecursiveASTVisitor::TraverseObjCProtocolLoc(ProtocolLoc);
+Events.push_back(VisitEvent::EndTraverseObjCProtocolLoc);
+
+return Ret;
+  }
+
   std::vector takeEvents() && { return std::move(Events); }
 
 private:
   std::vector Events;
 };
 
-std::vector collectEvents(llvm::StringRef Code) {
+std::vector collectEvents(llvm::StringRef Code,
+  const Twine  = "input.cc") {
   CollectInterestingEvents Visitor;
   clang::tooling::runToolOnCode(
   std::make_unique(
   [&](clang::ASTContext ) { Visitor.TraverseAST(Ctx); }),
-  Code);
+  Code, FileName);
   return std::move(Visitor).takeEvents();
 }
 } // namespace
@@ -139,3 +170,28 @@
   VisitEvent::EndTraverseTypedefType,
   VisitEvent::EndTraverseEnum));
 }
+
+TEST(RecursiveASTVisitorTest, InterfaceDeclWithProtocols) {
+  // Check interface and its protocols are visited.
+  llvm::StringRef Code = R"cpp(
+  @protocol Foo
+  @end
+  @protocol Bar
+  @end
+
+  @interface SomeObject 
+  @end
+  )cpp";
+
+  EXPECT_THAT(collectEvents(Code, "input.m"),
+  ElementsAre(VisitEvent::StartTraverseObjCProtocol,
+  VisitEvent::EndTraverseObjCProtocol,
+  VisitEvent::StartTraverseObjCProtocol,
+  VisitEvent::EndTraverseObjCProtocol,
+  VisitEvent::StartTraverseObjCInterface,
+  VisitEvent::StartTraverseObjCProtocolLoc,
+  VisitEvent::EndTraverseObjCProtocolLoc,
+  VisitEvent::StartTraverseObjCProtocolLoc,
+  VisitEvent::EndTraverseObjCProtocolLoc,
+  VisitEvent::EndTraverseObjCInterface));
+}
Index: clang/lib/AST/ParentMapContext.cpp
===
--- clang/lib/AST/ParentMapContext.cpp
+++ clang/lib/AST/ParentMapContext.cpp
@@ -330,6 +330,9 @@
 DynTypedNode createDynTypedNode(const NestedNameSpecifierLoc ) {
   return DynTypedNode::create(Node);
 }
+template <> DynTypedNode createDynTypedNode(const ObjCProtocolLoc ) {
+  return DynTypedNode::create(Node);
+}
 /// @}
 
 /// A \c RecursiveASTVisitor that builds a map from nodes to their
@@ -398,11 +401,14 @@
 }
   }
 
+  template bool isNull(T t) { return !t; }
+  template<> bool isNull(ObjCProtocolLoc t) { return false; }
+
   template 
   bool TraverseNode(T Node, MapNodeTy MapNode, BaseTraverseFn BaseTraverse,
 MapTy *Parents) {
-if (!Node)
+if (isNull(Node))
   return true;
 addParent(MapNode, Parents);
 ParentStack.push_back(createDynTypedNode(Node));
@@ -433,6 +439,12 @@
 AttrNode, AttrNode, [&] { return VisitorBase::TraverseAttr(AttrNode); },
 );
   }
+  bool TraverseObjCProtocolLoc(ObjCProtocolLoc ProtocolLocNode) {
+return TraverseNode(
+ProtocolLocNode, DynTypedNode::create(ProtocolLocNode),
+[&] { return VisitorBase::TraverseObjCProtocolLoc(ProtocolLocNode); },
+);
+  }
 
   // Using generic TraverseNode for Stmt 

[PATCH] D114714: [C++20][Modules] Add enumerations for partition modules and stream them.

[Nathan Sidwell via Phabricator via cfe-commits]

urnathan added inline comments.



Comment at: clang/include/clang/Basic/Module.h:109
 
-/// This is a C++ Modules TS module interface unit.
+/// This is a C++ Modules TS or C++20 module interface unit.
 ModuleInterfaceUnit,

I think it's confusing to continue to refer to modules-ts modules at this 
point.  Is that really necessary?
The specific confusion here is that does 'ModuleInterfaceUnit' mean one of two 
different things depending on compilation mode, or is it a single thing with 
two different names?



Comment at: clang/include/clang/Basic/Module.h:517-518
 
+  /// Is this a module partition.
+  /// ??? : make a bit and stream it?
+

???



Comment at: clang/include/clang/Basic/Module.h:520
+
+  bool isPartition() const { return Name.find(':') != std::string::npos; }
+

isModulePartition?  


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114714

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

[PATCH] D118893: [C++20][Modules] Track valid import state.

[Nathan Sidwell via Phabricator via cfe-commits]

urnathan added a comment.

Looks right to me -- I also implemented such a state machine in GCC's parser.  
There are a bunch of formatting issues to fix of course.




Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1543
+def err_import_not_allowed_here : Error<
+  "imports must be contiguous and immediately follow the module declaration">;
+def err_import_in_global_fragment : Error<

"imports must immediately follow a module declaration"?  (the contiguous isn't 
adding anything IMHO)



Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1544-1547
+def err_import_in_global_fragment : Error<
+  "module%select{| partition}0 imports cannot be in the global module 
fragment">;
+def err_import_in_private_fragment : Error<
+  "module%select{| partition}0 imports cannot be in the private module 
fragment">;

You could I suppose have a single diagnostuc and select between global & 
private?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118893

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

[PATCH] D119363: [clang] Add `ObjCProtocolLoc` to represent protocol references

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

I'm a bit concerned about the parent map vs ASTMatchFinder's view being out of 
sync: we'll have a ProtocolLoc node that has a parent but the parent doesn't 
have the child.

I'm not sure this breaks anything immediately, but I think we should also make 
these nodes visible to matchers, even if there's no specific matcher yet.




Comment at: clang/include/clang/AST/RecursiveASTVisitor.h:1350
+DEF_TRAVERSE_TYPELOC(ObjCTypeParamType, {
+  for (unsigned i = 0, n = TL.getNumProtocols(); i != n; ++i) {
+ObjCProtocolLoc ProtocolLoc(TL.getProtocol(i), TL.getProtocolLoc(i));

i => I etc



Comment at: clang/include/clang/AST/TypeLoc.h:2611
+class ObjCProtocolLoc {
+  const ObjCProtocolDecl *Protocol = nullptr;
+  SourceLocation Loc = SourceLocation();

Also add a public `getLocation()` accessor for ProtocolLoc? (That returns 
SourceLocation)



Comment at: clang/include/clang/AST/TypeLoc.h:2617
+  : Protocol(protocol), Loc(loc) {}
+  const ObjCProtocolDecl *getProtocol() const { return Protocol; }
+  SourceLocation getLocation() const { return Loc; }

Return non-const pointer, matching other AST nodes. (But method should be const)



Comment at: clang/include/clang/AST/TypeLoc.h:2620
+
+  /// Get the full source range.
+  SourceRange getSourceRange() const LLVM_READONLY {

This comment doesn't really say anything.

Maybe replace with "the source range is just the protocol name"?



Comment at: clang/include/clang/AST/TypeLoc.h:2621
+  /// Evaluates true when this protocol loc is valid/non-empty.
+  explicit operator bool() const { return Protocol; }
+};

dgoldman wrote:
> sammccall wrote:
> > will we ever have invalid instances?
> From what I can tell, nope. This is explicitly used here though: 
> https://github.com/llvm/llvm-project/blob/ceb5dc55c2e395c085cd9d16c4152c5a1923d7e2/clang/lib/AST/ParentMapContext.cpp#L405
> From what I can tell, nope. This is explicitly used here though: 
> https://github.com/llvm/llvm-project/blob/ceb5dc55c2e395c085cd9d16c4152c5a1923d7e2/clang/lib/AST/ParentMapContext.cpp#L405

Well it's not used today, you're adding the use in this patch.

It can be solved in some other way, like pulling out an isNull template and 
then overloading it for ProtocolLoc.
I don't think we should add API surface to AST nodes to satisfy brittle 
templates


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119363

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

[PATCH] D117989: [RISCV] Add the passthru operand for RVV nomask binary intrinsics.

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

LGTM other than what I think is an unnecessary include.




Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:15
 #include "RISCVISelLowering.h"
+#include "MCTargetDesc/RISCVBaseInfo.h"
 #include "MCTargetDesc/RISCVMatInt.h"

This file is included in RISCV.h can we remove this change?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117989

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

[clang] 5dc0a16 - [PowerPC] Fix __builtin_pdepd and __builtin_pextd to be 64-bit and P10 only.

[Amy Kwan via cfe-commits]

Author: Amy Kwan
Date: 2022-02-15T12:30:50-06:00
New Revision: 5dc0a1657be14df68bfc33deb2fb75476acdaec8

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

LOG: [PowerPC] Fix __builtin_pdepd and __builtin_pextd to be 64-bit and P10 
only.

The `__builtin_pdepd` and `__builtin_pextd` are P10 builtins that are meant to
be used under 64-bit only. For instance, when the builtins are compiled under
32-bit mode:
```
$ cat t.c
unsigned long long foo(unsigned long long a, unsigned long long b) {
  return __builtin_pextd(a,b);
}

$ clang -c t.c -mcpu=pwr10 -m32
ExpandIntegerResult #0: t31: i64 = llvm.ppc.pextd TargetConstant:i32<6928>, 
t28, t29

fatal error: error in backend: Do not know how to expand the result of this 
operator!
```
This patch adds sema checking for these builtins to compile under 64-bit
mode only and on P10. The builtins will emit a diagnostic when they are 
compiled on
non-P10 compilations and on 32-bit mode.

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

Added: 
clang/test/CodeGen/PowerPC/builtins-ppc-pwr10-64bit.c

Modified: 
clang/lib/Sema/SemaChecking.cpp
llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll

Removed: 




diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index c422981a1a2e6..cb65991cbe2e9 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -3604,6 +3604,8 @@ static bool isPPC_64Builtin(unsigned BuiltinID) {
   case PPC::BI__builtin_divde:
   case PPC::BI__builtin_divdeu:
   case PPC::BI__builtin_bpermd:
+  case PPC::BI__builtin_pdepd:
+  case PPC::BI__builtin_pextd:
   case PPC::BI__builtin_ppc_ldarx:
   case PPC::BI__builtin_ppc_stdcx:
   case PPC::BI__builtin_ppc_tdw:
@@ -3763,6 +3765,10 @@ bool Sema::CheckPPCBuiltinFunctionCall(const TargetInfo 
, unsigned BuiltinID,
   case PPC::BI__builtin_pack_vector_int128:
 return SemaFeatureCheck(*this, TheCall, "vsx",
 diag::err_ppc_builtin_only_on_arch, "7");
+  case PPC::BI__builtin_pdepd:
+  case PPC::BI__builtin_pextd:
+return SemaFeatureCheck(*this, TheCall, "isa-v31-instructions",
+diag::err_ppc_builtin_only_on_arch, "10");
   case PPC::BI__builtin_altivec_vgnb:
  return SemaBuiltinConstantArgRange(TheCall, 1, 2, 7);
   case PPC::BI__builtin_altivec_vec_replace_elt:

diff  --git a/clang/test/CodeGen/PowerPC/builtins-ppc-pwr10-64bit.c 
b/clang/test/CodeGen/PowerPC/builtins-ppc-pwr10-64bit.c
new file mode 100644
index 0..c6922eae6bf58
--- /dev/null
+++ b/clang/test/CodeGen/PowerPC/builtins-ppc-pwr10-64bit.c
@@ -0,0 +1,34 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -emit-llvm %s \
+// RUN:   -target-cpu pwr10 -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-linux-gnu -emit-llvm %s \
+// RUN:   -target-cpu pwr10 -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix -emit-llvm %s \
+// RUN:   -target-cpu pwr10 -o - | FileCheck %s
+// RUN: not %clang_cc1 -triple powerpc-unknown-aix -emit-llvm-only %s \
+// RUN:   -target-cpu pwr8 2>&1 | FileCheck %s --check-prefix=CHECK-32-ERROR
+// RUN: not %clang_cc1 -triple powerpc-unknown-linux-gnu -emit-llvm-only %s \
+// RUN:   -target-cpu pwr9 2>&1 | FileCheck %s --check-prefix=CHECK-32-ERROR
+// RUN: not %clang_cc1 -triple powerpc64-unknown-aix -emit-llvm-only %s \
+// RUN:   -target-cpu pwr9 2>&1 | FileCheck %s 
--check-prefix=CHECK-NONPWR10-ERR
+// RUN: not %clang_cc1 -triple powerpc64-unknown-linux-gnu -emit-llvm-only %s \
+// RUN:   -target-cpu pwr8 2>&1 | FileCheck %s 
--check-prefix=CHECK-NONPWR10-ERR
+
+extern unsigned long long ull;
+
+unsigned long long test_builtin_pextd() {
+  // CHECK-LABEL:@test_builtin_pextd(
+  // CHECK:  %2 = call i64 @llvm.ppc.pextd(i64 %0, i64 %1)
+  // CHECK-32-ERROR: error: this builtin is only available on 64-bit targets
+  // CHECK-NONPWR10-ERR:  error: this builtin is only valid on POWER10 or 
later CPUs
+  return __builtin_pextd(ull, ull);
+}
+
+unsigned long long test_builtin_pdepd() {
+  // CHECK-LABEL:@test_builtin_pdepd(
+  // CHECK:  %2 = call i64 @llvm.ppc.pdepd(i64 %0, i64 %1)
+  // CHECK-32-ERROR: error: this builtin is only available on 64-bit targets
+  // CHECK-NONPWR10-ERR:  error: this builtin is only valid on POWER10 or 
later CPUs
+  return __builtin_pdepd(ull, ull);
+}
+

diff  --git a/llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll 
b/llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
index 901b449bb5c39..4643faee88db1 100644
--- a/llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
+++ b/llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
@@ -2,6 +2,9 @@
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
 ; RUN:   -mcpu=pwr10 

[PATCH] D118753: [PowerPC] Fix __builtin_pdepd and __builtin_pextd to be 64-bit and P10 only.

[Amy Kwan 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 rG5dc0a1657be1: [PowerPC] Fix __builtin_pdepd and 
__builtin_pextd to be 64-bit and P10 only. (authored by amyk).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118753

Files:
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/PowerPC/builtins-ppc-pwr10-64bit.c
  llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll


Index: llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
===
--- llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
+++ llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
@@ -2,6 +2,9 @@
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
 ; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr < %s | \
 ; RUN:   FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr < %s | \
+; RUN:   FileCheck %s
 
 ; These test cases aim to test the bit manipulation operations on Power10.
 
Index: clang/test/CodeGen/PowerPC/builtins-ppc-pwr10-64bit.c
===
--- /dev/null
+++ clang/test/CodeGen/PowerPC/builtins-ppc-pwr10-64bit.c
@@ -0,0 +1,34 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -emit-llvm %s \
+// RUN:   -target-cpu pwr10 -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-linux-gnu -emit-llvm %s \
+// RUN:   -target-cpu pwr10 -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix -emit-llvm %s \
+// RUN:   -target-cpu pwr10 -o - | FileCheck %s
+// RUN: not %clang_cc1 -triple powerpc-unknown-aix -emit-llvm-only %s \
+// RUN:   -target-cpu pwr8 2>&1 | FileCheck %s --check-prefix=CHECK-32-ERROR
+// RUN: not %clang_cc1 -triple powerpc-unknown-linux-gnu -emit-llvm-only %s \
+// RUN:   -target-cpu pwr9 2>&1 | FileCheck %s --check-prefix=CHECK-32-ERROR
+// RUN: not %clang_cc1 -triple powerpc64-unknown-aix -emit-llvm-only %s \
+// RUN:   -target-cpu pwr9 2>&1 | FileCheck %s 
--check-prefix=CHECK-NONPWR10-ERR
+// RUN: not %clang_cc1 -triple powerpc64-unknown-linux-gnu -emit-llvm-only %s \
+// RUN:   -target-cpu pwr8 2>&1 | FileCheck %s 
--check-prefix=CHECK-NONPWR10-ERR
+
+extern unsigned long long ull;
+
+unsigned long long test_builtin_pextd() {
+  // CHECK-LABEL:@test_builtin_pextd(
+  // CHECK:  %2 = call i64 @llvm.ppc.pextd(i64 %0, i64 %1)
+  // CHECK-32-ERROR: error: this builtin is only available on 64-bit targets
+  // CHECK-NONPWR10-ERR:  error: this builtin is only valid on POWER10 or 
later CPUs
+  return __builtin_pextd(ull, ull);
+}
+
+unsigned long long test_builtin_pdepd() {
+  // CHECK-LABEL:@test_builtin_pdepd(
+  // CHECK:  %2 = call i64 @llvm.ppc.pdepd(i64 %0, i64 %1)
+  // CHECK-32-ERROR: error: this builtin is only available on 64-bit targets
+  // CHECK-NONPWR10-ERR:  error: this builtin is only valid on POWER10 or 
later CPUs
+  return __builtin_pdepd(ull, ull);
+}
+
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -3604,6 +3604,8 @@
   case PPC::BI__builtin_divde:
   case PPC::BI__builtin_divdeu:
   case PPC::BI__builtin_bpermd:
+  case PPC::BI__builtin_pdepd:
+  case PPC::BI__builtin_pextd:
   case PPC::BI__builtin_ppc_ldarx:
   case PPC::BI__builtin_ppc_stdcx:
   case PPC::BI__builtin_ppc_tdw:
@@ -3763,6 +3765,10 @@
   case PPC::BI__builtin_pack_vector_int128:
 return SemaFeatureCheck(*this, TheCall, "vsx",
 diag::err_ppc_builtin_only_on_arch, "7");
+  case PPC::BI__builtin_pdepd:
+  case PPC::BI__builtin_pextd:
+return SemaFeatureCheck(*this, TheCall, "isa-v31-instructions",
+diag::err_ppc_builtin_only_on_arch, "10");
   case PPC::BI__builtin_altivec_vgnb:
  return SemaBuiltinConstantArgRange(TheCall, 1, 2, 7);
   case PPC::BI__builtin_altivec_vec_replace_elt:


Index: llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
===
--- llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
+++ llvm/test/CodeGen/PowerPC/p10-bit-manip-ops.ll
@@ -2,6 +2,9 @@
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
 ; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr < %s | \
 ; RUN:   FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr < %s | \
+; RUN:   FileCheck %s
 
 ; These test cases aim to test the bit manipulation operations on Power10.
 
Index: clang/test/CodeGen/PowerPC/builtins-ppc-pwr10-64bit.c

[PATCH] D102614: [index] Add support for type of pointers to class members

[Argyrios Kyrtzidis via Phabricator via cfe-commits]

akyrtzi added a comment.

> What do you think about this patch? Can it be landed now? Or I should debug 
> the crash in the Windows version detected with the previous version of my 
> patch.

Is your change introducing the crash or is the crash triggered with the test 
file without your changes as well?


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

https://reviews.llvm.org/D102614

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

[PATCH] D119858: [OpenCL] Guard 64-bit atomic types

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh added a comment.

In D119858#3323565 , @Anastasia wrote:

> LGTM! Thanks!
>
> I imagine this is another change to align with `opencl-c.h`?

Yes. This addresses the issue of D119398  for 
tablegen (although the problem for the tablegen case was less severe, since it 
only affects diagnostics).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119858

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

[PATCH] D119850: Darwin: introduce a global override for debug prefix map entries

[Adrian Prantl via Phabricator via cfe-commits]

aprantl added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:686
+return;
+  if (!StringRef(GlobalRemapEntry).contains('='))
+D.Diag(diag::err_drv_invalid_argument_to_option)

arphaman wrote:
> Suggestion: It might be good to factor out the code that verifies the value 
> and either produces an error or adds an argument into some common helper as 
> it's used right above this codepath as well.
Good idea! Done.


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

https://reviews.llvm.org/D119850

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

[PATCH] D119850: Darwin: introduce a global override for debug prefix map entries

[Adrian Prantl via Phabricator via cfe-commits]

aprantl updated this revision to Diff 408944.
aprantl added a comment.

Refactored code.


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

https://reviews.llvm.org/D119850

Files:
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/Darwin.h
  clang/test/Driver/darwin-debug-prefix-map.c
  clang/test/Driver/darwin-debug-prefix-map.s

Index: clang/test/Driver/darwin-debug-prefix-map.s
===
--- /dev/null
+++ clang/test/Driver/darwin-debug-prefix-map.s
@@ -0,0 +1,6 @@
+// RUN: env RC_DEBUG_PREFIX_MAP=old=new \
+// RUN:  %clang -target arm64-apple-darwin -### -c -g %s 2>&1 | FileCheck %s
+// RUN: env RC_DEBUG_PREFIX_MAP=illegal \
+// RUN:  %clang -target arm64-apple-darwin -### -c -g %s 2>&1 | FileCheck %s --check-prefix=ERR
+// CHECK: "-fdebug-prefix-map=old=new" 
+// ERR: invalid argument 'illegal'
Index: clang/test/Driver/darwin-debug-prefix-map.c
===
--- /dev/null
+++ clang/test/Driver/darwin-debug-prefix-map.c
@@ -0,0 +1,6 @@
+// RUN: env RC_DEBUG_PREFIX_MAP=old=new \
+// RUN:  %clang -target arm64-apple-darwin -### -c -g %s 2>&1 | FileCheck %s
+// RUN: env RC_DEBUG_PREFIX_MAP=illegal \
+// RUN:  %clang -target arm64-apple-darwin -### -c -g %s 2>&1 | FileCheck %s --check-prefix=ERR
+// CHECK: "-fdebug-prefix-map=old=new" 
+// ERR: invalid argument 'illegal'
Index: clang/lib/Driver/ToolChains/Darwin.h
===
--- clang/lib/Driver/ToolChains/Darwin.h
+++ clang/lib/Driver/ToolChains/Darwin.h
@@ -267,6 +267,7 @@
   bool SupportsProfiling() const override;
 
   bool UseDwarfDebugFlags() const override;
+  std::string GetGlobalDebugPathRemapping() const override;
 
   llvm::ExceptionHandling
   GetExceptionModel(const llvm::opt::ArgList ) const override {
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -2772,6 +2772,12 @@
   return false;
 }
 
+std::string MachO::GetGlobalDebugPathRemapping() const {
+  if (const char *S = ::getenv("RC_DEBUG_PREFIX_MAP"))
+return S;
+  return {};
+}
+
 llvm::ExceptionHandling Darwin::GetExceptionModel(const ArgList ) const {
   // Darwin uses SjLj exceptions on ARM.
   if (getTriple().getArch() != llvm::Triple::arm &&
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -668,17 +668,25 @@
 }
 
 /// Add a CC1 and CC1AS option to specify the debug file path prefix map.
-static void addDebugPrefixMapArg(const Driver , const ArgList , ArgStringList ) {
-  for (const Arg *A : Args.filtered(options::OPT_ffile_prefix_map_EQ,
-options::OPT_fdebug_prefix_map_EQ)) {
-StringRef Map = A->getValue();
+static void addDebugPrefixMapArg(const Driver , const ToolChain ,
+ const ArgList , ArgStringList ) {
+  auto AddOneArg = [&](StringRef Map, StringRef Name) {
 if (!Map.contains('='))
   D.Diag(diag::err_drv_invalid_argument_to_option)
-  << Map << A->getOption().getName();
+  << Map << Name;
 else
   CmdArgs.push_back(Args.MakeArgString("-fdebug-prefix-map=" + Map));
+  };
+
+  for (const Arg *A : Args.filtered(options::OPT_ffile_prefix_map_EQ,
+options::OPT_fdebug_prefix_map_EQ)) {
+AddOneArg(A->getValue(), A->getOption().getName());
 A->claim();
   }
+  std::string GlobalRemapEntry = TC.GetGlobalDebugPathRemapping();
+  if (GlobalRemapEntry.empty())
+return;
+  AddOneArg(GlobalRemapEntry, "environment");
 }
 
 /// Add a CC1 and CC1AS option to specify the macro file path prefix map.
@@ -5717,7 +5725,7 @@
   const char *DebugCompilationDir =
   addDebugCompDirArg(Args, CmdArgs, D.getVFS());
 
-  addDebugPrefixMapArg(D, Args, CmdArgs);
+  addDebugPrefixMapArg(D, TC, Args, CmdArgs);
 
   if (Arg *A = Args.getLastArg(options::OPT_ftemplate_depth_,
options::OPT_ftemplate_depth_EQ)) {
@@ -7785,7 +7793,8 @@
 DebugInfoKind = (WantDebug ? codegenoptions::DebugInfoConstructor
: codegenoptions::NoDebugInfo);
 
-addDebugPrefixMapArg(getToolChain().getDriver(), Args, CmdArgs);
+addDebugPrefixMapArg(getToolChain().getDriver(), getToolChain(), Args,
+ CmdArgs);
 
 // Set the AT_producer to the clang version when using the integrated
 // assembler on assembly source files.
Index: clang/include/clang/Driver/ToolChain.h
===
--- clang/include/clang/Driver/ToolChain.h
+++ 

[PATCH] D119858: [OpenCL] Guard 64-bit atomic types

[Anastasia Stulova via Phabricator via cfe-commits]

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

LGTM! Thanks!

I imagine this is another change to align with `opencl-c.h`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119858

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

[PATCH] D119613: [OpenMP] Add support for CPU offloading in new driver

[Johannes Doerfert via Phabricator via cfe-commits]

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

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119613

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

[PATCH] D119363: [clang] Add `ObjCProtocolLoc` to represent protocol references

[David Goldman via Phabricator via cfe-commits]

dgoldman added a comment.

PTAL, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119363

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

[PATCH] D119366: [clangd] Use `ObjCProtocolLoc` for generalized ObjC protocol support

[David Goldman via Phabricator via cfe-commits]

dgoldman updated this revision to Diff 408937.
dgoldman added a comment.

Rebase on top of latest ProtocolLoc changes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119366

Files:
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/unittests/FindTargetTests.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp

Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -2522,6 +2522,22 @@
 HI.Definition = "@property(nonatomic, assign, unsafe_unretained, "
 "readwrite) int prop1;";
   }},
+  {
+  R"cpp(
+  @protocol MYProtocol
+  @end
+  @interface MYObject
+  @end
+
+  @interface MYObject (Ext) <[[MYProt^ocol]]>
+  @end
+  )cpp",
+  [](HoverInfo ) {
+HI.Name = "MYProtocol";
+HI.Kind = index::SymbolKind::Protocol;
+HI.NamespaceScope = "";
+HI.Definition = "@protocol MYProtocol\n@end";
+  }},
   {R"objc(
 @interface Foo
 @end
Index: clang-tools-extra/clangd/unittests/FindTargetTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -946,11 +946,9 @@
   EXPECT_DECLS("ObjCCategoryImplDecl", "@interface Foo(Ext)");
 
   Code = R"cpp(
-@protocol Foo
-@end
-void test([[id]] p);
+void test(id p);
   )cpp";
-  EXPECT_DECLS("ObjCObjectTypeLoc", "@protocol Foo");
+  EXPECT_DECLS("ParmVarDecl", "id p");
 
   Code = R"cpp(
 @class C;
@@ -966,7 +964,7 @@
 @end
 void test(C<[[Foo]]> *p);
   )cpp";
-  EXPECT_DECLS("ObjCObjectTypeLoc", "@protocol Foo");
+  EXPECT_DECLS("ObjCProtocolLoc", "@protocol Foo");
 
   Code = R"cpp(
 @class C;
@@ -976,8 +974,17 @@
 @end
 void test(C<[[Foo]], Bar> *p);
   )cpp";
-  // FIXME: We currently can't disambiguate between multiple protocols.
-  EXPECT_DECLS("ObjCObjectTypeLoc", "@protocol Foo", "@protocol Bar");
+  EXPECT_DECLS("ObjCProtocolLoc", "@protocol Foo");
+
+  Code = R"cpp(
+@class C;
+@protocol Foo
+@end
+@protocol Bar
+@end
+void test(C *p);
+  )cpp";
+  EXPECT_DECLS("ObjCProtocolLoc", "@protocol Bar");
 
   Code = R"cpp(
 @interface Foo
Index: clang-tools-extra/clangd/Selection.cpp
===
--- clang-tools-extra/clangd/Selection.cpp
+++ clang-tools-extra/clangd/Selection.cpp
@@ -684,6 +684,9 @@
 return traverseNode(
 , [&] { return TraverseTypeLoc(QX.getUnqualifiedLoc()); });
   }
+  bool TraverseObjCProtocolLoc(ObjCProtocolLoc PL) {
+return traverseNode(, [&] { return Base::TraverseObjCProtocolLoc(PL); });
+  }
   // Uninteresting parts of the AST that don't have locations within them.
   bool TraverseNestedNameSpecifier(NestedNameSpecifier *) { return true; }
   bool TraverseType(QualType) { return true; }
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -453,15 +453,6 @@
   void VisitObjCInterfaceType(const ObjCInterfaceType *OIT) {
 Outer.add(OIT->getDecl(), Flags);
   }
-  void VisitObjCObjectType(const ObjCObjectType *OOT) {
-// Make all of the protocols targets since there's no child nodes for
-// protocols. This isn't needed for the base type, which *does* have a
-// child `ObjCInterfaceTypeLoc`. This structure is a hack, but it works
-// well for go-to-definition.
-unsigned NumProtocols = OOT->getNumProtocols();
-for (unsigned I = 0; I < NumProtocols; I++)
-  Outer.add(OOT->getProtocol(I), Flags);
-  }
 };
 Visitor(*this, Flags).Visit(T.getTypePtr());
   }
@@ -547,6 +538,8 @@
 Finder.add(TAL->getArgument(), Flags);
   else if (const CXXBaseSpecifier *CBS = N.get())
 Finder.add(CBS->getTypeSourceInfo()->getType(), Flags);
+  else if (const ObjCProtocolLoc *PL = N.get())
+Finder.add(PL->getProtocol(), Flags);
   return Finder.takeDecls();
 }
 
@@ -669,25 +662,7 @@
   {OMD}});
 }
 
-void visitProtocolList(
-llvm::iterator_range Protocols,
-llvm::iterator_range Locations) {
-  for (const auto  : llvm::zip(Protocols, Locations)) {
-Refs.push_back(ReferenceLoc{NestedNameSpecifierLoc(),
-std::get<1>(P),
-/*IsDecl=*/false,
-{std::get<0>(P)}});
-  }
-