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

2022-02-16 Thread Zixuan Wu via Phabricator via cfe-commits
zixuan-wu added a comment.

Sorry for the wrong action of commandeer, @pcwang-thead will still be the 
author.


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

2022-02-16 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added a comment.

In D119893#3325375 , @curdeius wrote:

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

Yeah, I should have put that in the commit message, right? ;)

Maybe I would have discovered the bug myself, but this is from GitHub.




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

Quuxplusone wrote:
> Nit: For this pattern, consider `bool LambdaThisTimeAllowed = 
> std::exchange(LambdaNextTimeAllowed, false);`
I was under the impression that exchange was C++17. If I'd known that it's 14 
and I can use it, I'd done that in the first place.



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

Quuxplusone wrote:
> This seems like an overuse of fallthrough; how about simply
> ```
> LambdaNextTimeAllowed = true;
> nextToken();
> break;
> ```
> ?
Can do. I'm just thinking if there is ever a change to what to do, not just 
`nextToken()`, I would have to change it only at 2 not 3 places. But probably 
that will never happen.


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] D119893: [clang-format] Fixed handling of requires clauses followed by attributes

2022-02-16 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius added a comment.

In D119893#3325432 , 
@HazardyKnusperkeks wrote:

> In D119893#3325375 , @curdeius 
> wrote:
>
>> +1 to Arthur's comments.
>> Does it fix any of the recently created issues?
>
> Yeah, I should have put that in the commit message, right? ;)
>
> Maybe I would have discovered the bug myself, but this is from GitHub.

Just put `Fixes https://github.com/llvm/llvm-project/issues/123456.` in the 
description please so that the issues gets automatically closed when this patch 
lands.


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] D109239: Add support for floating-option `-ffp-eval-method` and for new `pragma clang fp eval-method`

2022-02-16 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added subscribers: cfe-commits, lebedev.ri.
lebedev.ri added a comment.

Looks like the lists weren't subscribed for the review


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

https://reviews.llvm.org/D109239

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


[PATCH] D102669: [analyzer][ctu] Fix wrong 'multiple definitions' errors caused by space characters in lookup names when parsing the ctu index file

2022-02-16 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a reviewer: keith.
steakhal added a subscriber: keith.
steakhal added a comment.

Hi @keith, I've seen you commented on a clang driver-related issue: "Why does 
march=native not work on Apple M1?" 

You might also have some valuable insight about this weird behavior about the 
detected target triple in a regular mode and using the `-cc1` mode.
You don't need to go through the whole conversation, the last few comments 
should be enough.
Feel free to invite more people if you think.


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

https://reviews.llvm.org/D102669

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


[libunwind] 2d2ef38 - [libunwind] Only include cet.h if __CET__ defined

2022-02-16 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2022-02-16T09:45:54+01:00
New Revision: 2d2ef384b2f6e723edb793d08f52e7f4dc94ba3a

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

LOG: [libunwind] Only include cet.h if __CET__ defined

We should not assume that the cet.h header exists just because
we're on x86 linux. Only include it if __CET__ is defined. This
makes the code more similar to what compiler-rt does in
https://github.com/llvm/llvm-project/blob/ee423d93ead39e94c2970b3cc7ef6e6faa75d10b/compiler-rt/lib/builtins/assembly.h#L17
(though that one also has a __has_include() check -- I've not found
that to be necessary).

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

Added: 


Modified: 
libunwind/src/assembly.h

Removed: 




diff  --git a/libunwind/src/assembly.h b/libunwind/src/assembly.h
index 978f6bd619bd3..89293a555bfc4 100644
--- a/libunwind/src/assembly.h
+++ b/libunwind/src/assembly.h
@@ -15,7 +15,7 @@
 #ifndef UNWIND_ASSEMBLY_H
 #define UNWIND_ASSEMBLY_H
 
-#if (defined(__i386__) || defined(__x86_64__)) && defined(__linux__)
+#if defined(__linux__) && defined(__CET__)
 #include 
 #define _LIBUNWIND_CET_ENDBR _CET_ENDBR
 #else



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


[PATCH] D119407: [PowerPC] [Clang] Add SSE4 and BMI compatible intrinsics implementation for PowerPC

2022-02-16 Thread Qiu Chaofan via Phabricator via cfe-commits
qiucf updated this revision to Diff 409167.
qiucf edited the summary of this revision.
qiucf added a comment.

Rebase the fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119407

Files:
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/ppc_wrappers/bmi2intrin.h
  clang/lib/Headers/ppc_wrappers/bmiintrin.h
  clang/lib/Headers/ppc_wrappers/emmintrin.h
  clang/lib/Headers/ppc_wrappers/immintrin.h
  clang/lib/Headers/ppc_wrappers/nmmintrin.h
  clang/lib/Headers/ppc_wrappers/pmmintrin.h
  clang/lib/Headers/ppc_wrappers/smmintrin.h
  clang/lib/Headers/ppc_wrappers/tmmintrin.h
  clang/lib/Headers/ppc_wrappers/x86gprintrin.h
  clang/lib/Headers/ppc_wrappers/x86intrin.h
  clang/lib/Headers/ppc_wrappers/xmmintrin.h
  clang/test/CodeGen/PowerPC/ppc-emmintrin.c
  clang/test/CodeGen/PowerPC/ppc-smmintrin.c
  clang/test/CodeGen/PowerPC/ppc-x86gprintrin.c
  clang/test/CodeGen/PowerPC/ppc-xmmintrin.c

Index: clang/test/CodeGen/PowerPC/ppc-xmmintrin.c
===
--- clang/test/CodeGen/PowerPC/ppc-xmmintrin.c
+++ clang/test/CodeGen/PowerPC/ppc-xmmintrin.c
@@ -383,12 +383,11 @@
 // CHECK: extractelement <4 x float> %{{[0-9a-zA-Z_.]+}}, i32 0
 
 // CHECK-LABEL: define available_externally signext i32 @_mm_cvtss_si32
-// CHECK-LE: %[[VEC:[0-9a-zA-Z_.]+]] = call { <4 x float>, i64, double } asm "xxsldwi ${0:x},${0:x},${0:x},3;\0Axscvspdp ${2:x},${0:x};\0Afctiw  $2,$2;\0Amfvsrd  $1,${2:x};\0A", "=^wa,=r,=f,0"
-// CHECK-BE: %[[VEC:[0-9a-zA-Z_.]+]] = call { <4 x float>, i64, double } asm "xscvspdp ${2:x},${0:x};\0Afctiw  $2,$2;\0Amfvsrd  $1,${2:x};\0A", "=^wa,=r,=f,0"
-// CHECK: extractvalue { <4 x float>, i64, double } %[[VEC]], 0
-// CHECK: extractvalue { <4 x float>, i64, double } %[[VEC]], 1
-// CHECK: extractvalue { <4 x float>, i64, double } %[[VEC]], 2
-// CHECK: trunc i64 %{{[0-9a-zA-Z_.]+}} to i32
+// CHECK-LE: %[[VEC:[0-9a-zA-Z_.]+]] = call { <4 x float>, i32, double } asm "xxsldwi ${0:x},${0:x},${0:x},3;\0Axscvspdp ${2:x},${0:x};\0Afctiw  $2,$2;\0Amfvsrd  $1,${2:x};\0A", "=^wa,=r,=f,0"
+// CHECK-BE: %[[VEC:[0-9a-zA-Z_.]+]] = call { <4 x float>, i32, double } asm "xscvspdp ${2:x},${0:x};\0Afctiw  $2,$2;\0Amfvsrd  $1,${2:x};\0A", "=^wa,=r,=f,0"
+// CHECK: extractvalue { <4 x float>, i32, double } %[[VEC]], 0
+// CHECK: extractvalue { <4 x float>, i32, double } %[[VEC]], 1
+// CHECK: extractvalue { <4 x float>, i32, double } %[[VEC]], 2
 
 // CHECK-LABEL: define available_externally i64 @_mm_cvtss_si64
 // CHECK-LE: %[[VEC:[0-9a-zA-Z_.]+]] = call { <4 x float>, i64, double } asm "xxsldwi ${0:x},${0:x},${0:x},3;\0Axscvspdp ${2:x},${0:x};\0Afctid  $2,$2;\0Amfvsrd  $1,${2:x};\0A", "=^wa,=r,=f,0"
Index: clang/test/CodeGen/PowerPC/ppc-x86gprintrin.c
===
--- /dev/null
+++ clang/test/CodeGen/PowerPC/ppc-x86gprintrin.c
@@ -0,0 +1,239 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang -S -emit-llvm -target powerpc64le-unknown-linux-gnu -mcpu=pwr7 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s
+// RUN: %clang -S -emit-llvm -target powerpc64-unknown-linux-gnu -mcpu=pwr7 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s
+
+// RUN: %clang -S -emit-llvm -target powerpc64le-unknown-freebsd13.0 -mcpu=pwr7 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s
+// RUN: %clang -S -emit-llvm -target powerpc64-unknown-freebsd13.0 -mcpu=pwr7 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s
+
+#include 
+
+unsigned short us;
+unsigned ui;
+unsigned long long ul;
+
+void __attribute__((noinline))
+test_bmiintrin() {
+  __tzcnt_u16(us);
+  __andn_u32(ui, ui);
+  _bextr_u32(ui, ui, ui);
+  __bextr_u32(ui, ui);
+  __blsi_u32(ui);
+  _blsi_u32(ui);
+  __blsmsk_u32(ui);
+  _blsmsk_u32(ui);
+  __blsr_u32(ui);
+  _blsr_u32(ui);
+  __tzcnt_u32(ui);
+  _tzcnt_u32(ui);
+  __andn_u64(ul, ul);
+  _bextr_u64(ul, ui, ui);
+  __bextr_u64(ul, ul);
+  __blsi_u64(ul);
+  _blsi_u64(ul);
+  __blsmsk_u64(ul);
+  _blsmsk_u64(ul);
+  __blsr_u64(ul);
+  _blsr_u64(ul);
+  __tzcnt_u64(ul);
+  _tzcnt_u64(ul);
+}
+
+// CHECK-LABEL: @test_bmiintrin
+
+// CHECK-LABEL: define available_externally zeroext i16 @__tzcnt_u16(i16 noundef zeroext %{{[0-9a-zA-Z._]+}})
+// CHECK: %[[CONV:[0-9a-zA-Z._]+]] = zext i16 %{{[0-9a-zA-Z._]+}} to i32
+// CHECK: %[[CALL:[0-9a-zA-Z._]+]] = call i32 @llvm.cttz.i32(i32 %[[CONV]], i1 false)
+// CHECK: trunc i32 %[[CALL]] to i16
+
+// CHECK-LABEL: define available_externally zeroext i32 @__andn_u32(i32 noundef zeroext %{{[0-9a-zA-Z._]+}}, i32 nounde

[PATCH] D119923: [clang-format][NFC] Return early in ContinuationIndenter::mustBreak

2022-02-16 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks created this revision.
HazardyKnusperkeks added reviewers: MyDeveloperDay, curdeius, owenpan.
HazardyKnusperkeks added a project: clang-format.
HazardyKnusperkeks requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

We can return as early as possible and only calculate IsComparison if we really 
need to. Also cache getPrecedence() instead of querying it at most 4 times.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D119923

Files:
  clang/lib/Format/ContinuationIndenter.cpp


Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -448,26 +448,31 @@
   // current style uses wrapping before or after operators for the given
   // operator.
   if (Previous.is(TT_BinaryOperator) && Current.CanBreakBefore) {
-// If we need to break somewhere inside the LHS of a binary expression, we
-// should also break after the operator. Otherwise, the formatting would
-// hide the operator precedence, e.g. in:
-//   if (aa ==
-//   bb && c) {..
-// For comparisons, we only apply this rule, if the LHS is a binary
-// expression itself as otherwise, the line breaks seem superfluous.
-// We need special cases for ">>" which we have split into two ">" while
-// lexing in order to make template parsing easier.
-bool IsComparison = (Previous.getPrecedence() == prec::Relational ||
- Previous.getPrecedence() == prec::Equality ||
- Previous.getPrecedence() == prec::Spaceship) &&
-Previous.Previous &&
-Previous.Previous->isNot(TT_BinaryOperator); // For >>.
-bool LHSIsBinaryExpr =
-Previous.Previous && Previous.Previous->EndsBinaryExpression;
-if ((!IsComparison || LHSIsBinaryExpr) && !Current.isTrailingComment() &&
-Previous.getPrecedence() != prec::Assignment &&
-CurrentState.BreakBeforeParameter)
-  return true;
+const auto PreviousPrecedence = Previous.getPrecedence();
+if (PreviousPrecedence != prec::Assignment &&
+CurrentState.BreakBeforeParameter && !Current.isTrailingComment()) {
+  const bool LHSIsBinaryExpr =
+  Previous.Previous && Previous.Previous->EndsBinaryExpression;
+  if (LHSIsBinaryExpr)
+return true;
+  // If we need to break somewhere inside the LHS of a binary expression, 
we
+  // should also break after the operator. Otherwise, the formatting would
+  // hide the operator precedence, e.g. in:
+  //   if (aa ==
+  //   bb && c) {..
+  // For comparisons, we only apply this rule, if the LHS is a binary
+  // expression itself as otherwise, the line breaks seem superfluous.
+  // We need special cases for ">>" which we have split into two ">" while
+  // lexing in order to make template parsing easier.
+  const bool IsComparison =
+  (PreviousPrecedence == prec::Relational ||
+   PreviousPrecedence == prec::Equality ||
+   PreviousPrecedence == prec::Spaceship) &&
+  Previous.Previous &&
+  Previous.Previous->isNot(TT_BinaryOperator); // For >>.
+  if (!IsComparison)
+return true;
+}
   } else if (Current.is(TT_BinaryOperator) && Current.CanBreakBefore &&
  CurrentState.BreakBeforeParameter) {
 return true;


Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -448,26 +448,31 @@
   // current style uses wrapping before or after operators for the given
   // operator.
   if (Previous.is(TT_BinaryOperator) && Current.CanBreakBefore) {
-// If we need to break somewhere inside the LHS of a binary expression, we
-// should also break after the operator. Otherwise, the formatting would
-// hide the operator precedence, e.g. in:
-//   if (aa ==
-//   bb && c) {..
-// For comparisons, we only apply this rule, if the LHS is a binary
-// expression itself as otherwise, the line breaks seem superfluous.
-// We need special cases for ">>" which we have split into two ">" while
-// lexing in order to make template parsing easier.
-bool IsComparison = (Previous.getPrecedence() == prec::Relational ||
- Previous.getPrecedence() == prec::Equality ||
- Previous.getPrecedence() == prec::Spaceship) &&
-Previous.Previous &&
-Previous.Previous->isNot(TT_BinaryOperator); // For >>.
-bool LHSIsBinaryExpr =
-Previous.Previous && Previous.Previous->EndsBinaryExpression;
-if ((

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

2022-02-16 Thread Iain Sandoe via Phabricator via cfe-commits
iains added inline comments.



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

ChuanqiXu wrote:
> 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?
I see this in the Tony tables, but OTOH I cannot exactly see where the wording 
forbids it - in fact it permits preprocesssor directives before the import 
(including in the example in 5.7)... perhaps I'm misreading.

This way of writing the test cases does make them much easier to manage (and 
for a reader to see the intent) - of course, if we should split into files - 
then that is what we should do.



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] 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

2022-02-16 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay updated this revision to Diff 409171.
MaskRay edited the summary of this revision.
MaskRay added a comment.

Detect both unnormalized and normalized paths for compatibility. hack when 
default -DLLVM_DEFAULT_TARGET_TRIPLE is x86_64-unknown-linux-gnu on Debian.

  -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=on 
-DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown-linux-gnu
  /tmp/out/custom0/bin/clang++ --stdlib=libc++ -fsanitize=address a.cc
  /tmp/out/custom0/bin/clang++ --target=x86_64-linux-gnu --stdlib=libc++ 
-fsanitize=address a.cc
  
  -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=on 
-DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu
  /tmp/out/custom1/bin/clang++ --stdlib=libc++ -fsanitize=address a.cc
  /tmp/out/custom1/bin/clang++ --target=x86_64-linux-gnu --stdlib=libc++ 
-fsanitize=address a.cc



> Say we provide our toolchain to projects A and B. Project A uses clang 
> --target=aarch64-linux-gnu  Project B uses clang 
> --target=aarch64-unknown-linux-gnu  Today, this works fine because we 
> internally normalize the target to aarch64-unknown-linux-gnu and use it find 
> headers and libraries. With this change, depending on how we build the 
> toolchain, either project A or B is going to break.

The new diff makes this work, though in the long term 
-DLLVM_DEFAULT_TARGET_TRIPLE should use x86_64-linux-gnu and mismatching 
--target= and -DLLVM_DEFAULT_TARGET_TRIPLE should be unsupported.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663

Files:
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  
clang/test/Driver/Inputs/debian_per_target_tree/usr/lib/llvm-14/lib/x86_64-linux-gnu/.keep
  
clang/test/Driver/Inputs/debian_per_target_unknown_tree/usr/lib/llvm-14/bin/.keep
  
clang/test/Driver/Inputs/debian_per_target_unknown_tree/usr/lib/llvm-14/include/c++/v1/.keep
  
clang/test/Driver/Inputs/debian_per_target_unknown_tree/usr/lib/llvm-14/include/i386-unknown-linux-gnu/c++/v1/.keep
  
clang/test/Driver/Inputs/debian_per_target_unknown_tree/usr/lib/llvm-14/include/x86_64-unknown-linux-gnu/c++/v1/.keep
  
clang/test/Driver/Inputs/debian_per_target_unknown_tree/usr/lib/llvm-14/lib/clang/14.0.0/lib/i386-unknown-linux-gnu/libclang_rt.builtins.a
  
clang/test/Driver/Inputs/debian_per_target_unknown_tree/usr/lib/llvm-14/lib/clang/14.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.builtins.a
  
clang/test/Driver/Inputs/debian_per_target_unknown_tree/usr/lib/llvm-14/lib/i386-unknown-linux-gnu/.keep
  
clang/test/Driver/Inputs/debian_per_target_unknown_tree/usr/lib/llvm-14/lib/x86_64-unknown-linux-gnu/.keep
  clang/test/Driver/linux-cross.cpp

Index: clang/test/Driver/linux-cross.cpp
===
--- clang/test/Driver/linux-cross.cpp
+++ clang/test/Driver/linux-cross.cpp
@@ -152,19 +152,20 @@
 // DEBIAN_AARCH64-SAME: {{^}} "-L[[SYSROOT]]/usr/lib"
 
 /// Test native x86-64 with -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=on.
-/// FIXME -internal-isystem .*bin/../include/x86_64-linux-gnu/c++/v1 and -L[[PREFIX]]/bin/../lib/x86_64-linux-gnu are missing.
 // RUN: %clang -### %s --target=x86_64-linux-gnu --sysroot=%S/Inputs/debian_multiarch_tree \
 // RUN:   -ccc-install-dir %S/Inputs/debian_per_target_tree/usr/lib/llvm-14/bin -resource-dir=%S/Inputs/debian_per_target_tree/usr/lib/llvm-14/lib/clang/14.0.0 \
 // RUN:   --stdlib=libc++ --rtlib=compiler-rt 2>&1 | FileCheck %s --check-prefix=DEBIAN_X86_64_PER_TARGET
 // DEBIAN_X86_64_PER_TARGET:  "-resource-dir" "[[RESOURCE:[^"]+]]"
 // DEBIAN_X86_64_PER_TARGET:  "-internal-isystem"
-// DEBIAN_X86_64_PER_TARGET-SAME: {{^}} "[[PREFIX:[^"]+llvm-14]]/bin/../include/c++/v1"
+// DEBIAN_X86_64_PER_TARGET-SAME: {{^}} "[[PREFIX:[^"]+llvm-14]]/bin/../include/x86_64-linux-gnu/c++/v1"
+// DEBIAN_X86_64_PER_TARGET-SAME: {{^}} "-internal-isystem" "[[PREFIX]]/bin/../include/c++/v1"
 // DEBIAN_X86_64_PER_TARGET-SAME: {{^}} "-internal-isystem" "[[RESOURCE]]/include"
 // DEBIAN_X86_64_PER_TARGET-SAME: {{^}} "-internal-isystem" "[[SYSROOT:[^"]+]]/usr/local/include"
 // DEBIAN_X86_64_PER_TARGET-SAME: {{^}} "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/include"
 
 // DEBIAN_X86_64_PER_TARGET:  "-L
-// DEBIAN_X86_64_PER_TARGET-SAME: {{^}}[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/10"
+// DEBIAN_X86_64_PER_TARGET-SAME: {{^}}[[PREFIX]]/bin/../lib/x86_64-linux-gnu"
+// DEBIAN_X86_64_PER_TARGET-SAME: {{^}} "-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/10"
 /// Debian patches MULTILIB_OSDIRNAMES (../lib64 -> ../lib), so gcc uses 'lib' instead of 'lib64'.
 /// This difference does not matter in practice.
 // DEBIAN_X86_64_PER_TARGET-SAME: {{^}} "-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/10/../../../../lib64"
@@ -177,21 +178,53 @@
 /// $sysroot/lib and $sysroot/usr/lib. Fallback when GCC installation is unavail

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

2022-02-16 Thread 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
+

iains wrote:
> ChuanqiXu wrote:
> > 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?
> I see this in the Tony tables, but OTOH I cannot exactly see where the 
> wording forbids it - in fact it permits preprocesssor directives before the 
> import (including in the example in 5.7)... perhaps I'm misreading.
> 
> This way of writing the test cases does make them much easier to manage (and 
> for a reader to see the intent) - of course, if we should split into files - 
> then that is what we should do.
> 
I think the grammar in [[ http://eel.is/c++draft/cpp | [cpp.pre] ]] forbid it.

First, the file could only be:
```
preprocessing-file:
group_opt
module-file
```

Then it is clear that we couldn't put macro declarative before module 
declaration. I agree the current style is easier and more convenient. In fact, 
I prefer it too. But I think we would better follow it since it is standard. 
Otherwise, it would be more work in later maintenance stage.


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] D119525: [clang] Fix crash when array size is missing in initializer

2022-02-16 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder updated this revision to Diff 409173.

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

https://reviews.llvm.org/D119525

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ExprCXX.h
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/AST/issue53742.cpp

Index: clang/test/AST/issue53742.cpp
===
--- /dev/null
+++ clang/test/AST/issue53742.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -fsyntax-only %s -verify
+
+struct Data {
+  char *a;
+  char *b;
+  bool *c;
+};
+
+int main() {
+  Data in;
+  in.a = new char[](); // expected-error {{cannot determine allocated array size from initializer}}
+  in.c = new bool[100]();
+  in.b = new char[100]();
+}
Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -11918,9 +11918,9 @@
 
   // Transform the size of the array we're allocating (if any).
   Optional ArraySize;
-  if (Optional OldArraySize = E->getArraySize()) {
+  if (E->isArray()) {
 ExprResult NewArraySize;
-if (*OldArraySize) {
+if (Optional OldArraySize = E->getArraySize()) {
   NewArraySize = getDerived().TransformExpr(*OldArraySize);
   if (NewArraySize.isInvalid())
 return ExprError();
Index: clang/lib/AST/StmtPrinter.cpp
===
--- clang/lib/AST/StmtPrinter.cpp
+++ clang/lib/AST/StmtPrinter.cpp
@@ -2132,10 +2132,10 @@
   if (E->isParenTypeId())
 OS << "(";
   std::string TypeS;
-  if (Optional Size = E->getArraySize()) {
+  if (E->isArray()) {
 llvm::raw_string_ostream s(TypeS);
 s << '[';
-if (*Size)
+if (Optional Size = E->getArraySize())
   (*Size)->printPretty(s, Helper, Policy);
 s << ']';
   }
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -9427,7 +9427,7 @@
   bool ValueInit = false;
 
   QualType AllocType = E->getAllocatedType();
-  if (Optional ArraySize = E->getArraySize()) {
+  if (Optional ArraySize = E->getArraySize()) {
 const Expr *Stripped = *ArraySize;
 for (; auto *ICE = dyn_cast(Stripped);
  Stripped = ICE->getSubExpr())
Index: clang/include/clang/AST/ExprCXX.h
===
--- clang/include/clang/AST/ExprCXX.h
+++ clang/include/clang/AST/ExprCXX.h
@@ -2261,15 +2261,32 @@
 
   bool isArray() const { return CXXNewExprBits.IsArray; }
 
+  /// This might return None even if isArray() returns true,
+  /// since there might not be an array size expression.
+  /// If the result is not-None, it will never wrap a nullptr.
   Optional getArraySize() {
 if (!isArray())
   return None;
-return cast_or_null(getTrailingObjects()[arraySizeOffset()]);
+
+if (auto *Result =
+cast_or_null(getTrailingObjects()[arraySizeOffset()]))
+  return Result;
+
+return None;
   }
+
+  /// This might return None even if isArray() returns true,
+  /// since there might not be an array size expression.
+  /// If the result is not-None, it will never wrap a nullptr.
   Optional getArraySize() const {
 if (!isArray())
   return None;
-return cast_or_null(getTrailingObjects()[arraySizeOffset()]);
+
+if (auto *Result =
+cast_or_null(getTrailingObjects()[arraySizeOffset()]))
+  return Result;
+
+return None;
   }
 
   unsigned getNumPlacementArgs() const {
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -49,6 +49,13 @@
 
 -  ...
 
+Bug Fixes
+--
+- ``CXXNewExpr::getArraySize()`` previously returned a ``llvm::Optional``
+  wrapping a ``nullptr`` when the ``CXXNewExpr`` did not have an array
+  size expression. This was fixed and ``::getArraySize()`` will now always
+  either return ``None`` or a ``llvm::Optional`` wrapping a valid ``Expr*``.
+
 Improvements to Clang's diagnostics
 ^^^
 
___
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

2022-02-16 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D110663#3324970 , @phosek wrote:

> 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).

It could be addressed by letting CMake normalize LLVM_DEFAULT_TARGET_TRIPLE 
before constructing the multiarch search path, but I think that's the wrong 
direction.
The only way allowing removal of various normalization code in 
CMake/ClangDriver is to do no normalization. Just respect user-specified target 
triples (from `LLVM_DEFAULT_TARGET_TRIPLE`, or from `--target=`) as is.


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] b3c0014 - Revert "Revert "[analyzer] Prevent misuses of -analyze-function""

2022-02-16 Thread Balazs Benics via cfe-commits

Author: Balazs Benics
Date: 2022-02-16T10:33:21+01:00
New Revision: b3c0014e5a7530645f502d8b19ef1df313cc85b9

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

LOG: Revert "Revert "[analyzer] Prevent misuses of -analyze-function""

This reverts commit 620d99b7edc64ee87b1ce209f179305e6a919006.

Let's see if removing the two offending RUN lines makes this patch pass.
Not ideal to drop tests but, it's just a debugging feature, probably not
that important.

Added: 
clang/test/Analysis/analyze-function-guide.cpp
clang/test/Analysis/analyze-function-guide.m

Modified: 
clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp 
b/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
index 323c002d0cef6..9e96e00011f4f 100644
--- a/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ b/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -499,6 +499,28 @@ static bool fileContainsString(StringRef Substring, 
ASTContext &C) {
   return Buffer.contains(Substring);
 }
 
+static void reportAnalyzerFunctionMisuse(const AnalyzerOptions &Opts,
+ const ASTContext &Ctx) {
+  llvm::errs() << "Every top-level function was skipped.\n";
+
+  if (!Opts.AnalyzerDisplayProgress)
+llvm::errs() << "Pass the -analyzer-display-progress for tracking which "
+"functions are analyzed.\n";
+
+  bool HasBrackets =
+  Opts.AnalyzeSpecificFunction.find("(") != std::string::npos;
+
+  if (Ctx.getLangOpts().CPlusPlus && !HasBrackets) {
+llvm::errs()
+<< "For analyzing C++ code you need to pass the function parameter "
+   "list: -analyze-function=\"foobar(int, _Bool)\"\n";
+  } else if (!Ctx.getLangOpts().CPlusPlus && HasBrackets) {
+llvm::errs() << "For analyzing C code you shouldn't pass the function "
+"parameter list, only the name of the function: "
+"-analyze-function=foobar\n";
+  }
+}
+
 void AnalysisConsumer::runAnalysisOnTranslationUnit(ASTContext &C) {
   BugReporter BR(*Mgr);
   TranslationUnitDecl *TU = C.getTranslationUnitDecl();
@@ -535,6 +557,14 @@ void 
AnalysisConsumer::runAnalysisOnTranslationUnit(ASTContext &C) {
 
   BR.FlushReports();
   RecVisitorBR = nullptr;
+
+  // If the user wanted to analyze a specific function and the number of basic
+  // blocks analyzed is zero, than the user might not specified the function
+  // name correctly.
+  // FIXME: The user might have analyzed the requested function in Syntax mode,
+  // but we are unaware of that.
+  if (!Opts->AnalyzeSpecificFunction.empty() && NumFunctionsAnalyzed == 0)
+reportAnalyzerFunctionMisuse(*Opts, *Ctx);
 }
 
 void AnalysisConsumer::reportAnalyzerProgress(StringRef S) {

diff  --git a/clang/test/Analysis/analyze-function-guide.cpp 
b/clang/test/Analysis/analyze-function-guide.cpp
new file mode 100644
index 0..daf029544a14e
--- /dev/null
+++ b/clang/test/Analysis/analyze-function-guide.cpp
@@ -0,0 +1,70 @@
+int fizzbuzz(int x, bool y) {
+  return x + y;
+}
+
+// C++ but not uses parentheses in the '-analyze-function' option.
+//
+// RUN: %clang_analyze_cc1 -analyzer-checker=core \
+// RUN:   -analyze-function='missing_fn' -x c++ \
+// RUN:   -triple x86_64-pc-linux-gnu 2>&1 %s \
+// RUN: | FileCheck %s -check-prefix=CHECK-CXX
+//
+// CHECK-CXX:  Every top-level function was skipped.
+// CHECK-CXX-NEXT: Pass the -analyzer-display-progress for tracking which 
functions are analyzed.
+// CHECK-CXX-NEXT: For analyzing C++ code you need to pass the function 
parameter list: -analyze-function="foobar(int, _Bool)"
+
+// C but uses parentheses in the '-analyze-function' option.
+//
+// RUN: %clang_analyze_cc1 -analyzer-checker=core \
+// RUN:   -analyze-function='missing_fn()' -x c -Dbool=_Bool \
+// RUN:   -triple x86_64-pc-linux-gnu 2>&1 %s \
+// RUN: | FileCheck %s -check-prefix=CHECK-C
+//
+// CHECK-C:  Every top-level function was skipped.
+// CHECK-C-NEXT: Pass the -analyzer-display-progress for tracking which 
functions are analyzed.
+// CHECK-C-NEXT: For analyzing C code you shouldn't pass the function 
parameter list, only the name of the function: -analyze-function=foobar
+
+// The user passed the '-analyzer-display-progress' option, we don't need to 
advocate it.
+//
+// RUN: %clang_analyze_cc1 -analyzer-checker=core \
+// RUN:   -analyze-function=missing_fn \
+// RUN:   -analyzer-display-progress -x c -Dbool=_Bool \
+// RUN:   -triple x86_64-pc-linux-gnu 2>&1 %s \
+// RUN: | FileCheck %s -check-prefix=CHECK-DONT-ADVOCATE-DISPLAY-PROGRESS
+//
+// CHECK-DONT-ADVOCATE-DISPLAY-PROGRESS: Every top-level function was 
skipped.
+// CHECK-DONT-ADVOCATE-DISPLAY-PROGRESS-NOT: Pass the

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

2022-02-16 Thread Pavel Labath via Phabricator via cfe-commits
labath added a comment.

Not my usual wheelhouse, but since I'm here, here are some of my thoughts:

- reusing the existing solution/code seems like a good idea -- no need to 
reinvent the wheel
- how does that work, actually? How does it differentiate between "my" code and 
"code that happens to be compiled in the current CU" (e.g. the STL).  What's 
the significance of the funky `___x@c` symbols?
- if the goal is to integrate this into lldb (and given that lldb currently 
does not support any feature like this), I'd recommend sending an RFC/heads up 
early, to identify possible issues


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

___
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

2022-02-16 Thread Diana Picus via Phabricator via cfe-commits
rovka added a comment.

Is this going to break for everyone that still passes TARGET_TRIPLE to cmake? 
If so, we should probably have a period where we support both.

In particular, this might break some of our buildbots 

 who explicitly set TARGET_TRIPLE. Could you send a patch to zorg cleaning that 
up (and maybe wait for that to go through before removing TARGET_TRIPLE 
completely)?


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


[clang] 4642c64 - [analyzer] Remove breaking RUN line in the test case

2022-02-16 Thread Balazs Benics via cfe-commits

Author: Balazs Benics
Date: 2022-02-16T10:56:18+01:00
New Revision: 4642c640f4ef76b7e98420c98b7391f069293838

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

LOG: [analyzer] Remove breaking RUN line in the test case

This is a followup for D118690.
I'm removing the offending RUN line, to resolve the build breakage:

https://lab.llvm.org/buildbot/#/builders/91/builds/3975/steps/8/logs/stdio

Exit Code: 1
Command Output (stderr):
--
/scratch/buildbot/bothome/clang-ve-ninja/llvm-project/clang/test/Analysis/analyze-function-guide.cpp:58:22:
error: CHECK-EMPTY2-NOT: excluded string found in input
// CHECK-EMPTY2-NOT: Every top-level function was skipped.
 ^
:1:1: note: found here
Every top-level function was skipped.
^

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

Added: 


Modified: 
clang/test/Analysis/analyze-function-guide.cpp

Removed: 




diff  --git a/clang/test/Analysis/analyze-function-guide.cpp 
b/clang/test/Analysis/analyze-function-guide.cpp
index daf029544a14..96f1001057eb 100644
--- a/clang/test/Analysis/analyze-function-guide.cpp
+++ b/clang/test/Analysis/analyze-function-guide.cpp
@@ -46,17 +46,6 @@ int fizzbuzz(int x, bool y) {
 // CHECK-ADVOCATE-DISPLAY-PROGRESS-NEXT: Pass the -analyzer-display-progress 
for tracking which functions are analyzed.
 // CHECK-ADVOCATE-DISPLAY-PROGRESS-NOT:  For analyzing
 
-// The user passed the '-analyze-function' option and that matches on a
-// declaration in C mode.
-//
-// RUN: %clang_analyze_cc1 -analyzer-checker=core \
-// RUN:   -analyze-function='fizzbuzz' -x c -Dbool=_Bool \
-// RUN:   -triple x86_64-pc-linux-gnu 2>&1 %s \
-// RUN: | FileCheck %s -check-prefix=CHECK-EMPTY2 --allow-empty
-//
-// Expected empty standard output.
-// CHECK-EMPTY2-NOT: Every top-level function was skipped.
-
 // Same as the previous but syntax mode only.
 // FIXME: This should have empty standard output.
 //



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


[PATCH] D118690: [analyzer] Prevent misuses of -analyze-function

2022-02-16 Thread Balázs Benics via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4642c640f4ef: [analyzer] Remove breaking RUN line in the 
test case (authored by steakhal).

Changed prior to commit:
  https://reviews.llvm.org/D118690?vs=406845&id=409175#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118690

Files:
  clang/test/Analysis/analyze-function-guide.cpp


Index: clang/test/Analysis/analyze-function-guide.cpp
===
--- clang/test/Analysis/analyze-function-guide.cpp
+++ clang/test/Analysis/analyze-function-guide.cpp
@@ -46,17 +46,6 @@
 // CHECK-ADVOCATE-DISPLAY-PROGRESS-NEXT: Pass the -analyzer-display-progress 
for tracking which functions are analyzed.
 // CHECK-ADVOCATE-DISPLAY-PROGRESS-NOT:  For analyzing
 
-// The user passed the '-analyze-function' option and that matches on a
-// declaration in C mode.
-//
-// RUN: %clang_analyze_cc1 -analyzer-checker=core \
-// RUN:   -analyze-function='fizzbuzz' -x c -Dbool=_Bool \
-// RUN:   -triple x86_64-pc-linux-gnu 2>&1 %s \
-// RUN: | FileCheck %s -check-prefix=CHECK-EMPTY2 --allow-empty
-//
-// Expected empty standard output.
-// CHECK-EMPTY2-NOT: Every top-level function was skipped.
-
 // Same as the previous but syntax mode only.
 // FIXME: This should have empty standard output.
 //


Index: clang/test/Analysis/analyze-function-guide.cpp
===
--- clang/test/Analysis/analyze-function-guide.cpp
+++ clang/test/Analysis/analyze-function-guide.cpp
@@ -46,17 +46,6 @@
 // CHECK-ADVOCATE-DISPLAY-PROGRESS-NEXT: Pass the -analyzer-display-progress for tracking which functions are analyzed.
 // CHECK-ADVOCATE-DISPLAY-PROGRESS-NOT:  For analyzing
 
-// The user passed the '-analyze-function' option and that matches on a
-// declaration in C mode.
-//
-// RUN: %clang_analyze_cc1 -analyzer-checker=core \
-// RUN:   -analyze-function='fizzbuzz' -x c -Dbool=_Bool \
-// RUN:   -triple x86_64-pc-linux-gnu 2>&1 %s \
-// RUN: | FileCheck %s -check-prefix=CHECK-EMPTY2 --allow-empty
-//
-// Expected empty standard output.
-// CHECK-EMPTY2-NOT: Every top-level function was skipped.
-
 // Same as the previous but syntax mode only.
 // FIXME: This should have empty standard output.
 //
___
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

2022-02-16 Thread Zakk Chen via Phabricator via cfe-commits
khchen added a comment.

In D70401#3325419 , @zixuan-wu wrote:

> 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?

I believe you can try QEMU, I tried it before.
https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/JE0aG-Mr0u4/m/tfFoITv7AgAJ
For llvm-test-suite, you could disable some non-baremental tests manually.
I found some issues in my local rv32e implementation by running llvm-test-suite 
before, it's why I think it's good to have a test.

Maybe the other reviewers have different opinions about this.
@luismarques @jrtc27 @asb @kito-cheng What do you think?


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] D119719: [Docs][OpenCL] Update OpenCL 3.0 status

2022-02-16 Thread Anton Zabaznov via Phabricator via cfe-commits
azabaznov accepted this revision.
azabaznov added a comment.

LGTM. Thanks!


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

https://reviews.llvm.org/D119719

___
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.

2022-02-16 Thread Iain Sandoe via Phabricator via cfe-commits
iains updated this revision to Diff 409178.
iains marked 2 inline comments as not done.
iains added a comment.

Address review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118893

Files:
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Parse/ParseAST.cpp
  clang/lib/Parse/ParseObjc.cpp
  clang/lib/Parse/Parser.cpp
  clang/lib/Sema/SemaModule.cpp
  clang/test/Modules/cxx20-import-diagnostics-a.cpp

Index: clang/test/Modules/cxx20-import-diagnostics-a.cpp
===
--- /dev/null
+++ clang/test/Modules/cxx20-import-diagnostics-a.cpp
@@ -0,0 +1,140 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=0 -x c++ %s \
+// RUN:  -o %t/B.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=1 -x c++ %s \
+// RUN:  -o %t/C.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=2 -x c++ %s \
+// RUN:  -fmodule-file=%t/B.pcm -fmodule-file=%t/C.pcm -o %t/AOK1.pcm
+
+// RUN: %clang_cc1 -std=c++20 -S -D TU=3 -x c++ %s \
+// RUN:  -fmodule-file=%t/AOK1.pcm -o %t/tu_3.s -verify
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=4 -x c++ %s \
+// RUN:  -fmodule-file=%t/B.pcm -fmodule-file=%t/C.pcm -o %t/BC.pcm -verify
+
+// RUN: %clang_cc1 -std=c++20 -S -D TU=5 -x c++ %s \
+// RUN:  -fmodule-file=%t/B.pcm -fmodule-file=%t/C.pcm -o %t/tu_5.s -verify
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=6 -x c++ %s \
+// RUN:  -fmodule-file=%t/B.pcm -o %t/D.pcm -verify
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=7 -x c++ %s \
+// RUN:  -fmodule-file=%t/B.pcm -o %t/D.pcm -verify
+
+// RUN: %clang_cc1 -std=c++20 -S -D TU=8 -x c++ %s \
+// RUN:  -fmodule-file=%t/B.pcm -o %t/tu_8.s -verify
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=9 -x c++ %s \
+// RUN:  -o %t/B.pcm -verify
+
+// RUN: %clang_cc1 -std=c++20 -emit-obj -D TU=10 -x c++ %s \
+// RUN:  -fmodule-file=%t/C.pcm  -o %t/impl.o
+
+// Test diagnostics for incorrect module import sequences.
+
+#if TU == 0
+
+export module B;
+
+int foo ();
+
+// expected-no-diagnostics
+
+#elif TU == 1
+
+export module C;
+
+int bar ();
+
+// expected-no-diagnostics
+
+#elif TU == 2
+
+export module AOK1;
+
+import B;
+export import C;
+
+export int theAnswer ();
+
+// expected-no-diagnostics
+
+#elif TU == 3
+
+module;
+
+module AOK1;
+
+export import C; // expected-error {{export declaration can only be used within a module interface unit}}
+
+int theAnswer () { return 42; }
+
+#elif TU == 4
+
+export module BC;
+
+export import B;
+
+int foo () { return 10; }
+
+import C; // expected-error {{imports must immediately follow the module declaration}}
+
+#elif TU == 5
+
+module B; // implicitly imports B.
+
+int foo () { return 10; }
+
+import C; // expected-error {{imports must immediately follow the module declaration}}
+
+#elif TU == 6
+
+module;
+// We can only have preprocessor commands here, which could include an include
+// translated header unit.  However those are identified specifically by the
+// preprocessor; non-preprocessed user code should not contain an import here.
+import B; // expected-error {{module imports cannot be in the global module fragment}}
+
+export module D;
+
+int delta ();
+
+#elif TU == 7
+
+export module D;
+
+int delta ();
+
+module :private;
+
+import B; // expected-error {{module imports cannot be in the private module fragment}}
+
+#elif TU == 8
+
+module B;
+
+import B; // expected-error {{import of module 'B' appears within same top-level module 'B'}}
+
+#elif TU == 9
+
+export module B;
+
+import B; // expected-error {{import of module 'B' appears within same top-level module 'B'}}
+
+#elif TU == 10
+
+int x;
+
+import C;
+
+int baz() { return 6174; }
+
+// expected-no-diagnostics
+
+#else
+#error "no MODE set"
+#endif
Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -80,12 +80,20 @@
   return nullptr;
 }
 
-Sema::DeclGroupPtrTy
-Sema::ActOnModuleDecl(SourceLocation StartLoc, SourceLocation ModuleLoc,
-  ModuleDeclKind MDK, ModuleIdPath Path, bool IsFirstDecl) {
+Sema::DeclGroupPtrTy Sema::ActOnModuleDecl(SourceLocation StartLoc,
+   SourceLocation ModuleLoc,
+   ModuleDeclKind MDK,
+   ModuleIdPath Path,
+   ModuleImportState &ImportState) {
   assert((getLangOpts().ModulesTS || getLangOpts().CPlusPlusModules) &&
  "should only have module decl in Modules TS or C++20");
 
+  bool IsFirstDecl = ImportState == ModuleImportState::Firs

[clang] 477bc8e - [OpenCL] Guard atomic_double with cl_khr_int64_*

2022-02-16 Thread Sven van Haastregt via cfe-commits

Author: Sven van Haastregt
Date: 2022-02-16T10:07:35Z
New Revision: 477bc8e8b9311fdac4c360b1fe7d29d0d10aac6c

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

LOG: [OpenCL] Guard atomic_double with cl_khr_int64_*

It is necessary to guard atomic_double type according to
https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#_footnotedef_54.
Platform that disable cl_khr_int64_base_atomics and
cl_khr_int64_extended_atomics will have compiling errors even if
atomic_double is not used.

Patch by Haonan Yang.

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

Added: 


Modified: 
clang/lib/Headers/opencl-c.h

Removed: 




diff  --git a/clang/lib/Headers/opencl-c.h b/clang/lib/Headers/opencl-c.h
index 7a2ddc47c9a1b..bf3f01253df32 100644
--- a/clang/lib/Headers/opencl-c.h
+++ b/clang/lib/Headers/opencl-c.h
@@ -13832,6 +13832,7 @@ float __ovld atomic_fetch_max_explicit(volatile 
atomic_float *object,
 #endif // defined(__opencl_c_ext_fp32_global_atomic_min_max) &&
\
 defined(__opencl_c_ext_fp32_local_atomic_min_max)
 
+#if defined(cl_khr_int64_base_atomics) && 
defined(cl_khr_int64_extended_atomics)
 #if defined(__opencl_c_ext_fp64_global_atomic_min_max)
 double __ovld atomic_fetch_min(volatile __global atomic_double *object,
double operand);
@@ -13882,6 +13883,8 @@ double __ovld atomic_fetch_max_explicit(volatile 
atomic_double *object,
 memory_scope scope);
 #endif // defined(__opencl_c_ext_fp64_global_atomic_min_max) &&
\
 defined(__opencl_c_ext_fp64_local_atomic_min_max)
+#endif // defined(cl_khr_int64_base_atomics) &&
\
+defined(cl_khr_int64_extended_atomics)
 
 #if defined(__opencl_c_ext_fp16_global_atomic_add)
 half __ovld atomic_fetch_add(volatile __global atomic_half *object,
@@ -13985,6 +13988,7 @@ float __ovld atomic_fetch_sub_explicit(volatile 
atomic_float *object,
 #endif // defined(__opencl_c_ext_fp32_global_atomic_add) &&
\
 defined(__opencl_c_ext_fp32_local_atomic_add)
 
+#if defined(cl_khr_int64_base_atomics) && 
defined(cl_khr_int64_extended_atomics)
 #if defined(__opencl_c_ext_fp64_global_atomic_add)
 double __ovld atomic_fetch_add(volatile __global atomic_double *object,
double operand);
@@ -14035,6 +14039,8 @@ double __ovld atomic_fetch_sub_explicit(volatile 
atomic_double *object,
 memory_scope scope);
 #endif // defined(__opencl_c_ext_fp64_global_atomic_add) &&
\
 defined(__opencl_c_ext_fp64_local_atomic_add)
+#endif // defined(cl_khr_int64_base_atomics) &&
\
+defined(cl_khr_int64_extended_atomics)
 
 #endif // cl_ext_float_atomics
 



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


[PATCH] D119398: [OpenCL] Guard atomic_double with cl_khr_int64_base_atomics and cl_khr_int64_extended_atomics

2022-02-16 Thread Sven van Haastregt via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG477bc8e8b931: [OpenCL] Guard atomic_double with 
cl_khr_int64_* (authored by svenvh).

Changed prior to commit:
  https://reviews.llvm.org/D119398?vs=407506&id=409179#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119398

Files:
  clang/lib/Headers/opencl-c.h


Index: clang/lib/Headers/opencl-c.h
===
--- clang/lib/Headers/opencl-c.h
+++ clang/lib/Headers/opencl-c.h
@@ -13832,6 +13832,7 @@
 #endif // defined(__opencl_c_ext_fp32_global_atomic_min_max) &&
\
 defined(__opencl_c_ext_fp32_local_atomic_min_max)
 
+#if defined(cl_khr_int64_base_atomics) && 
defined(cl_khr_int64_extended_atomics)
 #if defined(__opencl_c_ext_fp64_global_atomic_min_max)
 double __ovld atomic_fetch_min(volatile __global atomic_double *object,
double operand);
@@ -13882,6 +13883,8 @@
 memory_scope scope);
 #endif // defined(__opencl_c_ext_fp64_global_atomic_min_max) &&
\
 defined(__opencl_c_ext_fp64_local_atomic_min_max)
+#endif // defined(cl_khr_int64_base_atomics) &&
\
+defined(cl_khr_int64_extended_atomics)
 
 #if defined(__opencl_c_ext_fp16_global_atomic_add)
 half __ovld atomic_fetch_add(volatile __global atomic_half *object,
@@ -13985,6 +13988,7 @@
 #endif // defined(__opencl_c_ext_fp32_global_atomic_add) &&
\
 defined(__opencl_c_ext_fp32_local_atomic_add)
 
+#if defined(cl_khr_int64_base_atomics) && 
defined(cl_khr_int64_extended_atomics)
 #if defined(__opencl_c_ext_fp64_global_atomic_add)
 double __ovld atomic_fetch_add(volatile __global atomic_double *object,
double operand);
@@ -14035,6 +14039,8 @@
 memory_scope scope);
 #endif // defined(__opencl_c_ext_fp64_global_atomic_add) &&
\
 defined(__opencl_c_ext_fp64_local_atomic_add)
+#endif // defined(cl_khr_int64_base_atomics) &&
\
+defined(cl_khr_int64_extended_atomics)
 
 #endif // cl_ext_float_atomics
 


Index: clang/lib/Headers/opencl-c.h
===
--- clang/lib/Headers/opencl-c.h
+++ clang/lib/Headers/opencl-c.h
@@ -13832,6 +13832,7 @@
 #endif // defined(__opencl_c_ext_fp32_global_atomic_min_max) &&\
 defined(__opencl_c_ext_fp32_local_atomic_min_max)
 
+#if defined(cl_khr_int64_base_atomics) && defined(cl_khr_int64_extended_atomics)
 #if defined(__opencl_c_ext_fp64_global_atomic_min_max)
 double __ovld atomic_fetch_min(volatile __global atomic_double *object,
double operand);
@@ -13882,6 +13883,8 @@
 memory_scope scope);
 #endif // defined(__opencl_c_ext_fp64_global_atomic_min_max) &&\
 defined(__opencl_c_ext_fp64_local_atomic_min_max)
+#endif // defined(cl_khr_int64_base_atomics) &&\
+defined(cl_khr_int64_extended_atomics)
 
 #if defined(__opencl_c_ext_fp16_global_atomic_add)
 half __ovld atomic_fetch_add(volatile __global atomic_half *object,
@@ -13985,6 +13988,7 @@
 #endif // defined(__opencl_c_ext_fp32_global_atomic_add) &&\
 defined(__opencl_c_ext_fp32_local_atomic_add)
 
+#if defined(cl_khr_int64_base_atomics) && defined(cl_khr_int64_extended_atomics)
 #if defined(__opencl_c_ext_fp64_global_atomic_add)
 double __ovld atomic_fetch_add(volatile __global atomic_double *object,
double operand);
@@ -14035,6 +14039,8 @@
 memory_scope scope);
 #endif // defined(__opencl_c_ext_fp64_global_atomic_add) &&\
 defined(__opencl_c_ext_fp64_local_atomic_add)
+#endif // defined(cl_khr_int64_base_atomics) &&\
+defined(cl_khr_int64_extended_atomics)
 
 #endif // cl_ext_float_atomics
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2022-02-16 Thread Iain Sandoe via Phabricator via cfe-commits
iains marked 5 inline comments as done.
iains added a comment.

also reformatted.


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] D119923: [clang-format][NFC] Return early in ContinuationIndenter::mustBreak

2022-02-16 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius accepted this revision.
curdeius added a comment.
This revision is now accepted and ready to land.

CI is happy, I'm happy :). LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119923

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


[PATCH] D118690: [analyzer] Prevent misuses of -analyze-function

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

I've decided to remove the offending RUN lines.
It's less than ideal, but TBH I think it doesn't really matter.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118690

___
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.

2022-02-16 Thread Iain Sandoe via Phabricator via cfe-commits
iains updated this revision to Diff 409187.
iains added a comment.

address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114714

Files:
  clang/include/clang/Basic/Module.h
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaModule.cpp
  clang/lib/Serialization/ASTWriter.cpp


Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -2673,7 +2673,7 @@
   Abbrev->Add(BitCodeAbbrevOp(SUBMODULE_DEFINITION));
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // ID
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // Parent
-  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 2)); // Kind
+  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); // Kind
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // IsFramework
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // IsExplicit
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // IsSystem
Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -257,6 +257,8 @@
: ModuleScopes.back().Module->Kind) {
   case Module::ModuleMapModule:
   case Module::GlobalModuleFragment:
+  case Module::ModulePartitionImplementation:
+  case Module::ModulePartitionInterface:
 Diag(PrivateLoc, diag::err_private_module_fragment_not_module);
 return nullptr;
 
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -1550,6 +1550,8 @@
 return nullptr;
 
   case Module::ModuleInterfaceUnit:
+  case Module::ModulePartitionInterface:
+  case Module::ModulePartitionImplementation:
 return M;
 
   case Module::GlobalModuleFragment: {
Index: clang/include/clang/Basic/Module.h
===
--- clang/include/clang/Basic/Module.h
+++ clang/include/clang/Basic/Module.h
@@ -106,9 +106,15 @@
 /// of header files.
 ModuleMapModule,
 
-/// This is a C++ Modules TS module interface unit.
+/// This is a C++20 module interface unit.
 ModuleInterfaceUnit,
 
+/// This is a C++ 20 module partition interface.
+ModulePartitionInterface,
+
+/// This is a C++ 20 module partition implementation.
+ModulePartitionImplementation,
+
 /// This is a fragment of the global module within some C++ module.
 GlobalModuleFragment,
 
@@ -150,7 +156,9 @@
 
   /// Does this Module scope describe part of the purview of a named C++ 
module?
   bool isModulePurview() const {
-return Kind == ModuleInterfaceUnit || Kind == PrivateModuleFragment;
+return Kind == ModuleInterfaceUnit || Kind == ModulePartitionInterface ||
+   Kind == ModulePartitionImplementation ||
+   Kind == PrivateModuleFragment;
   }
 
   /// Does this Module scope describe a fragment of the global module within
@@ -506,6 +514,9 @@
 Parent->SubModules.push_back(this);
   }
 
+  /// Is this a module partition.
+  bool isModulePartition() const { return Name.find(':') != std::string::npos; 
}
+
   /// Retrieve the full name of this module, including the path from
   /// its top-level module.
   /// \param AllowStringLiterals If \c true, components that might not be


Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -2673,7 +2673,7 @@
   Abbrev->Add(BitCodeAbbrevOp(SUBMODULE_DEFINITION));
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // ID
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // Parent
-  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 2)); // Kind
+  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); // Kind
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // IsFramework
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // IsExplicit
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // IsSystem
Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -257,6 +257,8 @@
: ModuleScopes.back().Module->Kind) {
   case Module::ModuleMapModule:
   case Module::GlobalModuleFragment:
+  case Module::ModulePartitionImplementation:
+  case Module::ModulePartitionInterface:
 Diag(PrivateLoc, diag::err_private_module_fragment_not_module);
 return nullptr;
 
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -1550,6 +1550,8 

[PATCH] D119926: [Clang][AArch64] Enable _Float16 _Complex type

2022-02-16 Thread Matt Devereau via Phabricator via cfe-commits
MattDevereau created this revision.
MattDevereau added reviewers: georges, peterwaller-arm, paulwalker-arm, 
DavidTruby, bsmith, teemperor, rjmccall, qiucf.
Herald added a subscriber: kristof.beyls.
MattDevereau 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/D119926

Files:
  clang/include/clang/AST/ASTContext.h
  clang/lib/AST/ASTContext.cpp
  clang/test/CodeGen/aarch64-complex-half-math.c

Index: clang/test/CodeGen/aarch64-complex-half-math.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-complex-half-math.c
@@ -0,0 +1,145 @@
+// RUN: %clang_cc1 %s -O1 -emit-llvm -triple aarch64-unknown-unknown -ffast-math -o - | FileCheck %s --check-prefix=AARCH64
+
+_Float16 _Complex add_float_rr(_Float16 a, _Float16 b) {
+  // AARCH64-LABEL: @add_float_rr(
+  // AARCH64: fadd reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fadd
+  // AARCH64: ret { half, half }
+  return a + b;
+}
+_Float16 _Complex add_float_cr(_Float16 _Complex a, _Float16 b) {
+  // AARCH64-LABEL: @add_float_cr(
+  // AARCH64: fadd reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fadd
+  // AARCH64: ret { half, half }
+  return a + b;
+}
+_Float16 _Complex add_float_rc(_Float16 a, _Float16 _Complex b) {
+  // AARCH64-LABEL: @add_float_rc(
+  // AARCH64: fadd reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fadd
+  // AARCH64: ret { half, half }
+  return a + b;
+}
+_Float16 _Complex add_float_cc(_Float16 _Complex a, _Float16 _Complex b) {
+  // AARCH64-LABEL: @add_float_cc(
+  // AARCH64: fadd reassoc nnan ninf nsz arcp afn half
+  // AARCH64: fadd reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fadd
+  // AARCH64: ret { half, half }
+  return a + b;
+}
+
+_Float16 _Complex sub_float_rr(_Float16 a, _Float16 b) {
+  // AARCH64-LABEL: @sub_float_rr(
+  // AARCH64: fsub reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fsub
+  // AARCH64: ret { half, half }
+  return a - b;
+}
+_Float16 _Complex sub_float_cr(_Float16 _Complex a, _Float16 b) {
+  // AARCH64-LABEL: @sub_float_cr(
+  // AARCH64: fsub reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fsub
+  // AARCH64: ret { half, half }
+  return a - b;
+}
+_Float16 _Complex sub_float_rc(_Float16 a, _Float16 _Complex b) {
+  // AARCH64-LABEL: @sub_float_rc(
+  // AARCH64: fsub reassoc nnan ninf nsz arcp afn half
+  // AARCH64: fneg reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fsub
+  // AARCH64: ret { half, half }
+  return a - b;
+}
+_Float16 _Complex sub_float_cc(_Float16 _Complex a, _Float16 _Complex b) {
+  // AARCH64-LABEL: @sub_float_cc(
+  // AARCH64: fsub reassoc nnan ninf nsz arcp afn half
+  // AARCH64: fsub reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fsub
+  // AARCH64: ret { half, half }
+  return a - b;
+}
+
+_Float16 _Complex mul_float_rr(_Float16 a, _Float16 b) {
+  // AARCH64-LABEL: @mul_float_rr(
+  // AARCH64: fmul reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fmul
+  // AARCH64: ret { half, half }
+  return a * b;
+}
+_Float16 _Complex mul_float_cr(_Float16 _Complex a, _Float16 b) {
+  // AARCH64-LABEL: @mul_float_cr(
+  // AARCH64: fmul reassoc nnan ninf nsz arcp afn half
+  // AARCH64: fmul reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fmul
+  // AARCH64: ret { half, half }
+  return a * b;
+}
+_Float16 _Complex mul_float_rc(_Float16 a, _Float16 _Complex b) {
+  // AARCH64-LABEL: @mul_float_rc(
+  // AARCH64: fmul reassoc nnan ninf nsz arcp afn half
+  // AARCH64: fmul reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fmul
+  // AARCH64: ret { half, half }
+  return a * b;
+}
+_Float16 _Complex mul_float_cc(_Float16 _Complex a, _Float16 _Complex b) {
+  // AARCH64-LABEL: @mul_float_cc(
+  // AARCH64: fmul reassoc nnan ninf nsz arcp afn half
+  // AARCH64: fmul reassoc nnan ninf nsz arcp afn half
+  // AARCH64: fadd reassoc nnan ninf nsz arcp afn half
+  // AARCH64: fmul reassoc nnan ninf nsz arcp afn half
+  // AARCH64: fmul reassoc nnan ninf nsz arcp afn half
+  // AARCH64: fsub reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fmul
+  // AARCH64: ret { half, half }
+  return a * b;
+}
+
+_Float16 _Complex div_float_rr(_Float16 a, _Float16 b) {
+  // AARCH64-LABEL: @div_float_rr(
+  // AARCH64: fdiv reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fdiv reassoc nnan ninf nsz arcp afn half
+  // AARCH64: ret { half, half }
+  return a / b;
+}
+_Float16 _Complex div_float_cr(_Float16 _Complex a, _Float16 b) {
+  // AARCH64-LABEL: @div_float_cr(
+  // AARCH64: fdiv reassoc nnan ninf nsz arcp afn half
+  // AARCH64: fdiv reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fdiv reassoc nnan ninf nsz arcp afn half
+  // AARCH64: ret { half, half }
+  return a / b;
+}
+_Float16 _Complex div_float_rc(_Float16 a, _Float16 _Complex b) {
+  // AARCH64-LABEL: @div_float_rc(
+  // AARCH64: fmul reassoc nnan ninf nsz 

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

2022-02-16 Thread Iain Sandoe via Phabricator via cfe-commits
iains marked 4 inline comments as done.
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:
> 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.
> 
I think we can just go with C++20 and as you suggest treat the TS as a dialect.


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] D119926: [Clang][AArch64] Enable _Float16 _Complex type

2022-02-16 Thread Paul Walker via Phabricator via cfe-commits
paulwalker-arm added inline comments.



Comment at: clang/include/clang/AST/ASTContext.h:1117
   CanQualType BFloat16Ty;
-  CanQualType Float16Ty; // C11 extension ISO/IEC TS 18661-3
+  CanQualType Float16Ty, Float16ComplexTy; // C11 extension ISO/IEC TS 18661-3
   CanQualType VoidPtrTy, NullPtrTy;

Is this necessary? I don't see any other `*ComplexTy` types in this file (i.e. 
there is no `DoubleComplexTy`).



Comment at: clang/lib/AST/ASTContext.cpp:1330
   InitBuiltinType(Float16Ty,   BuiltinType::Float16);
+  InitBuiltinType(Float16ComplexTy,BuiltinType::Float16);
 

As above.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119926

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


[PATCH] D119926: [Clang][AArch64] Enable _Float16 _Complex type

2022-02-16 Thread Peter Waller via Phabricator via cfe-commits
peterwaller-arm added a comment.

Some comments.




Comment at: clang/include/clang/AST/ASTContext.h:1117
   CanQualType BFloat16Ty;
-  CanQualType Float16Ty; // C11 extension ISO/IEC TS 18661-3
+  CanQualType Float16Ty, Float16ComplexTy; // C11 extension ISO/IEC TS 18661-3
   CanQualType VoidPtrTy, NullPtrTy;

Is this necessary?



Comment at: clang/lib/AST/ASTContext.cpp:1330
   InitBuiltinType(Float16Ty,   BuiltinType::Float16);
+  InitBuiltinType(Float16ComplexTy,BuiltinType::Float16);
 

Is this necessary?



Comment at: clang/lib/AST/ASTContext.cpp:6811-6812
 switch (EltRank) {
-case BFloat16Rank: llvm_unreachable("Complex bfloat16 is not supported");
-case Float16Rank:
+case BFloat16Rank:
+  llvm_unreachable("Complex bfloat16 is not supported");
 case HalfRank: llvm_unreachable("Complex half is not supported");

This can be left unmodified.



Comment at: clang/test/CodeGen/aarch64-complex-half-math.c:1
+// RUN: %clang_cc1 %s -O1 -emit-llvm -triple aarch64-unknown-unknown 
-ffast-math -o - | FileCheck %s --check-prefix=AARCH64
+

Can these test outputs be autogenerated with update_cc_test_checks.py?



Comment at: clang/test/CodeGen/aarch64-complex-half-math.c:2
+// RUN: %clang_cc1 %s -O1 -emit-llvm -triple aarch64-unknown-unknown 
-ffast-math -o - | FileCheck %s --check-prefix=AARCH64
+
+_Float16 _Complex add_float_rr(_Float16 a, _Float16 b) {

I think this test needs a `// REQUIRES: aarch64-registered-target` to protect 
builds which don't have a LLVM_TARGETS_TO_BUILD which implies AArch64 is 
available.



Comment at: clang/test/CodeGen/aarch64-complex-half-math.c:5
+  // AARCH64-LABEL: @add_float_rr(
+  // AARCH64: fadd reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fadd

My read is that this appears to be testing both -ffast-math and _Float16. Do we 
want to be testing both these things at once like this, can anyone comment?

My preference would be to have these test only the operators, and not the 
flags, and then maybe have a single test which does
https://clang.llvm.org/docs/LanguageExtensions.html#extensions-to-specify-floating-point-flags
```
#pragma clang fp contract(fast)
```

and verifies that the flags are present.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119926

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


[PATCH] D119926: [Clang][AArch64] Enable _Float16 _Complex type

2022-02-16 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a reviewer: aaron.ballman.
fhahn added inline comments.



Comment at: clang/test/CodeGen/aarch64-complex-half-math.c:1
+// RUN: %clang_cc1 %s -O1 -emit-llvm -triple aarch64-unknown-unknown 
-ffast-math -o - | FileCheck %s --check-prefix=AARCH64
+

peterwaller-arm wrote:
> Can these test outputs be autogenerated with update_cc_test_checks.py?
Do the tests need to depend on LLVM optimizations? In general this is 
undesirable as it  makes them more fragile if things change on the LLVM side.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119926

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


[PATCH] D119927: [Clang] [P2025] More exhaustive tests for NRVO

2022-02-16 Thread Evgeny Shulgin via Phabricator via cfe-commits
Izaron created this revision.
Izaron added reviewers: mizvekov, Quuxplusone, sammccall, rsmith, doug.gregor.
Izaron requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This is a preliminary patch ahead of D119792  
(I'll rebase that one on top of this).
This shows what Clang's _current_ behaviour is for calculating NRVO in various
common cases. Then, in D119792  (and future 
patches), I'll be able to demostrate
exactly how LLVM IR for each of these cases changes.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D119927

Files:
  clang/test/CodeGenCXX/nrvo.cpp

Index: clang/test/CodeGenCXX/nrvo.cpp
===
--- clang/test/CodeGenCXX/nrvo.cpp
+++ clang/test/CodeGenCXX/nrvo.cpp
@@ -1,13 +1,14 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
 // RUN: %clang_cc1 -triple i386-unknown-unknown -emit-llvm -O1 -o - %s | FileCheck %s
 // RUN: %clang_cc1 -triple i386-unknown-unknown -emit-llvm -O1 -fcxx-exceptions -fexceptions -std=c++03 -o - %s | FileCheck --check-prefixes=CHECK-EH,CHECK-EH-03 %s
-// RUN: %clang_cc1 -triple i386-unknown-unknown -emit-llvm -O1 -fcxx-exceptions -fexceptions -std=c++11 -o - %s | FileCheck --check-prefixes=CHECK-EH,CHECK-EH-11 %s
+// RUN: %clang_cc1 -triple i386-unknown-unknown -emit-llvm -O1 -fcxx-exceptions -fexceptions -std=c++11 -DCXX11 -o - %s | FileCheck --check-prefixes=CHECK-EH,CHECK-EH-11 %s
 
 // Test code generation for the named return value optimization.
 class X {
 public:
   X();
   X(const X&);
+  X(const volatile X &);
   ~X();
 };
 
@@ -19,6 +20,9 @@
   }
 };
 
+void ConsumeX(X x);
+extern X OuterX;
+
 // CHECK-LABEL: @_Z5test0v(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:call void @_ZN1XC1Ev(%class.X* noundef nonnull align 1 dereferenceable(1) [[AGG_RESULT:%.*]]) #[[ATTR5:[0-9]+]]
@@ -411,7 +415,7 @@
   try {
 may_throw();
   } catch (X x) {
-return x;
+return x; // FIXME: we should NRVO this variable.
   }
 }
 #endif
@@ -536,3 +540,1230 @@
 Y test9() {
   Y::f();
 }
+
+// CHECK-LABEL: @_Z6test10b(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[X:%.*]] = alloca [[CLASS_X:%.*]], align 1
+// 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:br i1 [[B:%.*]], label [[IF_THEN:%.*]], label [[IF_ELSE:%.*]]
+// CHECK:   if.then:
+// 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:br label [[CLEANUP:%.*]]
+// CHECK:   if.else:
+// CHECK-NEXT:call void @_ZN1XC1Ev(%class.X* noundef nonnull align 1 dereferenceable(1) [[AGG_RESULT]]) #[[ATTR5]]
+// CHECK-NEXT:br label [[CLEANUP]]
+// CHECK:   cleanup:
+// 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:ret void
+//
+// CHECK-EH-03-LABEL: @_Z6test10b(
+// CHECK-EH-03-NEXT:  entry:
+// CHECK-EH-03-NEXT:[[X:%.*]] = alloca [[CLASS_X:%.*]], align 1
+// 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:br i1 [[B:%.*]], label [[IF_THEN:%.*]], label [[IF_ELSE:%.*]]
+// CHECK-EH-03:   if.then:
+// 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 [[CLEANUP:%.*]] unwind label [[LPAD:%.*]]
+// 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_CONT2:%.*]] unwind label [[TERMINATE_LPAD:%.*]]
+// CHECK-EH-03:   if.else:
+// CHECK-EH-03-NEXT:invoke void @_ZN1XC1Ev(%class.X* noundef nonnull align 1 dereferenceable(1) [[AGG_RESULT]])
+// CHECK-EH-03-NEXT:to label [[CLEANUP]] unwind label [[LPAD]]
+// CHECK-EH-03:   cleanup:
+// 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]]

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

2022-02-16 Thread Evgeny Shulgin via Phabricator via cfe-commits
Izaron added a comment.

This review will wait for D119927  to be 
merged, as it adds more tests.


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] D119893: [clang-format] Fixed handling of requires clauses followed by attributes

2022-02-16 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks updated this revision to Diff 409195.
HazardyKnusperkeks marked 2 inline comments as done.
HazardyKnusperkeks added a reviewer: Quuxplusone.

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

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
@@ -19,6 +19,7 @@
 #include "llvm/Support/raw_ostream.h"
 
 #include 
+#include 
 
 #define DEBUG_TYPE "format-parser"
 
@@ -3007,7 +3008,16 @@
 /// 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 = std::exchange(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,16 @@
 case tok::minus:
 case tok::star:
 case tok::slash:
-case tok::numeric_constant:
 case to

[PATCH] D119162: [Pseudo] Token/TokenStream, PP directive parser.

2022-02-16 Thread Haojian Wu via Phabricator via cfe-commits
hokein added a comment.

Thanks, this looks good in general.

I only reviewed the token part, but don't want to block the review. I think it 
might be nice to split out the preprocessor part from this patch, this would 
make the scope clearer and review efficient (sorry, quite busy with other stuff 
this week).




Comment at: clang/include/clang/Tooling/Syntax/Pseudo/Preprocess.h:103
+// FIXME: This approximates std::variant.
+// Switch once we can use C++17.
+class PPStructure::Chunk {

yeah, this should be happened soon, see 
https://discourse.llvm.org/t/rfc-increasing-the-gcc-and-clang-requirements-to-support-c-17-in-llvm/59983.



Comment at: clang/include/clang/Tooling/Syntax/Pseudo/Token.h:60
+  StringRef text() const { return StringRef(Data, Length); }
+  const char *Data;
+  uint32_t Length;

nit: add default init value.



Comment at: clang/include/clang/Tooling/Syntax/Pseudo/Token.h:64
+  /// Zero-based line number.
+  uint32_t Line = 0;
+  /// Width of whitespace before the first token on this line.

nit: mention this is the line number for the start of token, a token can be 
multiple-line.

I think the meaning of line number is token-stream-dependent, right? For a lex 
token-stream, it is raw line number; For a cook token stream, it might take the 
backslash continued line into account?




Comment at: clang/include/clang/Tooling/Syntax/Pseudo/Token.h:89
+  uint32_t size() const { return End - Begin; }
+  static Range empty(unsigned Index) { return Range{Index, Index}; }
+};

nit: unsigned -> Token::Index

I'd probably drop it (looks like only one place using it, inclining it should 
be fine), the name empty is usually a method checking the Range is empty rather 
than creating an empty Range.



Comment at: clang/include/clang/Tooling/Syntax/Pseudo/Token.h:128
+  /// T must be within the stream or the end sentinel (not the start sentinel).
+  Token::Index index(const Token &T) const {
+assert(&T != Storage.data() && "start sentinel");

nit: isFinalized assert?



Comment at: clang/include/clang/Tooling/Syntax/Pseudo/Token.h:130
+assert(&T != Storage.data() && "start sentinel");
+assert(&T >= Storage.data() && &T < Storage.data() + Storage.size());
+return &T - Tokens.data();

`>=` => `>`, since we have checked above.



Comment at: clang/include/clang/Tooling/Syntax/Pseudo/Token.h:143
+  /// May return the end sentinel if the stream is empty.
+  Token &front() { return Storage[1]; }
+  const Token &front() const { return Storage[1]; }

the mutated version seems not used?



Comment at: clang/include/clang/Tooling/Syntax/Pseudo/Token.h:144
+  Token &front() { return Storage[1]; }
+  const Token &front() const { return Storage[1]; }
+

`assert(isFinalized())`



Comment at: clang/include/clang/Tooling/Syntax/Pseudo/Token.h:155
+  MutableArrayRef Tokens;
+  std::vector Storage;
+};

I think it is probably good/clearer to have a comment like "Storage = eof + 
Tokens + eof" around here.



Comment at: clang/include/clang/Tooling/Syntax/Pseudo/Token.h:163
+///
+/// Tokens containing trigraps, escaped newlines, UCNs etc will have text() 
that
+/// reflect this, and will have NeedsCleaning set.

 trigraps => trigraphs



Comment at: clang/include/clang/Tooling/Syntax/Pseudo/Token.h:166
+/// Tokens at the start of an unescaped newline (where a directive may start)
+/// will have StartsPPLine.
+/// "word-like" tokens such as identifiers and keywords will be raw_identifier.

I think it would be clearer to give more details (for example, give some 
examples) in the comment to clarify -- it took me quite a while to understand 
"an unescaped newline" (I guess this refers to the backslash continued line?).

And having a PP in the name seems a little confusing, it somehow indicates this 
flag  is PP-specific, e.g. for a simple example without any PP structure `int 
a;` the `int` token has the  `StartsPPLine` being set.



Comment at: clang/include/clang/Tooling/Syntax/Pseudo/Token.h:171
+  NeedsCleaning = 1 << 0,
+  StartsPPLine = 1 << 1,
+};

I was going to say "add some comments around these enums", then realized that 
there were comments for them in the above `lex()` comment, I'd  move those 
comments to here.



Comment at: clang/lib/Tooling/Syntax/Pseudo/Lex.cpp:65
+
+if (CT.isAtStartOfLine())
+  Tok.setFlag(LexFlags::StartsPPLine);

just want to double-check this is the behavior we want,

From the clang's token comment:
```
TokenFlags::StartOfLine  // At start of line or only after whitespace


so the `abc` token will have this flag
```
abc // abc has 

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

2022-02-16 Thread Iain Sandoe via Phabricator via cfe-commits
iains updated this revision to Diff 409201.
iains added a comment.

Update to rebase on changes to parent patches and formatting checks.

while doing this made a check for module partitions more efficient.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118586

Files:
  clang/include/clang/AST/Decl.h
  clang/include/clang/Basic/DiagnosticIDs.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/Parser.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaModule.cpp
  clang/test/CXX/module/module.unit/p3.cpp
  clang/test/CXX/module/module.unit/p8.cpp
  clang/test/Modules/cxx20-import-diagnostics-a.cpp
  clang/test/Modules/cxx20-partition-diagnostics-a.cpp

Index: clang/test/Modules/cxx20-partition-diagnostics-a.cpp
===
--- /dev/null
+++ clang/test/Modules/cxx20-partition-diagnostics-a.cpp
@@ -0,0 +1,18 @@
+// Module Partition diagnostics
+
+// RUN: %clang_cc1 -std=c++20 -S -D TU=1 -x c++ %s -o /dev/null -verify
+
+// RUN: %clang_cc1 -std=c++20 -S -D TU=2 -x c++ %s -o /dev/null -verify
+
+#if TU == 1
+
+import :B; // expected-error {{module partition imports must be within a module purview}}
+
+#elif TU == 2
+module; // expected-error {{missing 'module' declaration at end of global module fragment introduced here}}
+
+import :Part; // expected-error {{module partition imports cannot be in the global module fragment}}
+
+#else
+#error "no TU set"
+#endif
Index: clang/test/Modules/cxx20-import-diagnostics-a.cpp
===
--- clang/test/Modules/cxx20-import-diagnostics-a.cpp
+++ clang/test/Modules/cxx20-import-diagnostics-a.cpp
@@ -54,6 +54,8 @@
 
 #elif TU == 2
 
+module;
+
 export module AOK1;
 
 import B;
Index: clang/test/CXX/module/module.unit/p8.cpp
===
--- clang/test/CXX/module/module.unit/p8.cpp
+++ clang/test/CXX/module/module.unit/p8.cpp
@@ -12,7 +12,7 @@
 
 #elif MODE == 1
 // expected-no-diagnostics
-module foo;
+module foo; // Implementation, implicitly imports foo.
 #define IMPORTED
 
 #elif MODE == 2
@@ -21,15 +21,15 @@
 #define IMPORTED
 
 #elif MODE == 3
-export module bar;
+export module bar; // A different module
 
 #elif MODE == 4
-module foo:bar; // expected-error {{not yet supported}}
-#define IMPORTED // FIXME
+module foo:bar; // Partition implementation
+//#define IMPORTED (we don't import foo here)
 
 #elif MODE == 5
-export module foo:bar; // expected-error {{not yet supported}} expected-error {{redefinition}} expected-note@* {{loaded from}}
-#define IMPORTED // FIXME
+export module foo:bar; // Partition interface
+//#define IMPORTED  (we don't import foo here)
 
 #endif
 
Index: clang/test/CXX/module/module.unit/p3.cpp
===
--- clang/test/CXX/module/module.unit/p3.cpp
+++ clang/test/CXX/module/module.unit/p3.cpp
@@ -1,4 +1,4 @@
 // RUN: %clang_cc1 -std=c++2a -verify %s
 
-export module foo:bar; // expected-error {{sorry, module partitions are not yet supported}}
-import :baz; // expected-error {{sorry, module partitions are not yet supported}}
+export module foo:bar;
+import :baz; // expected-error {{module 'foo:baz' not found}}
Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -54,6 +54,19 @@
   }
 }
 
+static std::string stringFromPath(ModuleIdPath Path) {
+  std::string Name;
+  if (Path.empty())
+return Name;
+
+  for (auto &Piece : Path) {
+if (!Name.empty())
+  Name += ".";
+Name += Piece.first->getName();
+  }
+  return Name;
+}
+
 Sema::DeclGroupPtrTy
 Sema::ActOnGlobalModuleFragmentDecl(SourceLocation ModuleLoc) {
   if (!ModuleScopes.empty() &&
@@ -80,11 +93,10 @@
   return nullptr;
 }
 
-Sema::DeclGroupPtrTy Sema::ActOnModuleDecl(SourceLocation StartLoc,
-   SourceLocation ModuleLoc,
-   ModuleDeclKind MDK,
-   ModuleIdPath Path,
-   ModuleImportState &ImportState) {
+Sema::DeclGroupPtrTy
+Sema::ActOnModuleDecl(SourceLocation StartLoc, SourceLocation ModuleLoc,
+  ModuleDeclKind MDK, ModuleIdPath NamePath,
+  ModuleIdPath Partition, ModuleImportState &ImportState) {
   assert((getLangOpts().ModulesTS || getLangOpts().CPlusPlusModules) &&
  "should only have module decl in Modules TS or C++20");
 
@@ -159,19 +171,20 @@
   // Flatten the dots in a module name. Unlike Clang's hierarchical module map
   // modules, the dots here are just another character that can appear in a
   // module name.
-  std::string ModuleName;
-

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

2022-02-16 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan accepted this revision.
urnathan added a comment.
This revision is now accepted and ready to land.

thanks for indexing the subject lines!


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] D114714: [C++20][Modules][2/8] Add enumerations for partition modules and stream them.

2022-02-16 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan accepted this revision.
urnathan 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/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] D118587: [C++20][Modules] Handle generation of partition implementation CMIs.

2022-02-16 Thread Iain Sandoe via Phabricator via cfe-commits
iains updated this revision to Diff 409202.
iains added a comment.

rebased onto changes in parent patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118587

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaModule.cpp
  clang/test/Modules/cxx20-10-1-ex1.cpp
  clang/test/Modules/cxx20-10-1-ex2.cpp
  clang/test/Modules/cxx20-import-diagnostics-a.cpp

Index: clang/test/Modules/cxx20-import-diagnostics-a.cpp
===
--- clang/test/Modules/cxx20-import-diagnostics-a.cpp
+++ clang/test/Modules/cxx20-import-diagnostics-a.cpp
@@ -96,9 +96,9 @@
 #elif TU == 6
 
 module;
-// We can only have preprocessor commands here, which could include an include
+// We can only have preprocessor directives here, which permits an include-
 // translated header unit.  However those are identified specifically by the
-// preprocessor; non-preprocessed user code should not contain an import here.
+// preprocessor; non-preprocessed user code should not contain an 'import' here.
 import B; // expected-error {{module imports cannot be in the global module fragment}}
 
 export module D;
Index: clang/test/Modules/cxx20-10-1-ex2.cpp
===
--- /dev/null
+++ clang/test/Modules/cxx20-10-1-ex2.cpp
@@ -0,0 +1,60 @@
+
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=1 -x c++ %s \
+// RUN:  -o %t/B_Y.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=2 -x c++ %s \
+// RUN:  -fmodule-file=%t/B_Y.pcm -o %t/B.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=3 -x c++ %s \
+// RUN:   -o %t/B_X1.pcm -verify
+
+// Not expected to work yet.
+//  %clang_cc1 -std=c++20 -emit-module-interface -D TU=4 -x c++ %s \
+//   -fmodule-file=%t/B.pcm  -o %t/B_X2.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-obj -D TU=5 -x c++ %s \
+// RUN:  -fmodule-file=%t/B.pcm  -o %t/b_tu5.s
+
+// RUN: %clang_cc1 -std=c++20 -S -D TU=6 -x c++ %s \
+// RUN:  -fmodule-file=%t/B.pcm  -o %t/b_tu6.s -verify
+
+// Not expected to work yet.
+//  %clang_cc1 -std=c++20 -emit-module-interface -D TU=7 -x c++ %s \
+//   -fmodule-file=%t/B_X2.pcm  -o %t/B_X3.pcm -verify
+
+#if TU == 1
+  module B:Y;
+  int y();
+// expected-no-diagnostics
+#elif TU == 2
+  export module B;
+  import :Y;
+  int n = y();
+// expected-no-diagnostics
+#elif TU == 3
+  module B:X1; // does not implicitly import B
+  int &a = n;  // expected-error {{use of undeclared identifier }}
+#elif TU == 4
+  module B:X2; // does not implicitly import B
+  import B;
+  int &b = n; // OK
+// expected-no-diagnostics
+#elif TU == 5
+  module B; // implicitly imports B
+  int &c = n; // OK
+// expected-no-diagnostics
+#elif TU == 6
+  import B;
+  // error, n is module-local and this is not a module.
+  int &c = n; // expected-error {{use of undeclared identifier}}
+#elif TU == 7
+  module B:X3; // does not implicitly import B
+  import :X2; // X2 is an implementation so exports nothing.
+  // error: n not visible here.
+  int &c = n; // expected-error {{use of undeclared identifier }}
+#else
+#error "no TU set"
+#endif
Index: clang/test/Modules/cxx20-10-1-ex1.cpp
===
--- /dev/null
+++ clang/test/Modules/cxx20-10-1-ex1.cpp
@@ -0,0 +1,50 @@
+// The example in the standard is not in required build order.
+// revised here
+
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=1 -x c++ %s \
+// RUN:  -o %t/A_Internals.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=2 -x c++ %s \
+// RUN:  -fmodule-file=%t/A_Internals.pcm -o %t/A_Foo.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=3 -x c++ %s \
+// RUN:  -fmodule-file=%t/A_Foo.pcm -o %t/A.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-obj  -D TU=4 -x c++ %s \
+// RUN:  -fmodule-file=%t/A.pcm -o %t/ex1.o
+
+// expected-no-diagnostics
+
+#if TU == 1
+
+module A:Internals;
+int bar();
+
+#elif TU == 2
+
+export module A:Foo;
+
+import :Internals;
+
+export int foo() { return 2 * (bar() + 1); }
+
+#elif TU == 3
+
+export module A;
+export import :Foo;
+export int baz();
+
+#elif TU == 4
+module A;
+
+import :Internals;
+
+int bar() { return baz() - 10; }
+int baz() { return 30; }
+
+#else
+#error "no TU set"
+#endif
Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -106,9 +106,24 @@
   // module state;
   ImportState = ModuleImportState::NotACXX20Module;
 
-  // A module implementation unit requires that we are not compiling a module
-  // of any kind. A module interface unit requires that we are not compiling a
-  // module map.
+  bool IsPartition = !Partition.empty();
+  if (IsPartition)
+s

[PATCH] D118588: [C++20][Modules] Diagnose wrong import/export for partition CMIs.

2022-02-16 Thread Iain Sandoe via Phabricator via cfe-commits
iains updated this revision to Diff 409203.
iains added a comment.

rebased onto changes in parent commits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118588

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaModule.cpp
  clang/test/Modules/cxx20-10-3-ex1.cpp
  clang/test/Modules/cxx20-10-3-ex2.cpp
  clang/test/Modules/cxx20-import-diagnostics-a.cpp

Index: clang/test/Modules/cxx20-import-diagnostics-a.cpp
===
--- clang/test/Modules/cxx20-import-diagnostics-a.cpp
+++ clang/test/Modules/cxx20-import-diagnostics-a.cpp
@@ -119,13 +119,13 @@
 
 module B;
 
-import B; // expected-error {{import of module 'B' appears within same top-level module 'B'}}
+import B; // expected-error {{import of module 'B' appears within its own implementation}}
 
 #elif TU == 9
 
 export module B;
 
-import B; // expected-error {{import of module 'B' appears within same top-level module 'B'}}
+import B; // expected-error {{import of module 'B' appears within its own interface}}
 
 #elif TU == 10
 
Index: clang/test/Modules/cxx20-10-3-ex2.cpp
===
--- /dev/null
+++ clang/test/Modules/cxx20-10-3-ex2.cpp
@@ -0,0 +1,28 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=0 -x c++ %s \
+// RUN:  -o %t/M.pcm
+
+// RUN: %clang_cc1 -std=c++20 -S -D TU=1 -x c++ %s \
+// RUN:  -fmodule-file=%t/M.pcm -o %t/tu_8.s -verify
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=2 -x c++ %s \
+// RUN:  -o %t/M.pcm -verify
+
+#if TU == 0
+export module M;
+
+#elif TU == 1
+module M;
+  // error: cannot import M in its own unit
+import M; // expected-error {{import of module 'M' appears within its own implementation}}
+
+#elif TU == 2
+export module M;
+  // error: cannot import M in its own unit
+import M; // expected-error {{import of module 'M' appears within its own interface}}
+
+#else
+#error "no TU set"
+#endif
Index: clang/test/Modules/cxx20-10-3-ex1.cpp
===
--- /dev/null
+++ clang/test/Modules/cxx20-10-3-ex1.cpp
@@ -0,0 +1,36 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=1 -x c++ %s \
+// RUN:  -o %t/M_PartImpl.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=2 -x c++ %s \
+// RUN:  -fmodule-file=%t/M_PartImpl.pcm -o %t/M.pcm -verify
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=3 -x c++ %s \
+// RUN:  -o %t/M_Part.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=4 -x c++ %s \
+// RUN:  -fmodule-file=%t/M_Part.pcm -o %t/M.pcm
+
+#if TU == 1
+module M:PartImpl;
+
+// expected-no-diagnostics
+#elif TU == 2
+export module M;
+ // error: exported partition :Part is an implementation unit
+export import :PartImpl; // expected-error {{module partition implementations cannot be exported}}
+
+#elif TU == 3
+export module M:Part;
+
+// expected-no-diagnostics
+#elif TU == 4
+export module M;
+export import :Part;
+
+// expected-no-diagnostics
+#else
+#error "no TU set"
+#endif
Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -396,10 +396,16 @@
   }
 
   // Diagnose self-import before attempting a load.
+  // [module.import]/9
+  // A module implementation unit of a module M that is not a module partition
+  // shall not contain a module-import-declaration nominating M.
+  // (for an implementation, the module interface is imported implicitly,
+  //  but that's handled in the module decl code).
+
   if (getLangOpts().CPlusPlusModules && isCurrentModulePurview() &&
   getCurrentModule()->Name == ModuleName) {
-Diag(ImportLoc, diag::err_module_self_import)
-<< ModuleName << getLangOpts().CurrentModule;
+Diag(ImportLoc, diag::err_module_self_import_cxx20)
+<< ModuleName << !ModuleScopes.back().ModuleInterface;
 return true;
   }
 
@@ -433,8 +439,7 @@
   // of the same top-level module. Until we do, make it an error rather than
   // silently ignoring the import.
   // FIXME: Should we warn on a redundant import of the current module?
-  if (!getLangOpts().CPlusPlusModules &&
-  Mod->getTopLevelModuleName() == getLangOpts().CurrentModule &&
+  if (Mod->getTopLevelModuleName() == getLangOpts().CurrentModule &&
   (getLangOpts().isCompilingModule() || !getLangOpts().ModulesTS)) {
 Diag(ImportLoc, getLangOpts().isCompilingModule()
 ? diag::err_module_self_import
@@ -475,7 +480,12 @@
   if (!ModuleScopes.empty())
 Context.addModuleInitializer(ModuleScopes.back().Module, Import);
 
-  if (!ModuleScopes.empty() && ModuleScopes.back().ModuleInterface) {
+  // 

[PATCH] D118589: [C++20][Modules] Record direct module imports.

2022-02-16 Thread Iain Sandoe via Phabricator via cfe-commits
iains updated this revision to Diff 409205.
iains added a comment.

rebased onto changes in parent patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118589

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaModule.cpp


Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -506,6 +506,11 @@
 assert(ThisModule && "was expecting a module if building one");
   }
 
+  // In some cases we need to know if an entity was present in a directly-
+  // imported module (as opposed to a transitive import).  This avoids
+  // searching both Imports and Exports.
+  DirectModuleImports.insert(Mod);
+
   return Import;
 }
 
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -,6 +,9 @@
   /// The global module fragment of the current translation unit.
   clang::Module *GlobalModuleFragment = nullptr;
 
+  /// The modules we imported directly.
+  llvm::SmallPtrSet DirectModuleImports;
+
   /// Namespace definitions that we will export when they finish.
   llvm::SmallPtrSet DeferredExportedNamespaces;
 
@@ -2249,6 +2252,10 @@
 return Entity->getOwningModule();
   }
 
+  bool isModuleDirectlyImported(const Module *M) {
+return DirectModuleImports.contains(M);
+  }
+
   /// Make a merged definition of an existing hidden definition \p ND
   /// visible at the specified location.
   void makeMergedDefinitionVisible(NamedDecl *ND);


Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -506,6 +506,11 @@
 assert(ThisModule && "was expecting a module if building one");
   }
 
+  // In some cases we need to know if an entity was present in a directly-
+  // imported module (as opposed to a transitive import).  This avoids
+  // searching both Imports and Exports.
+  DirectModuleImports.insert(Mod);
+
   return Import;
 }
 
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -,6 +,9 @@
   /// The global module fragment of the current translation unit.
   clang::Module *GlobalModuleFragment = nullptr;
 
+  /// The modules we imported directly.
+  llvm::SmallPtrSet DirectModuleImports;
+
   /// Namespace definitions that we will export when they finish.
   llvm::SmallPtrSet DeferredExportedNamespaces;
 
@@ -2249,6 +2252,10 @@
 return Entity->getOwningModule();
   }
 
+  bool isModuleDirectlyImported(const Module *M) {
+return DirectModuleImports.contains(M);
+  }
+
   /// Make a merged definition of an existing hidden definition \p ND
   /// visible at the specified location.
   void makeMergedDefinitionVisible(NamedDecl *ND);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 082f328 - [clang] Itanium mangler constructors

2022-02-16 Thread Nathan Sidwell via cfe-commits

Author: Nathan Sidwell
Date: 2022-02-16T04:30:47-08:00
New Revision: 082f328899be9ed8a38b04a4e52be936f4875495

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

LOG: [clang] Itanium mangler constructors

The Itanium mangler constructors use both NSDMI and explicit member
construction for default values.  This is confusing.

*) Use NSDMIs wherever possible

*) Use forwarding ctor for the nesting case with an
 llvm::raw_null_ostream (and explicitly set NullOut flag in that ctor).

*) Copy the ModuleSubstitutions.  This is a bug with no effect in the
 current mangling, but not in the newer mangling.

Reviewed By: ChuanqiXu

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

Added: 


Modified: 
clang/lib/AST/ItaniumMangle.cpp

Removed: 




diff  --git a/clang/lib/AST/ItaniumMangle.cpp b/clang/lib/AST/ItaniumMangle.cpp
index b92a6a07ff1f7..63e40a0f30721 100644
--- a/clang/lib/AST/ItaniumMangle.cpp
+++ b/clang/lib/AST/ItaniumMangle.cpp
@@ -267,10 +267,10 @@ class CXXNameMangler {
   /// that's not a template specialization; otherwise it's the pattern
   /// for that specialization.
   const NamedDecl *Structor;
-  unsigned StructorType;
+  unsigned StructorType = 0;
 
   /// The next substitution sequence number.
-  unsigned SeqID;
+  unsigned SeqID = 0;
 
   class FunctionTypeDepthState {
 unsigned Bits;
@@ -430,32 +430,32 @@ class CXXNameMangler {
 public:
   CXXNameMangler(ItaniumMangleContextImpl &C, raw_ostream &Out_,
  const NamedDecl *D = nullptr, bool NullOut_ = false)
-: Context(C), Out(Out_), NullOut(NullOut_),  Structor(getStructor(D)),
-  StructorType(0), SeqID(0), AbiTagsRoot(AbiTags) {
+  : Context(C), Out(Out_), NullOut(NullOut_), Structor(getStructor(D)),
+AbiTagsRoot(AbiTags) {
 // These can't be mangled without a ctor type or dtor type.
 assert(!D || (!isa(D) &&
   !isa(D)));
   }
   CXXNameMangler(ItaniumMangleContextImpl &C, raw_ostream &Out_,
  const CXXConstructorDecl *D, CXXCtorType Type)
-: Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
-  SeqID(0), AbiTagsRoot(AbiTags) { }
+  : Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
+AbiTagsRoot(AbiTags) {}
   CXXNameMangler(ItaniumMangleContextImpl &C, raw_ostream &Out_,
  const CXXDestructorDecl *D, CXXDtorType Type)
-: Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
-  SeqID(0), AbiTagsRoot(AbiTags) { }
+  : Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
+AbiTagsRoot(AbiTags) {}
 
   CXXNameMangler(CXXNameMangler &Outer, raw_ostream &Out_)
-  : Context(Outer.Context), Out(Out_), NullOut(false),
-Structor(Outer.Structor), StructorType(Outer.StructorType),
-SeqID(Outer.SeqID), FunctionTypeDepth(Outer.FunctionTypeDepth),
-AbiTagsRoot(AbiTags), Substitutions(Outer.Substitutions) {}
+  : Context(Outer.Context), Out(Out_), Structor(Outer.Structor),
+StructorType(Outer.StructorType), SeqID(Outer.SeqID),
+FunctionTypeDepth(Outer.FunctionTypeDepth), AbiTagsRoot(AbiTags),
+Substitutions(Outer.Substitutions),
+ModuleSubstitutions(Outer.ModuleSubstitutions) {}
 
   CXXNameMangler(CXXNameMangler &Outer, llvm::raw_null_ostream &Out_)
-  : Context(Outer.Context), Out(Out_), NullOut(true),
-Structor(Outer.Structor), StructorType(Outer.StructorType),
-SeqID(Outer.SeqID), FunctionTypeDepth(Outer.FunctionTypeDepth),
-AbiTagsRoot(AbiTags), Substitutions(Outer.Substitutions) {}
+  : CXXNameMangler(Outer, (raw_ostream &)Out_) {
+NullOut = true;
+  }
 
   raw_ostream &getStream() { return Out; }
 



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


[PATCH] D119550: [clang] Itanium mangler constructors

2022-02-16 Thread Nathan Sidwell via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG082f328899be: [clang] Itanium mangler constructors (authored 
by urnathan).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119550

Files:
  clang/lib/AST/ItaniumMangle.cpp


Index: clang/lib/AST/ItaniumMangle.cpp
===
--- clang/lib/AST/ItaniumMangle.cpp
+++ clang/lib/AST/ItaniumMangle.cpp
@@ -267,10 +267,10 @@
   /// that's not a template specialization; otherwise it's the pattern
   /// for that specialization.
   const NamedDecl *Structor;
-  unsigned StructorType;
+  unsigned StructorType = 0;
 
   /// The next substitution sequence number.
-  unsigned SeqID;
+  unsigned SeqID = 0;
 
   class FunctionTypeDepthState {
 unsigned Bits;
@@ -430,32 +430,32 @@
 public:
   CXXNameMangler(ItaniumMangleContextImpl &C, raw_ostream &Out_,
  const NamedDecl *D = nullptr, bool NullOut_ = false)
-: Context(C), Out(Out_), NullOut(NullOut_),  Structor(getStructor(D)),
-  StructorType(0), SeqID(0), AbiTagsRoot(AbiTags) {
+  : Context(C), Out(Out_), NullOut(NullOut_), Structor(getStructor(D)),
+AbiTagsRoot(AbiTags) {
 // These can't be mangled without a ctor type or dtor type.
 assert(!D || (!isa(D) &&
   !isa(D)));
   }
   CXXNameMangler(ItaniumMangleContextImpl &C, raw_ostream &Out_,
  const CXXConstructorDecl *D, CXXCtorType Type)
-: Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
-  SeqID(0), AbiTagsRoot(AbiTags) { }
+  : Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
+AbiTagsRoot(AbiTags) {}
   CXXNameMangler(ItaniumMangleContextImpl &C, raw_ostream &Out_,
  const CXXDestructorDecl *D, CXXDtorType Type)
-: Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
-  SeqID(0), AbiTagsRoot(AbiTags) { }
+  : Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
+AbiTagsRoot(AbiTags) {}
 
   CXXNameMangler(CXXNameMangler &Outer, raw_ostream &Out_)
-  : Context(Outer.Context), Out(Out_), NullOut(false),
-Structor(Outer.Structor), StructorType(Outer.StructorType),
-SeqID(Outer.SeqID), FunctionTypeDepth(Outer.FunctionTypeDepth),
-AbiTagsRoot(AbiTags), Substitutions(Outer.Substitutions) {}
+  : Context(Outer.Context), Out(Out_), Structor(Outer.Structor),
+StructorType(Outer.StructorType), SeqID(Outer.SeqID),
+FunctionTypeDepth(Outer.FunctionTypeDepth), AbiTagsRoot(AbiTags),
+Substitutions(Outer.Substitutions),
+ModuleSubstitutions(Outer.ModuleSubstitutions) {}
 
   CXXNameMangler(CXXNameMangler &Outer, llvm::raw_null_ostream &Out_)
-  : Context(Outer.Context), Out(Out_), NullOut(true),
-Structor(Outer.Structor), StructorType(Outer.StructorType),
-SeqID(Outer.SeqID), FunctionTypeDepth(Outer.FunctionTypeDepth),
-AbiTagsRoot(AbiTags), Substitutions(Outer.Substitutions) {}
+  : CXXNameMangler(Outer, (raw_ostream &)Out_) {
+NullOut = true;
+  }
 
   raw_ostream &getStream() { return Out; }
 


Index: clang/lib/AST/ItaniumMangle.cpp
===
--- clang/lib/AST/ItaniumMangle.cpp
+++ clang/lib/AST/ItaniumMangle.cpp
@@ -267,10 +267,10 @@
   /// that's not a template specialization; otherwise it's the pattern
   /// for that specialization.
   const NamedDecl *Structor;
-  unsigned StructorType;
+  unsigned StructorType = 0;
 
   /// The next substitution sequence number.
-  unsigned SeqID;
+  unsigned SeqID = 0;
 
   class FunctionTypeDepthState {
 unsigned Bits;
@@ -430,32 +430,32 @@
 public:
   CXXNameMangler(ItaniumMangleContextImpl &C, raw_ostream &Out_,
  const NamedDecl *D = nullptr, bool NullOut_ = false)
-: Context(C), Out(Out_), NullOut(NullOut_),  Structor(getStructor(D)),
-  StructorType(0), SeqID(0), AbiTagsRoot(AbiTags) {
+  : Context(C), Out(Out_), NullOut(NullOut_), Structor(getStructor(D)),
+AbiTagsRoot(AbiTags) {
 // These can't be mangled without a ctor type or dtor type.
 assert(!D || (!isa(D) &&
   !isa(D)));
   }
   CXXNameMangler(ItaniumMangleContextImpl &C, raw_ostream &Out_,
  const CXXConstructorDecl *D, CXXCtorType Type)
-: Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
-  SeqID(0), AbiTagsRoot(AbiTags) { }
+  : Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
+AbiTagsRoot(AbiTags) {}
   CXXNameMangler(ItaniumMangleContextImpl &C, raw_ostream &Out_,
  const CXXDestructorDecl *D, CXXDtorType Type)
-: Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
-  SeqID(0), A

[clang] fdd615d - [Docs][OpenCL] Update OpenCL 3.0 status in docs.

2022-02-16 Thread Anastasia Stulova via cfe-commits

Author: Anastasia Stulova
Date: 2022-02-16T12:32:20Z
New Revision: fdd615d4f91f7bbbf83e4ea6ca45dafb7abc2fa7

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

LOG: [Docs][OpenCL] Update OpenCL 3.0 status in docs.

Reflect the latest development in clang docs.

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

Added: 


Modified: 
clang/docs/OpenCLSupport.rst
clang/docs/UsersManual.rst

Removed: 




diff  --git a/clang/docs/OpenCLSupport.rst b/clang/docs/OpenCLSupport.rst
index 7303c2b4e645b..0a4f81cf5ca11 100644
--- a/clang/docs/OpenCLSupport.rst
+++ b/clang/docs/OpenCLSupport.rst
@@ -17,8 +17,8 @@
 OpenCL Support
 ==
 
-Clang has complete support of OpenCL C versions from 1.0 to 2.0.
-There is an ongoing work to support :ref:`OpenCL 3.0 `.
+Clang has complete support of OpenCL C versions from 1.0 to 3.0.
+Support for OpenCL 3.0 is in experimental phase (:ref:`OpenCL 3.0 
`).
 
 Clang also supports :ref:`the C++ for OpenCL kernel language 
`.
 
@@ -371,43 +371,43 @@ OpenCL C 3.0 Implementation Status
 The following table provides an overview of features in OpenCL C 3.0 and their
 implementation status.
 
-+--+-+-+--+--+
-| Category | Feature   
| Status   | Reviews
  |
-+==+=+=+==+==+
-| Command line interface   | New value for ``-cl-std`` flag
| :good:`done` | https://reviews.llvm.org/D88300
  |
-+--+-+-+--+--+
-| Predefined macros| New version macro 
| :good:`done` | https://reviews.llvm.org/D88300
  |
-+--+-+-+--+--+
-| Predefined macros| Feature macros
| :good:`done` | https://reviews.llvm.org/D95776
  |
-+--+-+-+--+--+
-| Feature optionality  | Generic address space 
| :good:`done` | https://reviews.llvm.org/D95778 
and https://reviews.llvm.org/D103401 |
-+--+-+-+--+--+
-| Feature optionality  | Builtin function overloads with generic 
address space | :good:`done` | 
https://reviews.llvm.org/D105526 and https://reviews.llvm.org/D107769   
 |
-+--+-+-+--+--+
-| Feature optionality  | Program scope variables in global memory  
| :good:`done` | https://reviews.llvm.org/D103191   
  |
-+--+-+-+--+--+
-| Feature optionality  | 3D image writes including builtin functions   
| :part:`worked on`| https://reviews.llvm.org/D106260 
(frontend)  |
-+--+-+-

[PATCH] D119719: [Docs][OpenCL] Update OpenCL 3.0 status

2022-02-16 Thread Anastasia Stulova 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 rGfdd615d4f91f: [Docs][OpenCL] Update OpenCL 3.0 status in 
docs. (authored by Anastasia).
Herald added a subscriber: ldrumm.
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D119719?vs=408806&id=409208#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119719

Files:
  clang/docs/OpenCLSupport.rst
  clang/docs/UsersManual.rst

Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -3060,9 +3060,8 @@
 Starting from clang 9 a C++ mode is available for OpenCL (see
 :ref:`C++ for OpenCL `).
 
-There is ongoing support for OpenCL v3.0 that is documented along with other
-experimental functionality and features in development on :doc:`OpenCLSupport`
-page.
+OpenCL v3.0 support is complete but it remains in experimental state, see more
+details about the experimental features in :doc:`OpenCLSupport` page.
 
 OpenCL Specific Options
 ---
Index: clang/docs/OpenCLSupport.rst
===
--- clang/docs/OpenCLSupport.rst
+++ clang/docs/OpenCLSupport.rst
@@ -17,8 +17,8 @@
 OpenCL Support
 ==
 
-Clang has complete support of OpenCL C versions from 1.0 to 2.0.
-There is an ongoing work to support :ref:`OpenCL 3.0 `.
+Clang has complete support of OpenCL C versions from 1.0 to 3.0.
+Support for OpenCL 3.0 is in experimental phase (:ref:`OpenCL 3.0 `).
 
 Clang also supports :ref:`the C++ for OpenCL kernel language `.
 
@@ -371,43 +371,43 @@
 The following table provides an overview of features in OpenCL C 3.0 and their
 implementation status.
 
-+--+-+-+--+--+
-| Category | Feature   | Status   | Reviews  |
-+==+=+=+==+==+
-| Command line interface   | New value for ``-cl-std`` flag| :good:`done` | https://reviews.llvm.org/D88300  |
-+--+-+-+--+--+
-| Predefined macros| New version macro | :good:`done` | https://reviews.llvm.org/D88300  |
-+--+-+-+--+--+
-| Predefined macros| Feature macros| :good:`done` | https://reviews.llvm.org/D95776  |
-+--+-+-+--+--+
-| Feature optionality  | Generic address space | :good:`done` | https://reviews.llvm.org/D95778 and https://reviews.llvm.org/D103401 |
-+--+-+-+--+--+
-| Feature optionality  | Builtin function overloads with generic address space | :good:`done` | https://reviews.llvm.org/D105526 and https://reviews.llvm.org/D107769|
-+--+-+-+--+--+
-| Feature optionality  | Program scope variables in global memory  | :good:`done` | https://reviews.llvm.org/D103191

[PATCH] D119710: [Docs][OpenCL] Release 14 notes

2022-02-16 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia closed this revision.
Anastasia added a comment.

Committed 
https://github.com/llvm/llvm-project/commit/e8712accba1150b94168d8ace6c7dd7b9612e174


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

https://reviews.llvm.org/D119710

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


[PATCH] D119713: [Docs] Release 14 notes for SPIR-V in clang

2022-02-16 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia closed this revision.
Anastasia added a comment.

Committed 
https://github.com/llvm/llvm-project/commit/b54c95790b8a410b8eab1cbaae306cdc56a8e82a


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

https://reviews.llvm.org/D119713

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


[PATCH] D118598: [C++20][Modules] Find the primary interface name for a module.

2022-02-16 Thread Iain Sandoe via Phabricator via cfe-commits
iains updated this revision to Diff 409209.
iains added a comment.

rebased onto changes in parent patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118598

Files:
  clang/include/clang/Basic/Module.h
  clang/lib/Sema/SemaModule.cpp


Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -375,17 +375,10 @@
 // We already checked that we are in a module purview in the parser.
 assert(!ModuleScopes.empty() && "in a module purview, but no module?");
 Module *NamedMod = ModuleScopes.back().Module;
-if (ModuleScopes.back().IsPartition) {
-  // We're importing a partition into a partition, find the name of the
-  // owning named module.
-  size_t P = NamedMod->Name.find_first_of(":");
-  ModuleName = NamedMod->Name.substr(0, P + 1);
-} else {
-  // We're importing a partition into the named module itself (either the
-  // interface or an implementation TU).
-  ModuleName = NamedMod->Name;
-  ModuleName += ":";
-}
+// If we are importing into a partition, find the owning named module,
+// otherwise, the name of the importing named module.
+ModuleName = NamedMod->getPrimaryModuleInterfaceName();
+ModuleName += ":";
 ModuleName += stringFromPath(Partition);
 ModuleNameLoc = {PP.getIdentifierInfo(ModuleName), Partition[0].second};
 Partition = ModuleIdPath(ModuleNameLoc);
Index: clang/include/clang/Basic/Module.h
===
--- clang/include/clang/Basic/Module.h
+++ clang/include/clang/Basic/Module.h
@@ -517,6 +517,15 @@
   /// Is this a module partition.
   bool isModulePartition() const { return Name.find(':') != std::string::npos; 
}
 
+  /// Get the primary module interface name from a partition.
+
+  std::string getPrimaryModuleInterfaceName() const {
+std::string::size_type pos = Name.find(':');
+if (pos == std::string::npos)
+  return Name;
+return Name.substr(0, pos);
+  }
+
   /// Retrieve the full name of this module, including the path from
   /// its top-level module.
   /// \param AllowStringLiterals If \c true, components that might not be


Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -375,17 +375,10 @@
 // We already checked that we are in a module purview in the parser.
 assert(!ModuleScopes.empty() && "in a module purview, but no module?");
 Module *NamedMod = ModuleScopes.back().Module;
-if (ModuleScopes.back().IsPartition) {
-  // We're importing a partition into a partition, find the name of the
-  // owning named module.
-  size_t P = NamedMod->Name.find_first_of(":");
-  ModuleName = NamedMod->Name.substr(0, P + 1);
-} else {
-  // We're importing a partition into the named module itself (either the
-  // interface or an implementation TU).
-  ModuleName = NamedMod->Name;
-  ModuleName += ":";
-}
+// If we are importing into a partition, find the owning named module,
+// otherwise, the name of the importing named module.
+ModuleName = NamedMod->getPrimaryModuleInterfaceName();
+ModuleName += ":";
 ModuleName += stringFromPath(Partition);
 ModuleNameLoc = {PP.getIdentifierInfo(ModuleName), Partition[0].second};
 Partition = ModuleIdPath(ModuleNameLoc);
Index: clang/include/clang/Basic/Module.h
===
--- clang/include/clang/Basic/Module.h
+++ clang/include/clang/Basic/Module.h
@@ -517,6 +517,15 @@
   /// Is this a module partition.
   bool isModulePartition() const { return Name.find(':') != std::string::npos; }
 
+  /// Get the primary module interface name from a partition.
+
+  std::string getPrimaryModuleInterfaceName() const {
+std::string::size_type pos = Name.find(':');
+if (pos == std::string::npos)
+  return Name;
+return Name.substr(0, pos);
+  }
+
   /// Retrieve the full name of this module, including the path from
   /// its top-level module.
   /// \param AllowStringLiterals If \c true, components that might not be
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D118599: [C++20][Modules] Amend module visibility rules for partitions.

2022-02-16 Thread Iain Sandoe via Phabricator via cfe-commits
iains updated this revision to Diff 409211.
iains added a comment.

rebased onto changes in parent patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118599

Files:
  clang/lib/Sema/SemaLookup.cpp
  clang/test/Modules/cxx20-10-1-ex2.cpp


Index: clang/test/Modules/cxx20-10-1-ex2.cpp
===
--- clang/test/Modules/cxx20-10-1-ex2.cpp
+++ clang/test/Modules/cxx20-10-1-ex2.cpp
@@ -11,9 +11,8 @@
 // RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=3 -x c++ %s \
 // RUN:   -o %t/B_X1.pcm -verify
 
-// Not expected to work yet.
-//  %clang_cc1 -std=c++20 -emit-module-interface -D TU=4 -x c++ %s \
-//   -fmodule-file=%t/B.pcm  -o %t/B_X2.pcm
+// RUN:  %clang_cc1 -std=c++20 -emit-module-interface -D TU=4 -x c++ %s \
+// RUN:   -fmodule-file=%t/B.pcm  -o %t/B_X2.pcm
 
 // RUN: %clang_cc1 -std=c++20 -emit-obj -D TU=5 -x c++ %s \
 // RUN:  -fmodule-file=%t/B.pcm  -o %t/b_tu5.s
@@ -21,9 +20,8 @@
 // RUN: %clang_cc1 -std=c++20 -S -D TU=6 -x c++ %s \
 // RUN:  -fmodule-file=%t/B.pcm  -o %t/b_tu6.s -verify
 
-// Not expected to work yet.
-//  %clang_cc1 -std=c++20 -emit-module-interface -D TU=7 -x c++ %s \
-//   -fmodule-file=%t/B_X2.pcm  -o %t/B_X3.pcm -verify
+// RUN:  %clang_cc1 -std=c++20 -emit-module-interface -D TU=7 -x c++ %s \
+// RUN: -fmodule-file=%t/B_X2.pcm  -o %t/B_X3.pcm -verify
 
 #if TU == 1
   module B:Y;
Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -1687,8 +1687,8 @@
   Module *DeclModule = SemaRef.getOwningModule(D);
   assert(DeclModule && "hidden decl has no owning module");
 
-  // If the owning module is visible, the decl is visible.
   if (SemaRef.isModuleVisible(DeclModule, D->isModulePrivate()))
+// If the owning module is visible, the decl is visible.
 return true;
 
   // Determine whether a decl context is a file context for the purpose of
@@ -1762,6 +1762,22 @@
   if (ModulePrivate) {
 if (isInCurrentModule(M, getLangOpts()))
   return true;
+else if (M->Kind == Module::ModuleKind::ModulePartitionImplementation &&
+ isModuleDirectlyImported(M))
+  // Unless a partition implementation is directly imported it is not
+  // counted as visible for lookup, although the contained decls might
+  // still be reachable.  It's a partition, so it must be part of the
+  // current module to be a valid import.
+  return true;
+else if (getLangOpts().CPlusPlusModules && !ModuleScopes.empty() &&
+ ModuleScopes[0].Module->Kind ==
+ Module::ModuleKind::ModulePartitionImplementation &&
+ ModuleScopes[0].Module->getPrimaryModuleInterfaceName() ==
+ M->Name &&
+ isModuleDirectlyImported(M))
+  // We are building a module implementation partition and the TU imports
+  // the primary module interface unit.
+  return true;
   } else {
 if (VisibleModules.isVisible(M))
   return true;


Index: clang/test/Modules/cxx20-10-1-ex2.cpp
===
--- clang/test/Modules/cxx20-10-1-ex2.cpp
+++ clang/test/Modules/cxx20-10-1-ex2.cpp
@@ -11,9 +11,8 @@
 // RUN: %clang_cc1 -std=c++20 -emit-module-interface -D TU=3 -x c++ %s \
 // RUN:   -o %t/B_X1.pcm -verify
 
-// Not expected to work yet.
-//  %clang_cc1 -std=c++20 -emit-module-interface -D TU=4 -x c++ %s \
-//   -fmodule-file=%t/B.pcm  -o %t/B_X2.pcm
+// RUN:  %clang_cc1 -std=c++20 -emit-module-interface -D TU=4 -x c++ %s \
+// RUN:   -fmodule-file=%t/B.pcm  -o %t/B_X2.pcm
 
 // RUN: %clang_cc1 -std=c++20 -emit-obj -D TU=5 -x c++ %s \
 // RUN:  -fmodule-file=%t/B.pcm  -o %t/b_tu5.s
@@ -21,9 +20,8 @@
 // RUN: %clang_cc1 -std=c++20 -S -D TU=6 -x c++ %s \
 // RUN:  -fmodule-file=%t/B.pcm  -o %t/b_tu6.s -verify
 
-// Not expected to work yet.
-//  %clang_cc1 -std=c++20 -emit-module-interface -D TU=7 -x c++ %s \
-//   -fmodule-file=%t/B_X2.pcm  -o %t/B_X3.pcm -verify
+// RUN:  %clang_cc1 -std=c++20 -emit-module-interface -D TU=7 -x c++ %s \
+// RUN: -fmodule-file=%t/B_X2.pcm  -o %t/B_X3.pcm -verify
 
 #if TU == 1
   module B:Y;
Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -1687,8 +1687,8 @@
   Module *DeclModule = SemaRef.getOwningModule(D);
   assert(DeclModule && "hidden decl has no owning module");
 
-  // If the owning module is visible, the decl is visible.
   if (SemaRef.isModuleVisible(DeclModule, D->isModulePrivate()))
+// If the owning module is visible, the decl is visible.
 return true;
 
   // Determine whether a decl context is a file context for the purpose of
@@ -1762,6 +1762,22 @@
   if (ModulePrivate) {
 if (isInCurrentModule(M, getLangOpts()

[clang] fdee512 - [clang-format] Add test for SpacesInLineCommentPrefix. NFC.

2022-02-16 Thread Marek Kurdej via cfe-commits

Author: Marek Kurdej
Date: 2022-02-16T13:54:55+01:00
New Revision: fdee51204848dce5e0c39db332a7c488dc5b333f

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

LOG: [clang-format] Add test for SpacesInLineCommentPrefix. NFC.

Fixes https://github.com/llvm/llvm-project/issues/52649.
This was already fixed in commit 
https://github.com/llvm/llvm-project/commit/e967d97a35a93c883528a9672159edff05f5addb.

Added: 


Modified: 
clang/unittests/Format/FormatTestComments.cpp

Removed: 




diff  --git a/clang/unittests/Format/FormatTestComments.cpp 
b/clang/unittests/Format/FormatTestComments.cpp
index 8cdca0eb5900a..c988a2869e568 100644
--- a/clang/unittests/Format/FormatTestComments.cpp
+++ b/clang/unittests/Format/FormatTestComments.cpp
@@ -3650,6 +3650,13 @@ TEST_F(FormatTestComments, SpaceAtLineCommentBegin) {
 format("//   x\n"
"// y",
Style));
+  EXPECT_EQ(
+  "// loong\n"
+  "// commentcomments\n"
+  "// normal comments",
+  format("//loong 
commentcomments\n"
+ "// normal comments",
+ Style));
 
   Style.SpacesInLineCommentPrefix = {3, 3};
   EXPECT_EQ("//   Lorem ipsum\n"



___
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

2022-02-16 Thread Johel Ernesto Guerrero Peña via Phabricator via cfe-commits
JohelEGP accepted this revision.
JohelEGP added a comment.
This revision is now accepted and ready to land.

Thank you.


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] D119525: [clang] Fix crash when array size is missing in initializer

2022-02-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Continues to LGTM, though I had a recommendation for the release note. Feel 
free to land when you'd like.




Comment at: clang/docs/ReleaseNotes.rst:54
+--
+- ``CXXNewExpr::getArraySize()`` previously returned a ``llvm::Optional``
+  wrapping a ``nullptr`` when the ``CXXNewExpr`` did not have an array

Just added a reference to the bug that was fixed.


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

https://reviews.llvm.org/D119525

___
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

2022-02-16 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius accepted this revision.
curdeius added a comment.

LGTM. Maybe you can add a minimal test in `FormatTest.cpp` though.


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] D119926: [Clang][AArch64] Enable _Float16 _Complex type

2022-02-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/AST/ASTContext.h:1117
   CanQualType BFloat16Ty;
-  CanQualType Float16Ty; // C11 extension ISO/IEC TS 18661-3
+  CanQualType Float16Ty, Float16ComplexTy; // C11 extension ISO/IEC TS 18661-3
   CanQualType VoidPtrTy, NullPtrTy;

paulwalker-arm wrote:
> peterwaller-arm wrote:
> > Is this necessary?
> Is this necessary? I don't see any other `*ComplexTy` types in this file 
> (i.e. there is no `DoubleComplexTy`).
This is the wrong way to handle this -- complex types are stored in the 
`ComplexTypes` folding set and are created through 
`ASTContext::getComplexType()`. So I don't think this change is necessary.



Comment at: clang/lib/AST/ASTContext.cpp:1330
   InitBuiltinType(Float16Ty,   BuiltinType::Float16);
+  InitBuiltinType(Float16ComplexTy,BuiltinType::Float16);
 

paulwalker-arm wrote:
> peterwaller-arm wrote:
> > Is this necessary?
> As above.
Same here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119926

___
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

2022-02-16 Thread Erich Keane via Phabricator via cfe-commits
erichkeane requested changes to this revision.
erichkeane added a comment.
This revision now requires changes to proceed.

Actually, based on the build bot pre-merge checks, it looks like something 
during self-build has hit your assert!

https://buildkite.com/llvm-project/premerge-checks/builds/79589#154a5e12-3ef1-4c5b-b644-0f0d5e3e4383

Please see if you can figure out how to deal with whatever situation is 
happening there.

FAILED: tools/clang/lib/Tooling/ASTNodeAPI.json 
/var/lib/buildkite-agent/builds/llvm-project/build/tools/clang/lib/Tooling/ASTNodeAPI.json
cd /var/lib/buildkite-agent/builds/llvm-project/build/tools/clang/lib/Tooling 
&& /var/lib/buildkite-agent/builds/llvm-project/build/bin/clang-ast-dump 
--skip-processing=0 -I 
/var/lib/buildkite-agent/builds/llvm-project/build/lib/clang/15.0.0/include -I 
/var/lib/buildkite-agent/builds/llvm-project/clang/include -I 
/var/lib/buildkite-agent/builds/llvm-project/build/tools/clang/include -I 
/var/lib/buildkite-agent/builds/llvm-project/build/include -I 
/var/lib/buildkite-agent/builds/llvm-project/llvm/include -I 
/usr/include/c++/11 -I /usr/include/x86_64-linux-gnu/c++/11 -I 
/usr/include/c++/11/backward -I /usr/lib/llvm-13/lib/clang/13.0.1/include -I 
/usr/local/include -I /usr/include/x86_64-linux-gnu -I /usr/include 
--json-output-path 
/var/lib/buildkite-agent/builds/llvm-project/build/tools/clang/lib/Tooling/ASTNodeAPI.json
clang-ast-dump: 
/var/lib/buildkite-agent/builds/llvm-project/clang/lib/Sema/SemaExpr.cpp:16644: 
void 
clang::Sema::PushExpressionEvaluationContext(clang::Sema::ExpressionEvaluationContext,
 clang::Decl *, ExpressionEvaluationContextRecord::ExpressionKind): Assertion 
`!(ExprEvalContexts.back().Context == 
ExpressionEvaluationContext::PotentiallyEvaluated && 
ExprEvalContexts[ExprEvalContexts.size() - 2].isConstantEvaluated()) && "Can't 
have an evaluated context within an unevaluated context!"' failed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119651

___
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

2022-02-16 Thread Louis Dionne via Phabricator via cfe-commits
ldionne accepted this revision.
ldionne added a comment.

LGTM from libc++/libc++abi's perspective.


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


[clang] fe3407a - [CGBuilder] Assert that CreateAddrSpaceCast does not change element type

2022-02-16 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2022-02-16T15:17:08+01:00
New Revision: fe3407a91b6dcc1100c0b30187aa8c9587c73cad

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

LOG: [CGBuilder] Assert that CreateAddrSpaceCast does not change element type

Address space casts in general may change the element type, but
don't allow it in the method working on Address, so we can
preserve the element type.

CreatePointerBitCastOrAddrSpaceCast() still needs to be addressed.

Added: 


Modified: 
clang/lib/CodeGen/CGBuilder.h
clang/lib/CodeGen/CGExpr.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGBuilder.h b/clang/lib/CodeGen/CGBuilder.h
index 2855649472ec..eaf563a436ca 100644
--- a/clang/lib/CodeGen/CGBuilder.h
+++ b/clang/lib/CodeGen/CGBuilder.h
@@ -154,8 +154,10 @@ class CGBuilderTy : public CGBuilderBaseTy {
   using CGBuilderBaseTy::CreateAddrSpaceCast;
   Address CreateAddrSpaceCast(Address Addr, llvm::Type *Ty,
   const llvm::Twine &Name = "") {
-return Address(CreateAddrSpaceCast(Addr.getPointer(), Ty, Name),
-   Addr.getAlignment());
+assert(cast(Ty)->isOpaqueOrPointeeTypeMatches(
+   Addr.getElementType()) &&
+   "Should not change the element type");
+return Addr.withPointer(CreateAddrSpaceCast(Addr.getPointer(), Ty, Name));
   }
 
   /// Cast the element type of the given address to a 
diff erent type,

diff  --git a/clang/lib/CodeGen/CGExpr.cpp b/clang/lib/CodeGen/CGExpr.cpp
index e0e1dd5df586..7fc4c4f35796 100644
--- a/clang/lib/CodeGen/CGExpr.cpp
+++ b/clang/lib/CodeGen/CGExpr.cpp
@@ -1114,11 +1114,11 @@ Address CodeGenFunction::EmitPointerWithAlignment(const 
Expr *E,
   CE->getBeginLoc());
 }
 
-if (CE->getCastKind() == CK_AddressSpaceConversion)
- return Builder.CreateAddrSpaceCast(Addr, ConvertType(E->getType()));
-
 llvm::Type *ElemTy = ConvertTypeForMem(E->getType()->getPointeeType());
-return Builder.CreateElementBitCast(Addr, ElemTy);
+Addr = Builder.CreateElementBitCast(Addr, ElemTy);
+if (CE->getCastKind() == CK_AddressSpaceConversion)
+  Addr = Builder.CreateAddrSpaceCast(Addr, ConvertType(E->getType()));
+return Addr;
   }
   break;
 



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


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

2022-02-16 Thread Nico Weber via Phabricator via cfe-commits
thakis accepted this revision.
thakis added a comment.
This revision is now accepted and ready to land.

Thanks! Relanding.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118070

___
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

2022-02-16 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added inline comments.



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

jdoerfert wrote:
> 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.)
I guess that hangs on whether libm is optional or not.

I am reluctant to tie every openmp execution to the rocm libdevice as it 
frequently fails to build with llvm trunk and I'm nervy about linking IR built 
by the rocm clang with IR generated from trunk. It mostly seems to work for 
rocm sufficiently similar in age to trunk but periodically the abi or intrinsic 
set diverges. 

Maybe our working assumption should be that everyone using openmp wants libm so 
rocm breaking trunk openmp has to be resolved each time it happens anyway. If 
so, there's a design decision to be made about how to manage that dependency.


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] D116015: [PowerPC] Add generic fnmsub intrinsic

2022-02-16 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

> hiding the semantics from the optimizer is sometimes a good thing and 
> sometimes a bad thing).

Agree. Imagining a case when the neg and fma (from fnmsub) can both be CSE-ed 
with another neg and fma, so we can totally eliminate the fnmsub. But after we 
convert it to an intrinsic, we may lose the opportunity to CSE the fnmsub.

> Here's a pretty simple case: vector float foo(vector float a, vector float b, 
> vector float c, vector float d) { return __builtin_vsx_xvnmsubasp(c, d, a*b); 
> }
> It current produces xvnegsp+xvmulsp+xvnmaddasp, after this patch it produces 
> xvmulsp+xvnmsubasp. In some complicated cases, we can see much more 
> unexpected instructions generated.

This is narrowed down from a real-world case. After CSE some part of the 
fnmsub, it is hard to optimize it back to a single hardware fnmsub instruction 
as normally we check the use number of a register and if the user number is not 
1, we may exit the combine.

Is it possible to get some perf data for some float workloads with this patch? 
@qiucf




Comment at: llvm/include/llvm/IR/IntrinsicsPowerPC.td:1737
+  [LLVMMatchType<0>, LLVMMatchType<0>, LLVMMatchType<0>],
+  [IntrNoMem]>;
   def int_ppc_fre

When `llvm_anyfloat_ty` is `f32` or `f64`, we will generate two intrinsics with 
same semantic. `llvm.ppc.nmsub.f32` + `llvm.ppc.fnmsubs` and 
`llvm.ppc.nmsub.f64` + `llvm.ppc.fnmsub`. At first glance, we seems can not 
delete the `int_ppc_fnmsub` and `int_ppc_fnmsubs`, because they are for XL 
compatibility and XL has seperated fnmsub for float and double and we need to 
map them 1 by 1. Better to check if it is possible to replace `int_ppc_fnmsub` 
and `int_ppc_fnmsubs` with `int_ppc_nmsub`. And if it can be replaced, we can 
use a meaningful name like `int_ppc_fnmsub` for the new intrinsic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116015

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


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

2022-02-16 Thread Nico Weber 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 rGc5fb05f663f2: Reland: Make lld-link work in a non-MSVC 
shell, add /winsysroot: (authored by pkasting, committed by thakis).

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 &VFS,
+  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 

[clang] c5fb05f - Reland: Make lld-link work in a non-MSVC shell, add /winsysroot:

2022-02-16 Thread Nico Weber via cfe-commits

Author: Peter Kasting
Date: 2022-02-16T09:22:39-05:00
New Revision: c5fb05f663f2ac0cbedb318d03b91d44900ab9de

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

LOG: Reland: Make lld-link work in a non-MSVC shell, add /winsysroot:

This relands 73e585e44d (and 0574b5fc657451), with a fix for
the failing test (by using Optionals instead of
making StringRef::empty() mean absence of value).

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

Added: 
lld/test/COFF/winsysroot.test
llvm/include/llvm/WindowsDriver/MSVCPaths.h
llvm/include/llvm/WindowsDriver/MSVCSetupApi.h
llvm/lib/WindowsDriver/CMakeLists.txt
llvm/lib/WindowsDriver/MSVCPaths.cpp
llvm/utils/gn/secondary/llvm/lib/WindowsDriver/BUILD.gn

Modified: 
clang/docs/tools/clang-formatted-files.txt
clang/lib/Driver/CMakeLists.txt
clang/lib/Driver/ToolChains/MSVC.cpp
clang/lib/Driver/ToolChains/MSVC.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
llvm/lib/CMakeLists.txt
llvm/utils/gn/secondary/clang/lib/Driver/BUILD.gn
llvm/utils/gn/secondary/lld/COFF/BUILD.gn

Removed: 
clang/lib/Driver/ToolChains/MSVCSetupApi.h



diff  --git a/clang/docs/tools/clang-formatted-files.txt 
b/clang/docs/tools/clang-formatted-files.txt
index c7defa9cd88c..4a2c28bcf32a 100644
--- a/clang/docs/tools/clang-formatted-files.txt
+++ b/clang/docs/tools/clang-formatted-files.txt
@@ -285,7 +285,6 @@ clang/lib/Driver/ToolChains/InterfaceStubs.h
 clang/lib/Driver/ToolChains/Minix.h
 clang/lib/Driver/ToolChains/MipsLinux.cpp
 clang/lib/Driver/ToolChains/MSP430.h
-clang/lib/Driver/ToolChains/MSVCSetupApi.h
 clang/lib/Driver/ToolChains/PPCFreeBSD.cpp
 clang/lib/Driver/ToolChains/PPCFreeBSD.h
 clang/lib/Driver/ToolChains/PPCLinux.h
@@ -5329,6 +5328,8 @@ 
llvm/include/llvm/Transforms/Utils/UnifyFunctionExitNodes.h
 llvm/include/llvm/Transforms/Utils/UnifyLoopExits.h
 llvm/include/llvm/Transforms/Utils/ValueMapper.h
 llvm/include/llvm/Transforms/Vectorize/SLPVectorizer.h
+llvm/include/llvm/WindowsDriver/MSVCPaths.h
+llvm/include/llvm/WindowsDriver/MSVCSetupApi.h
 llvm/include/llvm/WindowsManifest/WindowsManifestMerger.h
 llvm/include/llvm/WindowsResource/ResourceScriptToken.h
 llvm/include/llvm/XRay/BlockIndexer.h
@@ -6492,6 +6493,7 @@ llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
 llvm/lib/Transforms/Vectorize/VPlanTransforms.h
 llvm/lib/Transforms/Vectorize/VPlanValue.h
 llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp
+llvm/lib/WindowsDriver/MSVCPaths.cpp
 llvm/lib/WindowsManifest/WindowsManifestMerger.cpp
 llvm/lib/XRay/BlockIndexer.cpp
 llvm/lib/XRay/BlockVerifier.cpp

diff  --git a/clang/lib/Driver/CMakeLists.txt b/clang/lib/Driver/CMakeLists.txt
index 78e8fd185284..00c7a8f893ff 100644
--- a/clang/lib/Driver/CMakeLists.txt
+++ b/clang/lib/Driver/CMakeLists.txt
@@ -4,6 +4,7 @@ set(LLVM_LINK_COMPONENTS
   Option
   ProfileData
   Support
+  WindowsDriver
   )
 
 if(WIN32)

diff  --git a/clang/lib/Driver/ToolChains/MSVC.cpp 
b/clang/lib/Driver/ToolChains/MSVC.cpp
index 9f4751167ac1..3fc02eefe11b 100644
--- a/clang/lib/Driver/ToolChains/MSVC.cpp
+++ b/clang/lib/Driver/ToolChains/MSVC.cpp
@@ -40,91 +40,12 @@
   #include 
 #endif
 
-#ifdef _MSC_VER
-// Don't support SetupApi on MinGW.
-#define USE_MSVC_SETUP_API
-
-// Make sure this comes before MSVCSetupApi.h
-#include 
-
-#ifdef __clang__
-#pragma clang diagnostic push
-#pragma clang diagnostic ignored "-Wnon-virtual-dtor"
-#endif
-#include "MSVCSetupApi.h"
-#ifdef __clang__
-#pragma clang diagnostic pop
-#endif
-#include "llvm/Support/COM.h"
-_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
-
 using namespace clang::driver;
 using namespace clang::driver::toolchains;
 using namespace clang::driver::tools;
 using namespace clang;
 using namespace llvm::opt;
 
-// Windows SDKs and VC Toolchains group their contents into subdirectories 
based
-// on the target architecture. This function converts an llvm::Triple::ArchType
-// to the corresponding subdirectory name.
-static const char *llvmArchToWindowsSDKArch(llvm::Triple::ArchType Arch) {
-  using ArchType = llvm::Triple::ArchType;
-  switch (Arch) {
-  case ArchType::x86:
-return "x86";
-  case ArchType::x86_64:
-return "x64";
-  case ArchType::arm:
-return "arm";
-  case ArchType::aarch64:
-return "arm64";
-  d

[PATCH] D119837: [RISCV] Fix the include search path order between sysroot and resource folder

2022-02-16 Thread Alex Bradbury via Phabricator via cfe-commits
asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

Thanks Kito. This LGTM, but I'd appreciate someone else reviewing and approving 
as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119837

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


[PATCH] D109239: Add support for floating-option `-ffp-eval-method` and for new `pragma clang fp eval-method`

2022-02-16 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

> Oh, I added a NFC fix previously in 
> https://github.com/llvm/llvm-project/commit/25cdf87b13eb990eb84d31211280f4b0d5d470b3.
>  I think it should be reverted too? I am going to revert it.

I did that in 5d110ed4cd4 
. See this 
comment (and above) 
https://github.com/llvm/llvm-project/blob/main/clang/test/Misc/warning-flags.c#L19
 for why that change only papered over an actual problem :)


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

https://reviews.llvm.org/D109239

___
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

2022-02-16 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added inline comments.



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

JonChesterfield wrote:
> jdoerfert wrote:
> > 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.)
> I guess that hangs on whether libm is optional or not.
> 
> I am reluctant to tie every openmp execution to the rocm libdevice as it 
> frequently fails to build with llvm trunk and I'm nervy about linking IR 
> built by the rocm clang with IR generated from trunk. It mostly seems to work 
> for rocm sufficiently similar in age to trunk but periodically the abi or 
> intrinsic set diverges. 
> 
> Maybe our working assumption should be that everyone using openmp wants libm 
> so rocm breaking trunk openmp has to be resolved each time it happens anyway. 
> If so, there's a design decision to be made about how to manage that 
> dependency.
I tested this on Spock and it resolves linking math libraries. I'm not sure 
about overall stability however. I'm assuming this is sufficient until we get a 
real libdevice for AMDGPU.


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] D119837: [RISCV] Fix the include search path order between sysroot and resource folder

2022-02-16 Thread Hafiz Abid Qadeer via Phabricator via cfe-commits
abidh added a comment.

In D119837#3326179 , @asb wrote:

> Thanks Kito. This LGTM, but I'd appreciate someone else reviewing and 
> approving as well.

Looks ok to me too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119837

___
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

2022-02-16 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm 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 &I : llvm::make_range(OpenMPTCRange.first, OpenMPTCRange.second)) {

jhuber6 wrote:
> 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.
It can be subtley wrong, and also pushes reliance on setting the global 
subtarget. It's best to ensure the default attributes are propagated to the 
device libraries


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


[libunwind] 641a141 - [runtimes] Deprecate FOO_SYSROOT & friends

2022-02-16 Thread Louis Dionne via cfe-commits

Author: Louis Dionne
Date: 2022-02-16T09:44:08-05:00
New Revision: 641a141da1f22de319e891bdfd61e614632b39f0

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

LOG: [runtimes] Deprecate FOO_SYSROOT & friends

As suggested in https://reviews.llvm.org/D112155.

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

Added: 


Modified: 
libcxx/CMakeLists.txt
libcxxabi/CMakeLists.txt
libunwind/CMakeLists.txt

Removed: 




diff  --git a/libcxx/CMakeLists.txt b/libcxx/CMakeLists.txt
index aabecc529d202..06dd56a9b1a40 100644
--- a/libcxx/CMakeLists.txt
+++ b/libcxx/CMakeLists.txt
@@ -291,6 +291,16 @@ set(LIBCXX_TARGET_TRIPLE "${LIBCXX_DEFAULT_TARGET_TRIPLE}" 
CACHE STRING "Use alt
 set(LIBCXX_SYSROOT "${CMAKE_SYSROOT}" CACHE STRING "Use alternate sysroot.")
 set(LIBCXX_GCC_TOOLCHAIN "${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}" CACHE 
STRING "Use alternate GCC toolchain.")
 
+if(NOT CMAKE_SYSROOT AND LIBCXX_SYSROOT)
+  message(WARNING "LIBCXX_SYSROOT is deprecated, please use CMAKE_SYSROOT 
instead")
+endif()
+if(NOT CMAKE_CXX_COMPILER_TARGET AND LIBCXX_TARGET_TRIPLE)
+  message(WARNING "LIBCXX_TARGET_TRIPLE is deprecated, please use 
CMAKE_CXX_COMPILER_TARGET instead")
+endif()
+if(NOT CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN AND LIBCXX_GCC_TOOLCHAIN)
+  message(WARNING "LIBCXX_GCC_TOOLCHAIN is deprecated, please use 
CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN instead")
+endif()
+
 # Feature options -
 option(LIBCXX_ENABLE_EXCEPTIONS "Use exceptions." ON)
 option(LIBCXX_ENABLE_RTTI "Use run time type information." ON)

diff  --git a/libcxxabi/CMakeLists.txt b/libcxxabi/CMakeLists.txt
index f40ee883080a1..46c8c267102dd 100644
--- a/libcxxabi/CMakeLists.txt
+++ b/libcxxabi/CMakeLists.txt
@@ -132,6 +132,16 @@ set(LIBCXXABI_TARGET_TRIPLE 
"${LIBCXXABI_DEFAULT_TARGET_TRIPLE}" CACHE STRING "T
 set(LIBCXXABI_GCC_TOOLCHAIN "${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}" CACHE 
PATH "GCC toolchain for cross compiling.")
 set(LIBCXXABI_SYSROOT "${CMAKE_SYSROOT}" CACHE PATH "Sysroot for cross 
compiling.")
 
+if(NOT CMAKE_SYSROOT AND LIBCXXABI_SYSROOT)
+  message(WARNING "LIBCXXABI_SYSROOT is deprecated, please use CMAKE_SYSROOT 
instead")
+endif()
+if(NOT CMAKE_CXX_COMPILER_TARGET AND LIBCXXABI_TARGET_TRIPLE)
+  message(WARNING "LIBCXXABI_TARGET_TRIPLE is deprecated, please use 
CMAKE_CXX_COMPILER_TARGET instead")
+endif()
+if(NOT CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN AND LIBCXXABI_GCC_TOOLCHAIN)
+  message(WARNING "LIBCXXABI_GCC_TOOLCHAIN is deprecated, please use 
CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN instead")
+endif()
+
 set(LIBCXXABI_LIBCXX_LIBRARY_PATH "" CACHE PATH "The path to libc++ library.")
 set(LIBCXXABI_LIBRARY_VERSION "1.0" CACHE STRING
 "Version of libc++abi. This will be reflected in the name of the shared \

diff  --git a/libunwind/CMakeLists.txt b/libunwind/CMakeLists.txt
index 6e39bdedc0c2e..7ab4a7b2f5b89 100644
--- a/libunwind/CMakeLists.txt
+++ b/libunwind/CMakeLists.txt
@@ -110,6 +110,16 @@ set(LIBUNWIND_TEST_LINKER_FLAGS "" CACHE STRING
 set(LIBUNWIND_TEST_COMPILER_FLAGS "" CACHE STRING
 "Additional compiler flags for test programs.")
 
+if(NOT CMAKE_SYSROOT AND LIBUNWIND_SYSROOT)
+  message(WARNING "LIBUNWIND_SYSROOT is deprecated, please use CMAKE_SYSROOT 
instead")
+endif()
+if(NOT CMAKE_CXX_COMPILER_TARGET AND LIBUNWIND_TARGET_TRIPLE)
+  message(WARNING "LIBUNWIND_TARGET_TRIPLE is deprecated, please use 
CMAKE_CXX_COMPILER_TARGET instead")
+endif()
+if(NOT CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN AND LIBUNWIND_GCC_TOOLCHAIN)
+  message(WARNING "LIBUNWIND_GCC_TOOLCHAIN is deprecated, please use 
CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN instead")
+endif()
+
 if (LIBUNWIND_ENABLE_SHARED)
   set(LIBUNWIND_DEFAULT_TEST_CONFIG "llvm-libunwind-shared.cfg.in")
 else()



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


[PATCH] D119162: [Pseudo] Token/TokenStream, PP directive parser.

2022-02-16 Thread Haojian Wu via Phabricator via cfe-commits
hokein added a comment.

comments on preprocessor part.




Comment at: clang/include/clang/Tooling/Syntax/Pseudo/Preprocess.h:49
+/// | `printf("hello, ");
+/// |-+ Conditional -+ Directive #ifndef NDEBUG
+/// | |-+ Code printf("debug\n");

is the `-+ Directive` expected?



Comment at: clang/include/clang/Tooling/Syntax/Pseudo/Preprocess.h:60
+struct PPStructure {
+  /// A range of code containing no directives.
+  struct Code {

maybe mention it includes comments.



Comment at: clang/lib/Tooling/Syntax/Pseudo/Preprocess.cpp:18
+
+class Parser {
+public:

I'd use a more specific name, maybe `PPParser`



Comment at: clang/lib/Tooling/Syntax/Pseudo/Preprocess.cpp:21
+  explicit Parser(const TokenStream &Code) : Code(Code), Tok(&Code.front()) {}
+  void parse(PPStructure *result) { parse(result, /*TopLevel=*/true); }
+

nit: result -> Result



Comment at: clang/lib/Tooling/Syntax/Pseudo/Preprocess.cpp:26
+  enum class Cond { None, If, Else, End };
+  static Cond classifyDirective(tok::PPKeywordKind kind) {
+switch (kind) {

nit: kind => Kind



Comment at: clang/lib/Tooling/Syntax/Pseudo/Preprocess.cpp:45
+  // Parses tokens starting at Tok into PP.
+  // If we reach an #end or #else directive that ends PP, returns it.
+  // If TopLevel is true, then we do not expect #end and always return None.

#end => #endif.



Comment at: clang/lib/Tooling/Syntax/Pseudo/Preprocess.cpp:60
+while (Tok->Kind != tok::eof) {
+  while (StartsDirective()) {
+PPStructure::Directive Directive;

is there any special reason to use a nested while? it looks like we can replace 
with an `if`. -- in each iteration, we get a Chunk result (either a Code, or a 
Directive), something like below should probably work?

```
while (Tok->Kind != tok::eof) {
  if (!StartsDirective()) {
 // handle Chunk::Code case
 continue;
  } else {
 // handle directive case.
  }
}
```





Comment at: clang/lib/Tooling/Syntax/Pseudo/Preprocess.cpp:77
+}
+assert(Kind == Cond::Else || Kind == Cond::End);
+return std::move(Directive);

It took me a while to understand the logic here. It feels more natural to make 
this case as an early-exit case, and leave the above general case as a default 
case like 

```
if (ParsingCondBranch && (Kind == Cond::Else || Kind == Cond::End)
  return ...
```



Comment at: clang/lib/Tooling/Syntax/Pseudo/Preprocess.cpp:91
+  // Parse the rest of a conditional section, after seeing the #if directive.
+  // Returns after consuming the #end directive.
+  void parseConditional(PPStructure::Conditional *C) {

#end => #endif



Comment at: clang/lib/Tooling/Syntax/Pseudo/Preprocess.cpp:134
+  const Token *Tok;
+  clang::IdentifierTable Idents;
+};

maybe rename to PPKeywordTable, it seems clearer for the purpose



Comment at: clang/lib/Tooling/Syntax/Pseudo/Preprocess.cpp:145
+
+static llvm::StringLiteral ppKeywordName(tok::PPKeywordKind kind) {
+  switch (kind) {

nit: Kind



Comment at: clang/lib/Tooling/Syntax/Pseudo/Preprocess.cpp:145
+
+static llvm::StringLiteral ppKeywordName(tok::PPKeywordKind kind) {
+  switch (kind) {

hokein wrote:
> nit: Kind
looks like this function can be lifted to TokenKinds.h file (there is a similar 
getTokenName there), maybe a FIXME?



Comment at: clang/test/Syntax/lex.test:37
+PPS-NEXT: #endif (2 tokens)
+PPS-NEXT: code (1 tokens)
+

`1 tokens` seems silly :( maybe it doesn't matter.



Comment at: clang/test/Syntax/lex.test:38
+PPS-NEXT: code (1 tokens)
+

Does this extra trailing blank line matter?



Comment at: clang/unittests/Tooling/Syntax/Pseudo/PreprocessTest.cpp:40
+
+TEST(PPStructure, Parse) {
+  LangOptions Opts;

maybe add a mismatched-if testcase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119162

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


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

2022-02-16 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan added inline comments.



Comment at: clang/include/clang/Sema/Sema.h:2989
   /// \param ImportLoc The location of the 'import' keyword.
-  /// \param Path The module access path.
+  /// \param NamePath The module toplevel name as an access path.
+  /// \param Partition The module partition name as an access path.

Is `NamePath` really a better name?  You've not consistently changed all 
`Path`'s to this, and it doesn;t strike me as particularly mnemonic.



Comment at: clang/lib/Parse/Parser.cpp:2394
 /// Parse a module import declaration. This is essentially the same for
-/// Objective-C and the C++ Modules TS, except for the leading '@' (in ObjC)
+/// Objective-C and the C++20/Modules TS, except for the leading '@' (in ObjC)
 /// and the trailing optional attributes (in C++).

perhaps now we should just remove modules-ts references as drive-by cleanups?


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] D93298: [RISCV] add the MC layer support of Zfinx extension

2022-02-16 Thread Alex Bradbury via Phabricator via cfe-commits
asb added a comment.

I think all my comments have been addressed. @craig.topper - are you happy your 
RegInfo question is addressed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93298

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


[PATCH] D119926: [Clang][AArch64] Enable _Float16 _Complex type

2022-02-16 Thread Matt Devereau via Phabricator via cfe-commits
MattDevereau updated this revision to Diff 409236.
MattDevereau added a comment.

Removed -O1 and -ffast-math flags


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119926

Files:
  clang/lib/AST/ASTContext.cpp
  clang/test/CodeGen/aarch64-complex-half-math.c

Index: clang/test/CodeGen/aarch64-complex-half-math.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-complex-half-math.c
@@ -0,0 +1,419 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 %s -emit-llvm -triple aarch64-unknown-unknown -o - | FileCheck %s --check-prefix=AARCH64
+// REQUIRES: aarch64-registered-target
+
+// AARCH64-LABEL: @add_float_rr(
+// AARCH64-NEXT:  entry:
+// AARCH64-NEXT:[[RETVAL:%.*]] = alloca { half, half }, align 2
+// AARCH64-NEXT:[[A_ADDR:%.*]] = alloca half, align 2
+// AARCH64-NEXT:[[B_ADDR:%.*]] = alloca half, align 2
+// AARCH64-NEXT:store half [[A:%.*]], half* [[A_ADDR]], align 2
+// AARCH64-NEXT:store half [[B:%.*]], half* [[B_ADDR]], align 2
+// AARCH64-NEXT:[[TMP0:%.*]] = load half, half* [[A_ADDR]], align 2
+// AARCH64-NEXT:[[TMP1:%.*]] = load half, half* [[B_ADDR]], align 2
+// AARCH64-NEXT:[[ADD:%.*]] = fadd half [[TMP0]], [[TMP1]]
+// AARCH64-NEXT:[[RETVAL_REALP:%.*]] = getelementptr inbounds { half, half }, { half, half }* [[RETVAL]], i32 0, i32 0
+// AARCH64-NEXT:[[RETVAL_IMAGP:%.*]] = getelementptr inbounds { half, half }, { half, half }* [[RETVAL]], i32 0, i32 1
+// AARCH64-NEXT:store half [[ADD]], half* [[RETVAL_REALP]], align 2
+// AARCH64-NEXT:store half 0xH, half* [[RETVAL_IMAGP]], align 2
+// AARCH64-NEXT:[[TMP2:%.*]] = load { half, half }, { half, half }* [[RETVAL]], align 2
+// AARCH64-NEXT:ret { half, half } [[TMP2]]
+//
+_Float16 _Complex add_float_rr(_Float16 a, _Float16 b) {
+  return a + b;
+}
+// AARCH64-LABEL: @add_float_cr(
+// AARCH64-NEXT:  entry:
+// AARCH64-NEXT:[[RETVAL:%.*]] = alloca { half, half }, align 2
+// AARCH64-NEXT:[[A:%.*]] = alloca { half, half }, align 2
+// AARCH64-NEXT:[[B_ADDR:%.*]] = alloca half, align 2
+// AARCH64-NEXT:[[TMP0:%.*]] = bitcast { half, half }* [[A]] to [2 x half]*
+// AARCH64-NEXT:store [2 x half] [[A_COERCE:%.*]], [2 x half]* [[TMP0]], align 2
+// AARCH64-NEXT:store half [[B:%.*]], half* [[B_ADDR]], align 2
+// AARCH64-NEXT:[[A_REALP:%.*]] = getelementptr inbounds { half, half }, { half, half }* [[A]], i32 0, i32 0
+// AARCH64-NEXT:[[A_REAL:%.*]] = load half, half* [[A_REALP]], align 2
+// AARCH64-NEXT:[[A_IMAGP:%.*]] = getelementptr inbounds { half, half }, { half, half }* [[A]], i32 0, i32 1
+// AARCH64-NEXT:[[A_IMAG:%.*]] = load half, half* [[A_IMAGP]], align 2
+// AARCH64-NEXT:[[TMP1:%.*]] = load half, half* [[B_ADDR]], align 2
+// AARCH64-NEXT:[[ADD_R:%.*]] = fadd half [[A_REAL]], [[TMP1]]
+// AARCH64-NEXT:[[RETVAL_REALP:%.*]] = getelementptr inbounds { half, half }, { half, half }* [[RETVAL]], i32 0, i32 0
+// AARCH64-NEXT:[[RETVAL_IMAGP:%.*]] = getelementptr inbounds { half, half }, { half, half }* [[RETVAL]], i32 0, i32 1
+// AARCH64-NEXT:store half [[ADD_R]], half* [[RETVAL_REALP]], align 2
+// AARCH64-NEXT:store half [[A_IMAG]], half* [[RETVAL_IMAGP]], align 2
+// AARCH64-NEXT:[[TMP2:%.*]] = load { half, half }, { half, half }* [[RETVAL]], align 2
+// AARCH64-NEXT:ret { half, half } [[TMP2]]
+//
+_Float16 _Complex add_float_cr(_Float16 _Complex a, _Float16 b) {
+  return a + b;
+}
+// AARCH64-LABEL: @add_float_rc(
+// AARCH64-NEXT:  entry:
+// AARCH64-NEXT:[[RETVAL:%.*]] = alloca { half, half }, align 2
+// AARCH64-NEXT:[[B:%.*]] = alloca { half, half }, align 2
+// AARCH64-NEXT:[[A_ADDR:%.*]] = alloca half, align 2
+// AARCH64-NEXT:[[TMP0:%.*]] = bitcast { half, half }* [[B]] to [2 x half]*
+// AARCH64-NEXT:store [2 x half] [[B_COERCE:%.*]], [2 x half]* [[TMP0]], align 2
+// AARCH64-NEXT:store half [[A:%.*]], half* [[A_ADDR]], align 2
+// AARCH64-NEXT:[[TMP1:%.*]] = load half, half* [[A_ADDR]], align 2
+// AARCH64-NEXT:[[B_REALP:%.*]] = getelementptr inbounds { half, half }, { half, half }* [[B]], i32 0, i32 0
+// AARCH64-NEXT:[[B_REAL:%.*]] = load half, half* [[B_REALP]], align 2
+// AARCH64-NEXT:[[B_IMAGP:%.*]] = getelementptr inbounds { half, half }, { half, half }* [[B]], i32 0, i32 1
+// AARCH64-NEXT:[[B_IMAG:%.*]] = load half, half* [[B_IMAGP]], align 2
+// AARCH64-NEXT:[[ADD_R:%.*]] = fadd half [[TMP1]], [[B_REAL]]
+// AARCH64-NEXT:[[RETVAL_REALP:%.*]] = getelementptr inbounds { half, half }, { half, half }* [[RETVAL]], i32 0, i32 0
+// AARCH64-NEXT:[[RETVAL_IMAGP:%.*]] = getelementptr inbounds { half, half }, { half, half }* [[RETVAL]], i32 0, i32 1
+// AARCH64-NEXT:store half [[ADD_R]], half* [[RETVAL_REALP]], align 2
+// AARCH64-NEXT:store half 

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

2022-02-16 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan added inline comments.



Comment at: clang/lib/Sema/SemaTemplate.cpp:2654-2656
+if (!C.hasSameType(DefaultArgumentX->getType(),
+   DefaultArgumentY->getType()))
+  return false;

Can this ever trigger and the below expression test not trigger, given the 
above type comparison?



Comment at: clang/lib/Sema/SemaTemplate.cpp:2658-2682
+Expr::EvalResult EVRX, EVRY;
+if (!DefaultArgumentX->EvaluateAsConstantExpr(EVRX, C) ||
+!DefaultArgumentY->EvaluateAsConstantExpr(EVRY, C))
+  return false;
+
+APValue VX = EVRX.Val, VY = EVRY.Val;
+if (VX.getKind() != VY.getKind())

I'm kind of surprised how complex this check is.  Isn't there an AST comparator 
available somewhere?


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

https://reviews.llvm.org/D118034

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


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

2022-02-16 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

The bot that broke last time stayed green on the reland: 
https://lab.llvm.org/staging/#/builders/204/builds/1591 :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118070

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


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

2022-02-16 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan added inline comments.



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

ChuanqiXu wrote:
> iains wrote:
> > ChuanqiXu wrote:
> > > 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?
> > I see this in the Tony tables, but OTOH I cannot exactly see where the 
> > wording forbids it - in fact it permits preprocesssor directives before the 
> > import (including in the example in 5.7)... perhaps I'm misreading.
> > 
> > This way of writing the test cases does make them much easier to manage 
> > (and for a reader to see the intent) - of course, if we should split into 
> > files - then that is what we should do.
> > 
> I think the grammar in [[ http://eel.is/c++draft/cpp | [cpp.pre] ]] forbid it.
> 
> First, the file could only be:
> ```
> preprocessing-file:
> group_opt
> module-file
> ```
> 
> Then it is clear that we couldn't put macro declarative before module 
> declaration. I agree the current style is easier and more convenient. In 
> fact, I prefer it too. But I think we would better follow it since it is 
> standard. Otherwise, it would be more work in later maintenance stage.
ChuanqiXu is correct about preprocessor directives not being allowed before the 
initial module decl, but I don;t think compilers implement that.  There are a 
couple of issues.

a) some users have a need to have #pragma charset-or-similar before any tokens
b) forced headers

I do find the #if use here somewhat confusing.  A bunch of 
cxx20-file-info-[1-n].cpp might be more straightforwards?  (It does seem that 
directory is using cxx20 as a prefix rather than suffix btw.)


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] D119893: [clang-format] Fixed handling of requires clauses followed by attributes

2022-02-16 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks updated this revision to Diff 409237.
HazardyKnusperkeks added a comment.

Formatting Test added.


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

https://reviews.llvm.org/D119893

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

Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -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/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -23717,7 +23717,7 @@
"concept C = [] && requires(T t) { typename T::size_type; };");
 }
 
-TEST_F(FormatTest, RequiresClauses) {
+TEST_F(FormatTest, RequiresClausesPositions) {
   auto Style = getLLVMStyle();
   EXPECT_EQ(Style.RequiresClausePosition, FormatStyle::RCPS_OwnLine);
   EXPECT_EQ(Style.IndentRequiresClause, true);
@@ -23940,6 +23940,16 @@
ColumnStyle);
 }
 
+TEST_F(FormatTest, RequiresClauses) {
+  verifyFormat("struct [[nodiscard]] zero_t {\n"
+   "  template \n"
+   "requires requires { number_zero_v; }\n"
+   "  [[nodiscard]] constexpr operator T() const {\n"
+   "return number_zero_v;\n"
+   "  }\n"
+   "};");
+}
+
 TEST_F(FormatTest, StatementAttributeLikeMacros) {
   FormatStyle Style = getLLVMStyle();
   StringRef Source = "void Foo::slot() {\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -19,6 +19,7 @@
 #include "llvm/Support/raw_ostream.h"
 
 #include 
+#include 
 
 #define DEBUG_TYPE "format-parser"
 
@@ -3007,7 +3008,16 @@
 /// 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 exp

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

2022-02-16 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan added inline comments.



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

urnathan wrote:
> ChuanqiXu wrote:
> > iains wrote:
> > > ChuanqiXu wrote:
> > > > 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?
> > > I see this in the Tony tables, but OTOH I cannot exactly see where the 
> > > wording forbids it - in fact it permits preprocesssor directives before 
> > > the import (including in the example in 5.7)... perhaps I'm misreading.
> > > 
> > > This way of writing the test cases does make them much easier to manage 
> > > (and for a reader to see the intent) - of course, if we should split into 
> > > files - then that is what we should do.
> > > 
> > I think the grammar in [[ http://eel.is/c++draft/cpp | [cpp.pre] ]] forbid 
> > it.
> > 
> > First, the file could only be:
> > ```
> > preprocessing-file:
> > group_opt
> > module-file
> > ```
> > 
> > Then it is clear that we couldn't put macro declarative before module 
> > declaration. I agree the current style is easier and more convenient. In 
> > fact, I prefer it too. But I think we would better follow it since it is 
> > standard. Otherwise, it would be more work in later maintenance stage.
> ChuanqiXu is correct about preprocessor directives not being allowed before 
> the initial module decl, but I don;t think compilers implement that.  There 
> are a couple of issues.
> 
> a) some users have a need to have #pragma charset-or-similar before any tokens
> b) forced headers
> 
> I do find the #if use here somewhat confusing.  A bunch of 
> cxx20-file-info-[1-n].cpp might be more straightforwards?  (It does seem that 
> directory is using cxx20 as a prefix rather than suffix btw.)
or maybe splitting this up make it harder to understand the tests as a whole.  
I don;t think it terribly importand.  If we do ban pre-module directives, we 
can always split it then,


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] D119823: [Modules] Add module structure output to -module-file-info.

2022-02-16 Thread Iain Sandoe via Phabricator via cfe-commits
iains added inline comments.



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

urnathan wrote:
> urnathan wrote:
> > ChuanqiXu wrote:
> > > iains wrote:
> > > > ChuanqiXu wrote:
> > > > > 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?
> > > > I see this in the Tony tables, but OTOH I cannot exactly see where the 
> > > > wording forbids it - in fact it permits preprocesssor directives before 
> > > > the import (including in the example in 5.7)... perhaps I'm misreading.
> > > > 
> > > > This way of writing the test cases does make them much easier to manage 
> > > > (and for a reader to see the intent) - of course, if we should split 
> > > > into files - then that is what we should do.
> > > > 
> > > I think the grammar in [[ http://eel.is/c++draft/cpp | [cpp.pre] ]] 
> > > forbid it.
> > > 
> > > First, the file could only be:
> > > ```
> > > preprocessing-file:
> > > group_opt
> > > module-file
> > > ```
> > > 
> > > Then it is clear that we couldn't put macro declarative before module 
> > > declaration. I agree the current style is easier and more convenient. In 
> > > fact, I prefer it too. But I think we would better follow it since it is 
> > > standard. Otherwise, it would be more work in later maintenance stage.
> > ChuanqiXu is correct about preprocessor directives not being allowed before 
> > the initial module decl, but I don;t think compilers implement that.  There 
> > are a couple of issues.
> > 
> > a) some users have a need to have #pragma charset-or-similar before any 
> > tokens
> > b) forced headers
> > 
> > I do find the #if use here somewhat confusing.  A bunch of 
> > cxx20-file-info-[1-n].cpp might be more straightforwards?  (It does seem 
> > that directory is using cxx20 as a prefix rather than suffix btw.)
> or maybe splitting this up make it harder to understand the tests as a whole. 
>  I don;t think it terribly importand.  If we do ban pre-module directives, we 
> can always split it then,
OK ( actually, I find it easier to grok the test case intent if the various 
required inputs are built in order, in the single file - but that's the nature 
of preferences :) )

I suppose that (a) and (b) mean that we cannot reasonably diagnose this?

Probably some of the files (e.g. ones making dummy modules to be consumed by 
the actual tests) could be in 'Inputs'.  Will rework this accordingly.


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] D119525: [clang] Fix crash when array size is missing in initializer

2022-02-16 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:54
+--
+- ``CXXNewExpr::getArraySize()`` previously returned a ``llvm::Optional``
+  wrapping a ``nullptr`` when the ``CXXNewExpr`` did not have an array

aaron.ballman wrote:
> Just added a reference to the bug that was fixed.
I was wondering about this. Where does the "PRXX" syntax come from? Since 
the repo and issues are on github now, I don't see how it makes sense to call 
it a PR (it's an issue, not a pull request) and github doesn't linkify those, 
while it does when using the `#xx` syntax (which isn't relevant in this 
case, but it is when using it in git commit messages). I have seen other people 
use the same syntax to refer to issues. I'd probably just add an actual link to 
the github issue here if that's permitted. Thanks for the suggestion though, 
I'm on PTO this week so don't land this until Monday  :)


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

https://reviews.llvm.org/D119525

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


[clang] 6690b7d - [OpenCL] Ensure atomic_init is guarded with extension

2022-02-16 Thread Sven van Haastregt via cfe-commits

Author: Sven van Haastregt
Date: 2022-02-16T15:12:23Z
New Revision: 6690b7d3ac9ab6410b7909207552ce4edbe2147b

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

LOG: [OpenCL] Ensure atomic_init is guarded with extension

The named and generic address space overloads for atomic_init added
by 50f8abb9f40a ("[OpenCL] Add OpenCL 3.0 atomics to
-fdeclare-opencl-builtins", 2022-02-11) were not guarded by the
corresponding extensions.

Added: 


Modified: 
clang/lib/Sema/OpenCLBuiltins.td

Removed: 




diff  --git a/clang/lib/Sema/OpenCLBuiltins.td 
b/clang/lib/Sema/OpenCLBuiltins.td
index ab30553005729..556d1778625e7 100644
--- a/clang/lib/Sema/OpenCLBuiltins.td
+++ b/clang/lib/Sema/OpenCLBuiltins.td
@@ -1082,8 +1082,10 @@ multiclass OpenCL2Atomics {
   foreach TypePair = [[AtomicInt, Int], [AtomicUInt, UInt],
   [AtomicLong, Long], [AtomicULong, ULong],
   [AtomicFloat, Float], [AtomicDouble, Double]] in {
-def : Builtin<"atomic_init",
-[Void, PointerType, addrspace>, 
TypePair[1]]>;
+let Extension = BaseExt in {
+  def : Builtin<"atomic_init",
+  [Void, PointerType, addrspace>, 
TypePair[1]]>;
+}
 defm : BuiltinAtomicExplicit<"atomic_store",
 [Void, PointerType, addrspace>, 
TypePair[1]], BaseExt>;
 defm : BuiltinAtomicExplicit<"atomic_load",



___
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

2022-02-16 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

(I wish there was a flag that said "clang, never ever read any env vars 
please". Some people think that builds should be deterministic and not depend 
on random env vars people might have set (and then not do correct incremental 
rebuilds when the value of such env var flags change). But given that clang 
already reads a whole bunch of such env vars and we can always add such a flag 
later, I suppose this change doesn't make things that much worse.)


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] D119409: [C++20] [Modules] Remain variable's definition in module interface

2022-02-16 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan 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:
> 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

[PATCH] D118587: [C++20][Modules][4/8] Handle generation of partition implementation CMIs.

2022-02-16 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan accepted this revision.
urnathan added a comment.
This revision is now accepted and ready to land.

with the assert fixed




Comment at: clang/lib/Sema/SemaModule.cpp:119
+default:
+  assert(0 && "how did we get a partition type set?");
+}

llvm::unreachable ("how did we get a partition type set?");



Comment at: clang/test/Modules/cxx20-10-1-ex1.cpp:21
+
+#if TU == 1
+

I think I'm getting used to this idiom, or maybe Stockholm has kicked in?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118587

___
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'"

2022-02-16 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added a comment.

I'll update with the `CodeSynthesisContext` approach in a little bit. But 
meanwhile there's a problem with both the current patch //and// (I think even 
more) with the new approach. @rsmith any help?:
When I try my latest patch with the libc++ tests, with `bin/llvm-lit -sv 
--param enable_modules=True` (which corresponds to the `-fmodules` compiler 
flag), I get lots of errors like the following. Do you have any idea what's 
going wrong?

I can't minimize the example beyond "all of libc++" because Modules prevents 
`creduce` from doing anything meaningful. And unfortunately whatever's going 
wrong seems to be //specifically// about Modules.

  Assertion failed: (Replacement.isCanonical() && "replacement types must 
always be canonical"), function getSubstTemplateTypeParmType, file 
/Users/aodwyer/llvm-project/clang/lib/AST/ASTContext.cpp, line 4691.
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.Program arguments: /Users/aodwyer/llvm-project/build3/bin/clang-14 -cc1 
-triple x86_64-apple-macosx10.15.0 -Wundef-prefix=TARGET_OS_ 
-Werror=undef-prefix -Wdeprecated-objc-isa-usage 
-Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all --mrelax-relocations 
-disable-free -clear-ast-before-backend -main-file-name rbegin.pass.cpp 
-mrelocation-model pic -pic-level 2 -mframe-pointer=all -ffp-contract=on 
-fno-rounding-math -funwind-tables=2 -target-sdk-version=10.15.6 
-fcompatibility-qualified-id-block-type-checking 
-fvisibility-inlines-hidden-static-local-var -target-cpu penryn -tune-cpu 
generic -mllvm -treat-scalable-fixed-error-as-warning -debugger-tuning=lldb 
-target-linker-version 609.8 -v 
-fcoverage-compilation-dir=/Users/aodwyer/llvm-project/build3/projects/libcxx/test/std/ranges/range.access
 -nostdinc++ -resource-dir /Users/aodwyer/llvm-project/build3/lib/clang/15.0.0 
-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -isystem 
/Users/aodwyer/llvm-project/build3/include/c++/v1 -I 
/Users/aodwyer/llvm-project/build3/projects/libcxx/include/c++build -I 
/Users/aodwyer/llvm-project/libcxx/test/support -D _LIBCPP_DISABLE_AVAILABILITY 
-D _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -stdlib=libc++ -internal-isystem 
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/local/include 
-internal-isystem /Users/aodwyer/llvm-project/build3/lib/clang/15.0.0/include 
-internal-externc-isystem 
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include -Werror 
-Wall -Wextra -Wshadow -Wundef -Wno-unused-command-line-argument 
-Wno-attributes -Wno-pessimizing-move -Wno-c++11-extensions 
-Wno-user-defined-literals -Wno-noexcept-type -Wno-atomic-alignment 
-Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code 
-Wno-unused-local-typedef -Werror=thread-safety -Wuser-defined-warnings 
-std=c++20 -fdeprecated-macro 
-fdebug-compilation-dir=/Users/aodwyer/llvm-project/build3/projects/libcxx/test/std/ranges/range.access
 -ferror-limit 19 -stack-protector 1 -fblocks -fencode-extended-block-signature 
-fcoroutines-ts -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 
-fmodules -fimplicit-module-maps 
-fmodules-cache-path=/var/folders/0l/9t0yv2890_g4wgmy53n_mg7wgy/C/clang/ModuleCache
 -fmodules-validate-system-headers -fcxx-exceptions -fexceptions 
-fmax-type-align=16 -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o 
/var/folders/0l/9t0yv2890_g4wgmy53n_mg7wgy/T/lit-tmp-fkh9o_f4/rbegin-d58043.o
 -x c++ 
/Users/aodwyer/llvm-project/libcxx/test/std/ranges/range.access/rbegin.pass.cpp
  1.
/Users/aodwyer/llvm-project/libcxx/test/support/test_iterators.h:524:30: 
current parser token '{'
  Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH 
or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
  0  clang-14 0x00010634385d 
llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 61
  1  clang-14 0x000106343ddb 
PrintStackTraceSignalHandler(void*) + 27
  2  clang-14 0x000106341cfa llvm::sys::RunSignalHandlers() 
+ 138
  3  clang-14 0x0001063457af SignalHandler(int) + 223
  4  libsystem_platform.dylib 0x7fff677255fd _sigtramp + 29
  5  libsystem_platform.dylib 0x7ffeed912f58 _sigtramp + 
18446744071664753016
  6  libsystem_c.dylib0x7fff675fb808 abort + 120
  7  libsystem_c.dylib0x7fff675faac6 err + 0
  8  clang-14 0x00010b769ce1 
clang::ASTContext::getSubstTemplateTypeParmType(clang::TemplateTypeParmType 
const*, clang::QualType) const + 161
  9  clang-14 0x00010b1feb40 (anonymous 
namespace)::TemplateInstantiator::TransformTemplateTypeParmType(clang::TypeLocBuilder&,
 clang::TemplateTypeParmTypeLoc) + 1456
  10 clang-14 0x00010b1ba74f 
clang::TreeTransform<(anonymous 
namespace)::TemplateInstantiator>::TransformType(c

[PATCH] D119612: [clang] Pass more flags to ld64.lld

2022-02-16 Thread Nico Weber via Phabricator via cfe-commits
thakis added inline comments.



Comment at: clang/lib/Driver/ToolChains/Darwin.cpp:272
 
-  // ld64 version 262 and above run the deduplicate pass by default.
-  if (Version >= VersionTuple(262) && 
shouldLinkerNotDedup(C.getJobs().empty(), Args))
+  // ld64 version 262 and above and lld run the deduplicate pass by default.
+  if ((Version >= VersionTuple(262) || LinkerIsLLD) &&

MaskRay wrote:
> lld runs `--icf=none` (i.e. `-no_deduplicate`) by default.
Hm, good point. Should we pass `--icf=safe` for lld if `!shouldLinkerNotDedup` 
here then?



Comment at: clang/test/Driver/darwin-ld-dedup.c:4
+// -no_deduplicate is only present from ld64 version 262 and later, or lld.
+// RUN: %clang -target x86_64-apple-darwin10 -### -fuse-ld= %s \
 // RUN:   -mlinker-version=261 -O0 2>&1 | FileCheck -check-prefix=LINK_DEDUP %s

MaskRay wrote:
> If you are going to change the command line, prefer the canonical `--target=` 
> to the legacy `-target `.
"legacy" really has no semantic meaning here other than "I like that other 
spelling more". It's not like we're ever going to remove `-target`, it's way 
too actively used (see e.g. D119446 :P).

It seems like a change unrelated to what this patch is doing. If we want to 
change it, we can do it in a separate patch.


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

https://reviews.llvm.org/D119612

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


[PATCH] D119591: clang-analyzer plugins require LLVM_ENABLE_PLUGINS also

2022-02-16 Thread Jameson Nash via Phabricator via cfe-commits
vtjnash updated this revision to Diff 409241.
vtjnash added a comment.

add one more missing case to check


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119591

Files:
  clang/CMakeLists.txt
  clang/examples/AnnotateFunctions/CMakeLists.txt
  clang/examples/Attribute/CMakeLists.txt
  clang/examples/CMakeLists.txt
  clang/examples/CallSuperAttribute/CMakeLists.txt
  clang/examples/PluginsOrder/CMakeLists.txt
  clang/examples/PrintFunctionNames/CMakeLists.txt
  clang/lib/Analysis/plugins/CMakeLists.txt
  clang/test/CMakeLists.txt

Index: clang/test/CMakeLists.txt
===
--- clang/test/CMakeLists.txt
+++ clang/test/CMakeLists.txt
@@ -95,7 +95,7 @@
   )
 endif ()
 
-if (CLANG_BUILD_EXAMPLES)
+if(CLANG_BUILD_EXAMPLES AND CLANG_PLUGIN_SUPPORT)
   list(APPEND CLANG_TEST_DEPS
 Attribute
 AnnotateFunctions
@@ -145,8 +145,8 @@
   endif()
 endif()
 
-if (CLANG_ENABLE_STATIC_ANALYZER)
-  if (CLANG_PLUGIN_SUPPORT)
+if(CLANG_ENABLE_STATIC_ANALYZER)
+  if(CLANG_PLUGIN_SUPPORT AND LLVM_ENABLE_PLUGINS) # Determine if we built them
 list(APPEND CLANG_TEST_DEPS
   SampleAnalyzerPlugin
   CheckerDependencyHandlingAnalyzerPlugin
Index: clang/lib/Analysis/plugins/CMakeLists.txt
===
--- clang/lib/Analysis/plugins/CMakeLists.txt
+++ clang/lib/Analysis/plugins/CMakeLists.txt
@@ -1,4 +1,7 @@
-if(CLANG_ENABLE_STATIC_ANALYZER AND CLANG_PLUGIN_SUPPORT)
+# Since these do not specify a specific PLUGIN_TOOL (which could be clang or
+# clang-tidy), we cannot compile this unless the platform supports plugins with
+# undefined symbols, and cannot use it unless the user has opted for clang plugins).
+if(CLANG_ENABLE_STATIC_ANALYZER AND CLANG_PLUGIN_SUPPORT AND LLVM_ENABLE_PLUGINS)
   add_subdirectory(SampleAnalyzer)
   add_subdirectory(CheckerDependencyHandling)
   add_subdirectory(CheckerOptionHandling)
Index: clang/examples/PrintFunctionNames/CMakeLists.txt
===
--- clang/examples/PrintFunctionNames/CMakeLists.txt
+++ clang/examples/PrintFunctionNames/CMakeLists.txt
@@ -11,7 +11,7 @@
 
 add_llvm_library(PrintFunctionNames MODULE PrintFunctionNames.cpp PLUGIN_TOOL clang)
 
-if(CLANG_PLUGIN_SUPPORT AND (WIN32 OR CYGWIN))
+if(WIN32 OR CYGWIN)
   set(LLVM_LINK_COMPONENTS
 Support
   )
Index: clang/examples/PluginsOrder/CMakeLists.txt
===
--- clang/examples/PluginsOrder/CMakeLists.txt
+++ clang/examples/PluginsOrder/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_library(PluginsOrder MODULE PluginsOrder.cpp PLUGIN_TOOL clang)
 
-if(CLANG_PLUGIN_SUPPORT AND (WIN32 OR CYGWIN))
+if(WIN32 OR CYGWIN)
   set(LLVM_LINK_COMPONENTS
 Support
   )
Index: clang/examples/CallSuperAttribute/CMakeLists.txt
===
--- clang/examples/CallSuperAttribute/CMakeLists.txt
+++ clang/examples/CallSuperAttribute/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_library(CallSuperAttr MODULE CallSuperAttrInfo.cpp PLUGIN_TOOL clang)
 
-if(CLANG_PLUGIN_SUPPORT AND (WIN32 OR CYGWIN))
+if(WIN32 OR CYGWIN)
   set(LLVM_LINK_COMPONENTS
 Support
   )
Index: clang/examples/CMakeLists.txt
===
--- clang/examples/CMakeLists.txt
+++ clang/examples/CMakeLists.txt
@@ -3,8 +3,10 @@
   set(EXCLUDE_FROM_ALL ON)
 endif()
 
-add_subdirectory(PrintFunctionNames)
-add_subdirectory(AnnotateFunctions)
-add_subdirectory(Attribute)
-add_subdirectory(CallSuperAttribute)
-add_subdirectory(PluginsOrder)
+if(CLANG_PLUGIN_SUPPORT)
+  add_subdirectory(PrintFunctionNames)
+  add_subdirectory(AnnotateFunctions)
+  add_subdirectory(Attribute)
+  add_subdirectory(CallSuperAttribute)
+  add_subdirectory(PluginsOrder)
+endif()
Index: clang/examples/Attribute/CMakeLists.txt
===
--- clang/examples/Attribute/CMakeLists.txt
+++ clang/examples/Attribute/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_library(Attribute MODULE Attribute.cpp PLUGIN_TOOL clang)
 
-if(CLANG_PLUGIN_SUPPORT AND (WIN32 OR CYGWIN))
+if(WIN32 OR CYGWIN)
   target_link_libraries(Attribute PRIVATE
 clangAST
 clangBasic
Index: clang/examples/AnnotateFunctions/CMakeLists.txt
===
--- clang/examples/AnnotateFunctions/CMakeLists.txt
+++ clang/examples/AnnotateFunctions/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_library(AnnotateFunctions MODULE AnnotateFunctions.cpp PLUGIN_TOOL clang)
 
-if(CLANG_PLUGIN_SUPPORT AND (WIN32 OR CYGWIN))
+if(WIN32 OR CYGWIN)
   set(LLVM_LINK_COMPONENTS
 Support
   )
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -476,

[PATCH] D119591: clang-analyzer plugins require LLVM_ENABLE_PLUGINS also

2022-02-16 Thread Jameson Nash via Phabricator via cfe-commits
vtjnash added a comment.

Okay, this should work now for those cases! Sorry, I kept thinking it was 
clang/examples that was broken, and missed that it was clang/test that was 
failing, so I failed to see what I needed to fix there too, so that we were not 
trying to build the tests in configurations where the functionality is disabled.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119591

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


[PATCH] D119612: [clang] Pass more flags to ld64.lld

2022-02-16 Thread Nico Weber via Phabricator via cfe-commits
thakis updated this revision to Diff 409243.
thakis added a comment.

undo no_deduplicate bit again for now


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

https://reviews.llvm.org/D119612

Files:
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/Driver/darwin-ld-lto.c
  clang/test/Driver/darwin-ld.c


Index: clang/test/Driver/darwin-ld.c
===
--- clang/test/Driver/darwin-ld.c
+++ clang/test/Driver/darwin-ld.c
@@ -236,6 +236,9 @@
 // RUN: %clang -target x86_64-apple-darwin12 -rdynamic -### %t.o \
 // RUN:   -fuse-ld= -mlinker-version=137 2> %t.log
 // RUN: FileCheck -check-prefix=LINK_EXPORT_DYNAMIC %s < %t.log
+// RUN: %clang -target x86_64-apple-darwin12 -rdynamic -### %t.o \
+// RUN:   -fuse-ld=lld -mlinker-version=100 2> %t.log
+// RUN: FileCheck -check-prefix=LINK_EXPORT_DYNAMIC %s < %t.log
 // LINK_EXPORT_DYNAMIC: {{ld(.exe)?"}}
 // LINK_EXPORT_DYNAMIC: "-export_dynamic"
 
Index: clang/test/Driver/darwin-ld-lto.c
===
--- clang/test/Driver/darwin-ld-lto.c
+++ clang/test/Driver/darwin-ld-lto.c
@@ -20,13 +20,17 @@
 
 
 // Check that -object_lto_path is passed correctly to ld64
-// RUN: %clang -target x86_64-apple-darwin10 %s -flto=full -### 2>&1 | \
-// RUN:   FileCheck -check-prefix=FULL_LTO_OBJECT_PATH %s
+// RUN: %clang -fuse-ld= -target x86_64-apple-darwin10 %s -flto=full -### \
+// RUN: 2>&1 | FileCheck -check-prefix=FULL_LTO_OBJECT_PATH %s
+// RUN: %clang -fuse-ld=lld -target x86_64-apple-darwin10 %s -flto=full -### \
+// RUN: 2>&1 | FileCheck -check-prefix=FULL_LTO_OBJECT_PATH %s
 // FULL_LTO_OBJECT_PATH: {{ld(.exe)?"}}
 // FULL_LTO_OBJECT_PATH-SAME: "-object_path_lto"
 // FULL_LTO_OBJECT_PATH-SAME: {{cc\-[a-zA-Z0-9_]+.o}}"
-// RUN: %clang -target x86_64-apple-darwin10 %s -flto=thin -### 2>&1 | \
-// RUN:   FileCheck -check-prefix=THIN_LTO_OBJECT_PATH %s
+// RUN: %clang -fuse-ld= -target x86_64-apple-darwin10 %s -flto=thin -### \
+// RUN: 2>&1 | FileCheck -check-prefix=THIN_LTO_OBJECT_PATH %s
+// RUN: %clang -fuse-ld=lld -target x86_64-apple-darwin10 %s -flto=thin -### \
+// RUN: 2>&1 | FileCheck -check-prefix=THIN_LTO_OBJECT_PATH %s
 // THIN_LTO_OBJECT_PATH: {{ld(.exe)?"}}
 // THIN_LTO_OBJECT_PATH-SAME: "-object_path_lto"
 // THIN_LTO_OBJECT_PATH-SAME: {{thinlto\-[a-zA-Z0-9_]+}}
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -219,9 +219,8 @@
   !Args.hasArg(options::OPT_Z_Xlinker__no_demangle))
 CmdArgs.push_back("-demangle");
 
-  // FIXME: Pass most of the flags below that check Version if LinkerIsLLD too.
-
-  if (Args.hasArg(options::OPT_rdynamic) && Version >= VersionTuple(137))
+  if (Args.hasArg(options::OPT_rdynamic) &&
+  (Version >= VersionTuple(137) || LinkerIsLLD))
 CmdArgs.push_back("-export_dynamic");
 
   // If we are using App Extension restrictions, pass a flag to the linker
@@ -230,7 +229,8 @@
options::OPT_fno_application_extension, false))
 CmdArgs.push_back("-application_extension");
 
-  if (D.isUsingLTO() && Version >= VersionTuple(116) && NeedsTempPath(Inputs)) 
{
+  if (D.isUsingLTO() && (Version >= VersionTuple(116) || LinkerIsLLD) &&
+  NeedsTempPath(Inputs)) {
 std::string TmpPathName;
 if (D.getLTOMode() == LTOK_Full) {
   // If we are using full LTO, then automatically create a temporary file
@@ -269,8 +269,11 @@
 CmdArgs.push_back(C.getArgs().MakeArgString(LibLTOPath));
   }
 
-  // ld64 version 262 and above run the deduplicate pass by default.
-  if (Version >= VersionTuple(262) && 
shouldLinkerNotDedup(C.getJobs().empty(), Args))
+  // ld64 version 262 and above runs the deduplicate pass by default.
+  // FIXME: lld doesn't dedup by default. Should we pass `--icf=safe`
+  //if `!shouldLinkerNotDedup()` if LinkerIsLLD here?
+  if (Version >= VersionTuple(262) &&
+  shouldLinkerNotDedup(C.getJobs().empty(), Args))
 CmdArgs.push_back("-no_deduplicate");
 
   // Derived from the "link" spec.
@@ -368,6 +371,7 @@
 // Check if the toolchain supports bitcode build flow.
 if (MachOTC.SupportsEmbeddedBitcode()) {
   CmdArgs.push_back("-bitcode_bundle");
+  // FIXME: Pass this if LinkerIsLLD too, once it implements this flag.
   if (C.getDriver().embedBitcodeMarkerOnly() &&
   Version >= VersionTuple(278)) {
 CmdArgs.push_back("-bitcode_process_mode");


Index: clang/test/Driver/darwin-ld.c
===
--- clang/test/Driver/darwin-ld.c
+++ clang/test/Driver/darwin-ld.c
@@ -236,6 +236,9 @@
 // RUN: %clang -target x86_64-apple-darwin12 -rdynamic -### %t.o \
 // RUN:   -fuse-ld= -mlinker-version=137 2> %t.log
 // RUN: FileCheck -check-prefix=LINK_EXPORT_DYNAMIC %s < %t.log
+// RUN: %clang -targ

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

2022-02-16 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius accepted this revision.
curdeius added a comment.

In D119893#3326247 , 
@HazardyKnusperkeks wrote:

> Formatting Test added.

Thanks!


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] D119612: [clang] Pass more flags to ld64.lld

2022-02-16 Thread Nico Weber via Phabricator via cfe-commits
thakis updated this revision to Diff 409254.
thakis added a comment.

Pass `-B` with `-fuse-ld=lld` since the latter flag only has an effect if 
ld64.lld exists on disk, and clang/test doesn't depend on lld (and shouldn't).

Also move object_path_lto to its own file since it can run fine on non-darwin 
hosts.


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

https://reviews.llvm.org/D119612

Files:
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/Driver/darwin-ld-lto-lld.c
  clang/test/Driver/darwin-ld-lto.c
  clang/test/Driver/darwin-ld.c

Index: clang/test/Driver/darwin-ld.c
===
--- clang/test/Driver/darwin-ld.c
+++ clang/test/Driver/darwin-ld.c
@@ -236,6 +236,9 @@
 // RUN: %clang -target x86_64-apple-darwin12 -rdynamic -### %t.o \
 // RUN:   -fuse-ld= -mlinker-version=137 2> %t.log
 // RUN: FileCheck -check-prefix=LINK_EXPORT_DYNAMIC %s < %t.log
+// RUN: %clang -target x86_64-apple-darwin12 -rdynamic -### %t.o \
+// RUN:   -fuse-ld=lld -B%S/Inputs/lld -mlinker-version=100 2> %t.log
+// RUN: FileCheck -check-prefix=LINK_EXPORT_DYNAMIC %s < %t.log
 // LINK_EXPORT_DYNAMIC: {{ld(.exe)?"}}
 // LINK_EXPORT_DYNAMIC: "-export_dynamic"
 
Index: clang/test/Driver/darwin-ld-lto.c
===
--- clang/test/Driver/darwin-ld-lto.c
+++ clang/test/Driver/darwin-ld-lto.c
@@ -20,13 +20,13 @@
 
 
 // Check that -object_lto_path is passed correctly to ld64
-// RUN: %clang -target x86_64-apple-darwin10 %s -flto=full -### 2>&1 | \
-// RUN:   FileCheck -check-prefix=FULL_LTO_OBJECT_PATH %s
+// RUN: %clang -fuse-ld= -target x86_64-apple-darwin10 %s -flto=full -### 2>&1 \
+// RUN: | FileCheck -check-prefix=FULL_LTO_OBJECT_PATH %s
 // FULL_LTO_OBJECT_PATH: {{ld(.exe)?"}}
 // FULL_LTO_OBJECT_PATH-SAME: "-object_path_lto"
 // FULL_LTO_OBJECT_PATH-SAME: {{cc\-[a-zA-Z0-9_]+.o}}"
-// RUN: %clang -target x86_64-apple-darwin10 %s -flto=thin -### 2>&1 | \
-// RUN:   FileCheck -check-prefix=THIN_LTO_OBJECT_PATH %s
+// RUN: %clang -fuse-ld= -target x86_64-apple-darwin10 %s -flto=thin -### 2>&1 \
+// RUN: | FileCheck -check-prefix=THIN_LTO_OBJECT_PATH %s
 // THIN_LTO_OBJECT_PATH: {{ld(.exe)?"}}
 // THIN_LTO_OBJECT_PATH-SAME: "-object_path_lto"
 // THIN_LTO_OBJECT_PATH-SAME: {{thinlto\-[a-zA-Z0-9_]+}}
Index: clang/test/Driver/darwin-ld-lto-lld.c
===
--- /dev/null
+++ clang/test/Driver/darwin-ld-lto-lld.c
@@ -0,0 +1,19 @@
+// REQUIRES: shell
+
+// Check that lld gets "-lto_library".
+// (Separate test file since darwin-ld-lto requires system-darwin but this
+// test doesn't require that.)
+
+// Check that -object_lto_path is passed correctly to ld64
+// RUN: %clang -fuse-ld=lld -B%S/Inputs/lld -target x86_64-apple-darwin10 \
+// RUN: %s -flto=full -### 2>&1 \
+// RUN: | FileCheck -check-prefix=FULL_LTO_OBJECT_PATH %s
+// FULL_LTO_OBJECT_PATH: {{ld(.exe)?"}}
+// FULL_LTO_OBJECT_PATH-SAME: "-object_path_lto"
+// FULL_LTO_OBJECT_PATH-SAME: {{cc\-[a-zA-Z0-9_]+.o}}"
+// RUN: %clang -fuse-ld=lld -B%S/Inputs/lld -target x86_64-apple-darwin10 \
+// RUN: %s -flto=thin -### 2>&1 \
+// RUN: | FileCheck -check-prefix=THIN_LTO_OBJECT_PATH %s
+// THIN_LTO_OBJECT_PATH: {{ld(.exe)?"}}
+// THIN_LTO_OBJECT_PATH-SAME: "-object_path_lto"
+// THIN_LTO_OBJECT_PATH-SAME: {{thinlto\-[a-zA-Z0-9_]+}}
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -219,9 +219,8 @@
   !Args.hasArg(options::OPT_Z_Xlinker__no_demangle))
 CmdArgs.push_back("-demangle");
 
-  // FIXME: Pass most of the flags below that check Version if LinkerIsLLD too.
-
-  if (Args.hasArg(options::OPT_rdynamic) && Version >= VersionTuple(137))
+  if (Args.hasArg(options::OPT_rdynamic) &&
+  (Version >= VersionTuple(137) || LinkerIsLLD))
 CmdArgs.push_back("-export_dynamic");
 
   // If we are using App Extension restrictions, pass a flag to the linker
@@ -230,7 +229,8 @@
options::OPT_fno_application_extension, false))
 CmdArgs.push_back("-application_extension");
 
-  if (D.isUsingLTO() && Version >= VersionTuple(116) && NeedsTempPath(Inputs)) {
+  if (D.isUsingLTO() && (Version >= VersionTuple(116) || LinkerIsLLD) &&
+  NeedsTempPath(Inputs)) {
 std::string TmpPathName;
 if (D.getLTOMode() == LTOK_Full) {
   // If we are using full LTO, then automatically create a temporary file
@@ -269,8 +269,11 @@
 CmdArgs.push_back(C.getArgs().MakeArgString(LibLTOPath));
   }
 
-  // ld64 version 262 and above run the deduplicate pass by default.
-  if (Version >= VersionTuple(262) && shouldLinkerNotDedup(C.getJobs().empty(), Args))
+  // ld64 version 262 and above runs the deduplicate pass by default.
+  // FIXME: lld doesn't dedup by default. Should we pass `--icf=safe`
+  //

[clang] 597f2bc - [clang] [test] [NFC] Eliminate some hard tabs in tests

2022-02-16 Thread Arthur O'Dwyer via cfe-commits

Author: Arthur O'Dwyer
Date: 2022-02-16T10:42:58-05:00
New Revision: 597f2bcee895c1a9cc18067b85d6846137c11816

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

LOG: [clang] [test] [NFC] Eliminate some hard tabs in tests

"cxx2b-consteval-if.cpp" was showing up misindented.

Added: 


Modified: 
clang/test/SemaCXX/cxx2b-consteval-if.cpp
clang/test/SemaCXX/typo-correction-cxx17.cpp
clang/test/SemaCXX/warn-static-function-inheader.cpp

Removed: 




diff  --git a/clang/test/SemaCXX/cxx2b-consteval-if.cpp 
b/clang/test/SemaCXX/cxx2b-consteval-if.cpp
index ca65f2733fc1d..68921b3852f22 100644
--- a/clang/test/SemaCXX/cxx2b-consteval-if.cpp
+++ b/clang/test/SemaCXX/cxx2b-consteval-if.cpp
@@ -19,9 +19,9 @@ constexpr auto h() {
 constexpr auto i() {
   if consteval {
 if consteval { // expected-warning {{consteval if is always true in an 
immediate context}}
- return 1;
-   }
-   return 2;
+  return 1;
+}
+return 2;
   } else {
 return 1.0; // expected-error {{'auto' in return type deduced as 'double' 
here but deduced as 'int' in earlier return statement}}
   }

diff  --git a/clang/test/SemaCXX/typo-correction-cxx17.cpp 
b/clang/test/SemaCXX/typo-correction-cxx17.cpp
index f137499753422..d6a8994f74e13 100644
--- a/clang/test/SemaCXX/typo-correction-cxx17.cpp
+++ b/clang/test/SemaCXX/typo-correction-cxx17.cpp
@@ -2,6 +2,6 @@
 
 namespace decomp_decl {
 void f() {
-   auto [this_is_a_typo] = this_is_a_typp(); // expected-error{{use of 
undeclared identifier 'this_is_a_typp'}}
+  auto [this_is_a_typo] = this_is_a_typp(); // expected-error{{use of 
undeclared identifier 'this_is_a_typp'}}
 }
 }

diff  --git a/clang/test/SemaCXX/warn-static-function-inheader.cpp 
b/clang/test/SemaCXX/warn-static-function-inheader.cpp
index 30386d9a258c8..9eccfca933c78 100644
--- a/clang/test/SemaCXX/warn-static-function-inheader.cpp
+++ b/clang/test/SemaCXX/warn-static-function-inheader.cpp
@@ -7,6 +7,6 @@ static void another(void) { // expected-warning {{function 
'another' is not need
 
 template 
 void foo(void) {
-thing();
-   another();
+  thing();
+  another();
 }



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


[PATCH] D119926: [Clang][AArch64] Enable _Float16 _Complex type

2022-02-16 Thread Peter Waller via Phabricator via cfe-commits
peterwaller-arm accepted this revision.
peterwaller-arm added a comment.
This revision is now accepted and ready to land.

LGTM.




Comment at: clang/test/CodeGen/aarch64-complex-half-math.c:5
+  // AARCH64-LABEL: @add_float_rr(
+  // AARCH64: fadd reassoc nnan ninf nsz arcp afn half
+  // AARCH64-NOT: fadd

peterwaller-arm wrote:
> My read is that this appears to be testing both -ffast-math and _Float16. Do 
> we want to be testing both these things at once like this, can anyone comment?
> 
> My preference would be to have these test only the operators, and not the 
> flags, and then maybe have a single test which does
> https://clang.llvm.org/docs/LanguageExtensions.html#extensions-to-specify-floating-point-flags
> ```
> #pragma clang fp contract(fast)
> ```
> 
> and verifies that the flags are present.
> 
Discussed off-review: concluded for now that a no-optimizations test with no 
fast math flags seems reasonable, to address @fhahn's comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119926

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


[PATCH] D28213: [Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin

2022-02-16 Thread Kai Luo via Phabricator via cfe-commits
lkail added a comment.

Hi, is this patch ready to land?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D28213

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


[PATCH] D119949: [Clang-tidy] Check the existence of ElaboratedType's qualifiers

2022-02-16 Thread Jun Zhang via Phabricator via cfe-commits
junaire created this revision.
junaire added reviewers: aaron.ballman, alexfh.
Herald added subscribers: carlosgalvezp, xazax.hun.
junaire requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

The ElaboratedType can have no qualifiers, so we should check it before
use.

Fix #issue53874(https://github.com/llvm/llvm-project/issues/53874)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D119949

Files:
  
clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
  
clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp


Index: 
clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp
===
--- 
clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp
+++ 
clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp
@@ -197,6 +197,15 @@
 
   h<4>();
 }
+struct SP {
+  static int I;
+} P;
+
+void usep() {
+  P.I;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: static member
+  // CHECK-FIXES: {{^}}  struct SP::I;{{$}}
+}
 
 // Overloaded member access operator
 struct Q {
Index: 
clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
===
--- 
clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
+++ 
clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
@@ -19,14 +19,15 @@
 
 static unsigned getNameSpecifierNestingLevel(const QualType &QType) {
   if (const ElaboratedType *ElType = QType->getAs()) {
-const NestedNameSpecifier *NestedSpecifiers = ElType->getQualifier();
-unsigned NameSpecifierNestingLevel = 1;
-do {
-  NameSpecifierNestingLevel++;
-  NestedSpecifiers = NestedSpecifiers->getPrefix();
-} while (NestedSpecifiers);
-
-return NameSpecifierNestingLevel;
+if (const NestedNameSpecifier *NestedSpecifiers = ElType->getQualifier()) {
+  unsigned NameSpecifierNestingLevel = 1;
+  do {
+NameSpecifierNestingLevel++;
+NestedSpecifiers = NestedSpecifiers->getPrefix();
+  } while (NestedSpecifiers);
+
+  return NameSpecifierNestingLevel;
+}
   }
   return 0;
 }


Index: clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/readability-static-accessed-through-instance.cpp
@@ -197,6 +197,15 @@
 
   h<4>();
 }
+struct SP {
+  static int I;
+} P;
+
+void usep() {
+  P.I;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: static member
+  // CHECK-FIXES: {{^}}  struct SP::I;{{$}}
+}
 
 // Overloaded member access operator
 struct Q {
Index: clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
===
--- clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
+++ clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
@@ -19,14 +19,15 @@
 
 static unsigned getNameSpecifierNestingLevel(const QualType &QType) {
   if (const ElaboratedType *ElType = QType->getAs()) {
-const NestedNameSpecifier *NestedSpecifiers = ElType->getQualifier();
-unsigned NameSpecifierNestingLevel = 1;
-do {
-  NameSpecifierNestingLevel++;
-  NestedSpecifiers = NestedSpecifiers->getPrefix();
-} while (NestedSpecifiers);
-
-return NameSpecifierNestingLevel;
+if (const NestedNameSpecifier *NestedSpecifiers = ElType->getQualifier()) {
+  unsigned NameSpecifierNestingLevel = 1;
+  do {
+NameSpecifierNestingLevel++;
+NestedSpecifiers = NestedSpecifiers->getPrefix();
+  } while (NestedSpecifiers);
+
+  return NameSpecifierNestingLevel;
+}
   }
   return 0;
 }
___
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

2022-02-16 Thread 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, with or without the -lm lookup




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 &I : llvm::make_range(OpenMPTCRange.first, OpenMPTCRange.second)) {

arsenm wrote:
> jhuber6 wrote:
> > 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.
> It can be subtley wrong, and also pushes reliance on setting the global 
> subtarget. It's best to ensure the default attributes are propagated to the 
> device libraries
We will build a better solution for this soon, for now this is "good enough".


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] D119823: [Modules] Add module structure output to -module-file-info.

2022-02-16 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan added inline comments.



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

iains wrote:
> urnathan wrote:
> > urnathan wrote:
> > > ChuanqiXu wrote:
> > > > iains wrote:
> > > > > ChuanqiXu wrote:
> > > > > > 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?
> > > > > I see this in the Tony tables, but OTOH I cannot exactly see where 
> > > > > the wording forbids it - in fact it permits preprocesssor directives 
> > > > > before the import (including in the example in 5.7)... perhaps I'm 
> > > > > misreading.
> > > > > 
> > > > > This way of writing the test cases does make them much easier to 
> > > > > manage (and for a reader to see the intent) - of course, if we should 
> > > > > split into files - then that is what we should do.
> > > > > 
> > > > I think the grammar in [[ http://eel.is/c++draft/cpp | [cpp.pre] ]] 
> > > > forbid it.
> > > > 
> > > > First, the file could only be:
> > > > ```
> > > > preprocessing-file:
> > > > group_opt
> > > > module-file
> > > > ```
> > > > 
> > > > Then it is clear that we couldn't put macro declarative before module 
> > > > declaration. I agree the current style is easier and more convenient. 
> > > > In fact, I prefer it too. But I think we would better follow it since 
> > > > it is standard. Otherwise, it would be more work in later maintenance 
> > > > stage.
> > > ChuanqiXu is correct about preprocessor directives not being allowed 
> > > before the initial module decl, but I don;t think compilers implement 
> > > that.  There are a couple of issues.
> > > 
> > > a) some users have a need to have #pragma charset-or-similar before any 
> > > tokens
> > > b) forced headers
> > > 
> > > I do find the #if use here somewhat confusing.  A bunch of 
> > > cxx20-file-info-[1-n].cpp might be more straightforwards?  (It does seem 
> > > that directory is using cxx20 as a prefix rather than suffix btw.)
> > or maybe splitting this up make it harder to understand the tests as a 
> > whole.  I don;t think it terribly importand.  If we do ban pre-module 
> > directives, we can always split it then,
> OK ( actually, I find it easier to grok the test case intent if the various 
> required inputs are built in order, in the single file - but that's the 
> nature of preferences :) )
> 
> I suppose that (a) and (b) mean that we cannot reasonably diagnose this?
> 
> Probably some of the files (e.g. ones making dummy modules to be consumed by 
> the actual tests) could be in 'Inputs'.  Will rework this accordingly.

> I suppose that (a) and (b) mean that we cannot reasonably diagnose this?

The #pragma item came up in stdization and IIRC there was some handwaving that 
such a pragma is not actually in the source text -- because it's telling you 
something about the encoding.  One could probably make a similar argument about 
forced headers -- they're implementation detail (that the user might be able to 
control).

Anyway, IMHO this is orthogonal, and we might even be able to deploy something 
like:
```
#pragma GCC system_header
#look ma! random directive
module;
```
if we do start being pickier.


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] D118598: [C++20][Modules][7/8] Find the primary interface name for a module.

2022-02-16 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan added inline comments.



Comment at: clang/include/clang/Basic/Module.h:520-522
+  /// Get the primary module interface name from a partition.
+
+  std::string getPrimaryModuleInterfaceName() const {

stray blank line?



Comment at: clang/include/clang/Basic/Module.h:523-524
+  std::string getPrimaryModuleInterfaceName() const {
+std::string::size_type pos = Name.find(':');
+if (pos == std::string::npos)
+  return Name;

haven't you added an IsPartition flag to Module? can't you test that before 
searching? Also, Almost Always Auto?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118598

___
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

2022-02-16 Thread Adrian Prantl via Phabricator via cfe-commits
aprantl added a comment.

In D119850#3326266 , @thakis wrote:

> (I wish there was a flag that said "clang, never ever read any env vars 
> please". Some people think that builds should be deterministic and not depend 
> on random env vars people might have set (and then not do correct incremental 
> rebuilds when the value of such env var flags change). But given that clang 
> already reads a whole bunch of such env vars and we can always add such a 
> flag later, I suppose this change doesn't make things that much worse.)

These are all good points. The environment variables are useful to side-step 
the many project-specific build systems that you have to deal with when 
building an entire OS and this is also the primary use-case here.


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


[clang] 0604d86 - Darwin: introduce a global override for debug prefix map entries.

2022-02-16 Thread Adrian Prantl via cfe-commits

Author: Adrian Prantl
Date: 2022-02-16T08:36:26-08:00
New Revision: 0604d86c07ab8a28b95df689aff4ddd26347f35f

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

LOG: Darwin: introduce a global override for debug prefix map entries.

This patch adds a new Darwin clang driver environment variable in the
spirit of RC_DEBUG_OPTIONS, called RC_DEBUG_PREFIX_MAP, which allows a
meta build tool to add one additional -fdebug-prefix-map entry without
the knowledge of the build system.

rdar://85224675

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

Added: 
clang/test/Driver/darwin-debug-prefix-map.c
clang/test/Driver/darwin-debug-prefix-map.s

Modified: 
clang/include/clang/Driver/ToolChain.h
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/Darwin.cpp
clang/lib/Driver/ToolChains/Darwin.h

Removed: 




diff  --git a/clang/include/clang/Driver/ToolChain.h 
b/clang/include/clang/Driver/ToolChain.h
index bfc46af002657..adf1753e8d3a6 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -513,6 +513,9 @@ class ToolChain {
   /// compile unit information.
   virtual bool UseDwarfDebugFlags() const { return false; }
 
+  /// Add an additional -fdebug-prefix-map entry.
+  virtual std::string GetGlobalDebugPathRemapping() const { return {}; }
+  
   // Return the DWARF version to emit, in the absence of arguments
   // to the contrary.
   virtual unsigned GetDefaultDwarfVersion() const { return 5; }

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 945f626977799..de289683596be 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -668,17 +668,24 @@ static void addDebugObjectName(const ArgList &Args, 
ArgStringList &CmdArgs,
 }
 
 /// Add a CC1 and CC1AS option to specify the debug file path prefix map.
-static void addDebugPrefixMapArg(const Driver &D, const ArgList &Args, 
ArgStringList &CmdArgs) {
-  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 &D, const ToolChain &TC,
+ const ArgList &Args, ArgStringList &CmdArgs) {
+  auto AddOneArg = [&](StringRef Map, StringRef Name) {
 if (!Map.contains('='))
-  D.Diag(diag::err_drv_invalid_argument_to_option)
-  << Map << A->getOption().getName();
+  D.Diag(diag::err_drv_invalid_argument_to_option) << 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 +5724,7 @@ void Clang::ConstructJob(Compilation &C, const JobAction 
&JA,
   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 +7792,8 @@ void ClangAs::ConstructJob(Compilation &C, const 
JobAction &JA,
 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.

diff  --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index 3c408010b5b19..dc75b2b4621bb 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -2843,6 +2843,12 @@ bool MachO::UseDwarfDebugFlags() const {
   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 &Args) const {
   // Darwin uses SjLj exceptions on ARM.
   if (getTriple().getArch() != llvm::Triple::arm &&

diff  --git a/clang/lib/Driver/ToolChains/Darwin.h 

  1   2   >