[PATCH] D99278: [clang][parser] Allow GNU-style attributes in struct declarations

2021-03-29 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added a comment.

This (and https://reviews.llvm.org/D99338) are both NFC changes once 
https://reviews.llvm.org/D97362 lands (they need the three-parameter version of 
`ProhibitCXX11Attributes()`). I can merge the three into one patch if you 
prefer.


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

https://reviews.llvm.org/D99278

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


[PATCH] D98783: [CUDA][HIP] Remove unused addr space casts

2021-03-29 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

In D98783#2642269 , @tra wrote:

> We may want to add someone with more expertise with the IR as a reviewer. I'd 
> like an educated opinion on whether the invisible dangling IR is something 
> that needs fixing in general or if it's OK to just clean it up in this 
> particular case. Or both.
>
> @rjmccall, @rsmith -- do you have any suggestions -- either on the subject of 
> the invisible dangling IR or on who may be the right person to talk to?

If Clang is creating constants unnecessarily, we should try to avoid that on 
general compile time / memory usage grounds unless doing so is a serious 
problem.  But I don't think it should be our responsibility to GC unused 
constant expressions in order to make DCE work.

It's extremely common to create `bitcast` global constants.  So the fact that 
this happens with `addrspacecast`s but hasn't been a persistent problem with 
`bitcast`s makes more suspect that DCE actually tries to handle this, but 
something about what it's doing isn't aware of `addrspacecast`.  And indeed, 
LLVM's GlobalDCE seems to call a method called `removeDeadConstantUsers()` 
before concluding that a constant can't be thrown away.  So either you're using 
a different transform that needs to do the same thing, or something is stopping 
`removeDeadConstantUsers()` from eliminating this `addrspacecast`.


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

https://reviews.llvm.org/D98783

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


[PATCH] D99489: [clang] [PR49736] [C++2b] Correctly reject lambdas with requires clause and no parameter list

2021-03-29 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

Only a nit, please go ahead once Aaron is happy :)




Comment at: clang/test/Parser/cxx2a-template-lambdas.cpp:25-29
+auto L11 = [] requires true(){};
+auto L12 = [] requires true() noexcept {};
+auto L13 = [] requires true() noexcept requires true {};
+auto L14 = []() noexcept requires true {};
+auto L15 = [] requires true(){};

I'd find these examples easier to read with a space between `true` and `()`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99489

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


[PATCH] D71726: Let clang atomic builtins fetch add/sub support floating point types

2021-03-29 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:5011
+!ValType->isFloatingType()) {
+  Diag(ExprRange.getBegin(), 
diag::err_atomic_op_needs_atomic_int_ptr_or_fp)
   << IsC11 << Ptr->getType() << Ptr->getSourceRange();

Does LLVM support atomics on all floating-point types?


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

https://reviews.llvm.org/D71726

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


[PATCH] D99456: [C++2b] Support size_t literals

2021-03-29 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: clang/lib/Lex/LiteralSupport.cpp:640
 isFloat16 = true;
 continue;
   }

Looks like this might fix [[ https://godbolt.org/z/9Pe4qr1c7 | incorrect 
acceptance ]] of `1.0f16f` and `1.0f16L` in CUDA mode too :)



Comment at: clang/lib/Sema/SemaExpr.cpp:3920-3927
+if (ResultVal.isIntN(SizeTSize)) {
+  // Does it fit in a ssize_t?
+  if (!Literal.isUnsigned && ResultVal[SizeTSize - 1] == 0)
+Ty = Context.getSignedSizeType();
+  else if (AllowUnsigned)
+Ty = Context.getSizeType();
+  Width = SizeTSize;

I'd like to see some test coverage for this, particularly the testing of the 
high bit to determine if we're forming a signed or unsigned literal.



Comment at: clang/lib/Sema/SemaExpr.cpp:3975
   // Check long long if needed.
   if (Ty.isNull()) {
 unsigned LongLongSize = Context.getTargetInfo().getLongLongWidth();

rsmith wrote:
> Likewise here -- and this one actually does matter, because we have targets 
> with a 32-bit `size_t` but a 64-bit `long long`.
Can we get a test for this case? (Eg, `5'000'000'000z` with `-triple 
i686-linux`.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99456

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


[PATCH] D95984: [CodeGen] Fix codegen for __attribute__((swiftasynccall)).

2021-03-29 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:1240
+  if (auto *CE = dyn_cast(RV))
+::makeTailCallIfSwiftAsync(CE, Builder, CurFnInfo);
+}

What's with the explicit `::` here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95984

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


[PATCH] D91327: [NewPM] Redesign of PreserveCFG Checker

2021-03-29 Thread Yevgeny Rouban via Phabricator via cfe-commits
yrouban updated this revision to Diff 334042.
yrouban added a comment.

fixed the nits


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

https://reviews.llvm.org/D91327

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/Passes/StandardInstrumentations.h
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/Passes/StandardInstrumentations.cpp
  llvm/test/Other/loop-pm-invalidation.ll
  llvm/test/Other/new-pass-manager.ll
  llvm/test/Other/new-pm-O0-defaults.ll
  llvm/test/Other/new-pm-defaults.ll
  llvm/test/Other/new-pm-lto-defaults.ll
  llvm/test/Other/new-pm-thinlto-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-samplepgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
  llvm/test/Transforms/LoopRotate/pr35210.ll
  llvm/test/Transforms/SCCP/ipsccp-preserve-analysis.ll
  llvm/tools/opt/NewPMDriver.cpp
  llvm/unittests/IR/PassManagerTest.cpp

Index: llvm/unittests/IR/PassManagerTest.cpp
===
--- llvm/unittests/IR/PassManagerTest.cpp
+++ llvm/unittests/IR/PassManagerTest.cpp
@@ -827,7 +827,7 @@
   FunctionPassManager FPM(/*DebugLogging*/ true);
   PassInstrumentationCallbacks PIC;
   StandardInstrumentations SI(/*DebugLogging*/ true);
-  SI.registerCallbacks(PIC);
+  SI.registerCallbacks(PIC, );
   FAM.registerPass([&] { return PassInstrumentationAnalysis(); });
   FAM.registerPass([&] { return DominatorTreeAnalysis(); });
   FAM.registerPass([&] { return AssumptionAnalysis(); });
@@ -873,7 +873,7 @@
   FunctionPassManager FPM(/*DebugLogging*/ true);
   PassInstrumentationCallbacks PIC;
   StandardInstrumentations SI(/*DebugLogging*/ true);
-  SI.registerCallbacks(PIC);
+  SI.registerCallbacks(PIC, );
   FAM.registerPass([&] { return PassInstrumentationAnalysis(); });
   FAM.registerPass([&] { return DominatorTreeAnalysis(); });
   FAM.registerPass([&] { return AssumptionAnalysis(); });
@@ -938,7 +938,7 @@
   FunctionPassManager FPM(/*DebugLogging*/ true);
   PassInstrumentationCallbacks PIC;
   StandardInstrumentations SI(/*DebugLogging*/ true);
-  SI.registerCallbacks(PIC);
+  SI.registerCallbacks(PIC, );
   FAM.registerPass([&] { return PassInstrumentationAnalysis(); });
   FAM.registerPass([&] { return DominatorTreeAnalysis(); });
   FAM.registerPass([&] { return AssumptionAnalysis(); });
Index: llvm/tools/opt/NewPMDriver.cpp
===
--- llvm/tools/opt/NewPMDriver.cpp
+++ llvm/tools/opt/NewPMDriver.cpp
@@ -275,9 +275,14 @@
   P->CSAction = PGOOptions::CSIRUse;
 }
   }
+  LoopAnalysisManager LAM(DebugPM);
+  FunctionAnalysisManager FAM(DebugPM);
+  CGSCCAnalysisManager CGAM(DebugPM);
+  ModuleAnalysisManager MAM(DebugPM);
+
   PassInstrumentationCallbacks PIC;
   StandardInstrumentations SI(DebugPM, VerifyEachPass);
-  SI.registerCallbacks(PIC);
+  SI.registerCallbacks(PIC, );
   DebugifyEachInstrumentation Debugify;
   if (DebugifyEach)
 Debugify.registerCallbacks(PIC);
@@ -373,11 +378,6 @@
 }
   }
 
-  LoopAnalysisManager LAM(DebugPM);
-  FunctionAnalysisManager FAM(DebugPM);
-  CGSCCAnalysisManager CGAM(DebugPM);
-  ModuleAnalysisManager MAM(DebugPM);
-
   // Register the AA manager first so that our version is the one used.
   FAM.registerPass([&] { return std::move(AA); });
   // Register our TargetLibraryInfoImpl.
Index: llvm/test/Transforms/SCCP/ipsccp-preserve-analysis.ll
===
--- llvm/test/Transforms/SCCP/ipsccp-preserve-analysis.ll
+++ llvm/test/Transforms/SCCP/ipsccp-preserve-analysis.ll
@@ -16,7 +16,7 @@
 ; NEW-PM: Running pass: IPSCCPPass
 ; NEW-PM-DAG: Running analysis: AssumptionAnalysis on f1
 ; NEW-PM-DAG: Running analysis: AssumptionAnalysis on f2
-; NEW-PM-NOT: Running analysis:
+; NEW-PM-NOT: Running analysis: AssumptionAnalysis
 
 ; IR-LABEL: @f1
 ; IR-LABEL: entry:
Index: llvm/test/Transforms/LoopRotate/pr35210.ll
===
--- llvm/test/Transforms/LoopRotate/pr35210.ll
+++ llvm/test/Transforms/LoopRotate/pr35210.ll
@@ -1,5 +1,5 @@
-;RUN: opt %s -aa-pipeline= -passes='adce,loop(loop-rotate),adce' -S -debug-pass-manager -debug-only=loop-rotate 2>&1 | FileCheck %s
-;RUN: opt %s -aa-pipeline= -passes='adce,loop-mssa(loop-rotate),adce' -S -debug-pass-manager -debug-only=loop-rotate -verify-memoryssa 2>&1 | FileCheck %s --check-prefix=MSSA
+;RUN: opt %s -aa-pipeline= -passes='adce,loop(loop-rotate),adce' -S -verify-cfg-preserved=0 -debug-pass-manager -debug-only=loop-rotate 2>&1 | FileCheck %s
+;RUN: opt %s -aa-pipeline= -passes='adce,loop-mssa(loop-rotate),adce' -S -verify-cfg-preserved=0 -debug-pass-manager -debug-only=loop-rotate -verify-memoryssa 2>&1 | FileCheck %s --check-prefix=MSSA
 ;REQUIRES: asserts
 
 ; This test is to make sure we invalidate the post 

[PATCH] D91327: [NewPM] Redesign of PreserveCFG Checker

2021-03-29 Thread Yevgeny Rouban via Phabricator via cfe-commits
yrouban marked 2 inline comments as done.
yrouban added a comment.

In D91327#2655786 , @kuhar wrote:

> Just two nits from me. I think it looks fine, but I'm not familiar with the 
> new pass manager and don't feel confident enough to approve it.

Jakub, thank you for comments. I expect @skatkov or @fedor.sergeev to look from 
NewPM point of view.


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

https://reviews.llvm.org/D91327

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


[PATCH] D99151: [RISCV][Clang] Add RVV vleff intrinsic functions.

2021-03-29 Thread Liao Chunyu via Phabricator via cfe-commits
liaolucy added a comment.

LGTM, thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99151

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


[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

2021-03-29 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added inline comments.



Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:2091
+  static const char *const X32Triples[] = {
+  "x86_64-linux-gnux32","x86_64-unknown-linux-gnux32",
+  "x86_64-pc-linux-gnux32"};

Just add `x86_64-linux-gnux32`. It is sufficient for Debian. Only add others 
when needed.



Comment at: clang/lib/Driver/ToolChains/Linux.cpp:90
   return "x86_64-linux-android";
-// We don't want this for x32, otherwise it will match x86_64 libs
-if (TargetEnvironment != llvm::Triple::GNUX32 &&
-D.getVFS().exists(SysRoot + "/lib/x86_64-linux-gnu"))
-  return "x86_64-linux-gnu";
+if (TargetEnvironment == llvm::Triple::GNUX32) {
+  if (D.getVFS().exists(SysRoot + "/lib/x86_64-linux-gnux32"))

I have cleaned up the code a bit. You may need to rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D52050

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


[PATCH] D99556: Add support to -Wa,--version in clang

2021-03-29 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added inline comments.



Comment at: clang/test/Driver/as-options.s:40
+
+// RUN: %clang -Wa,--version -c -integrated-as  %s -o /dev/null 2>&1 \
+// RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s

Drop `2>&1` because you specifically want to test stdout.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99556

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


[PATCH] D99556: Add support to -Wa,--version in clang

2021-03-29 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

gcc does not understand options in `-Wa,` so `-Wa,--version` needs to be used 
this way: `gcc -Wa,--version -c -x assembler /dev/null -o /dev/null`
The verbose syntax makes it not that useful. If the kernel really wants to use 
it, I have no issue with it.

`-integrated-as` => `-fintegrated-as`. `-i*` options are generally used for 
include related features.
Similarly, `-no-integrated-as` => `-fno-integrated-as`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99556

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


[PATCH] D99456: [C++2b] Support size_t literals

2021-03-29 Thread Anton Bikineev via Phabricator via cfe-commits
AntonBikineev updated this revision to Diff 334037.
AntonBikineev marked 2 inline comments as done.
AntonBikineev added a comment.

Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99456

Files:
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/include/clang/Lex/LiteralSupport.h
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Lex/PPExpressions.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Lexer/cxx-features.cpp
  clang/test/Lexer/size_t-literal.cpp
  clang/test/SemaCXX/cxx1y-user-defined-literals.cpp
  clang/test/SemaCXX/size_t-literal.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1270,7 +1270,7 @@
 
   Literal suffix uz, z for size_t, ssize_t
   https://wg21.link/p0330r8;>P0330R8
-  No
+  Clang 13
 
 
 
Index: clang/test/SemaCXX/size_t-literal.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/size_t-literal.cpp
@@ -0,0 +1,86 @@
+// RUN: %clang_cc1 -std=c++2b -Wpre-c++2b-compat -fsyntax-only -verify=cxx2b %s
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=cxx20 %s
+// RUN: %clang_cc1 -x c -std=c11 -fsyntax-only -verify=c11 %s
+
+#ifdef __cplusplus
+
+typedef __SIZE_TYPE__ size_t;
+// Assume ptrdiff_t is the signed integer type corresponding to size_t.
+typedef __PTRDIFF_TYPE__ ssize_t;
+
+template 
+struct is_same { static constexpr bool value = false; };
+
+template 
+struct is_same { static constexpr bool value = true; };
+
+void SSizeT() {
+  auto a1 = 1z;
+  // cxx2b-warning@-1 {{'size_t' suffix for literals is incompatible with C++ standards before C++2b}}
+  // cxx20-warning@-2 {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a2 = 1Z;
+  // cxx2b-warning@-1 {{'size_t' suffix for literals is incompatible with C++ standards before C++2b}}
+  // cxx20-warning@-2 {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+}
+
+void SizeT() {
+  auto a1 = 1uz;
+  // cxx2b-warning@-1 {{'size_t' suffix for literals is incompatible with C++ standards before C++2b}}
+  // cxx20-warning@-2 {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a2 = 1uZ;
+  // cxx2b-warning@-1 {{'size_t' suffix for literals is incompatible with C++ standards before C++2b}}
+  // cxx20-warning@-2 {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a3 = 1Uz;
+  // cxx2b-warning@-1 {{'size_t' suffix for literals is incompatible with C++ standards before C++2b}}
+  // cxx20-warning@-2 {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a4 = 1UZ;
+  // cxx2b-warning@-1 {{'size_t' suffix for literals is incompatible with C++ standards before C++2b}}
+  // cxx20-warning@-2 {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a5 = 1zu;
+  // cxx2b-warning@-1 {{'size_t' suffix for literals is incompatible with C++ standards before C++2b}}
+  // cxx20-warning@-2 {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a6 = 1Zu;
+  // cxx2b-warning@-1 {{'size_t' suffix for literals is incompatible with C++ standards before C++2b}}
+  // cxx20-warning@-2 {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a7 = 1zU;
+  // cxx2b-warning@-1 {{'size_t' suffix for literals is incompatible with C++ standards before C++2b}}
+  // cxx20-warning@-2 {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a8 = 1ZU;
+  // cxx2b-warning@-1 {{'size_t' suffix for literals is incompatible with C++ standards before C++2b}}
+  // cxx20-warning@-2 {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+}
+
+#else
+
+void f() {
+  (void)1z;  // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1Z;  // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1uz; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1uZ; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1Uz; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1UZ; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1zu; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1Zu; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1zU; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1ZU; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+}
+
+#endif
Index: 

[PATCH] D99456: [C++2b] Support size_t literals

2021-03-29 Thread Anton Bikineev via Phabricator via cfe-commits
AntonBikineev marked 7 inline comments as done.
AntonBikineev added a comment.

Thanks Richard for taking a look!




Comment at: clang/include/clang/Basic/DiagnosticCommonKinds.td:190
   InGroup, DefaultIgnore;
+def ext_cxx2b_size_t_suffix : Extension<
+  "'size_t' suffix for literals is a C++2b extension">,

rsmith wrote:
> Should this be an `ExtWarn`? I think we should warn on this by default.
I tried to follow the strategy used for 'long long' (only warn with 
-Wlong-long), but I agree that warn-by-default would probably be better.



Comment at: clang/lib/Lex/LiteralSupport.cpp:594-595
 
   // Loop over all of the characters of the suffix.  If we see something bad,
   // we break out of the loop.
   for (; s != ThisTokEnd; ++s) {

rsmith wrote:
> General comment: I think the checks here have become too complex and 
> error-prone. I suggest we add another flag, `hasSize`, that's set when we 
> parse any size modifier (`F`, `L`, `LL`, `H`, `F128`, `I64`, and now `Z`), 
> and when parsing any size modifier, replace the existing ad-hoc set of checks 
> with a check for `hasSize`.
Good idea! It actually helped to flush out the issue when Q and H are mixed 
together: https://godbolt.org/z/8hj39P93a


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99456

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


[PATCH] D99005: [clang] Implement P2266 Simpler implicit move

2021-03-29 Thread John McCall via Phabricator via cfe-commits
rjmccall added a subscriber: fhahn.
rjmccall added inline comments.



Comment at: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:1059
+else if (auto *F = dyn_cast(DC))
+  goto unimplemented; // FIXME: get the return type here somehow...
+else

mizvekov wrote:
> rjmccall wrote:
> > mizvekov wrote:
> > > @rjmccall Hello! Do you have any tips for fixing this one?
> > I've always found it annoying that we only store the block type on the 
> > `BlockExpr` and not the `BlockDecl`, so if you've got a good reason to 
> > change that, I'm not opposed.
> > 
> > That said, while I'm not an expert in how we do NRVO variable tracking, the 
> > code must have some ability to handle an unknown return type when just 
> > processing declarations by delaying some of the bookkeeping/analysis until 
> > the end of the function.  It's possible but quite uncommon to declare a 
> > return type explicitly in a block, so that's the dominant case here.  I'm 
> > actually surprised we do any of this tracking when we're just instantiating 
> > a variable.
> Thanks, your observations have been extremely helpful.
> 
> So this whole NRVO tracking thing looks to be in bad shape. This tracker here 
> fails to handle 'auto' types. I don't think this gets fixed up anywhere else.
> 
> This is also badly covered by the test suite. The test included with the 
> merge request that introduced this tracking (`CodeGenCXX/nrvo.cpp`) still 
> passes if you either delete this whole block here, or if you just do 
> `Var->setNRVOVariable(D->isNRVOVariable())`.
> 
> In fact, almost the whole test suite passes with those changes, the only 
> tests which fail are `CodeGenCXX/matrix-type-builtins.cpp` and 
> `CodeGenCXX/matrix-type-operators.cpp` respectively.
I'm surprised that this has any impact on matrix types; pinging @fhahn in case 
he understands what the interaction might be.

It looks like we're assuming that the parse-time analysis of NRVO candidates is 
correct except for possibly needing adjustment for dependent expressions / 
return types.  The parse-time analysis seems to work by keeping track of NRVO 
candidates on `Scope`; since we don't push meaningful `Scope`s during template 
instantiation, that won't work, so we have to trust the parse-time analysis.  
But the parse-time analysis can also be overly conservative, mostly because of 
`if constexpr`; that might be enough of a corner case to not merit something 
better, though.  @rsmith is the expert here, though.

At any rate, it should be *correct* to handle non-function cases as if the 
return type were dependent, the same way it presumably works for functions with 
deduced return types.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99005

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


[PATCH] D98616: [RISCV] Add inline asm constraint 'v' in Clang for RISC-V 'V'.

2021-03-29 Thread Hsiangkai Wang 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 rG5821a58d8e4c: [RISCV] Add inline asm constraint 
vr and vm in Clang for RISC-V V. (authored 
by HsiangKai).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98616

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Basic/Targets/RISCV.h
  clang/test/CodeGen/RISCV/riscv-inline-asm-rvv.c

Index: clang/test/CodeGen/RISCV/riscv-inline-asm-rvv.c
===
--- /dev/null
+++ clang/test/CodeGen/RISCV/riscv-inline-asm-rvv.c
@@ -0,0 +1,36 @@
+// RUN: %clang_cc1 -triple riscv32 -target-feature +experimental-v \
+// RUN: -O2 -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+// RUN: %clang_cc1 -triple riscv64 -target-feature +experimental-v \
+// RUN: -O2 -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+
+// Test RISC-V V-extension specific inline assembly constraints.
+#include 
+
+void test_v_reg() {
+  asm volatile(
+  "vsetvli x1, x0, e32,m2,tu,mu\n"
+  "vadd.vv v1, v2, v3, v0.t"
+  :
+  :
+  : "v1", "x1");
+// CHECK-LABEL: define{{.*}} @test_v_reg
+// CHECK: "~{v1},~{x1}"
+}
+
+vint32m1_t test_vr(vint32m1_t a, vint32m1_t b) {
+// CHECK-LABEL: define{{.*}} @test_vr
+// CHECK: %0 = tail call  asm sideeffect "vadd.vv $0, $1, $2", "=v,v,v"( %a,  %b)
+  vint32m1_t ret;
+  asm volatile ("vadd.vv %0, %1, %2" : "=vr"(ret) : "vr"(a), "vr"(b));
+  return ret;
+}
+
+vbool1_t test_vm(vbool1_t a, vbool1_t b) {
+// CHECK-LABEL: define{{.*}} @test_vm
+// CHECK: %0 = tail call  asm sideeffect "vmand.mm $0, $1, $2", "=v,v,v"( %a,  %b)
+  vbool1_t ret;
+  asm volatile ("vmand.mm %0, %1, %2" : "=vm"(ret) : "vm"(a), "vm"(b));
+  return ret;
+}
Index: clang/lib/Basic/Targets/RISCV.h
===
--- clang/lib/Basic/Targets/RISCV.h
+++ clang/lib/Basic/Targets/RISCV.h
@@ -97,6 +97,8 @@
   bool validateAsmConstraint(const char *,
  TargetInfo::ConstraintInfo ) const override;
 
+  std::string convertConstraint(const char *) const override;
+
   bool hasFeature(StringRef Feature) const override;
 
   bool handleTargetFeatures(std::vector ,
Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -31,7 +31,13 @@
   "f0",  "f1",  "f2",  "f3",  "f4",  "f5",  "f6",  "f7",
   "f8",  "f9",  "f10", "f11", "f12", "f13", "f14", "f15",
   "f16", "f17", "f18", "f19", "f20", "f21", "f22", "f23",
-  "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31"};
+  "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31",
+
+  // Vector registers
+  "v0",  "v1",  "v2",  "v3",  "v4",  "v5",  "v6",  "v7",
+  "v8",  "v9",  "v10", "v11", "v12", "v13", "v14", "v15",
+  "v16", "v17", "v18", "v19", "v20", "v21", "v22", "v23",
+  "v24", "v25", "v26", "v27", "v28", "v29", "v30", "v31"};
   return llvm::makeArrayRef(GCCRegNames);
 }
 
@@ -81,7 +87,29 @@
 // An address that is held in a general-purpose register.
 Info.setAllowsMemory();
 return true;
+  case 'v':
+// A vector register.
+if (Name[1] == 'r' || Name[1] == 'm') {
+  Info.setAllowsRegister();
+  Name += 1;
+  return true;
+}
+return false;
+  }
+}
+
+std::string RISCVTargetInfo::convertConstraint(const char *) const {
+  std::string R;
+  switch (*Constraint) {
+  case 'v':
+R = std::string("v");
+Constraint += 1;
+break;
+  default:
+R = TargetInfo::convertConstraint(Constraint);
+break;
   }
+  return R;
 }
 
 void RISCVTargetInfo::getTargetDefines(const LangOptions ,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 5821a58 - [RISCV] Add inline asm constraint 'vr' and 'vm' in Clang for RISC-V 'V'.

2021-03-29 Thread Hsiangkai Wang via cfe-commits

Author: Hsiangkai Wang
Date: 2021-03-30T09:47:27+08:00
New Revision: 5821a58d8e4c5510a4ab30fa758a9d22f41c346a

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

LOG: [RISCV] Add inline asm constraint 'vr' and 'vm' in Clang for RISC-V 'V'.

Add asm constraint 'vr' for vector registers.
Add asm constraint 'vm' for vector mask registers.

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

Added: 
clang/test/CodeGen/RISCV/riscv-inline-asm-rvv.c

Modified: 
clang/lib/Basic/Targets/RISCV.cpp
clang/lib/Basic/Targets/RISCV.h

Removed: 




diff  --git a/clang/lib/Basic/Targets/RISCV.cpp 
b/clang/lib/Basic/Targets/RISCV.cpp
index aee5aba97fd3..4ca41414a9d6 100644
--- a/clang/lib/Basic/Targets/RISCV.cpp
+++ b/clang/lib/Basic/Targets/RISCV.cpp
@@ -31,7 +31,13 @@ ArrayRef RISCVTargetInfo::getGCCRegNames() 
const {
   "f0",  "f1",  "f2",  "f3",  "f4",  "f5",  "f6",  "f7",
   "f8",  "f9",  "f10", "f11", "f12", "f13", "f14", "f15",
   "f16", "f17", "f18", "f19", "f20", "f21", "f22", "f23",
-  "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31"};
+  "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31",
+
+  // Vector registers
+  "v0",  "v1",  "v2",  "v3",  "v4",  "v5",  "v6",  "v7",
+  "v8",  "v9",  "v10", "v11", "v12", "v13", "v14", "v15",
+  "v16", "v17", "v18", "v19", "v20", "v21", "v22", "v23",
+  "v24", "v25", "v26", "v27", "v28", "v29", "v30", "v31"};
   return llvm::makeArrayRef(GCCRegNames);
 }
 
@@ -81,7 +87,29 @@ bool RISCVTargetInfo::validateAsmConstraint(
 // An address that is held in a general-purpose register.
 Info.setAllowsMemory();
 return true;
+  case 'v':
+// A vector register.
+if (Name[1] == 'r' || Name[1] == 'm') {
+  Info.setAllowsRegister();
+  Name += 1;
+  return true;
+}
+return false;
+  }
+}
+
+std::string RISCVTargetInfo::convertConstraint(const char *) const {
+  std::string R;
+  switch (*Constraint) {
+  case 'v':
+R = std::string("v");
+Constraint += 1;
+break;
+  default:
+R = TargetInfo::convertConstraint(Constraint);
+break;
   }
+  return R;
 }
 
 void RISCVTargetInfo::getTargetDefines(const LangOptions ,

diff  --git a/clang/lib/Basic/Targets/RISCV.h b/clang/lib/Basic/Targets/RISCV.h
index 8df6e05ebcd5..4fc8cd1e22df 100644
--- a/clang/lib/Basic/Targets/RISCV.h
+++ b/clang/lib/Basic/Targets/RISCV.h
@@ -97,6 +97,8 @@ class RISCVTargetInfo : public TargetInfo {
   bool validateAsmConstraint(const char *,
  TargetInfo::ConstraintInfo ) const override;
 
+  std::string convertConstraint(const char *) const override;
+
   bool hasFeature(StringRef Feature) const override;
 
   bool handleTargetFeatures(std::vector ,

diff  --git a/clang/test/CodeGen/RISCV/riscv-inline-asm-rvv.c 
b/clang/test/CodeGen/RISCV/riscv-inline-asm-rvv.c
new file mode 100644
index ..14558778278e
--- /dev/null
+++ b/clang/test/CodeGen/RISCV/riscv-inline-asm-rvv.c
@@ -0,0 +1,36 @@
+// RUN: %clang_cc1 -triple riscv32 -target-feature +experimental-v \
+// RUN: -O2 -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+// RUN: %clang_cc1 -triple riscv64 -target-feature +experimental-v \
+// RUN: -O2 -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+
+// Test RISC-V V-extension specific inline assembly constraints.
+#include 
+
+void test_v_reg() {
+  asm volatile(
+  "vsetvli x1, x0, e32,m2,tu,mu\n"
+  "vadd.vv v1, v2, v3, v0.t"
+  :
+  :
+  : "v1", "x1");
+// CHECK-LABEL: define{{.*}} @test_v_reg
+// CHECK: "~{v1},~{x1}"
+}
+
+vint32m1_t test_vr(vint32m1_t a, vint32m1_t b) {
+// CHECK-LABEL: define{{.*}} @test_vr
+// CHECK: %0 = tail call  asm sideeffect "vadd.vv $0, $1, 
$2", "=v,v,v"( %a,  %b)
+  vint32m1_t ret;
+  asm volatile ("vadd.vv %0, %1, %2" : "=vr"(ret) : "vr"(a), "vr"(b));
+  return ret;
+}
+
+vbool1_t test_vm(vbool1_t a, vbool1_t b) {
+// CHECK-LABEL: define{{.*}} @test_vm
+// CHECK: %0 = tail call  asm sideeffect "vmand.mm $0, $1, 
$2", "=v,v,v"( %a,  %b)
+  vbool1_t ret;
+  asm volatile ("vmand.mm %0, %1, %2" : "=vm"(ret) : "vm"(a), "vm"(b));
+  return ret;
+}



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


[PATCH] D99539: [OPENMP]Fix PR48740: OpenMP declare reduction in C does not require an initializer

2021-03-29 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


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99539

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


[PATCH] D99556: Add support to -Wa,--version in clang

2021-03-29 Thread Jian Cai via Phabricator via cfe-commits
jcai19 created this revision.
jcai19 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Clang currently only supports -Wa,--version when -no-integrated-as is
used. This adds support to -Wa,--version with -integrated-as.

Link:
https://github.com/ClangBuiltLinux/linux/issues/1320


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99556

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/as-options.s


Index: clang/test/Driver/as-options.s
===
--- clang/test/Driver/as-options.s
+++ clang/test/Driver/as-options.s
@@ -34,6 +34,15 @@
 // RUN:   -Ifoo_dir -### 2>&1 \
 // RUN:   | FileCheck %s
 
+
+// Test version information.
+
+// RUN: %clang -Wa,--version -c -integrated-as  %s -o /dev/null 2>&1 \
+// RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s
+
+// RUN: %clang -Wa,--version -c -no-integrated-as  %s -o /dev/null 2>&1 \
+// RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s
+
 // CHECK: "-I" "foo_dir"
 
 // Test that assembler options don't cause warnings when there's no assembler
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2549,6 +2549,8 @@
 // -fdebug-compilation-dir (without '=') here.
 CmdArgs.push_back("-fdebug-compilation-dir");
 CmdArgs.push_back(Value.data());
+  } else if (Value == "--version") {
+D.PrintVersion(C, llvm::outs());
   } else {
 D.Diag(diag::err_drv_unsupported_option_argument)
 << A->getOption().getName() << Value;


Index: clang/test/Driver/as-options.s
===
--- clang/test/Driver/as-options.s
+++ clang/test/Driver/as-options.s
@@ -34,6 +34,15 @@
 // RUN:   -Ifoo_dir -### 2>&1 \
 // RUN:   | FileCheck %s
 
+
+// Test version information.
+
+// RUN: %clang -Wa,--version -c -integrated-as  %s -o /dev/null 2>&1 \
+// RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s
+
+// RUN: %clang -Wa,--version -c -no-integrated-as  %s -o /dev/null 2>&1 \
+// RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s
+
 // CHECK: "-I" "foo_dir"
 
 // Test that assembler options don't cause warnings when there's no assembler
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2549,6 +2549,8 @@
 // -fdebug-compilation-dir (without '=') here.
 CmdArgs.push_back("-fdebug-compilation-dir");
 CmdArgs.push_back(Value.data());
+  } else if (Value == "--version") {
+D.PrintVersion(C, llvm::outs());
   } else {
 D.Diag(diag::err_drv_unsupported_option_argument)
 << A->getOption().getName() << Value;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99554: [ThinLTO] During module importing, close one source module before open another one for distributed mode.

2021-03-29 Thread Wei Mi via Phabricator via cfe-commits
wmi created this revision.
wmi added a reviewer: tejohnson.
Herald added subscribers: steven_wu, hiraditya, inglorion.
wmi requested review of this revision.
Herald added projects: clang, LLVM.
Herald added a subscriber: cfe-commits.

Currently during module importing, ThinLTO opens all the source modules, 
collect functions to be imported and append them to the destination module, 
then leave all the modules open through out the lto backend pipeline. This 
patch refactors it in the way that one source module will be closed before 
another source module is opened. All the source modules will be closed after 
importing phase is done. It will save some amount of memory when there are many 
source modules to be imported.

Note that this patch only changes the distributed thinlto mode. For in process 
thinlto mode, one source module is shared acorss different thinlto backend 
threads so it is not changed in this patch.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99554

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/thinlto_backend.ll
  llvm/include/llvm/LTO/LTOBackend.h
  llvm/lib/LTO/LTO.cpp
  llvm/lib/LTO/LTOBackend.cpp

Index: llvm/lib/LTO/LTOBackend.cpp
===
--- llvm/lib/LTO/LTOBackend.cpp
+++ llvm/lib/LTO/LTOBackend.cpp
@@ -539,7 +539,7 @@
Module , const ModuleSummaryIndex ,
const FunctionImporter::ImportMapTy ,
const GVSummaryMapTy ,
-   MapVector ,
+   MapVector *ModuleMap,
const std::vector ) {
   Expected TOrErr = initAndLookupTarget(Conf, Mod);
   if (!TOrErr)
@@ -608,11 +608,35 @@
   auto ModuleLoader = [&](StringRef Identifier) {
 assert(Mod.getContext().isODRUniquingDebugTypes() &&
"ODR Type uniquing should be enabled on the context");
-auto I = ModuleMap.find(Identifier);
-assert(I != ModuleMap.end());
-return I->second.getLazyModule(Mod.getContext(),
-   /*ShouldLazyLoadMetadata=*/true,
-   /*IsImporting*/ true);
+if (ModuleMap) {
+  auto I = ModuleMap->find(Identifier);
+  assert(I != ModuleMap->end());
+  return I->second.getLazyModule(Mod.getContext(),
+ /*ShouldLazyLoadMetadata=*/true,
+ /*IsImporting*/ true);
+}
+
+ErrorOr> MBOrErr =
+llvm::MemoryBuffer::getFile(Identifier);
+if (!MBOrErr)
+  return Expected>(make_error(
+  Twine("Error loading imported file ") + Identifier + " : ",
+  MBOrErr.getError()));
+
+Expected BMOrErr = findThinLTOModule(**MBOrErr);
+if (!BMOrErr)
+  return Expected>(make_error(
+  Twine("Error loading imported file ") + Identifier + " : " +
+  toString(BMOrErr.takeError()),
+  inconvertibleErrorCode()));
+
+Expected> MOrErr =
+BMOrErr->getLazyModule(Mod.getContext(),
+   /*ShouldLazyLoadMetadata=*/true,
+   /*IsImporting*/ true);
+if (MOrErr)
+  (*MOrErr)->setOwnedMemoryBuffer(std::move(*MBOrErr));
+return MOrErr;
   };
 
   FunctionImporter Importer(CombinedIndex, ModuleLoader,
@@ -652,12 +676,9 @@
  inconvertibleErrorCode());
 }
 
-bool lto::loadReferencedModules(
-const Module , const ModuleSummaryIndex ,
-FunctionImporter::ImportMapTy ,
-MapVector ,
-std::vector>
-) {
+bool lto::initImportList(const Module ,
+ const ModuleSummaryIndex ,
+ FunctionImporter::ImportMapTy ) {
   if (ThinLTOAssumeMerged)
 return true;
   // We can simply import the values mentioned in the combined index, since
@@ -678,26 +699,5 @@
   ImportList[Summary->modulePath()].insert(GUID);
 }
   }
-
-  for (auto  : ImportList) {
-ErrorOr> MBOrErr =
-llvm::MemoryBuffer::getFile(I.first());
-if (!MBOrErr) {
-  errs() << "Error loading imported file '" << I.first()
- << "': " << MBOrErr.getError().message() << "\n";
-  return false;
-}
-
-Expected BMOrErr = findThinLTOModule(**MBOrErr);
-if (!BMOrErr) {
-  handleAllErrors(BMOrErr.takeError(), [&](ErrorInfoBase ) {
-errs() << "Error loading imported file '" << I.first()
-   << "': " << EIB.message() << '\n';
-  });
-  return false;
-}
-ModuleMap.insert({I.first(), *BMOrErr});
-OwnedImportsLifetimeManager.push_back(std::move(*MBOrErr));
-  }
   return true;
 }
Index: llvm/lib/LTO/LTO.cpp
===
--- llvm/lib/LTO/LTO.cpp
+++ llvm/lib/LTO/LTO.cpp
@@ -1215,7 +1215,7 @@
 return MOrErr.takeError();
 
   return thinBackend(Conf, Task, AddStream, **MOrErr, CombinedIndex,
- ImportList, 

[PATCH] D98160: [clang] Use decltype((E)) for compound requirement type constraint

2021-03-29 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov updated this revision to Diff 334016.
mizvekov added a comment.

Changes per rsmith review:

Just print the non-canonical type in the diagnostics.
Instead of printing the expression, make the caret point to it, instead of
pointing to the constraint.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98160

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/compound-requirement.cpp

Index: clang/test/CXX/expr/expr.prim/expr.prim.req/compound-requirement.cpp
===
--- clang/test/CXX/expr/expr.prim/expr.prim.req/compound-requirement.cpp
+++ clang/test/CXX/expr/expr.prim/expr.prim.req/compound-requirement.cpp
@@ -79,19 +79,23 @@
 template
 constexpr bool is_same_v = true;
 
+template struct remove_reference { using type = T; };
+template struct remove_reference { using type = T; };
+
 template
 concept Same = is_same_v;
 
 template
-concept Large = sizeof(T) >= 4; // expected-note{{because 'sizeof(short) >= 4' (2 >= 4) evaluated to false}}
+concept Large = sizeof(typename remove_reference::type) >= 4;
+// expected-note@-1{{because 'sizeof(typename remove_reference::type) >= 4' (2 >= 4) evaluated to false}}
 
-template requires requires (T t) { { t } -> Large; } // expected-note{{because 'decltype(t)' (aka 'short') does not satisfy 'Large':}}
+template requires requires (T t) { { t } -> Large; } // expected-note{{because 'short &' does not satisfy 'Large':}}
 struct r7 {};
 
 using r7i1 = r7;
 using r7i2 = r7; // expected-error{{constraints not satisfied for class template 'r7' [with T = short]}}
 
-template requires requires (T t) { { t } -> Same; }
+template requires requires (T t) { { t } -> Same; }
 struct r8 {};
 
 using r8i1 = r8;
@@ -99,7 +103,8 @@
 
 // Substitution failure in type constraint
 
-template requires requires (T t) { { t } -> Same; } // expected-note{{because 'Same' would be invalid: type 'int' cannot be used prior to '::' because it has no members}}
+template requires requires (T t) { { t } -> Same; }
+// expected-note@-1{{because 'Same' would be invalid: type 'int' cannot be used prior to '::' because it has no members}}
 struct r9 {};
 
 struct M { using type = M; };
@@ -122,6 +127,17 @@
 template requires requires (T t) { { t } -> IsEven; } // expected-error{{concept named in type constraint is not a type concept}}
 struct r11 {};
 
+// Value categories
+
+template
+requires requires (int b) {
+  { a } -> Same;
+  { b } -> Same;
+  { 0 } -> Same;
+  { static_cast(a) } -> Same;
+} void f1() {}
+template void f1<>();
+
 // C++ [expr.prim.req.compound] Example
 namespace std_example {
   template concept C1 =
@@ -172,4 +188,4 @@
   static_assert(C5);
   template struct C5_check {}; // expected-note{{because 'short' does not satisfy 'C5'}}
   using c5 = C5_check; // expected-error{{constraints not satisfied for class template 'C5_check' [with T = short]}}
-}
\ No newline at end of file
+}
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -8830,6 +8830,29 @@
   return Context.getTypeOfExprType(E);
 }
 
+/// getDecltypeForParenthesizedExpr - Given an expr, will return the type for
+/// that expression, as in [dcl.type.simple]p4 but without taking id-expressions
+/// and class member access into account.
+QualType Sema::getDecltypeForParenthesizedExpr(Expr *E) {
+  // C++11 [dcl.type.simple]p4:
+  //   [...]
+  QualType T = E->getType();
+  switch (E->getValueKind()) {
+  // - otherwise, if e is an xvalue, decltype(e) is T&&, where T is the
+  //   type of e;
+  case VK_XValue:
+return Context.getRValueReferenceType(T);
+  // - otherwise, if e is an lvalue, decltype(e) is T&, where T is the
+  //   type of e;
+  case VK_LValue:
+return Context.getLValueReferenceType(T);
+  //  - otherwise, decltype(e) is the type of e.
+  case VK_RValue:
+return T;
+  }
+  llvm_unreachable("Unknown value kind");
+}
+
 /// getDecltypeForExpr - Given an expr, will return the decltype for
 /// that expression, according to the rules in C++11
 /// [dcl.type.simple]p4 and C++11 [expr.lambda.prim]p18.
@@ -8894,22 +8917,7 @@
 }
   }
 
-
-  // C++11 [dcl.type.simple]p4:
-  //   [...]
-  QualType T = E->getType();
-  switch (E->getValueKind()) {
-  // - otherwise, if e is an xvalue, decltype(e) is T&&, where T is the
-  //   type of e;
-  case VK_XValue: T = S.Context.getRValueReferenceType(T); break;
-  // - otherwise, if e is an lvalue, decltype(e) is T&, where T is the
-  //   type of e;
-  case VK_LValue: T = S.Context.getLValueReferenceType(T); break;
-  //  - otherwise, decltype(e) is the type of e.
-  case VK_RValue: break;
-  }
-
-  return T;
+  return 

[PATCH] D99360: [OpenMP][WIP] Add standard notes for ELF offload images

2021-03-29 Thread Vyacheslav Zakharin via Phabricator via cfe-commits
vzakhari added a comment.

In D99360#2654244 , @MaskRay wrote:

>> It might make sense to do the llvm-readobj portions of this patch in a 
>> separate review, since they are somewhat independent.
>
> +1. Patches touching BinaryFormat/llvm-readobj/yaml2obj/etc part and others 
> (MC/CodeGen/etc) are often required to do 
> BinaryFormat/llvm-readobj/yaml2obj/etc separately.
> The part is usually very loosely connected with the MC/CodeGen/etc part code.

Thanks. I split the patches.

>> Decide how to test the LLVM ELF implementation of ELF light, since I expect 
>> the upstream builds will use libelf implementation.
>
> Does the current code use both llvm/Object and libelf? First, for in-tree 
> components we exclusively use llvm/Object - there should be no dependency on 
> the external libelf.

The current code uses only libelf.  I believe many OpenMP offload plugins have 
been using libelf for a long time, and they did not switch to LLVM/Object, when 
libomptarget was merged into the tree.  I am not going to change this now, 
because this may cause too much disturbance downstream.  The purpose of this 
patch is to make some ELF reading functionality available in OSes, where it is 
(historically) unreasonable to require libelf dependency for user environments.

> Having two implementations can make llvm/Object API refactoring difficult. 
> Other contributors will not know that an libelf implementation (a different 
> configuration) exists and can break the libelf implementation.

I think it will be actually vice versa :)  the upstream and many downstream 
repos will continue to use the libelf path, and the LLVM/Object path may be 
broken, as you say.  At the same time, we will have QA testing downstream for 
the LLVM/Object path, so I will be able to catch issues and upstream the fixes.




Comment at: clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp:327
+  // Look for llvm-objcopy.exe as well.
+  ObjcopyPathOrErr = sys::findProgramByName("llvm-objcopy.exe");
+  if (!ObjcopyPathOrErr) {

MaskRay wrote:
> `sys::findProgramByName` tests the filename with an `.exe` suffix appended, 
> no need to duplicate it in application code.
Thanks! Fixed in D99551.



Comment at: openmp/libomptarget/plugins/common/elf_common/elf_light.cpp:47
+//for 64-bit ELFs produced by LLVM.
+typedef struct {
+  uint32_t n_namesz; // Length of note's name.

MaskRay wrote:
> C++ does not require the use sites to prepend `struct` so `typedef struct` is 
> not used by convention.
Thanks! Fixed in D99553.


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

https://reviews.llvm.org/D99360

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


[PATCH] D99525: [RISCV][Clang] Add RVV vnsra, vnsrl and vwmul intrinsic functions.

2021-03-29 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper 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/D99525/new/

https://reviews.llvm.org/D99525

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


[PATCH] D99551: [clang-offload-wrapper] Add standard notes for ELF offload images

2021-03-29 Thread Vyacheslav Zakharin via Phabricator via cfe-commits
vzakhari created this revision.
vzakhari added reviewers: ABataev, sdmitriev, grokos.
vzakhari added a project: OpenMP.
Herald added a reviewer: alexshap.
vzakhari requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: llvm-commits, cfe-commits, sstefan1.
Herald added projects: clang, LLVM.

This patch is a piece of D99360 .

The patch adds ELF notes into SHT_NOTE sections of ELF offload images passed to 
clang-offload-wrapper.

The new notes use a null-terminated //"LLVMOMPOFFLOAD"// note name. There are 
currently three types of notes:

//VERSION//: a string (not null-terminated) representing the ELF offload image 
structure. The current version '1.0' does not put any restrictions on the 
structure of the image. If we ever need to come up with a common structure for 
ELF offload images (e.g. to be able to analyze the images in libomptarget in 
some standard way), then we will introduce new versions.
//PRODUCER//: a vendor specific name of the producing toolchain. Upstream LLVM 
uses //"LLVM"// (not null-terminated).
//PRODUCER_VERSION//: a vendor specific version of the producing toolchain. 
Upstream LLVM uses //LLVM_VERSION_STRING// with optional // 
LLVM_REVISION//.

All three notes are not mandatory currently.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99551

Files:
  clang/test/Driver/Inputs/clang-offload-wrapper/elf32be
  clang/test/Driver/Inputs/clang-offload-wrapper/elf32le
  clang/test/Driver/Inputs/clang-offload-wrapper/elf64be
  clang/test/Driver/Inputs/clang-offload-wrapper/elf64le
  clang/test/Driver/clang-offload-wrapper.c
  clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp
  llvm/include/llvm/BinaryFormat/ELF.h

Index: llvm/include/llvm/BinaryFormat/ELF.h
===
--- llvm/include/llvm/BinaryFormat/ELF.h
+++ llvm/include/llvm/BinaryFormat/ELF.h
@@ -1606,6 +1606,13 @@
   NT_AMDGPU_METADATA = 32
 };
 
+// LLVMOMPOFFLOAD specific notes.
+enum : unsigned {
+  NT_LLVM_OPENMP_OFFLOAD_VERSION = 1,
+  NT_LLVM_OPENMP_OFFLOAD_PRODUCER = 2,
+  NT_LLVM_OPENMP_OFFLOAD_PRODUCER_VERSION = 3
+};
+
 enum {
   GNU_ABI_TAG_LINUX = 0,
   GNU_ABI_TAG_HURD = 1,
Index: clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp
===
--- clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp
+++ clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp
@@ -17,26 +17,35 @@
 #include "clang/Basic/Version.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/Triple.h"
+#include "llvm/BinaryFormat/ELF.h"
 #include "llvm/Bitcode/BitcodeWriter.h"
 #include "llvm/IR/Constants.h"
 #include "llvm/IR/GlobalVariable.h"
 #include "llvm/IR/IRBuilder.h"
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/Module.h"
+#include "llvm/Object/ELFObjectFile.h"
+#include "llvm/Object/ObjectFile.h"
 #include "llvm/Support/CommandLine.h"
+#include "llvm/Support/EndianStream.h"
 #include "llvm/Support/Errc.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/ErrorOr.h"
 #include "llvm/Support/MemoryBuffer.h"
+#include "llvm/Support/Program.h"
 #include "llvm/Support/Signals.h"
 #include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/VCSRevision.h"
 #include "llvm/Support/WithColor.h"
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/Transforms/Utils/ModuleUtils.h"
 #include 
 #include 
 
+#define OPENMP_OFFLOAD_IMAGE_VERSION "1.0"
+
 using namespace llvm;
+using namespace llvm::object;
 
 static cl::opt Help("h", cl::desc("Alias for -help"), cl::Hidden);
 
@@ -59,6 +68,12 @@
cl::desc("Target triple for the output module"),
cl::value_desc("triple"), cl::cat(ClangOffloadWrapperCategory));
 
+static cl::opt SaveTemps(
+"save-temps",
+cl::desc("Save temporary files that may be produced by the tool. "
+ "This option forces print-out of the temporary files' names."),
+cl::Hidden);
+
 namespace {
 
 class BinaryWrapper {
@@ -69,6 +84,15 @@
   StructType *ImageTy = nullptr;
   StructType *DescTy = nullptr;
 
+  std::string ToolName;
+  std::string ObjcopyPath;
+  // Temporary file names that may be created during adding notes
+  // to ELF offload images. Use -save-temps to keep them and also
+  // see their names. A temporary file's name includes the name
+  // of the original input ELF image, so you can easily match
+  // them, if you have multiple inputs.
+  std::vector TempFiles;
+
 private:
   IntegerType *getSizeTTy() {
 switch (M.getDataLayout().getPointerTypeSize(Type::getInt8PtrTy(C))) {
@@ -293,8 +317,62 @@
   }
 
 public:
-  BinaryWrapper(StringRef Target) : M("offload.wrapper.object", C) {
+  BinaryWrapper(StringRef Target, StringRef ToolName)
+  : M("offload.wrapper.object", C), ToolName(ToolName) {
 M.setTargetTriple(Target);
+// Look for llvm-objcopy in the same directory, from which
+// clang-offload-wrapper is 

[PATCH] D99005: [clang] Implement P2266 Simpler implicit move

2021-03-29 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov added inline comments.



Comment at: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:1059
+else if (auto *F = dyn_cast(DC))
+  goto unimplemented; // FIXME: get the return type here somehow...
+else

rjmccall wrote:
> mizvekov wrote:
> > @rjmccall Hello! Do you have any tips for fixing this one?
> I've always found it annoying that we only store the block type on the 
> `BlockExpr` and not the `BlockDecl`, so if you've got a good reason to change 
> that, I'm not opposed.
> 
> That said, while I'm not an expert in how we do NRVO variable tracking, the 
> code must have some ability to handle an unknown return type when just 
> processing declarations by delaying some of the bookkeeping/analysis until 
> the end of the function.  It's possible but quite uncommon to declare a 
> return type explicitly in a block, so that's the dominant case here.  I'm 
> actually surprised we do any of this tracking when we're just instantiating a 
> variable.
Thanks, your observations have been extremely helpful.

So this whole NRVO tracking thing looks to be in bad shape. This tracker here 
fails to handle 'auto' types. I don't think this gets fixed up anywhere else.

This is also badly covered by the test suite. The test included with the merge 
request that introduced this tracking (`CodeGenCXX/nrvo.cpp`) still passes if 
you either delete this whole block here, or if you just do 
`Var->setNRVOVariable(D->isNRVOVariable())`.

In fact, almost the whole test suite passes with those changes, the only tests 
which fail are `CodeGenCXX/matrix-type-builtins.cpp` and 
`CodeGenCXX/matrix-type-operators.cpp` respectively.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99005

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


[PATCH] D98499: [clangd] Introduce ASTHooks to FeatureModules

2021-03-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/FeatureModule.h:112
+  };
+  /// Can be called asynchronously before building an AST.
+  virtual std::unique_ptr astHooks() { return nullptr; }

sammccall wrote:
> kadircet wrote:
> > sammccall wrote:
> > > This comment hints at what I *thought* was the idea: astHooks() is called 
> > > each time we parse a file, the returned object has methods called on it 
> > > while the file is being parsed, and is then destroyed.
> > > 
> > > But the code suggests we call once globally and it has effectively the 
> > > same lifetime as the module.
> > > This seems much less useful, e.g. if we want to observe several 
> > > diagnostics, examine the preamble, and emit new diagnostics, then we have 
> > > to plumb around some notion of "AST identity" rather than just tying it 
> > > to the identity of the ParseASTHooks object itself.
> > > 
> > > (Lots of natural extensions here like providing ParseInputs to 
> > > astHooks(), but YAGNI for now)
> > > This comment hints at what I *thought* was the idea: astHooks() is called 
> > > each time we parse a file, the returned object has methods called on it 
> > > while the file is being parsed, and is then destroyed.
> > 
> > This was the intent actually (to enable modularization of other features 
> > like clangtidy, includefixer, etc. as mentioned above), but looks like i 
> > got confused while integrating this into clangdserver :/
> > 
> > While trying to resolve my confusion i actually noticed that we cannot 
> > uphold the contract of "hooks being called synchronously", because we 
> > actually have both a preamblethread and astworker that can invoke hooks 
> > (embarrassing of me to forget that ).
> > 
> > So we can:
> > - Give up on that promise and make life slightly complicated for module 
> > implementers
> > - Don't invoke hooks from preamblethread, (at the cost of limiting 
> > functionality, we can still have downstream users that act on PPCallbacks, 
> > but no direct integration with compiler, and that's where layering 
> > violations are generated :/)
> > - Handle the synchronization ourselves, only complicates TUScheduler more, 
> > rather than all the module implementers.
> > - Propogate FeatureModuleSet into TUScheduler and create 2 set of hooks on 
> > each thread :)
> > 
> > I am leaning towards 4, but unsure (mostly hesitant about dependency 
> > schema, as featuremodules also depend on TUScheduler..). WDYT?
> > we actually have both a preamblethread and astworker that can invoke hooks 
> > (embarrassing of me to forget that )
> 
> Ha! And yes, in our motivating case of fixing build system rules, the 
> diagnostics are mostly going to be in the preamble.
> 
> The options that seem most tempting to me are:
>  - don't attempt to create/run astHooks while building preambles, but *do* 
> feed the preamble's Diags into the main-file's AST hooks every time it's 
> used. (you won't have a clang::Diagnostic, so that param would have to be 
> gone/optional, and we'd scrape the messages instead of extracting args). This 
> is kind of thematic, remember how we replay PPCallbacks for clang-tidy :-). 
> This is the smallest tweak to your #2 that actually works for us, I think.
>  - create one astHooks for the preamble, and another for the AST build, and 
> try to make the interface suitable for both. This is cute but there may be 
> too much tension between the two cases. (Is this what you mean by #4?)
>  - or have separate ASTHooks & PreambleHooks interfaces and support all this 
> crap for both. (Or is *this* what you mean by #4?) Hybrid is also possible, 
> give the interfaces an inheritance relationship, or have one interface but 
> pass boolean parameters to indicate which version we're doing, or...
>  - preambles and ASTs are a tree, so... give modules a PreambleHooks factory, 
> and the factory function for ASTHooks is PreambleHooks::astHooks(). Holy 
> overengineering batman...
> 
> These are roughly in order of complexity so we should probably start toward 
> the top of the list somewhere. Up to you.
> 
> (I don't like the #1 or #3 in your list above much at all.)
> create one astHooks for the preamble, and another for the AST build, and try 
> to make the interface suitable for both. This is cute but there may be too 
> much tension between the two cases. (Is this what you mean by #4?)

yes this is what i meant by #4. 

> These are roughly in order of complexity so we should probably start toward 
> the top of the list somewhere. Up to you.

I'd lean towards the second option(creating separate ASTHooks with the same 
interface for preamble and astworker). As discussed before first one (i.e. 
scraping diag message) is a limited solution that's likely to get us into a 
corner in the future. let me know if you have any concerns around this approach.


Repository:
  rG LLVM Github Monorepo

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


[PATCH] D99456: [C++2b] Support size_t literals

2021-03-29 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticCommonKinds.td:190
   InGroup, DefaultIgnore;
+def ext_cxx2b_size_t_suffix : Extension<
+  "'size_t' suffix for literals is a C++2b extension">,

Should this be an `ExtWarn`? I think we should warn on this by default.



Comment at: clang/lib/Lex/LiteralSupport.cpp:594-595
 
   // Loop over all of the characters of the suffix.  If we see something bad,
   // we break out of the loop.
   for (; s != ThisTokEnd; ++s) {

General comment: I think the checks here have become too complex and 
error-prone. I suggest we add another flag, `hasSize`, that's set when we parse 
any size modifier (`F`, `L`, `LL`, `H`, `F128`, `I64`, and now `Z`), and when 
parsing any size modifier, replace the existing ad-hoc set of checks with a 
check for `hasSize`.



Comment at: clang/lib/Lex/PPExpressions.cpp:325
+// 'z/uz' literals are a C++2b feature.
+if (!PP.getLangOpts().CPlusPlus2b && Literal.isSizeT)
+  PP.Diag(PeekTok, PP.getLangOpts().CPlusPlus

We should issue a compat warning when these literals are used in C++2b or 
later. (That is, always issue a diagnostic for a `size_t` literal: in C, it's 
an error, in C++20 and before, it's an extension warning, and in C++2b and 
later, it's a backwards-compatibility warning.) There are a bunch of examples 
of this elsewhere in the codebase -- look for the emission of 
`warn_cxx.*_compat`.



Comment at: clang/lib/Sema/SemaExpr.cpp:3871
+// 'z/uz' literals are a C++2b feature.
+if (!getLangOpts().CPlusPlus2b && Literal.isSizeT)
+  Diag(Tok.getLocation(), getLangOpts().CPlusPlus

Also need the C++20-and-before compat warning here for C++2b-onwards mode.



Comment at: clang/lib/Sema/SemaExpr.cpp:3928
+
   if (Ty.isNull() && !Literal.isLong && !Literal.isLongLong) {
 // Are int/unsigned possibilities?

This should exclude the `isSizeT` case in addition to `isLong` and 
`isLongLong`. (It probably doesn't matter, because `int` is not larger than 
`size_t` on any platform we support, but nonetheless we should check.)



Comment at: clang/lib/Sema/SemaExpr.cpp:3944
   // Are long/unsigned long possibilities?
   if (Ty.isNull() && !Literal.isLongLong) {
 unsigned LongSize = Context.getTargetInfo().getLongWidth();

Likewise here.



Comment at: clang/lib/Sema/SemaExpr.cpp:3975
   // Check long long if needed.
   if (Ty.isNull()) {
 unsigned LongLongSize = Context.getTargetInfo().getLongLongWidth();

Likewise here -- and this one actually does matter, because we have targets 
with a 32-bit `size_t` but a 64-bit `long long`.



Comment at: clang/test/Lexer/size_t-literal.cpp:6-8
+#if 1uz != 1
+#error "size_t suffix must be recognized by preprocessor"
+#endif

Please also check `-1z < 0` and `-1zu < 0` to ensure that the preprocessor gets 
the signedness correct.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99456

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


[PATCH] D98242: [clangd] Store system relative includes as verbatim

2021-03-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet planned changes to this revision.
kadircet added a comment.
Herald added a project: clang-tools-extra.

as discussed offline, this gets messy if the header can be included both as a 
system and quoted included, and the coding style actually prefers the quoted 
one. it is not a big deal yet, but if it turns out to be we can move forward 
this patch by also having a way for users to resolve such ambiguities (probably 
through config).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98242

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


[PATCH] D17183: Make TargetInfo store an actual DataLayout instead of a string.

2021-03-29 Thread Eric Christopher via Phabricator via cfe-commits
echristo added a comment.

In D17183#2656771 , @jyknight wrote:

> In general, I think it's extremely unfortunate that Clang and LLVM have 
> different copies of the same information. It's a problem for way more than 
> just this one situation. So, I really don't like choice 1 -- I think it's 
> moving in the wrong direction.
>
> The recent thread about compiler-rt libcalls vs size of "int" is another 
> example of this sort of issue of duplicated info across the llvm/clang 
> boundary being troublesome. Other times, the information in question is 
> buried in the Target implementation in LLVM, and Clang doesn't depend upon 
> targets being compiled in...usually, so it can't access it from there. E.g. 
> the fact that Clang even has to come up with a DataLayout string on its own 
> is an example of this problem.
>
> So, I like option 2. I think a lot more of the information in TargetInfo 
> ought to be shared with LLVM. I note that ARM already pushed a bunch of 
> shared stuff into LLVM to reduce duplication, which is great. But, it had to 
> put it into a rather odd place 
> (`llvm/include/llvm/Support/{ARMTargetParser.h,ARMAttributeParser.h,...`), 
> because of the layering and optionality concerns. That part is not so great 
> -- putting all this target-specific info into "Support" doesn't feel like the 
> best fit. There should be some sort of Target-specific location for this sort 
> of stuff to live which Clang can depend on.

FWIW I agree here.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D17183

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


[PATCH] D98505: [clangd] Propagate data in diagnostics

2021-03-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 333982.
kadircet marked 2 inline comments as done.
kadircet added a comment.

- Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98505

Files:
  clang-tools-extra/clangd/Diagnostics.cpp
  clang-tools-extra/clangd/Diagnostics.h
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/refactor/Tweak.h


Index: clang-tools-extra/clangd/refactor/Tweak.h
===
--- clang-tools-extra/clangd/refactor/Tweak.h
+++ clang-tools-extra/clangd/refactor/Tweak.h
@@ -26,6 +26,7 @@
 #include "index/Index.h"
 #include "support/Path.h"
 #include "clang/Tooling/Core/Replacement.h"
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -844,6 +844,13 @@
   /// Only with capability textDocument.publishDiagnostics.codeActionsInline.
   /// (These actions can also be obtained using textDocument/codeAction).
   llvm::Optional> codeActions;
+
+  /// A data entry field that is preserved between a
+  /// `textDocument/publishDiagnostics` notification
+  /// and`textDocument/codeAction` request.
+  /// Mutating users should associate their data with a unique key they can use
+  /// to retrieve later on.
+  llvm::json::Object data;
 };
 llvm::json::Value toJSON(const Diagnostic &);
 
Index: clang-tools-extra/clangd/Protocol.cpp
===
--- clang-tools-extra/clangd/Protocol.cpp
+++ clang-tools-extra/clangd/Protocol.cpp
@@ -599,6 +599,8 @@
 Diag["source"] = D.source;
   if (D.relatedInformation)
 Diag["relatedInformation"] = *D.relatedInformation;
+  if (!D.data.empty())
+Diag["data"] = llvm::json::Object(D.data);
   // FIXME: workaround for older gcc/clang
   return std::move(Diag);
 }
@@ -606,7 +608,11 @@
 bool fromJSON(const llvm::json::Value , Diagnostic ,
   llvm::json::Path P) {
   llvm::json::ObjectMapper O(Params, P);
-  return O && O.map("range", R.range) && O.map("message", R.message) &&
+  if (!O)
+return false;
+  if (auto *Data = Params.getAsObject()->getObject("data"))
+R.data = *Data;
+  return O.map("range", R.range) && O.map("message", R.message) &&
  mapOptOrNull(Params, "severity", R.severity, P) &&
  mapOptOrNull(Params, "category", R.category, P) &&
  mapOptOrNull(Params, "code", R.code, P) &&
Index: clang-tools-extra/clangd/Diagnostics.h
===
--- clang-tools-extra/clangd/Diagnostics.h
+++ clang-tools-extra/clangd/Diagnostics.h
@@ -21,10 +21,12 @@
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringSet.h"
+#include "llvm/Support/JSON.h"
 #include "llvm/Support/SourceMgr.h"
 #include 
 #include 
 #include 
+#include 
 
 namespace clang {
 namespace tidy {
@@ -69,6 +71,10 @@
   // diags from the main file.
   bool InsideMainFile = false;
   unsigned ID; // e.g. member of clang::diag, or clang-tidy assigned ID.
+  // Feature modules can make use of this field to propagate data from a
+  // diagnostic to a CodeAction request. Each module should only append to the
+  // list.
+  llvm::json::Object OpaqueData;
 };
 llvm::raw_ostream <<(llvm::raw_ostream , const DiagBase );
 
Index: clang-tools-extra/clangd/Diagnostics.cpp
===
--- clang-tools-extra/clangd/Diagnostics.cpp
+++ clang-tools-extra/clangd/Diagnostics.cpp
@@ -476,6 +476,10 @@
   Res.message = noteMessage(D, Note, Opts);
   OutFn(std::move(Res), llvm::ArrayRef());
 }
+
+  // FIXME: Get rid of the copies here by taking in a mutable clangd::Diag.
+  for (auto  : D.OpaqueData)
+Main.data.insert({Entry.first, Entry.second});
 }
 
 int getSeverity(DiagnosticsEngine::Level L) {


Index: clang-tools-extra/clangd/refactor/Tweak.h
===
--- clang-tools-extra/clangd/refactor/Tweak.h
+++ clang-tools-extra/clangd/refactor/Tweak.h
@@ -26,6 +26,7 @@
 #include "index/Index.h"
 #include "support/Path.h"
 #include "clang/Tooling/Core/Replacement.h"
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -844,6 +844,13 @@
   /// Only with capability textDocument.publishDiagnostics.codeActionsInline.
   /// (These actions can also be obtained using 

[PATCH] D98505: [clangd] Propagate data in diagnostics

2021-03-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet marked 4 inline comments as done.
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/Diagnostics.h:77
+  // list.
+  std::vector OpaqueData;
 };

sammccall wrote:
> Hmm, you've replaced the json::Array with an array of objects :-)
> Any reason we can't just use llvm::json::Object here?
> 
> We don't really handle conflicts anyway, and I don't think having one tweak 
> read another one's data out of this field is a real concern.
oops, that wasn't the intention. changed to `llvm::json::Object`.



Comment at: clang-tools-extra/clangd/Protocol.cpp:616
+  if (auto *Data = Params.getAsObject()->getObject("data"))
+R.data = std::move(*Data);
+  return O.map("range", R.range) && O.map("message", R.message) &&

sammccall wrote:
> std::move is a fancy way to spell copy here, since Params is const.
> 
> json::Value(*Data) (or can you just use mapOptOrNull?)
> std::move is a fancy way to spell copy here, since Params is const.

right.. dropped that.

> json::Value(*Data) (or can you just use mapOptOrNull?)

we can't `mapOptOrNull` as `fromJSON` doesn't have output specializations for 
JSON types. i don't think it is worth having them (i think, they would actually 
be confusing). but if you think it's worth, maybe we can have some identity 
mapper specialization.



Comment at: clang-tools-extra/clangd/refactor/Tweak.h:71
+/// Diagnostics related to this selection.
+llvm::ArrayRef Diags;
 // FIXME: provide a way to get sources and ASTs for other files.

sammccall wrote:
> unrelated?
> (well not quite, but neither populated or used in this patch)
yeah this was supposed to be a separate change but forgot to strip this bit 
off..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98505

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


[PATCH] D98160: [clang] Use decltype((E)) for compound requirement type constraint

2021-03-29 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov marked an inline comment as done.
mizvekov added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2761
 def note_expr_requirement_constraints_not_satisfied_simple : Note<
-  "%select{and|because}0 %1 does not satisfy %2:">;
+  "%select{and|because}0 'decltype((%1))' (aka %2) does not satisfy %3:">;
 def note_type_requirement_substitution_error : Note<

rsmith wrote:
> I don't think we need to talk about the mechanics of how we formed the type 
> here. Also, adding a manual 'aka' like this will result in a double-aka 
> (`decltype((foo))' (aka 'bar' (aka 'baz'))`) in some cases.
> 
> Aside [not something to address in this patch]: this (and other diagnostics 
> nearby) also violate our [diagnostics best 
> practices](https://clang.llvm.org/docs/InternalsManual.html#the-format-string)
>  by redundantly including in the diagnostic the source expression that the 
> caret will be pointing to, but perhaps that's justifiable in this case 
> because we expect these expressions to be short and they're so central to 
> what's being diagnosed.
Though the original code just built a decltype and printed it here. This format 
string, as far as I remember, matches exactly what the original code printed, 
so that a sweeping change to update all the tests would not have to be made.
I vaguely remember following the code of the type printer here and seeing that 
it would stop from printing an aka chain by just canonicalizing the type on the 
first aka.

So yeah, the original code ironically violated this best practice by just 
printing a type, but which in this case contains the expression.

But I agree we do not necessarily need to explain the mechanics of this type 
here, though I think the standard does explain how the type is obtained here in 
terms of `decltype(())`.

But since you mentioned this, I think the best approach here might be to just 
print the non canonical type, and not print the expression.
Will have to update all the tests but no big deal. Agreed?



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98160

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


[PATCH] D99363: [Windows] Turn off text mode in TableGen and Rewriter to stop CRLF translation

2021-03-29 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added a comment.

In D99363#2653476 , 
@abhina.sreeskantharajan wrote:

> There were a lot of similar patches so reverting all of them might be more 
> work than isolating the change that caused it and reverting that. It seems 
> that the patch you initially commented on did not contain the problematic 
> change since reverting the change doesn't fix your issue. I created the 
> following patch https://reviews.llvm.org/D99426 based on @rnk suggestion. I 
> created a new flag for OF_TextWithCRLF on Windows and made sure my most 
> recent text changes use the OF_Text flag while all other uses were changed to 
> OF_TextWithCRLF. This should solve any CRLF issues that were introduced 
> recently by my patches. If you have time, would you be able to test if that 
> patch fixes your issue?

I've applied https://reviews.llvm.org/D99426#2656738 over 
rGc4d5b956170dd85941c1c2787abaa2e01575234c 
 but I'm 
still seeing the issue in https://reviews.llvm.org/D96363#2650460.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99363

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


[PATCH] D99539: [OPENMP]Fix PR48740: OpenMP declare reduction in C does not require an initializer

2021-03-29 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev created this revision.
ABataev added a reviewer: jdoerfert.
Herald added subscribers: guansong, yaxunl.
ABataev requested review of this revision.
Herald added a subscriber: sstefan1.
Herald added a project: clang.

If no initializer-clause is specified, the private variables will be
initialized following the rules for initialization of objects with static
storage duration.

Need to adjust the implementation to the current version of the
standard.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99539

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/declare_reduction_ast_print.c
  clang/test/OpenMP/declare_reduction_codegen.c
  clang/test/OpenMP/declare_reduction_messages.c

Index: clang/test/OpenMP/declare_reduction_messages.c
===
--- clang/test/OpenMP/declare_reduction_messages.c
+++ clang/test/OpenMP/declare_reduction_messages.c
@@ -49,9 +49,9 @@
 #pragma omp declare reduction(|: struct S: omp_out.s += omp_in.s) initializer(omp_priv = { 0 })
 
 int fun(int arg) {
-  struct S s;// expected-note {{'s' defined here}}
+  struct S s;
   s.s = 0;
-#pragma omp parallel for reduction(+ : s) // expected-error {{list item of type 'struct S' is not valid for specified reduction operation: unable to provide default initialization value}}
+#pragma omp parallel for reduction(+ : s)
   for (arg = 0; arg < 10; ++arg)
 s.s += arg;
 #pragma omp declare reduction(red : int : omp_out++)
Index: clang/test/OpenMP/declare_reduction_codegen.c
===
--- clang/test/OpenMP/declare_reduction_codegen.c
+++ clang/test/OpenMP/declare_reduction_codegen.c
@@ -17,6 +17,9 @@
 // CHECK: [[SSS_INT:.+]] = type { i32 }
 // CHECK-LOAD: [[SSS_INT:.+]] = type { i32 }
 
+// CHECK-DAG: [[SSS_INIT:@.+]] = private constant %struct.SSS zeroinitializer
+// CHECK-DAG: [[INT_INIT:@.+]] = private constant i32 0
+
 #pragma omp declare reduction(+ : int, char : omp_out *= omp_in)
 // CHECK: define internal {{.*}}void @{{[^(]+}}(i32* noalias %0, i32* noalias %1)
 // CHECK: [[MUL:%.+]] = mul nsw i32
@@ -163,4 +166,27 @@
 // OMP45-LOAD-NEXT: store i8 [[TRUNC]], i8*
 // OMP45-LOAD-NEXT: ret void
 // OMP45-LOAD-NEXT: }
+
+// CHECK-LABEL: bar
+struct SSS ss;
+int in;
+void bar() {
+  // CHECK: [[SS_PRIV:%.+]] = alloca %struct.SSS,
+  // CHECK: [[IN_PRIV:%.+]] = alloca i32,
+  // CHECK: [[BC:%.+]] = bitcast %struct.SSS* [[SS_PRIV]] to i8*
+  // CHECK: call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 4 [[BC]], i8* align 4 bitcast (%struct.SSS* [[SSS_INIT]] to i8*), i64 4, i1 false)
+  // CHECK: [[IN_VAL:%.+]] = load i32, i32* [[INT_INIT]],
+  // CHECK: store i32 [[IN_VAL]], i32* [[IN_PRIV]],
+  // CHECK: call void @__kmpc_for_static_init_4(
+#pragma omp declare reduction(+\
+  : struct SSS \
+  : omp_out = omp_in)
+#pragma omp declare reduction(+ \
+  : int \
+  : omp_out = omp_in)
+#pragma omp for reduction(+ \
+  : ss, in)
+  for (int i = 0; i < 10; ++i)
+;
+}
 #endif
Index: clang/test/OpenMP/declare_reduction_ast_print.c
===
--- clang/test/OpenMP/declare_reduction_ast_print.c
+++ clang/test/OpenMP/declare_reduction_ast_print.c
@@ -47,13 +47,18 @@
   : omp_out = omp_out > omp_in ? omp_in : omp_out) \
 initializer(omp_priv = 2147483647)
 
+#pragma omp declare reduction(mymin\
+  : struct SSS \
+  : omp_out = omp_out.field > omp_in.field ? omp_in : omp_out)
+
 int foo(int argc, char **argv) {
   int x;
-#pragma omp parallel for reduction(mymin : x)
+  struct SSS ss;
+#pragma omp parallel for reduction(mymin : x, ss)
   for (int i = 0; i < 1000; i++)
 ;
   return 0;
 }
 
-// CHECK: #pragma omp parallel for reduction(mymin: x)
+// CHECK: #pragma omp parallel for reduction(mymin: x,ss)
 #endif
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -16567,8 +16567,7 @@
 }
 if (RHSVD->isInvalidDecl())
   continue;
-if (!RHSVD->hasInit() &&
-(DeclareReductionRef.isUnset() || !S.LangOpts.CPlusPlus)) {
+if (!RHSVD->hasInit() && DeclareReductionRef.isUnset()) {
   S.Diag(ELoc, diag::err_omp_reduction_id_not_compatible)
   << Type << ReductionIdRange;
   bool IsDecl = !VD || VD->isThisDeclarationADefinition(Context) ==
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -655,9 +655,13 @@
   InitRVal =
   

[PATCH] D99524: [RISCV][Clang] Add some RVV Integer intrinsic functions.

2021-03-29 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: clang/include/clang/Basic/riscv_vector.td:432
+["vv", "Uv", "UvUvUv"],
+["vx", "Uv", "UvUvUe"]]>;
+

Should we have a common class for vadd/vsub/vand/vxor/vor. They all have the 
same argments except for the name.

Or maybe a common class for signed binary ops and unsigned binary ops. And some 
can just instantiate both classes? That would allow us to pick up min/max and 
shifts as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99524

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


[PATCH] D99458: [clang-format] Fix east const pointer alignment of operators

2021-03-29 Thread Nico Rieck via Phabricator via cfe-commits
nrieck added a comment.

Ah, I missed transferring my commit access from svn. If anyone could commit for 
me, please do.

In D99458#2655458 , @curdeius wrote:

> Thinking out loud, do we test `volatile` at all?

I see only the variants with block comments inbetween. There should probably 
more, but it's a lot of permutations though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99458

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


[PATCH] D99514: [NFC] clang-formatting zos-alignment.c

2021-03-29 Thread Fanbo Meng via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbd8dd580ffd2: [NFC] clang-formatting zos-alignment.c 
(authored by fanbo-meng).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99514

Files:
  clang/test/CodeGen/SystemZ/zos-alignment.c

Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -13,8 +13,8 @@
 // DECL-NEXT: @v3 {{.*}} align 32
 
 const struct cs0 {
-  unsigned long   :0;
-  long longa;
+  unsigned long : 0;
+  long long a;
 } CS0 = {};
 // CHECK:  0 | struct cs0
 // CHECK-NEXT:   0:- |   unsigned long
@@ -22,8 +22,8 @@
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 volatile struct vs0 {
-  long:0;
-  short   a;
+  long : 0;
+  short a;
 } VS0;
 // CHECK:  0 | struct vs0
 // CHECK-NEXT:   0:- |   long
@@ -31,11 +31,11 @@
 // CHECK-NEXT:   | [sizeof=2, align=2]
 
 struct s0 {
-  short a:3;
-  long b:5;
-  int c:1;
-  long d:10;
-  char e:5;
+  short a : 3;
+  long b : 5;
+  int c : 1;
+  long d : 10;
+  char e : 5;
 } S0;
 // CHECK:  0 | struct s0
 // CHECK-NEXT: 0:0-2 |   short a
@@ -46,9 +46,9 @@
 // CHECK-NEXT:   | [sizeof=3, align=1]
 
 struct s1 {
-  char a:7;
-  long b:27;
-  int c:2;
+  char a : 7;
+  long b : 27;
+  int c : 2;
 } S1;
 // CHECK:  0 | struct s1
 // CHECK-NEXT: 0:0-6 |   char a
@@ -57,10 +57,10 @@
 // CHECK-NEXT:   | [sizeof=5, align=1]
 
 struct s2 {
-  char a:7;
-  char  :0;
-  short :0;
-  short :0;
+  char a : 7;
+  char : 0;
+  short : 0;
+  short : 0;
 } S2;
 // CHECK:  0 | struct s2
 // CHECK-NEXT: 0:0-6 |   char a
@@ -71,9 +71,9 @@
 
 struct s3 {
   int a;
-  int b:16;
-  char  :0;
-  char c:1;
+  int b : 16;
+  char : 0;
+  char c : 1;
 } S3;
 // CHECK:  0 | struct s3
 // CHECK-NEXT: 0 |   int a
@@ -83,7 +83,7 @@
 // CHECK-NEXT:   | [sizeof=12, align=4]
 
 struct s4 {
- unsigned int __attribute__((aligned(32))) a;
+  unsigned int __attribute__((aligned(32))) a;
 } S4;
 // CHECK:  0 | struct s4
 // CHECK-NEXT: 0 |   unsigned int a
@@ -91,10 +91,10 @@
 
 struct s5 {
   char a;
-  int  b:19 __attribute__((aligned(4)));
-  int  c:22 __attribute__((aligned(8)));
-  int  :0;
-  int  d:10;
+  int b : 19 __attribute__((aligned(4)));
+  int c : 22 __attribute__((aligned(8)));
+  int : 0;
+  int d : 10;
 } S5;
 // CHECK:  0 | struct s5
 // CHECK-NEXT: 0 |   char a
@@ -105,8 +105,8 @@
 // CHECK-NEXT:   | [sizeof=16, align=8]
 
 struct s6 {
-  char * a;
-  char * b[];
+  char *a;
+  char *b[];
 } S6;
 // CHECK:  0 | struct s6
 // CHECK-NEXT: 0 |   char * a
@@ -114,7 +114,7 @@
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 struct s7 {
-  long  :0;
+  long : 0;
   short a;
 } S7;
 // CHECK:  0 | struct s7
@@ -124,8 +124,8 @@
 
 #pragma pack(2)
 struct s8 {
-  unsigned long   :0;
-  long long   a;
+  unsigned long : 0;
+  long long a;
 } S8;
 #pragma pack()
 // CHECK:  0 | struct s8
@@ -134,8 +134,8 @@
 // CHECK-NEXT:   | [sizeof=8, align=2]
 
 struct s9 {
-  unsigned int   :0;
-  unsigned short :0;
+  unsigned int : 0;
+  unsigned short : 0;
 } S9;
 // CHECK:  0 | struct s9
 // CHECK-NEXT:   0:- |   unsigned int
@@ -143,7 +143,7 @@
 // CHECK-NEXT:   | [sizeof=0, align=1]
 
 struct s10 {
- unsigned int __attribute__((aligned)) a;
+  unsigned int __attribute__((aligned)) a;
 } S10;
 // CHECK:  0 | struct s10
 // CHECK-NEXT: 0 |   unsigned int a
@@ -151,7 +151,7 @@
 
 struct s11 {
   char a;
-  long :0;
+  long : 0;
   char b;
 } S11;
 // CHECK:  0 | struct s11
@@ -161,9 +161,9 @@
 // CHECK-NEXT:   | [sizeof=16, align=8]
 
 union u0 {
-  unsigned short d1 __attribute__((packed));
-  intd2:10;
-  long   d3;
+  unsigned short d1 __attribute__((packed));
+  int d2 : 10;
+  long d3;
 } U0 __attribute__((aligned(8)));
 // CHECK:  0 | union u0
 // CHECK-NEXT: 0 |   unsigned short d1
@@ -172,8 +172,8 @@
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 union u1 {
-  unsigned int:0;
-  short   a;
+  unsigned int : 0;
+  short a;
 } U1;
 // CHECK:  0 | union u1
 // CHECK-NEXT:   0:- |   unsigned int
@@ -181,8 +181,8 @@
 // CHECK-NEXT:   | [sizeof=4, align=4]
 
 union u2 {
-  long  :0;
-  short  a;
+  long : 0;
+  short a;
 } U2;
 // CHECK:  0 | union u2
 // CHECK-NEXT:   0:- |   long
@@ -190,8 +190,8 @@
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 union u3 {
-  unsigned char :0;
-  unsigned short :0;
+  unsigned char : 0;
+  unsigned short : 0;
 

[PATCH] D91630: [Parse] Add parsing support for C++ attributes on using-declarations

2021-03-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.

LGTM with a minor improvement for attribute ordering.




Comment at: clang/lib/Parse/ParseDeclCXX.cpp:732-733
+// Parse (optional) attributes.
 MaybeParseGNUAttributes(Attrs);
+MaybeParseCXX11Attributes(Attrs);
+DiagnoseCXX11AttributeExtension(Attrs);

You should replace these two lines with a call to: 
`MaybeParseAttributes(PAKM_GNU | PAKM_CXX11, Attrs);` so that order of GNU vs 
CXX syntax doesn't matter (they can be interleaved).


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

https://reviews.llvm.org/D91630

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


[clang] bd8dd58 - [NFC] clang-formatting zos-alignment.c

2021-03-29 Thread Fanbo Meng via cfe-commits

Author: Fanbo Meng
Date: 2021-03-29T16:48:10-04:00
New Revision: bd8dd580ffd221dd38e28c609b30d9b6361efac7

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

LOG: [NFC] clang-formatting zos-alignment.c

Reviewed By: abhina.sreeskantharajan

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

Added: 


Modified: 
clang/test/CodeGen/SystemZ/zos-alignment.c

Removed: 




diff  --git a/clang/test/CodeGen/SystemZ/zos-alignment.c 
b/clang/test/CodeGen/SystemZ/zos-alignment.c
index b43968410cec..7b08f4bf7f4a 100644
--- a/clang/test/CodeGen/SystemZ/zos-alignment.c
+++ b/clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -13,8 +13,8 @@ int f0() { return v0 + v1 + v2 + v3; }
 // DECL-NEXT: @v3 {{.*}} align 32
 
 const struct cs0 {
-  unsigned long   :0;
-  long longa;
+  unsigned long : 0;
+  long long a;
 } CS0 = {};
 // CHECK:  0 | struct cs0
 // CHECK-NEXT:   0:- |   unsigned long
@@ -22,8 +22,8 @@ const struct cs0 {
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 volatile struct vs0 {
-  long:0;
-  short   a;
+  long : 0;
+  short a;
 } VS0;
 // CHECK:  0 | struct vs0
 // CHECK-NEXT:   0:- |   long
@@ -31,11 +31,11 @@ volatile struct vs0 {
 // CHECK-NEXT:   | [sizeof=2, align=2]
 
 struct s0 {
-  short a:3;
-  long b:5;
-  int c:1;
-  long d:10;
-  char e:5;
+  short a : 3;
+  long b : 5;
+  int c : 1;
+  long d : 10;
+  char e : 5;
 } S0;
 // CHECK:  0 | struct s0
 // CHECK-NEXT: 0:0-2 |   short a
@@ -46,9 +46,9 @@ struct s0 {
 // CHECK-NEXT:   | [sizeof=3, align=1]
 
 struct s1 {
-  char a:7;
-  long b:27;
-  int c:2;
+  char a : 7;
+  long b : 27;
+  int c : 2;
 } S1;
 // CHECK:  0 | struct s1
 // CHECK-NEXT: 0:0-6 |   char a
@@ -57,10 +57,10 @@ struct s1 {
 // CHECK-NEXT:   | [sizeof=5, align=1]
 
 struct s2 {
-  char a:7;
-  char  :0;
-  short :0;
-  short :0;
+  char a : 7;
+  char : 0;
+  short : 0;
+  short : 0;
 } S2;
 // CHECK:  0 | struct s2
 // CHECK-NEXT: 0:0-6 |   char a
@@ -71,9 +71,9 @@ struct s2 {
 
 struct s3 {
   int a;
-  int b:16;
-  char  :0;
-  char c:1;
+  int b : 16;
+  char : 0;
+  char c : 1;
 } S3;
 // CHECK:  0 | struct s3
 // CHECK-NEXT: 0 |   int a
@@ -83,7 +83,7 @@ struct s3 {
 // CHECK-NEXT:   | [sizeof=12, align=4]
 
 struct s4 {
- unsigned int __attribute__((aligned(32))) a;
+  unsigned int __attribute__((aligned(32))) a;
 } S4;
 // CHECK:  0 | struct s4
 // CHECK-NEXT: 0 |   unsigned int a
@@ -91,10 +91,10 @@ struct s4 {
 
 struct s5 {
   char a;
-  int  b:19 __attribute__((aligned(4)));
-  int  c:22 __attribute__((aligned(8)));
-  int  :0;
-  int  d:10;
+  int b : 19 __attribute__((aligned(4)));
+  int c : 22 __attribute__((aligned(8)));
+  int : 0;
+  int d : 10;
 } S5;
 // CHECK:  0 | struct s5
 // CHECK-NEXT: 0 |   char a
@@ -105,8 +105,8 @@ struct s5 {
 // CHECK-NEXT:   | [sizeof=16, align=8]
 
 struct s6 {
-  char * a;
-  char * b[];
+  char *a;
+  char *b[];
 } S6;
 // CHECK:  0 | struct s6
 // CHECK-NEXT: 0 |   char * a
@@ -114,7 +114,7 @@ struct s6 {
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 struct s7 {
-  long  :0;
+  long : 0;
   short a;
 } S7;
 // CHECK:  0 | struct s7
@@ -124,8 +124,8 @@ struct s7 {
 
 #pragma pack(2)
 struct s8 {
-  unsigned long   :0;
-  long long   a;
+  unsigned long : 0;
+  long long a;
 } S8;
 #pragma pack()
 // CHECK:  0 | struct s8
@@ -134,8 +134,8 @@ struct s8 {
 // CHECK-NEXT:   | [sizeof=8, align=2]
 
 struct s9 {
-  unsigned int   :0;
-  unsigned short :0;
+  unsigned int : 0;
+  unsigned short : 0;
 } S9;
 // CHECK:  0 | struct s9
 // CHECK-NEXT:   0:- |   unsigned int
@@ -143,7 +143,7 @@ struct s9 {
 // CHECK-NEXT:   | [sizeof=0, align=1]
 
 struct s10 {
- unsigned int __attribute__((aligned)) a;
+  unsigned int __attribute__((aligned)) a;
 } S10;
 // CHECK:  0 | struct s10
 // CHECK-NEXT: 0 |   unsigned int a
@@ -151,7 +151,7 @@ struct s10 {
 
 struct s11 {
   char a;
-  long :0;
+  long : 0;
   char b;
 } S11;
 // CHECK:  0 | struct s11
@@ -161,9 +161,9 @@ struct s11 {
 // CHECK-NEXT:   | [sizeof=16, align=8]
 
 union u0 {
-  unsigned short d1 __attribute__((packed));
-  intd2:10;
-  long   d3;
+  unsigned short d1 __attribute__((packed));
+  int d2 : 10;
+  long d3;
 } U0 __attribute__((aligned(8)));
 // CHECK:  0 | union u0
 // CHECK-NEXT: 0 |   unsigned short d1
@@ -172,8 +172,8 @@ union u0 {
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 union u1 {
-  unsigned int:0;
-  short   a;
+  

[PATCH] D98160: [clang] Use decltype((E)) for compound requirement type constraint

2021-03-29 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

Thanks, I like this approach.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2761
 def note_expr_requirement_constraints_not_satisfied_simple : Note<
-  "%select{and|because}0 %1 does not satisfy %2:">;
+  "%select{and|because}0 'decltype((%1))' (aka %2) does not satisfy %3:">;
 def note_type_requirement_substitution_error : Note<

I don't think we need to talk about the mechanics of how we formed the type 
here. Also, adding a manual 'aka' like this will result in a double-aka 
(`decltype((foo))' (aka 'bar' (aka 'baz'))`) in some cases.

Aside [not something to address in this patch]: this (and other diagnostics 
nearby) also violate our [diagnostics best 
practices](https://clang.llvm.org/docs/InternalsManual.html#the-format-string) 
by redundantly including in the diagnostic the source expression that the caret 
will be pointing to, but perhaps that's justifiable in this case because we 
expect these expressions to be short and they're so central to what's being 
diagnosed.



Comment at: clang/lib/Sema/SemaConcept.cpp:448
diag::note_expr_requirement_constraints_not_satisfied_simple)
-<< (int)First << S.BuildDecltypeType(Req->getExpr(),
- Req->getExpr()->getBeginLoc())
+<< (int)First << e << S.getCanonicalTypeForParenthesizedExpr(e)
 << ConstraintExpr->getNamedConcept();

Please don't canonicalize the type here. If we've retained type sugar for the 
type of `e`, it'll be more helpful to the user if we present that type sugar.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98160

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


[PATCH] D98616: [RISCV] Add inline asm constraint 'v' in Clang for RISC-V 'V'.

2021-03-29 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper 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/D98616/new/

https://reviews.llvm.org/D98616

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


[PATCH] D99421: [ASTImporter] Import member specialization/instantiation of enum decls

2021-03-29 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik accepted this revision.
shafik added a comment.
This revision is now accepted and ready to land.

LGTM




Comment at: clang/unittests/AST/ASTImporterTest.cpp:6256
+  EXPECT_TRUE(ToD);
+  EXPECT_TRUE(ToD->getMemberSpecializationInfo());
+}

Is it worth also verifying the `TemplateSpecializationKind`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99421

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


[PATCH] D99456: [C++2b] Support size_t literals

2021-03-29 Thread Anton Bikineev via Phabricator via cfe-commits
AntonBikineev updated this revision to Diff 333972.
AntonBikineev marked an inline comment as done.
AntonBikineev added a comment.

Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99456

Files:
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/include/clang/Lex/LiteralSupport.h
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Lex/PPExpressions.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Lexer/cxx-features.cpp
  clang/test/Lexer/size_t-literal.cpp
  clang/test/SemaCXX/cxx1y-user-defined-literals.cpp
  clang/test/SemaCXX/size_t-literal.cpp

Index: clang/test/SemaCXX/size_t-literal.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/size_t-literal.cpp
@@ -0,0 +1,68 @@
+// RUN: %clang_cc1 -std=c++2b -Wc++2b-extensions -fsyntax-only -verify=cxx2b %s
+// RUN: %clang_cc1 -std=c++20 -Wc++2b-extensions -fsyntax-only -verify=cxx20 %s
+// RUN: %clang_cc1 -x c -std=c11 -fsyntax-only -verify=c11 %s
+
+#ifdef __cplusplus
+
+typedef __SIZE_TYPE__ size_t;
+// Assume ptrdiff_t is the signed integer type corresponding to size_t.
+typedef __PTRDIFF_TYPE__ ssize_t;
+
+template 
+struct is_same { static constexpr bool value = false; };
+
+template 
+struct is_same { static constexpr bool value = true; };
+
+// cxx2b-no-diagnostics
+
+void SSizeT() {
+  auto a1 = 1z; // cxx20-warning {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a2 = 1Z; // cxx20-warning {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+}
+
+void SizeT() {
+  auto a1 = 1uz; // cxx20-warning {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a2 = 1uZ; // cxx20-warning {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a3 = 1Uz; // cxx20-warning {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a4 = 1UZ; // cxx20-warning {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a5 = 1zu; // cxx20-warning {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a6 = 1Zu; // cxx20-warning {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a7 = 1zU; // cxx20-warning {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+
+  auto a8 = 1ZU; // cxx20-warning {{'size_t' suffix for literals is a C++2b extension}}
+  static_assert(is_same::value);
+}
+
+#else
+
+void f() {
+  (void)1z;  // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1Z;  // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1uz; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1uZ; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1Uz; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1UZ; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1zu; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1Zu; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1zU; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+  (void)1ZU; // c11-error {{'size_t' suffix for literals is a C++2b feature}}
+}
+
+#endif
Index: clang/test/SemaCXX/cxx1y-user-defined-literals.cpp
===
--- clang/test/SemaCXX/cxx1y-user-defined-literals.cpp
+++ clang/test/SemaCXX/cxx1y-user-defined-literals.cpp
@@ -34,7 +34,7 @@
 string s = "foo"s;
 char error = 'x's; // expected-error {{invalid suffix}} expected-error {{expected ';'}}
 
-int _1z = 1z; // expected-error {{invalid suffix}}
+int _1y = 1y; // expected-error {{invalid suffix}}
 int _1b = 1b; // expected-error {{invalid digit}}
 
 complex cf1 = 1if, cf2 = 2.if, cf3 = 0x3if;
Index: clang/test/Lexer/size_t-literal.cpp
===
--- /dev/null
+++ clang/test/Lexer/size_t-literal.cpp
@@ -0,0 +1,161 @@
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify %s
+
+#if 1z != 1
+#error "size_t suffix must be recognized by preprocessor"
+#endif
+#if 1uz != 1
+#error "size_t suffix must be recognized by preprocessor"
+#endif
+
+void ValidSuffix() {
+  // Decimal literals.
+  {
+auto a1 = 1z;
+auto a2 = 1Z;
+
+auto a3 = 1uz;
+auto a4 = 1uZ;
+auto a5 = 1Uz;
+auto a6 = 1UZ;
+
+auto a7 = 1zu;
+auto a8 = 1Zu;
+auto a9 = 1zU;
+auto a10 = 1ZU;
+
+auto a11 = 1'2z;
+auto a12 = 1'2Z;
+  }
+  // Hexadecimal literals.
+  {
+auto a1 = 0x1z;
+auto a2 = 0x1Z;
+
+auto a3 = 0x1uz;
+auto a4 = 0x1uZ;
+auto a5 = 0x1Uz;
+auto a6 = 0x1UZ;
+

[PATCH] D96906: [AMDGPU] gfx90a support

2021-03-29 Thread Stanislav Mekhanoshin via Phabricator via cfe-commits
rampitec marked an inline comment as done.
rampitec added inline comments.



Comment at: llvm/lib/Target/AMDGPU/SIFoldOperands.cpp:100
   bool tryFoldOMod(MachineInstr );
+  bool tryFoldRegSeqence(MachineInstr );
+  bool tryFoldLCSSAPhi(MachineInstr );

foad wrote:
> Spelling "sequence".
Thanks! https://reviews.llvm.org/rG619b88849e14


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96906

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


[PATCH] D96906: [AMDGPU] gfx90a support

2021-03-29 Thread Jay Foad via Phabricator via cfe-commits
foad added inline comments.
Herald added a subscriber: mstorsjo.



Comment at: llvm/lib/Target/AMDGPU/SIFoldOperands.cpp:100
   bool tryFoldOMod(MachineInstr );
+  bool tryFoldRegSeqence(MachineInstr );
+  bool tryFoldLCSSAPhi(MachineInstr );

Spelling "sequence".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96906

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


[PATCH] D99456: [C++2b] Support size_t literals

2021-03-29 Thread Anton Bikineev via Phabricator via cfe-commits
AntonBikineev marked 9 inline comments as done.
AntonBikineev added a comment.

Thanks Aaron for taking a look! Addressed the comments. I also hope it's okay 
to test preprocessor in the same test (test/Lexer/size_t-literal.cpp).




Comment at: clang/lib/Sema/SemaExpr.cpp:3911
+  if (Literal.isSizeT) {
+assert(Ty.isNull() && "size_t literals can't be Microsoft literals");
+unsigned SizeTSize = Context.getTargetInfo().getTypeWidth(

aaron.ballman wrote:
> The assert message doesn't seem to match the predicate -- why does a null 
> qualtype imply it's a microsoft literal?
Hm, agree, that's probably misleading. I've tried to check that the previous 
branch couldn't be taken if this one has been. I think 
"assert(!Literal.MicrosoftInteger && ...);" would make more sense.



Comment at: clang/test/SemaCXX/size_t-literal.cpp:14-16
+#if __cplusplus >= 202101L
+//  expected-no-diagnostics
+#endif

aaron.ballman wrote:
> Rather than check `__cplusplus` like this, I think the RUN lines should 
> specify a verify prefix. e.g., `-verify=cxx2b` and then use 
> `cxx2b-no-diagnostics` and `-verify=cxx20` and then use `cxx20-warning {{}}`.
Good idea, thanks! That has made the test much cleaner.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99456

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


[PATCH] D82317: [Clang/Test]: Update tests where `noundef` attribute is necessary

2021-03-29 Thread Juneyoung Lee via Phabricator via cfe-commits
aqjune added a comment.
Herald added a subscriber: lxfind.

Hello all,
Is there a plan to enable `-enable-noundef-analysis` by default? It seems this 
patch is already addressing a lot of test cases.
Another good news is that DeadArgElim is also fixed by D98899 
 to correctly drop UB-raising attributes such 
as noundef when replacing an unused argument with undef. This was an issue 
which is known to be problematic when the flag was activated.
I can make a patch based on this work instead if people want.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82317

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


[PATCH] D99484: Use `GNUInstallDirs` to support custom installation dirs.

2021-03-29 Thread John Ericson via Phabricator via cfe-commits
Ericson2314 updated this revision to Diff 333885.
Ericson2314 added a comment.



1. Updating D99484 : Use `GNUInstallDirs` to 
support custom installation dirs. #
2. Enter a brief description of the changes included in this update.
3. The first line is used as subject, next lines as comment. #
4. If you intended to create a new revision, use:
5. $ arc diff --create

Fix lint by renaming path -> Path


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99484

Files:
  clang-tools-extra/clang-doc/tool/CMakeLists.txt
  clang-tools-extra/clang-include-fixer/find-all-symbols/tool/CMakeLists.txt
  clang-tools-extra/clang-include-fixer/tool/CMakeLists.txt
  clang-tools-extra/clang-tidy/CMakeLists.txt
  clang-tools-extra/clang-tidy/tool/CMakeLists.txt
  clang-tools-extra/modularize/CMakeLists.txt
  clang/CMakeLists.txt
  clang/cmake/modules/AddClang.cmake
  clang/lib/Headers/CMakeLists.txt
  clang/tools/c-index-test/CMakeLists.txt
  clang/tools/clang-format/CMakeLists.txt
  clang/tools/clang-rename/CMakeLists.txt
  clang/tools/libclang/CMakeLists.txt
  clang/tools/scan-build/CMakeLists.txt
  clang/tools/scan-view/CMakeLists.txt
  clang/utils/hmaptool/CMakeLists.txt
  compiler-rt/CMakeLists.txt
  compiler-rt/cmake/Modules/AddCompilerRT.cmake
  compiler-rt/cmake/Modules/CompilerRTDarwinUtils.cmake
  compiler-rt/cmake/Modules/CompilerRTUtils.cmake
  compiler-rt/cmake/base-config-ix.cmake
  compiler-rt/include/CMakeLists.txt
  compiler-rt/lib/dfsan/CMakeLists.txt
  flang/CMakeLists.txt
  flang/cmake/modules/AddFlang.cmake
  flang/tools/f18/CMakeLists.txt
  flang/tools/flang-driver/CMakeLists.txt
  libc/CMakeLists.txt
  libc/lib/CMakeLists.txt
  libcxx/CMakeLists.txt
  libcxx/cmake/Modules/HandleLibCXXABI.cmake
  libcxx/include/CMakeLists.txt
  libcxx/src/CMakeLists.txt
  libcxxabi/CMakeLists.txt
  libunwind/CMakeLists.txt
  libunwind/src/CMakeLists.txt
  lld/CMakeLists.txt
  lld/cmake/modules/AddLLD.cmake
  lld/tools/lld/CMakeLists.txt
  lldb/CMakeLists.txt
  lldb/cmake/modules/AddLLDB.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/tools/intel-features/CMakeLists.txt
  llvm/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/cmake/modules/AddOCaml.cmake
  llvm/cmake/modules/AddSphinxTarget.cmake
  llvm/cmake/modules/CMakeLists.txt
  llvm/cmake/modules/LLVMInstallSymlink.cmake
  llvm/docs/CMake.rst
  llvm/examples/Bye/CMakeLists.txt
  llvm/include/llvm/CMakeLists.txt
  llvm/tools/llvm-config/BuildVariables.inc.in
  llvm/tools/llvm-config/llvm-config.cpp
  llvm/tools/lto/CMakeLists.txt
  llvm/tools/opt-viewer/CMakeLists.txt
  llvm/tools/remarks-shlib/CMakeLists.txt
  mlir/CMakeLists.txt
  mlir/cmake/modules/AddMLIR.cmake
  openmp/CMakeLists.txt
  openmp/libomptarget/plugins/amdgpu/CMakeLists.txt
  openmp/libomptarget/plugins/ve/CMakeLists.txt
  openmp/runtime/src/CMakeLists.txt
  openmp/tools/multiplex/CMakeLists.txt
  polly/CMakeLists.txt
  polly/cmake/CMakeLists.txt
  polly/cmake/polly_macros.cmake
  polly/lib/External/CMakeLists.txt
  pstl/CMakeLists.txt

Index: pstl/CMakeLists.txt
===
--- pstl/CMakeLists.txt
+++ pstl/CMakeLists.txt
@@ -7,6 +7,8 @@
 #===--===##
 cmake_minimum_required(VERSION 3.13.4)
 
+include(GNUInstallDirs)
+
 set(PARALLELSTL_VERSION_FILE "${CMAKE_CURRENT_SOURCE_DIR}/include/pstl/internal/pstl_config.h")
 file(STRINGS "${PARALLELSTL_VERSION_FILE}" PARALLELSTL_VERSION_SOURCE REGEX "#define _PSTL_VERSION .*$")
 string(REGEX REPLACE "#define _PSTL_VERSION (.*)$" "\\1" PARALLELSTL_VERSION_SOURCE "${PARALLELSTL_VERSION_SOURCE}")
@@ -81,15 +83,15 @@
 install(EXPORT ParallelSTLTargets
 FILE ParallelSTLTargets.cmake
 NAMESPACE pstl::
-DESTINATION lib/cmake/ParallelSTL)
+DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/ParallelSTL)
 install(FILES "${CMAKE_CURRENT_BINARY_DIR}/ParallelSTLConfig.cmake"
   "${CMAKE_CURRENT_BINARY_DIR}/ParallelSTLConfigVersion.cmake"
-DESTINATION lib/cmake/ParallelSTL)
+DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/ParallelSTL)
 install(DIRECTORY include/
-DESTINATION include
+DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
 PATTERN "*.in" EXCLUDE)
 install(FILES "${PSTL_CONFIG_SITE_PATH}"
-DESTINATION include)
+DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
 
 add_custom_target(install-pstl
   COMMAND "${CMAKE_COMMAND}" -P "${PROJECT_BINARY_DIR}/cmake_install.cmake" -DCOMPONENT=ParallelSTL)
Index: polly/lib/External/CMakeLists.txt
===
--- polly/lib/External/CMakeLists.txt
+++ polly/lib/External/CMakeLists.txt
@@ -275,7 +275,7 @@
 install(DIRECTORY
   ${ISL_SOURCE_DIR}/include/
   ${ISL_BINARY_DIR}/include/
-  DESTINATION include/polly
+  DESTINATION 

[PATCH] D99489: [clang] [PR49736] [C++2b] Correctly reject lambdas with requires clause and no parameter list

2021-03-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Mostly looks good, just a few things with the tests.




Comment at: clang/test/Parser/cxx-concepts-requires-clause.cpp:160-162
 #if __cplusplus <= 202002L
 // expected-warning@-2{{is a C++2b extension}}
 #endif

This warning seems less than ideal (same issue happens below).



Comment at: clang/test/Parser/cxx2a-template-lambdas.cpp:15
+#if __cplusplus <= 202002L
+// expected-warning@-2 {{is a C++2b extension}}
+#endif

You should spell out the full diagnostic the first time it's used in a file.



Comment at: clang/test/Parser/cxx2a-template-lambdas.cpp:17
+#endif
+auto L7 = [] requires true {}; // ?
+auto L8 = [] requires true noexcept {};

This seems grammatically valid to me, was there a reason for the `// ?`?



Comment at: clang/test/Parser/cxx2a-template-lambdas.cpp:33-36
+#if __cplusplus <= 202002L
+// expected-warning@-3 {{is a C++2b extension}}
+// expected-warning@-3 {{is a C++2b extension}}
+#endif

It seems odd to warn the user about use of an extension they're not really 
using, but I don't think this is strictly wrong as opposed to just not being 
ideal. I don't think this will be trivial to improve the behavior, so I think 
it's fine for the moment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99489

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


[PATCH] D17183: Make TargetInfo store an actual DataLayout instead of a string.

2021-03-29 Thread James Y Knight via Phabricator via cfe-commits
jyknight added a comment.

In general, I think it's extremely unfortunate that Clang and LLVM have 
different copies of the same information. It's a problem for way more than just 
this one situation. So, I really don't like choice 1 -- I think it's moving in 
the wrong direction.

The recent thread about compiler-rt libcalls vs size of "int" is another 
example of this sort of issue of duplicated info across the llvm/clang boundary 
being troublesome. Other times, the information in question is buried in the 
Target implementation in LLVM, and Clang doesn't depend upon targets being 
compiled in...usually, so it can't access it from there. E.g. the fact that 
Clang even has to come up with a DataLayout string on its own is an example of 
this problem.

So, I like option 2. I think a lot more of the information in TargetInfo ought 
to be shared with LLVM. I note that ARM already pushed a bunch of shared stuff 
into LLVM to reduce duplication, which is great. But, it had to put it into a 
rather odd place 
(`llvm/include/llvm/Support/{ARMTargetParser.h,ARMAttributeParser.h,...`), 
because of the layering and optionality concerns. That part is not so great -- 
putting all this target-specific info into "Support" doesn't feel like the best 
fit. There should be some sort of Target-specific location for this sort of 
stuff to live which Clang can depend on.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D17183

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


[PATCH] D99426: [Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

2021-03-29 Thread Abhina Sree via Phabricator via cfe-commits
abhina.sreeskantharajan updated this revision to Diff 333965.
abhina.sreeskantharajan edited the summary of this revision.
abhina.sreeskantharajan added a comment.

mention OF_CRLF is Windows-only


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99426

Files:
  clang-tools-extra/clang-move/tool/ClangMove.cpp
  clang-tools-extra/modularize/ModuleAssistant.cpp
  clang-tools-extra/pp-trace/PPTrace.cpp
  clang/lib/ARCMigrate/PlistReporter.cpp
  clang/lib/Driver/Compilation.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/DependencyFile.cpp
  clang/lib/Frontend/DependencyGraph.cpp
  clang/lib/Frontend/FrontendActions.cpp
  clang/lib/Frontend/HeaderIncludeGen.cpp
  clang/lib/Frontend/ModuleDependencyCollector.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
  clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
  clang/tools/clang-refactor/ClangRefactor.cpp
  clang/tools/driver/cc1as_main.cpp
  flang/lib/Frontend/CompilerInstance.cpp
  lld/COFF/DriverUtils.cpp
  lld/lib/ReaderWriter/YAML/ReaderWriterYAML.cpp
  lldb/include/lldb/Utility/ReproducerProvider.h
  lldb/source/Utility/GDBRemote.cpp
  lldb/source/Utility/ReproducerProvider.cpp
  lldb/tools/lldb-server/LLDBServerUtilities.cpp
  llvm/include/llvm/Analysis/DOTGraphTraitsPass.h
  llvm/include/llvm/Support/FileSystem.h
  llvm/lib/CodeGen/RegAllocPBQP.cpp
  llvm/lib/IR/Core.cpp
  llvm/lib/IR/LLVMRemarkStreamer.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/MC/MCParser/DarwinAsmParser.cpp
  llvm/lib/ProfileData/GCOV.cpp
  llvm/lib/ProfileData/SampleProfWriter.cpp
  llvm/lib/Support/FileCollector.cpp
  llvm/lib/Support/MemoryBuffer.cpp
  llvm/lib/Support/TimeProfiler.cpp
  llvm/lib/Support/Timer.cpp
  llvm/lib/Support/Unix/Program.inc
  llvm/lib/Support/Windows/Path.inc
  llvm/lib/Support/Windows/Program.inc
  llvm/lib/Transforms/IPO/Attributor.cpp
  llvm/lib/Transforms/IPO/LowerTypeTests.cpp
  llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
  llvm/lib/Transforms/Utils/Debugify.cpp
  llvm/tools/dsymutil/DwarfLinkerForBinary.cpp
  llvm/tools/dsymutil/dsymutil.cpp
  llvm/tools/llc/llc.cpp
  llvm/tools/lli/lli.cpp
  llvm/tools/llvm-cxxmap/llvm-cxxmap.cpp
  llvm/tools/llvm-dis/llvm-dis.cpp
  llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp
  llvm/tools/llvm-exegesis/lib/BenchmarkResult.cpp
  llvm/tools/llvm-link/llvm-link.cpp
  llvm/tools/llvm-mc/llvm-mc.cpp
  llvm/tools/llvm-mca/llvm-mca.cpp
  llvm/tools/llvm-opt-report/OptReport.cpp
  llvm/tools/llvm-profdata/llvm-profdata.cpp
  llvm/tools/llvm-xray/xray-account.cpp
  llvm/tools/llvm-xray/xray-converter.cpp
  llvm/tools/llvm-xray/xray-extract.cpp
  llvm/tools/llvm-xray/xray-graph-diff.cpp
  llvm/tools/llvm-xray/xray-graph.cpp
  llvm/tools/opt/opt.cpp
  llvm/tools/verify-uselistorder/verify-uselistorder.cpp
  llvm/unittests/Support/Path.cpp
  polly/lib/Exchange/JSONExporter.cpp

Index: polly/lib/Exchange/JSONExporter.cpp
===
--- polly/lib/Exchange/JSONExporter.cpp
+++ polly/lib/Exchange/JSONExporter.cpp
@@ -178,7 +178,7 @@
 
   // Write to file.
   std::error_code EC;
-  ToolOutputFile F(FileName, EC, llvm::sys::fs::OF_Text);
+  ToolOutputFile F(FileName, EC, llvm::sys::fs::OF_TextWithCRLF);
 
   std::string FunctionName = S.getFunction().getName().str();
   errs() << "Writing JScop '" << S.getNameStr() << "' in function '"
Index: llvm/unittests/Support/Path.cpp
===
--- llvm/unittests/Support/Path.cpp
+++ llvm/unittests/Support/Path.cpp
@@ -1253,7 +1253,7 @@
   path::append(FilePathname, "test");
 
   {
-raw_fd_ostream File(FilePathname, EC, sys::fs::OF_Text);
+raw_fd_ostream File(FilePathname, EC, sys::fs::OF_TextWithCRLF);
 ASSERT_NO_ERROR(EC);
 File << '\n';
   }
Index: llvm/tools/verify-uselistorder/verify-uselistorder.cpp
===
--- llvm/tools/verify-uselistorder/verify-uselistorder.cpp
+++ llvm/tools/verify-uselistorder/verify-uselistorder.cpp
@@ -136,7 +136,7 @@
 bool TempFile::writeAssembly(const Module ) const {
   LLVM_DEBUG(dbgs() << " - write assembly\n");
   std::error_code EC;
-  raw_fd_ostream OS(Filename, EC, sys::fs::OF_Text);
+  raw_fd_ostream OS(Filename, EC, sys::fs::OF_TextWithCRLF);
   if (EC) {
 errs() << "verify-uselistorder: error: " << EC.message() << "\n";
 return true;
Index: llvm/tools/opt/opt.cpp
===
--- llvm/tools/opt/opt.cpp
+++ llvm/tools/opt/opt.cpp
@@ -700,8 +700,8 @@
   OutputFilename = "-";
 
 std::error_code EC;
-sys::fs::OpenFlags Flags = OutputAssembly ? sys::fs::OF_Text
-  : sys::fs::OF_None;
+sys::fs::OpenFlags Flags =
+OutputAssembly ? 

[PATCH] D99426: [Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

2021-03-29 Thread Abhina Sree via Phabricator via cfe-commits
abhina.sreeskantharajan added a comment.

In D99426#2656582 , @MaskRay wrote:

> In D99426#2656217 , @rnk wrote:
>
>> In D99426#2653725 , @MaskRay wrote:
>>
>>> This touches a lot of files. I am a bit worried that it would not be easy 
>>> for a contributor to know OF_TextWithCRLF is needed to make SystemZ happy.
>>
>> Right, we need to separate text-ness for System/Z EBCDIC re-encoding from 
>> Windows CRLF translation. I think it's best to have a separate, positive 
>> CRLF bit, and to make that spelling longer than OF_Text. I think, in 
>> general, more problems are caused by extra unintended CRLF than by missing 
>> carriage returns.
>
> OK.
>
>> OF_CRLF which indicates that CRLF translation is used.
>> OF_TextWithCRLF = OF_Text | OF_CRLF indicates that the file is text and uses 
>> CRLF translation.
>
> My confusion came from I do not know what "CRLF translation" in the 
> description refers to. So it seems like EBCDIC->ASCII translation for CRLF? I 
> thought it was related to Windows.
>
> The current comment in the source code should be clarified too:
>
>   /// The file should be opened with CRLF translation on platforms that
>   /// make this distinction.
>   OF_CRLF = 2,
>   OF_TextWithCRLF = 3,

Sorry for causing confusion. CRLF in text files is a Windows-only problem, it 
doesn't affect z/OS. On z/OS we only need text files to be marked accurately as 
text. I updated the description and comments in FileSystem.h to be more clear.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99426

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


[PATCH] D98193: [CUDA][HIP] Allow non-ODR use of host var in device

2021-03-29 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

In principle this seems reasonable to me.


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

https://reviews.llvm.org/D98193

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


[PATCH] D98193: [CUDA][HIP] Allow non-ODR use of host var in device

2021-03-29 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:17050
+auto Target = SemaRef.IdentifyCUDATarget(FD);
+if (Var && Var->isFileVarDecl() && !Var->hasAttr() &&
+!Var->hasAttr() && !Var->hasAttr() &&

I suspect you want `hasGlobalStorage` rather than `isFileVarDecl` here (that 
is, preserve the condition from the deleted code), in order to disallow use of 
host-side local static variables from device-side functions:

```
__host__ void f() {
  static int n;
  struct X {
__device__ void g() { ++n; }
  };
  // ...
}
```


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

https://reviews.llvm.org/D98193

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


[PATCH] D99426: [Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

2021-03-29 Thread Abhina Sree via Phabricator via cfe-commits
abhina.sreeskantharajan updated this revision to Diff 333960.
abhina.sreeskantharajan edited the summary of this revision.
abhina.sreeskantharajan added a comment.

Rebase + I updated the comments in FileSystem.h to be a bit more descriptive.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99426

Files:
  clang-tools-extra/clang-move/tool/ClangMove.cpp
  clang-tools-extra/modularize/ModuleAssistant.cpp
  clang-tools-extra/pp-trace/PPTrace.cpp
  clang/lib/ARCMigrate/PlistReporter.cpp
  clang/lib/Driver/Compilation.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/DependencyFile.cpp
  clang/lib/Frontend/DependencyGraph.cpp
  clang/lib/Frontend/FrontendActions.cpp
  clang/lib/Frontend/HeaderIncludeGen.cpp
  clang/lib/Frontend/ModuleDependencyCollector.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
  clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
  clang/tools/clang-refactor/ClangRefactor.cpp
  clang/tools/driver/cc1as_main.cpp
  flang/lib/Frontend/CompilerInstance.cpp
  lld/COFF/DriverUtils.cpp
  lld/lib/ReaderWriter/YAML/ReaderWriterYAML.cpp
  lldb/include/lldb/Utility/ReproducerProvider.h
  lldb/source/Utility/GDBRemote.cpp
  lldb/source/Utility/ReproducerProvider.cpp
  lldb/tools/lldb-server/LLDBServerUtilities.cpp
  llvm/include/llvm/Analysis/DOTGraphTraitsPass.h
  llvm/include/llvm/Support/FileSystem.h
  llvm/lib/CodeGen/RegAllocPBQP.cpp
  llvm/lib/IR/Core.cpp
  llvm/lib/IR/LLVMRemarkStreamer.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/MC/MCParser/DarwinAsmParser.cpp
  llvm/lib/ProfileData/GCOV.cpp
  llvm/lib/ProfileData/SampleProfWriter.cpp
  llvm/lib/Support/FileCollector.cpp
  llvm/lib/Support/MemoryBuffer.cpp
  llvm/lib/Support/TimeProfiler.cpp
  llvm/lib/Support/Timer.cpp
  llvm/lib/Support/Unix/Program.inc
  llvm/lib/Support/Windows/Path.inc
  llvm/lib/Support/Windows/Program.inc
  llvm/lib/Transforms/IPO/Attributor.cpp
  llvm/lib/Transforms/IPO/LowerTypeTests.cpp
  llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
  llvm/lib/Transforms/Utils/Debugify.cpp
  llvm/tools/dsymutil/DwarfLinkerForBinary.cpp
  llvm/tools/dsymutil/dsymutil.cpp
  llvm/tools/llc/llc.cpp
  llvm/tools/lli/lli.cpp
  llvm/tools/llvm-cxxmap/llvm-cxxmap.cpp
  llvm/tools/llvm-dis/llvm-dis.cpp
  llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp
  llvm/tools/llvm-exegesis/lib/BenchmarkResult.cpp
  llvm/tools/llvm-link/llvm-link.cpp
  llvm/tools/llvm-mc/llvm-mc.cpp
  llvm/tools/llvm-mca/llvm-mca.cpp
  llvm/tools/llvm-opt-report/OptReport.cpp
  llvm/tools/llvm-profdata/llvm-profdata.cpp
  llvm/tools/llvm-xray/xray-account.cpp
  llvm/tools/llvm-xray/xray-converter.cpp
  llvm/tools/llvm-xray/xray-extract.cpp
  llvm/tools/llvm-xray/xray-graph-diff.cpp
  llvm/tools/llvm-xray/xray-graph.cpp
  llvm/tools/opt/opt.cpp
  llvm/tools/verify-uselistorder/verify-uselistorder.cpp
  llvm/unittests/Support/Path.cpp
  polly/lib/Exchange/JSONExporter.cpp

Index: polly/lib/Exchange/JSONExporter.cpp
===
--- polly/lib/Exchange/JSONExporter.cpp
+++ polly/lib/Exchange/JSONExporter.cpp
@@ -178,7 +178,7 @@
 
   // Write to file.
   std::error_code EC;
-  ToolOutputFile F(FileName, EC, llvm::sys::fs::OF_Text);
+  ToolOutputFile F(FileName, EC, llvm::sys::fs::OF_TextWithCRLF);
 
   std::string FunctionName = S.getFunction().getName().str();
   errs() << "Writing JScop '" << S.getNameStr() << "' in function '"
Index: llvm/unittests/Support/Path.cpp
===
--- llvm/unittests/Support/Path.cpp
+++ llvm/unittests/Support/Path.cpp
@@ -1253,7 +1253,7 @@
   path::append(FilePathname, "test");
 
   {
-raw_fd_ostream File(FilePathname, EC, sys::fs::OF_Text);
+raw_fd_ostream File(FilePathname, EC, sys::fs::OF_TextWithCRLF);
 ASSERT_NO_ERROR(EC);
 File << '\n';
   }
Index: llvm/tools/verify-uselistorder/verify-uselistorder.cpp
===
--- llvm/tools/verify-uselistorder/verify-uselistorder.cpp
+++ llvm/tools/verify-uselistorder/verify-uselistorder.cpp
@@ -136,7 +136,7 @@
 bool TempFile::writeAssembly(const Module ) const {
   LLVM_DEBUG(dbgs() << " - write assembly\n");
   std::error_code EC;
-  raw_fd_ostream OS(Filename, EC, sys::fs::OF_Text);
+  raw_fd_ostream OS(Filename, EC, sys::fs::OF_TextWithCRLF);
   if (EC) {
 errs() << "verify-uselistorder: error: " << EC.message() << "\n";
 return true;
Index: llvm/tools/opt/opt.cpp
===
--- llvm/tools/opt/opt.cpp
+++ llvm/tools/opt/opt.cpp
@@ -700,8 +700,8 @@
   OutputFilename = "-";
 
 std::error_code EC;
-sys::fs::OpenFlags Flags = OutputAssembly ? sys::fs::OF_Text
-  : sys::fs::OF_None;
+sys::fs::OpenFlags Flags =

[PATCH] D99414: [clang][tooling] Create SourceManager for DiagnosticsEngine before command-line parsing

2021-03-29 Thread Jordan Rupprecht via Phabricator via cfe-commits
rupprecht accepted this revision.
rupprecht added a comment.
This revision is now accepted and ready to land.

Thanks, the error message is much better now!

When applying this patch locally and also undoing the fix in our internal tool 
(i.e. change it to `-ferror-limit=-1`), the error I get is:

  message: "invalid integral value \'-1\' in \'-ferror-limit -1\'"

which, you know, actually tells me what to fix instead of giving some weird 
internal assertion :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99414

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


[PATCH] D99488: [SYCL][Doc] Add address space handling section to SYCL documentation

2021-03-29 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

Do you plan to implement any of the following restriction?

> To allocate local memory within a kernel, the user can either pass a 
> sycl::local_accessor object as a argument to an ND-range kernel (that has a 
> user-defined work-group size), or can define a variable in work-group scope 
> inside sycl::parallel_for_work_group.



> Explicit pointer class values cannot be passed as arguments to kernels or 
> stored in global memory.

Can I confirm that in your implementation any raw pointer obtained from 
`multi_ptr` will be in generic/default address space? This is something that 
might be worth adding in the documentation unless it is explained in the spec 
already?




Comment at: clang/docs/SYCLSupport.md:821
+SYCL compiler toolchain. Section 3.8.2 of SYCL 2020 specification defines
+[memory 
model](https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_sycl_device_memory_model),
+section 4.7.7 - [address space 
classes](https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_address_space_classes)

> The memory model for SYCL devices is based on the OpenCL 1.2 memory model.

Is this possibly a spec bug? OpenCL didn't have generic address space in v1.2, 
it has only been added in v2.0.

https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#the-generic-address-space





Comment at: clang/docs/SYCLSupport.md:830
+Similar to other single-source C++-based GPU programming modes like
+OpenMP/CUDA/HIP, SYCL uses clang's "default" address space for types with no
+address space attributes. This design has two important features: keeps the 
type system consistent with C++ on one hand and enable tools for emitting 
device code aligned with SPIR memory model (and other GPU targets).

Is this explained somewhere would you be able to add any reference?



Comment at: clang/docs/SYCLSupport.md:851
+
+Changing variable type has massive and destructive effect in C++. For instance
+this does not compile in C++ for OpenCL mode:

aaron.ballman wrote:
> 
> This example demonstrates the problem with compiling C++ code when address 
> space type qualifiers are inferred.
> 
> The example compiles in accordance with OpenCL language semantic...
> 
> https://godbolt.org/z/9jzxK5xc4 - ToT clang doesn't compile this example.

I am still not clear what message you are trying to convey here? In OpenCL 
kernel languages any object is always in some address space so if you write the 
following `decltype(p)`, it will always have address space attribute in a type. 
OpenCL spec is very explicit about this:

https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#addr-spaces-inference

So if you compare a type not attributed by an address space with an attributed 
one they will never compare as equal because according to C++ rules if the 
qualifiers differ the types will differ. You need to use a special type trait 
to remove an address space if you need to compare types not qualified by an 
address space. What is important to highlight however is that address space 
inference is where OpenCL differs to C or C++. But of course, neither C nor C++ 
have address spaces so it is hard to compare.

In relation to your documentation, it is not clear what you are trying to 
achieve with this paragraph?
 



Comment at: clang/docs/SYCLSupport.md:909
+| `__attribute__((opencl_local))` | local_space |
+| `__attribute__((opencl_private))` | private_space |
+

Since SYCL spec has constant AS you should explain whether it is going to be 
supported or not and if so then how.



Comment at: clang/docs/SYCLSupport.md:914-919
+Default address space represents "Generic-memory", which is a virtual address
+space which overlaps the global, local and private address spaces. SYCL mode
+enables conversion to/from default address space from/to address space
+attributed type.
+
+SPIR target allocates SYCL namespace scope variables in global address space.

Naghasan wrote:
> aaron.ballman wrote:
> > 
> I think this section should be extended.
> 
> Pointers to `Default` address space should get lowered into a pointer to a 
> generic address space (or flat to reuse more general terminology).
> But depending on the allocation context, the `default` address space of a 
> non-pointer type is assigned to a specific address space. This is described 
> in 
> https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:commonAddressSpace.
> 
> This is also in line with the behaviour of CUDA (small example 
> https://godbolt.org/z/veqTfo9PK).
Ok, if the implementation plans to follow the spec precisely then just adding a 
reference should be sufficient. 

Do I understand it correctly that your implementation will use the first 
approach from the two described in:
> If the target of 

[PATCH] D98538: [clangd] Perform merging for stale symbols in MergeIndex

2021-03-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 333956.
kadircet marked 3 inline comments as done.
kadircet added a comment.

- Add comments to the unittest to explain why we chose incorrect behaviour.
- Extract authorization logic to a helper.
- Count dropped symbols separately in fuzzyfind tracer stats.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98538

Files:
  clang-tools-extra/clangd/index/Index.h
  clang-tools-extra/clangd/index/Merge.cpp
  clang-tools-extra/clangd/unittests/IndexTests.cpp

Index: clang-tools-extra/clangd/unittests/IndexTests.cpp
===
--- clang-tools-extra/clangd/unittests/IndexTests.cpp
+++ clang-tools-extra/clangd/unittests/IndexTests.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "Annotations.h"
+#include "SyncAPI.h"
 #include "TestIndex.h"
 #include "TestTU.h"
 #include "index/FileIndex.h"
@@ -17,6 +18,7 @@
 #include "clang/Index/IndexSymbol.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
+#include 
 
 using ::testing::_;
 using ::testing::AllOf;
@@ -312,16 +314,28 @@
   AST = Test.build();
   DynamicIndex.updateMain(testPath(Test.Filename), AST);
 
-  // Merged index should not return the symbol definition if this definition
-  // location is inside a file from the dynamic index.
+  // Even though the definition is actually deleted in the newer version of the
+  // file, we still chose to merge with information coming from static index.
+  // This seems wrong, but is generic behavior we want for e.g. include headers
+  // which are always missing from the dynamic index
   LookupRequest LookupReq;
   LookupReq.IDs = {Foo.ID};
   unsigned SymbolCounter = 0;
   Merge.lookup(LookupReq, [&](const Symbol ) {
 ++SymbolCounter;
-EXPECT_FALSE(Sym.Definition);
+EXPECT_TRUE(Sym.Definition);
   });
   EXPECT_EQ(SymbolCounter, 1u);
+
+  // Drop the symbol completely.
+  Test.Code = "class Bar {};";
+  AST = Test.build();
+  DynamicIndex.updateMain(testPath(Test.Filename), AST);
+
+  // Now we don't expect to see the symbol at all.
+  SymbolCounter = 0;
+  Merge.lookup(LookupReq, [&](const Symbol ) { ++SymbolCounter; });
+  EXPECT_EQ(SymbolCounter, 0u);
 }
 
 TEST(MergeIndexTest, FuzzyFind) {
@@ -585,6 +599,44 @@
IncludeHeaderWithRef("new", 1u)));
 }
 
+TEST(MergeIndexTest, IncludeHeadersMerged) {
+  auto S = symbol("Z");
+  S.Definition.FileURI = "unittest:///foo.cc";
+
+  SymbolSlab::Builder DynB;
+  S.IncludeHeaders.clear();
+  DynB.insert(S);
+  SymbolSlab DynSymbols = std::move(DynB).build();
+  RefSlab DynRefs;
+  auto DynSize = DynSymbols.bytes() + DynRefs.bytes();
+  auto DynData = std::make_pair(std::move(DynSymbols), std::move(DynRefs));
+  llvm::StringSet<> DynFiles = {S.Definition.FileURI};
+  MemIndex DynIndex(std::move(DynData.first), std::move(DynData.second),
+RelationSlab(), std::move(DynFiles), IndexContents::Symbols,
+std::move(DynData), DynSize);
+
+  SymbolSlab::Builder StaticB;
+  S.IncludeHeaders.push_back({"", 0});
+  StaticB.insert(S);
+  auto StaticIndex =
+  MemIndex::build(std::move(StaticB).build(), RefSlab(), RelationSlab());
+  MergedIndex Merge(, StaticIndex.get());
+
+  EXPECT_THAT(runFuzzyFind(Merge, S.Name),
+  ElementsAre(testing::Field(
+  ::IncludeHeaders,
+  ElementsAre(IncludeHeaderWithRef("", 0u);
+
+  LookupRequest Req;
+  Req.IDs = {S.ID};
+  std::string IncludeHeader;
+  Merge.lookup(Req, [&](const Symbol ) {
+EXPECT_TRUE(IncludeHeader.empty());
+ASSERT_EQ(S.IncludeHeaders.size(), 1u);
+IncludeHeader = S.IncludeHeaders.front().IncludeHeader.str();
+  });
+  EXPECT_EQ(IncludeHeader, "");
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/index/Merge.cpp
===
--- clang-tools-extra/clangd/index/Merge.cpp
+++ clang-tools-extra/clangd/index/Merge.cpp
@@ -22,6 +22,19 @@
 namespace clang {
 namespace clangd {
 
+namespace {
+
+// Returns true if file defining/declaring \p S is covered by \p Index.
+bool isIndexAuthoritative(const SymbolIndex::IndexedFiles ,
+  const Symbol ) {
+  // We expect the definition to see the canonical declaration, so it seems to
+  // be enough to check only the definition if it exists.
+  const char *OwningFile =
+  S.Definition ? S.Definition.FileURI : S.CanonicalDeclaration.FileURI;
+  return (Index(OwningFile) & IndexContents::Symbols) != IndexContents::None;
+}
+} // namespace
+
 bool MergedIndex::fuzzyFind(
 const FuzzyFindRequest ,
 llvm::function_ref Callback) const {
@@ -37,36 +50,44 @@
   unsigned DynamicCount = 0;
   unsigned StaticCount = 0;
   unsigned MergedCount = 0;
+  // Number of results ignored due to 

[PATCH] D99459: [OpenMP] Implement '#pragma omp unroll'. WIP.

2021-03-29 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: clang/include/clang/AST/OpenMPClause.h:899
+public:
+  /// Build a 'sizes' AST node.
+  ///

`sizes`->`full`



Comment at: clang/include/clang/AST/OpenMPClause.h:902
+  /// \param C Context of the AST.
+  /// \param StartLoc  Location of the 'sizes' identifier.
+  /// \param LParenLoc Location of '('.

Same



Comment at: clang/include/clang/AST/OpenMPClause.h:903
+  /// \param StartLoc  Location of the 'sizes' identifier.
+  /// \param LParenLoc Location of '('.
+  /// \param EndLocLocation of ')'.

No param



Comment at: clang/include/clang/AST/OpenMPClause.h:904
+  /// \param LParenLoc Location of '('.
+  /// \param EndLocLocation of ')'.
+  /// \param Sizes Content of the clause.

Wrong description



Comment at: clang/include/clang/AST/OpenMPClause.h:905
+  /// \param EndLocLocation of ')'.
+  /// \param Sizes Content of the clause.
+  static OMPFullClause *Create(const ASTContext , SourceLocation StartLoc,

No param



Comment at: clang/include/clang/AST/OpenMPClause.h:912
+  /// \param C Context of the AST.
+  /// \param NumSizes Number of items in the clause.
+  static OMPFullClause *CreateEmpty(const ASTContext );

No param



Comment at: clang/include/clang/AST/OpenMPClause.h:946
+public:
+  /// Build a 'sizes' AST node.
+  ///

sizes->partial



Comment at: clang/include/clang/AST/OpenMPClause.h:948-952
+  /// \param C Context of the AST.
+  /// \param StartLoc  Location of the 'sizes' identifier.
+  /// \param LParenLoc Location of '('.
+  /// \param EndLocLocation of ')'.
+  /// \param Sizes Content of the clause.

Fix params descriptions



Comment at: clang/include/clang/AST/OpenMPClause.h:957-960
+  /// Build an empty 'sizes' AST node for deserialization.
+  ///
+  /// \param C Context of the AST.
+  /// \param NumSizes Number of items in the clause.

Description



Comment at: clang/include/clang/AST/OpenMPClause.h:971
+
+  void setFactor(Expr *E) { Factor = E; }
+

Make it private, if possible



Comment at: clang/include/clang/AST/StmtOpenMP.h:5037
 
+/// This represents the '#pragma omp tile' loop transformation directive.
+class OMPUnrollDirective final : public OMPLoopBasedDirective {

Description



Comment at: clang/include/clang/AST/StmtOpenMP.h:5061-5072
+  /// Create a new AST node representation for '#pragma omp tile'.
+  ///
+  /// \param C Context of the AST.
+  /// \param StartLoc  Location of the introducer (e.g. the 'omp' token).
+  /// \param EndLocLocation of the directive's end (e.g. the tok::eod).
+  /// \param Clauses   The directive's clauses.
+  /// \param NumLoops  Number of associated loops (number of items in the

Fix description



Comment at: clang/include/clang/AST/StmtOpenMP.h:5078-5082
+  /// Build an empty '#pragma omp tile' AST node for deserialization.
+  ///
+  /// \param C  Context of the AST.
+  /// \param NumClauses Number of clauses to allocate.
+  /// \param NumLoops   Number of associated loops to allocate.

Description



Comment at: clang/lib/AST/StmtProfile.cpp:466
 void OMPClauseProfiler::VisitOMPSizesClause(const OMPSizesClause *C) {
-  for (auto E : C->getSizesRefs())
+  for (Expr *E : C->getSizesRefs())
 if (E)

Unelated change?



Comment at: clang/lib/AST/StmtProfile.cpp:474
+void OMPClauseProfiler::VisitOMPPartialClause(const OMPPartialClause *C) {
+  if (Expr *Factor = C->getFactor())
+Profiler->VisitExpr(Factor);

`const Expr *`



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:2573
+
+  auto FullClauses = S.getClausesOfKind();
+  const OMPFullClause *FullClause = nullptr;

`getSingleClause` or `hasClausesOfKind`



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:2580
+
+  auto PartialClauses = S.getClausesOfKind();
+  const OMPPartialClause *PartialClause = nullptr;

`getSingleClause`



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:2589
+  if (PartialClause) {
+if (Expr *FactorExpr = PartialClause->getFactor()) {
+  RValue FactorRVal = EmitAnyExpr(FactorExpr, AggValueSlot::ignored(),

`const Expr *`



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:2590-2593
+  RValue FactorRVal = EmitAnyExpr(FactorExpr, AggValueSlot::ignored(),
+  /*ignoreResult=*/true);
+  Factor =
+  cast(FactorRVal.getScalarVal())->getZExtValue();

I suppose it is compiled-time 

[PATCH] D99292: [flang][driver] Add support for `-cpp/-nocpp`

2021-03-29 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added inline comments.



Comment at: clang/include/clang/Driver/Options.td:4302
+def cpp : Flag<["-"], "cpp">, Group,
+  HelpText<"Always add standard macro predefinitions">;
+def nocpp : Flag<["-"], "nocpp">, Group,

tskeith wrote:
> This option affects command line macro definitions too. So maybe something 
> like:
> `Enable predefined and command line preprocessor macros`
I've actually missed this case altogether - thank you for pointing it out. 
Updated accordingly.



Comment at: flang/lib/Frontend/FrontendOptions.cpp:23
   // TODO: Add Cuda Fortan files (i.e. `*.cuf` and `*.CUF`).
   return suffix == "f77" || suffix == "f90" || suffix == "F90" ||
   suffix == "ff90" || suffix == "f95" || suffix == "F95" ||

kiranchandramohan wrote:
> Unrelated comment: f77 is probably not free form.
Thanks for noticing and pointing out! https://reviews.llvm.org/D99494


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99292

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


[PATCH] D99292: [flang][driver] Add support for `-cpp/-nocpp`

2021-03-29 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski updated this revision to Diff 333953.
awarzynski added a comment.

Make sure that `-cpp\-nocpp` controls command line macro definitions too

As @tskeith pointed out, `-cpp\-nocpp` should also affect command line macro
definitions (on top of standard macro predefinitions). With this change, the
file extension becomes significant in all tests that depend on macros. I've
renamed some of them accordingly. Few other tests are updated to
demonstrate that the new flags work as expected.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99292

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/include/flang/Frontend/FrontendOptions.h
  flang/include/flang/Frontend/PreprocessorOptions.h
  flang/lib/Frontend/CompilerInstance.cpp
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendAction.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/Frontend/FrontendOptions.cpp
  flang/test/Driver/cpp-nocpp-command-line-macro.f90
  flang/test/Driver/cpp-nocpp-predefined-macro.F90
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/input-from-stdin.f90
  flang/test/Driver/macro-def-undef.F90
  flang/test/Driver/macro-def-undef.f90
  flang/test/Driver/macro-multiline.F90
  flang/test/Driver/macro-multiline.f90
  flang/test/Driver/predefined-macros-compiler-version.F90
  flang/test/Driver/predefined-macros-compiler-version.f90

Index: flang/test/Driver/predefined-macros-compiler-version.f90
===
--- /dev/null
+++ flang/test/Driver/predefined-macros-compiler-version.f90
@@ -1,26 +0,0 @@
-! Check that the driver correctly defines macros with the compiler version
-
-! REQUIRES: new-flang-driver
-
-!--
-! FLANG DRIVER (flang-new)
-!--
-! RUN: %flang-new -E %s  2>&1 | FileCheck %s --ignore-case
-
-!-
-! FRONTEND FLANG DRIVER (flang-new -fc1)
-!-
-! RUN: %flang-new -fc1 -E %s  2>&1 | FileCheck %s --ignore-case
-
-!-
-! EXPECTED OUTPUT
-!-
-! CHECK: flang = 1
-! CHECK: flang_major = {{[1-9][0-9]*$}}
-! CHECK: flang_minor = {{[0-9]+$}}
-! CHECK: flang_patchlevel = {{[0-9]+$}}
-
-integer, parameter :: flang = __flang__
-integer, parameter :: flang_major = __flang_major__
-integer, parameter :: flang_minor = __flang_minor__
-integer, parameter :: flang_patchlevel = __flang_patchlevel__
Index: flang/test/Driver/macro-multiline.f90
===
--- /dev/null
+++ flang/test/Driver/macro-multiline.f90
@@ -1,22 +0,0 @@
-! Ensure the end-of-line character and anything that follows after in a macro definition (-D) is ignored.
-
-! REQUIRES: new-flang-driver
-
-!--
-! FLANG DRIVER (flang-new)
-!--
-! RUN: printf -- "-DX=A\nTHIS_SHOULD_NOT_EXIST_IN_THE_OUTPUT\n" | xargs %flang-new -E %s  2>&1 | FileCheck --strict-whitespace --match-full-lines %s
-
-!-
-! FRONTEND FLANG DRIVER (flang-new -fc1)
-!-
-! RUN: printf -- "-DX=A\nTHIS_SHOULD_NOT_EXIST_IN_THE_OUTPUT\n" | xargs %flang-new -fc1 -E %s  2>&1 | FileCheck --strict-whitespace --match-full-lines %s
-
-!---
-! EXPECTED OUTPUT FOR MACRO 'X'
-!---
-! CHECK:start a end
-! CHECK-NOT:THIS_SHOULD_NOT_EXIST_IN_THE_OUTPUT
-! CHECK-NOT:this_should_not_exist_in_the_output
-
-START X END
\ No newline at end of file
Index: flang/test/Driver/macro-def-undef.F90
===
--- flang/test/Driver/macro-def-undef.F90
+++ flang/test/Driver/macro-def-undef.F90
@@ -1,20 +1,18 @@
 ! Ensure arguments -D and -U work as expected.
 
-! REQUIRES: new-flang-driver
-
 !--
 ! FLANG DRIVER (flang-new)
 !--
-! RUN: %flang-new -E %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
-! RUN: %flang-new -E -DX=A %s  2>&1 | FileCheck %s --check-prefix=DEFINED
-! RUN: %flang-new -E -DX=A -UX %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+! RUN: %flang -E %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+! RUN: %flang -E -DX=A %s  2>&1 | FileCheck %s --check-prefix=DEFINED
+! RUN: %flang -E -DX=A -UX %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
 
 !-
 ! FRONTEND FLANG DRIVER (flang-new -fc1)
 !-
-! RUN: %flang-new -fc1 -E %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
-! RUN: %flang-new -fc1 -E -DX=A %s  2>&1 | FileCheck %s --check-prefix=DEFINED
-! RUN: %flang-new -fc1 -E -DX -UX %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+! 

[PATCH] D99530: [OPENMP]Fix PR49098: respect firstprivate of declare target variable.

2021-03-29 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev created this revision.
ABataev added a reviewer: jdoerfert.
Herald added subscribers: guansong, yaxunl.
ABataev requested review of this revision.
Herald added a subscriber: sstefan1.
Herald added a project: clang.

Need to respect mapping/privatization of declare target variables in the
target regions if explicitly specified by the user.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99530

Files:
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/target_firstprivate_codegen.cpp

Index: clang/test/OpenMP/target_firstprivate_codegen.cpp
===
--- clang/test/OpenMP/target_firstprivate_codegen.cpp
+++ clang/test/OpenMP/target_firstprivate_codegen.cpp
@@ -43,6 +43,9 @@
   tx X;
   ty Y;
 };
+#pragma omp declare target
+int ga = 5;
+#pragma omp end declare target
 
 // CHECK-DAG:  [[TT:%.+]] = type { i64, i8 }
 // CHECK-DAG:  [[TTII:%.+]] = type { i32, i32 }
@@ -52,9 +55,9 @@
 // TCHECK-DAG:  [[TTII:%.+]] = type { i32, i32 }
 // TCHECK-DAG:  [[S1:%.+]] = type { double }
 
-// CHECK-DAG:  [[FP_E:@__omp_offloading_firstprivate_.+_e_l76]] = internal global [[TTII]] zeroinitializer
-// CHECK-DAG:  [[SIZET:@.+]] = private unnamed_addr constant [2 x i{{32|64}}] [i[[SZ:32|64]] 4, i{{64|32}} {{8|4}}]
-// CHECK-DAG:  [[MAPT:@.+]] = private unnamed_addr constant [2 x i64] [i64 288, i64 49]
+// CHECK-DAG:  [[FP_E:@__omp_offloading_firstprivate_.+_e_l79]] = internal global [[TTII]] zeroinitializer
+// CHECK-DAG:  [[SIZET:@.+]] = private unnamed_addr constant [3 x i{{32|64}}] [i[[SZ:32|64]] 4, i{{64|32}} {{8|4}}, i[[SZ:32|64]] 4]
+// CHECK-DAG:  [[MAPT:@.+]] = private unnamed_addr constant [3 x i64] [i64 288, i64 49, i64 288]
 // CHECK-DAG:  [[MAPT2:@.+]] = private unnamed_addr constant [9 x i64] [i64 288, i64 161, i64 800, i64 161, i64 161, i64 800, i64 800, i64 161, i64 161]
 // CHECK-DAG:  [[SIZET3:@.+]] = private unnamed_addr constant [2 x i{{32|64}}] [i{{32|64}} 0, i{{32|64}} 8]
 // CHECK-DAG:  [[MAPT3:@.+]] = private unnamed_addr constant [2 x i64] [i64 32, i64 37]
@@ -76,7 +79,7 @@
   const TT e = {n, n};
   int *p __attribute__ ((aligned (64))) = 
 
-#pragma omp target firstprivate(a, p)
+#pragma omp target firstprivate(a, p, ga)
   {
   }
 
@@ -91,8 +94,8 @@
   // CHECK:  [[D:%.+]] = alloca [[TT]],
   // CHECK:  [[P:%.+]] = alloca i32*, align 64
   // CHECK:  [[ACAST:%.+]] = alloca i{{[0-9]+}},
-  // CHECK:  [[BASE_PTR_ARR:%.+]] = alloca [2 x i8*],
-  // CHECK:  [[PTR_ARR:%.+]] = alloca [2 x i8*],
+  // CHECK:  [[BASE_PTR_ARR:%.+]] = alloca [3 x i8*],
+  // CHECK:  [[PTR_ARR:%.+]] = alloca [3 x i8*],
   // CHECK:  [[A2CAST:%.+]] = alloca i{{[0-9]+}},
   // CHECK:  [[BASE_PTR_ARR2:%.+]] = alloca [9 x i8*],
   // CHECK:  [[PTR_ARR2:%.+]] = alloca [9 x i8*],
@@ -116,29 +119,37 @@
   // CHECK-32:  store i{{[0-9]+}} [[AVAL]], i{{[0-9]+}}* [[ACAST]],
   // CHECK:  [[ACAST_VAL:%.+]] = load i{{[0-9]+}}, i{{[0-9]+}}* [[ACAST]],
   // CHECK:  [[P_PTR:%.+]] = load i32*, i32** [[P]], align 64
-  // CHECK:  [[BASE_PTR_GEP:%.+]] = getelementptr inbounds [2 x i8*], [2 x i8*]* [[BASE_PTR_ARR]], i{{[0-9]+}} 0, i{{[0-9]+}} 0
+  // CHECK:  [[BASE_PTR_GEP:%.+]] = getelementptr inbounds [3 x i8*], [3 x i8*]* [[BASE_PTR_ARR]], i{{[0-9]+}} 0, i{{[0-9]+}} 0
   // CHECK:  [[ACAST_TOPTR:%.+]] = bitcast i8** [[BASE_PTR_GEP]] to i{{[0-9]+}}*
   // CHECK:  store i{{[0-9]+}} [[ACAST_VAL]], i{{[0-9]+}}* [[ACAST_TOPTR]],
-  // CHECK:  [[PTR_GEP:%.+]] = getelementptr inbounds [2 x i8*], [2 x i8*]* [[PTR_ARR]], i{{[0-9]+}} 0, i{{[0-9]+}} 0
+  // CHECK:  [[PTR_GEP:%.+]] = getelementptr inbounds [3 x i8*], [3 x i8*]* [[PTR_ARR]], i{{[0-9]+}} 0, i{{[0-9]+}} 0
   // CHECK:  [[ACAST_TOPTR2:%.+]] = bitcast i8** [[PTR_GEP]] to i{{[0-9]+}}*
   // CHECK:  store i{{[0-9]+}} [[ACAST_VAL]], i{{[0-9]+}}* [[ACAST_TOPTR2]],
-  // CHECK:  [[BASE_PTR_GEP:%.+]] = getelementptr inbounds [2 x i8*], [2 x i8*]* [[BASE_PTR_ARR]], i{{[0-9]+}} 0, i{{[0-9]+}} 1
+  // CHECK:  [[BASE_PTR_GEP:%.+]] = getelementptr inbounds [3 x i8*], [3 x i8*]* [[BASE_PTR_ARR]], i{{[0-9]+}} 0, i{{[0-9]+}} 1
   // CHECK:  [[PCAST_TOPTR:%.+]] = bitcast i8** [[BASE_PTR_GEP]] to i32***
   // CHECK:  store i32** [[P]], i32*** [[PCAST_TOPTR]],
-  // CHECK:  [[PTR_GEP:%.+]] = getelementptr inbounds [2 x i8*], [2 x i8*]* [[PTR_ARR]], i{{[0-9]+}} 0, i{{[0-9]+}} 1
+  // CHECK:  [[PTR_GEP:%.+]] = getelementptr inbounds [3 x i8*], [3 x i8*]* [[PTR_ARR]], i{{[0-9]+}} 0, i{{[0-9]+}} 1
   // CHECK:  [[PCAST_TOPTR2:%.+]] = bitcast i8** [[PTR_GEP]] to i32**
   // CHECK:  store i32* [[P_PTR]], i32** [[PCAST_TOPTR2]],
-  // CHECK:  [[BASE_PTR_GEP_ARG:%.+]] = getelementptr inbounds [2 x i8*], [2 x i8*]* [[BASE_PTR_ARR]], i{{[0-9]+}} 0, i{{[0-9]+}} 0
-  // CHECK:  [[PTR_GEP_ARG:%.+]] = getelementptr inbounds [2 x i8*], [2 x i8*]* [[PTR_ARR]], i{{[0-9]+}} 0, i{{[0-9]+}} 0
-  // CHECK:  {{.+}} = call i32 @__tgt_target_mapper(%struct.ident_t* @{{.+}}, i64 -1, {{.+}}, i32 2, i8** [[BASE_PTR_GEP_ARG]], i8** [[PTR_GEP_ARG]], 

[PATCH] D99426: [Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

2021-03-29 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D99426#2656217 , @rnk wrote:

> In D99426#2653725 , @MaskRay wrote:
>
>> This touches a lot of files. I am a bit worried that it would not be easy 
>> for a contributor to know OF_TextWithCRLF is needed to make SystemZ happy.
>
> Right, we need to separate text-ness for System/Z EBCDIC re-encoding from 
> Windows CRLF translation. I think it's best to have a separate, positive CRLF 
> bit, and to make that spelling longer than OF_Text. I think, in general, more 
> problems are caused by extra unintended CRLF than by missing carriage returns.

OK.

> OF_CRLF which indicates that CRLF translation is used.
> OF_TextWithCRLF = OF_Text | OF_CRLF indicates that the file is text and uses 
> CRLF translation.

My confusion came from I do not know what "CRLF translation" in the description 
refers to. So it seems like EBCDIC->ASCII translation for CRLF? I thought it 
was related to Windows.

The current comment in the source code should be clarified too:

  /// The file should be opened with CRLF translation on platforms that
  /// make this distinction.
  OF_CRLF = 2,
  OF_TextWithCRLF = 3,


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99426

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


[PATCH] D99524: [RISCV][Clang] Add some RVV Integer intrinsic functions.

2021-03-29 Thread Zakk Chen via Phabricator via cfe-commits
khchen added a comment.

So sorry.. those huge tests make the browser so slowly, should I split them in 
the different patch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99524

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


[PATCH] D99528: [RISCV][Clang] Add more RVV Integer intrinsic functions.

2021-03-29 Thread Zakk Chen via Phabricator via cfe-commits
khchen created this revision.
khchen added reviewers: craig.topper, rogfer01, HsiangKai, evandro, liaolucy, 
jrtc27.
Herald added subscribers: vkmr, frasercrmck, dexonsmith, luismarques, apazos, 
sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, 
brucehoult, MartinMosbeck, edward-jones, zzheng, shiva0217, kito-cheng, niosHD, 
sabuasal, simoncook, johnrusso, rbar, asb.
khchen requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

Support below instructions.

1. Vector Integer Add-with-Carry / Subtract-with-Borrow Instructions
2. Vector Integer Comparison Instructions
3. Vector Widening Integer Multiply-Add Instructions


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99528

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vadc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmadc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmsbc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmseq.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmsgt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmsle.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmslt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmsne.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vsbc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vadc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmadc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmsbc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmseq.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmsgt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmsle.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmslt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmsne.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vsbc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vwmacc.c

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


[PATCH] D99526: [RISCV][Clang] Add RVV Widening Integer Add/Subtract intrinsic functions.

2021-03-29 Thread Zakk Chen via Phabricator via cfe-commits
khchen created this revision.
khchen added reviewers: craig.topper, rogfer01, HsiangKai, evandro, liaolucy, 
jrtc27.
Herald added subscribers: vkmr, frasercrmck, dexonsmith, luismarques, apazos, 
sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, 
brucehoult, MartinMosbeck, edward-jones, zzheng, shiva0217, kito-cheng, niosHD, 
sabuasal, simoncook, johnrusso, rbar, asb.
khchen requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99526

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vwsub.c

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


[PATCH] D99525: [RISCV][Clang] Add RVV vnsra, vnsrl and vwmul intrinsic functions.

2021-03-29 Thread Zakk Chen via Phabricator via cfe-commits
khchen created this revision.
khchen added reviewers: craig.topper, rogfer01, HsiangKai, evandro, liaolucy, 
jrtc27.
Herald added subscribers: vkmr, frasercrmck, dexonsmith, luismarques, apazos, 
sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, 
brucehoult, MartinMosbeck, edward-jones, zzheng, shiva0217, kito-cheng, niosHD, 
sabuasal, simoncook, johnrusso, rbar, asb.
khchen requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99525

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vnsra.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vnsrl.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vnsra.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vnsrl.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vwmul.c

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


[PATCH] D99524: [RISCV][Clang] Add some RVV Integer intrinsic functions.

2021-03-29 Thread Zakk Chen via Phabricator via cfe-commits
khchen created this revision.
khchen added reviewers: craig.topper, rogfer01, HsiangKai, evandro, liaolucy, 
jrtc27.
Herald added subscribers: vkmr, frasercrmck, dexonsmith, luismarques, apazos, 
sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, 
brucehoult, MartinMosbeck, edward-jones, zzheng, shiva0217, kito-cheng, niosHD, 
sabuasal, simoncook, johnrusso, rbar, asb.
khchen requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

1. Rename RVVBinBuiltin to RVVOutputOp1Builtin because it is not related

to the number of operand.

2. Add RVV Integer instuctions which use RVVOutputOp1Builtin.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99524

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vand.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vnmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vor.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vrem.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vrsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vsll.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vsra.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vsrl.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vxor.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vand.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vnmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vor.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vrem.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vrsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vsll.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vsra.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vsrl.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vxor.c

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


[PATCH] D99233: [HIP] Add option --gpu-inline-threshold

2021-03-29 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

I'm concerned that if we make it a top-level option, it's likely to be 
cargo-culted and (mis)used as a sledgehammer in cases where it's not needed. I 
think the option should remain hidden.

While thresholds do need to be tweaked,  in my experience it happens very 
rarely. 
When it does, most of the time it's sufficient to apply 
`__attribute__((always_inline))` to a few functions where it matters.
If AMDGPU bumps into the limit too often, perhaps it's the default threshold 
value that needs to be changed.

If we do add an option to control inlining threshold, then we should also 
consider doing the same for other thresholds. 
For instance, loop unrolling thresholds in my experience need bumping up about 
as often as the inlining ones. 
Similarly, most of the time the issue can be dealt with at the source code 
level with `#pragma unroll`.

Perhaps we should generalize this patch to deal with wider range of threshold. 
E.g. we could have something like `--gpu-threshold threshold-kind=x` which 
would expand to appropriate cc1 options for GPU sub-compilations.
It would also be nice to handle it in a way that can be used by both CUDA and 
HIP w/o having to copy/paste code.

Also, this patch would not be necessary if we had the generalized way to 
specify options for particular offload targets. Alas, we don't have it yet.


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

https://reviews.llvm.org/D99233

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


[PATCH] D98193: [CUDA][HIP] Allow non-ODR use of host var in device

2021-03-29 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D98193#2656326 , @tra wrote:

> I think we also may want to check that we allow `sizeof(host_var)` in the GPU 
> code.

We have tests for that at line 94 of test/SemaCUDA/device-use-host-var.cu


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

https://reviews.llvm.org/D98193

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


[PATCH] D99320: [RISCV] [1/2] Add intrinsic for Zbb extension

2021-03-29 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: clang/include/clang/Basic/BuiltinsRISCV.def:21
+// Zbb extension
+TARGET_BUILTIN(__builtin_riscv_orc_b, "LiLi", "nc", "experimental-zbb")
+TARGET_BUILTIN(__builtin_riscv32_orc_b, "ZiZi", "nc", "experimental-zbb")

Can we select between the 32 and 64 bit version in the header based on 
__riscv_xlen so we only need 2 builtins, rather than 3?



Comment at: clang/include/clang/Basic/BuiltinsRISCV.def:22
+TARGET_BUILTIN(__builtin_riscv_orc_b, "LiLi", "nc", "experimental-zbb")
+TARGET_BUILTIN(__builtin_riscv32_orc_b, "ZiZi", "nc", "experimental-zbb")
+TARGET_BUILTIN(__builtin_riscv64_orc_b, "WiWi", "nc", "experimental-zbb")

All RISCV builtins should start with "__builtin_riscv_". I don't think we 
should use riscv32/riscv64 here. Especially since the 32-bit version is 
available on RV64. So I think these should be named

__builtin_riscv_orc_b_32 and __builtin_riscv_orc_b_64.



Comment at: clang/include/clang/Basic/BuiltinsRISCV.def:23
+TARGET_BUILTIN(__builtin_riscv32_orc_b, "ZiZi", "nc", "experimental-zbb")
+TARGET_BUILTIN(__builtin_riscv64_orc_b, "WiWi", "nc", "experimental-zbb")
+

Ideally this would be "experimental-zbb,64bit" but I'm not sure that the 
frontend knows about "64bit".



Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:4175
+case Intrinsic::riscv_orc_b: {
+  SDValue LHS =
+  DAG.getNode(ISD::ANY_EXTEND, DL, MVT::i64, N->getOperand(0));

"LHS" stands for "left hand side", but operand 0 is the intrinsic ID which 
should already be i64. Only operand 1 needs to be extended. So just do

```
SDValue NewOp1 = DAG.getNode(ISD::ANY_EXTEND, DL, MVT::i64, N->getOperand(1));
SDValue Res = DAG.getNode(N->getOpcode(), DL, MVT::i64, N->getOperand(0), 
NewOp1);
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99320

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


[PATCH] D99521: [OPENMP]Fix PR48885: Crash in passing firstprivate args to tasks on Apple M1.

2021-03-29 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev created this revision.
ABataev added a reviewer: jdoerfert.
Herald added subscribers: guansong, yaxunl.
ABataev requested review of this revision.
Herald added a project: clang.

Need to bitcast the function pointer passed as a parameter to the real
type to avoid possible problem with calling conventions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99521

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/declare_mapper_codegen.cpp
  clang/test/OpenMP/master_taskloop_firstprivate_codegen.cpp
  clang/test/OpenMP/master_taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/master_taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/master_taskloop_private_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_private_codegen.cpp
  clang/test/OpenMP/nvptx_param_translate.c
  clang/test/OpenMP/parallel_master_taskloop_firstprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_private_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_private_codegen.cpp
  clang/test/OpenMP/target_codegen.cpp
  clang/test/OpenMP/target_depend_codegen.cpp
  clang/test/OpenMP/target_enter_data_codegen.cpp
  clang/test/OpenMP/target_enter_data_depend_codegen.cpp
  clang/test/OpenMP/target_exit_data_codegen.cpp
  clang/test/OpenMP/target_exit_data_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_codegen.cpp
  clang/test/OpenMP/target_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_depend_codegen.cpp
  clang/test/OpenMP/target_simd_depend_codegen.cpp
  clang/test/OpenMP/target_teams_codegen.cpp
  clang/test/OpenMP/target_teams_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_simd_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
  clang/test/OpenMP/target_update_codegen.cpp
  clang/test/OpenMP/target_update_depend_codegen.cpp
  clang/test/OpenMP/task_codegen.cpp
  clang/test/OpenMP/task_firstprivate_codegen.cpp
  clang/test/OpenMP/task_in_reduction_codegen.cpp
  clang/test/OpenMP/task_private_codegen.cpp
  clang/test/OpenMP/taskloop_firstprivate_codegen.cpp
  clang/test/OpenMP/taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/taskloop_private_codegen.cpp
  clang/test/OpenMP/taskloop_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/taskloop_simd_private_codegen.cpp
  clang/test/OpenMP/taskloop_with_atomic_codegen.cpp

Index: clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
===
--- clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
+++ clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
@@ -27,6 +27,7 @@
 // Check that occupanices var is firstprivatized.
 // CHECK-DAG: atomicrmw add i32* [[FP_OCCUP:%.+]], i32 1 monotonic, align 4
 // CHECK-DAG: [[FP_OCCUP]] = load i32*, i32** [[FP_OCCUP_ADDR:%[^,]+]],
-// CHECK-DAG: call void (i8*, ...) %{{.+}}(i8* %{{.+}}, i32** [[FP_OCCUP_ADDR]])
+// CHECK-DAG: [[FN:%.+]] = bitcast void (i8*, ...)* %{{.*}} to void (i8*,
+// CHECK-DAG: call void [[FN]](i8* %{{.+}}, i32** [[FP_OCCUP_ADDR]])
 
 #endif
Index: clang/test/OpenMP/taskloop_simd_private_codegen.cpp
===
--- clang/test/OpenMP/taskloop_simd_private_codegen.cpp
+++ clang/test/OpenMP/taskloop_simd_private_codegen.cpp
@@ -230,7 +230,8 @@
 // CHECK: [[PRIV_SIVAR_ADDR:%.+]] = alloca i32*,
 // CHECK: store void (i8*, ...)* bitcast (void ([[PRIVATES_MAIN_TY]]*, [[S_DOUBLE_TY]]**, i32**, [2 x [[S_DOUBLE_TY]]]**, [2 x i32]**, i32**)* [[PRIVATES_MAP_FN]] to void (i8*, ...)*), void (i8*, ...)** [[MAP_FN_ADDR:%.+]],
 // CHECK: [[MAP_FN:%.+]] = load void (i8*, ...)*, void (i8*, ...)** [[MAP_FN_ADDR]],
-// CHECK: call void (i8*, ...) [[MAP_FN]](i8* %{{.+}}, [[S_DOUBLE_TY]]** [[PRIV_VAR_ADDR]], i32** [[PRIV_T_VAR_ADDR]], [2 x [[S_DOUBLE_TY]]]** [[PRIV_S_ARR_ADDR]], [2 x i32]** [[PRIV_VEC_ADDR]], i32** [[PRIV_SIVAR_ADDR]])
+// CHECK: [[FN:%.+]] = bitcast void (i8*, ...)* [[MAP_FN]] to void (i8*,
+// CHECK: call void [[FN]](i8* %{{.+}}, [[S_DOUBLE_TY]]** [[PRIV_VAR_ADDR]], i32** 

[PATCH] D99005: [clang] Implement P2266 Simpler implicit move

2021-03-29 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov updated this revision to Diff 333925.
mizvekov added a comment.

Small update making some invariants more clear, with some simplifications.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99005

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCoroutine.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/class/class.init/class.copy.elision/p3.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p7-cxx14.cpp
  clang/test/CXX/drs/dr3xx.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/p4-cxx14.cpp
  clang/test/CXX/temp/temp.decls/temp.mem/p5.cpp
  clang/test/SemaCXX/constant-expression-cxx11.cpp
  clang/test/SemaCXX/constant-expression-cxx14.cpp
  clang/test/SemaCXX/coroutine-rvo.cpp
  clang/test/SemaCXX/coroutines.cpp
  clang/test/SemaCXX/deduced-return-type-cxx14.cpp
  clang/test/SemaCXX/return-stack-addr.cpp
  clang/test/SemaCXX/warn-return-std-move.cpp

Index: clang/test/SemaCXX/warn-return-std-move.cpp
===
--- clang/test/SemaCXX/warn-return-std-move.cpp
+++ clang/test/SemaCXX/warn-return-std-move.cpp
@@ -1,8 +1,8 @@
-// RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify=cxx20_2b -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=cxx20_2b -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify=cxx11_17 -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify=cxx11_17 -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=cxx11_17 -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify=cxx20_2b,cxx2b -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=cxx20_2b   -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify=cxx11_17   -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify=cxx11_17   -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=cxx11_17   -fcxx-exceptions -Wreturn-std-move %s
 
 // RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcxx-exceptions -Wreturn-std-move -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s -check-prefix=CHECK
 // RUN: %clang_cc1 -std=c++14 -fsyntax-only -fcxx-exceptions -Wreturn-std-move -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s -check-prefix=CHECK
@@ -217,8 +217,8 @@
 }
 
 // But if the return type is a reference type, then moving would be wrong.
-Derived& testRetRef1(Derived&& d) { return d; }
-Base& testRetRef2(Derived&& d) { return d; }
+Derived (Derived &) { return d; } // cxx2b-error {{on-const lvalue reference to type 'Derived' cannot bind to a temporary of type 'Derived'}}
+Base (Derived &) { return d; }// cxx2b-error {{non-const lvalue reference to type 'Base' cannot bind to a temporary of type 'Derived'}}
 #if __cplusplus >= 201402L
 auto&& testRetRef3(Derived&& d) { return d; }
 decltype(auto) testRetRef4(Derived&& d) { return (d); }
Index: clang/test/SemaCXX/return-stack-addr.cpp
===
--- clang/test/SemaCXX/return-stack-addr.cpp
+++ clang/test/SemaCXX/return-stack-addr.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify=expected   %s
-// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=expected   %s
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11 %s
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify=expected,cxx2b  %s
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=expected,cxx11_20   %s
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11 %s
 
 int* ret_local() {
   int x = 1;
@@ -29,7 +29,8 @@
 
 int& ret_local_ref() {
   int x = 1;
-  return x;  // expected-warning {{reference to stack memory}}
+  return x; // cxx11_20-warning {{reference to stack memory}}
+  // cxx2b-error@-1 {{non-const lvalue reference to type 'int' cannot bind to a temporary of type 'int'}}
 }
 
 int* ret_local_addrOf() {
@@ -154,8 +155,10 @@
   (void) [&]() -> int& { return b; };
   (void) [=]() mutable -> int& { return a; };
   (void) [=]() mutable -> int& { return b; };
-  (void) [&]() -> int& { int a; return a; }; // expected-warning {{reference to stack}}
-  (void) [=]() -> int& { int a; return a; }; // expected-warning {{reference to stack}}
+  (void) [&]() -> int& { int a; return a; }; // cxx11_20-warning {{reference to stack}}
+  // cxx2b-error@-1 {{non-const lvalue reference to type 'int' cannot bind to a temporary of type 'int'}}
+  (void) [=]() -> int& { int a; return a; }; // cxx11_20-warning {{reference to stack}}
+  // cxx2b-error@-1 {{non-const lvalue 

[PATCH] D98193: [CUDA][HIP] Allow non-ODR use of host var in device

2021-03-29 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

I think we also may want to check that we allow `sizeof(host_var)` in the GPU 
code.


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

https://reviews.llvm.org/D98193

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


[PATCH] D17183: Make TargetInfo store an actual DataLayout instead of a string.

2021-03-29 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

I think 1 is OK as long as we can assert that things don't get out of sync. I 
like the idea of putting the prefix next to the data layout string.

In the long run, splitting up Support might be reasonable, and pushing 
DataLayout down out of IR seems like something that could happen at that time. 
I would like to reduce the set of things that tablgen depends on by making 
Support into a smaller library of just system APIs and data structures, moving 
everything else out. Maybe the right way to do that is to leave Support as the 
ambiguous, kitchen sink library, and make a smaller, more targeted library 
under it. We already have the notion of the ADT library in our header structure 
for data structures. We used to have the System library before it was merged 
with Support. I think the only thing blocking this refactoring is the will to 
disentangle the circular dependencies.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D17183

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


[PATCH] D99514: [NFC] clang-formatting zos-alignment.c

2021-03-29 Thread Abhina Sree via Phabricator via cfe-commits
abhina.sreeskantharajan accepted this revision.
abhina.sreeskantharajan 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/D99514/new/

https://reviews.llvm.org/D99514

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


[PATCH] D99426: [Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

2021-03-29 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

In D99426#2653725 , @MaskRay wrote:

> This touches a lot of files. I am a bit worried that it would not be easy for 
> a contributor to know OF_TextWithCRLF is needed to make SystemZ happy.

Right, we need to separate text-ness for System/Z EBCDIC re-encoding from 
Windows CRLF translation. I think it's best to have a separate, positive CRLF 
bit, and to make that spelling longer than OF_Text. I think, in general, more 
problems are caused by extra unintended CRLF than by missing carriage returns.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99426

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


[PATCH] D99353: [driver] Make `clang` warn rather then error on `flang` options

2021-03-29 Thread Joachim Protze via Phabricator via cfe-commits
protze.joachim added a comment.

Thank you for working on this! It works for me.
As you mentioned in D95460 , this makes the 
behavior more similar to gcc.

I tested with `-Werror`:

  $ flang -fopenmp test-f77.f -ffree-form -c
  $ clang -fopenmp test-f77.o -ffree-form -lgfortran -Werror && echo $?
  clang-13: warning: command line option ‘-ffree-form’ is only valid in Flang 
mode (i.e. for Fortran input)
  clang-13: error: argument unused during compilation: '-ffree-form' 
[-Werror,-Wunused-command-line-argument]

Since `-Werror` only raises the second warning, 
`-Wno-error=unused-command-line-argument` allows to successfully compile with 
`-Werror`.

  $ clang -fopenmp test-f77.o -ffree-form -lgfortran -Werror 
-Wno-error=unused-command-line-argument && echo $?
  clang-13: warning: command line option ‘-ffree-form’ is only valid in Flang 
mode (i.e. for Fortran input)
  clang-13: warning: argument unused during compilation: '-ffree-form' 
[-Wunused-command-line-argument]
  0

I also tested with `-ffixed-form` and `-ffixed-line-length-132`. The latter 
doesn't work, while `-ffixed-line-length=132` works.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99353

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


[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

2021-03-29 Thread Josh Haberman via Phabricator via cfe-commits
haberman updated this revision to Diff 333914.
haberman added a comment.

- Updated formatting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99517

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/JumpDiagnostics.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/test/CodeGen/attr-musttail.cpp
  clang/test/Sema/attr-musttail.cpp

Index: clang/test/Sema/attr-musttail.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-musttail.cpp
@@ -0,0 +1,137 @@
+// RUN: %clang_cc1 -verify -fsyntax-only %s
+
+int Bar();
+
+int Func1() {
+  [[clang::musttail(1, 2)]] Bar(); // expected-error {{'musttail' attribute takes no arguments}}
+  [[clang::musttail]] Bar();   // expected-error {{musttail attribute can only be applied to a return statement}}
+  [[clang::musttail]] return 5;// expected-error {{musttail attribute requires that the return value is a function call}}
+  [[clang::musttail]] return Bar();
+}
+
+int f();
+
+[[clang::musttail]] static int i = f(); // expected-error {{'musttail' attribute cannot be applied to a declaration}}
+
+long g(int x);
+int h(long x);
+
+class Foo {
+public:
+  int MemberFunction(int x);
+  int MemberFunction2();
+};
+
+int Func2(int x) {
+  // Param arity differs.
+  [[clang::musttail]] return Bar(); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+  // Return type differs.
+  [[clang::musttail]] return g(x); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+  // Param type differs.
+  [[clang::musttail]] return h(x); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+  // "this" pointer differs.
+  Foo foo;
+  [[clang::musttail]] return foo.MemberFunction(x); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+}
+
+int j = 0;
+
+class HasNonTrivialDestructor {
+public:
+  ~HasNonTrivialDestructor() { j--; }
+};
+
+int ReturnsInt(int x);
+
+int Func3(int x) {
+  HasNonTrivialDestructor foo;  // expected-note {{jump exits scope of variable with non-trivial destructor}}
+  [[clang::musttail]] return ReturnsInt(x); // expected-error {{musttail attribute does not allow any variables in scope that require destruction}}
+}
+
+int Func4(int x) {
+  HasNonTrivialDestructor foo; // expected-note {{jump exits scope of variable with non-trivial destructor}}
+  {
+[[clang::musttail]] return ReturnsInt(x); // expected-error {{musttail attribute does not allow any variables in scope that require destruction}}
+  }
+}
+
+int NonTrivialParam(HasNonTrivialDestructor x);
+
+int Func5(HasNonTrivialDestructor x) {
+  [[clang::musttail]] return NonTrivialParam(x); // expected-error {{musttail attribute requires that the return value is a function call, which must not create or destroy any temporaries}}
+}
+
+HasNonTrivialDestructor ReturnsNonTrivialValue();
+
+HasNonTrivialDestructor Func6() {
+  [[clang::musttail]] return ReturnsNonTrivialValue(); // expected-error {{musttail attribute requires that the return value is a function call, which must not create or destroy any temporaries}}
+}
+
+int Func8(Foo *foo, int (Foo::*p_mem)()) {
+  [[clang::musttail]] return (foo->*p_mem)(); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+}
+
+int Func10(Foo *foo) {
+  [[clang::musttail]] return foo->MemberFunction2(); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+}
+
+void Func7() {
+  HasNonTrivialDestructor foo;
+  class Nested {
+__attribute__((noinline)) static int NestedMethod(int x) {
+  // This is ok.
+  [[clang::musttail]] return ReturnsInt(x);
+}
+  };
+}
+
+struct Data {
+  int (Data::*pmf)();
+  typedef int Func(Data *);
+  static void StaticMethod();
+  void NonStaticMethod() {
+[[clang::musttail]] return StaticMethod(); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+  }
+
+  void BadPMF() {
+// We need to specially handle this, otherwise it can crash the compiler.
+[[clang::musttail]] return ((*this)->*pmf)(); // expected-error {{left hand operand to ->* must be a pointer to class compatible with the right hand operand, but is 'Data'}}
+  }
+};
+
+Data 

[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

2021-03-29 Thread Josh Haberman via Phabricator via cfe-commits
haberman created this revision.
haberman added reviewers: rsmith, aaron.ballman.
haberman requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This is a Clang-only change and depends on the existing "musttail"
support already implemented in LLVM.

The [[clang::musttail]] attribute goes on a return statement, not
a function definition. There are several constraints that the user
must follow when using [[clang::musttail]], and these constraints
are verified by Sema.

Tail calls are supported on regular function calls, calls through a
function pointer, member function calls, and even pointer to member.

Future work would be to throw a warning if a users tries to pass
a pointer or reference to a local variable through a musttail call.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99517

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/JumpDiagnostics.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/test/CodeGen/attr-musttail.cpp
  clang/test/Sema/attr-musttail.cpp

Index: clang/test/Sema/attr-musttail.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-musttail.cpp
@@ -0,0 +1,137 @@
+// RUN: %clang_cc1 -verify -fsyntax-only %s
+
+int Bar();
+
+int Func1() {
+  [[clang::musttail(1, 2)]] Bar(); // expected-error {{'musttail' attribute takes no arguments}}
+  [[clang::musttail]] Bar(); // expected-error {{musttail attribute can only be applied to a return statement}}
+  [[clang::musttail]] return 5; // expected-error {{musttail attribute requires that the return value is a function call}}
+  [[clang::musttail]] return Bar();
+}
+
+int f();
+
+[[clang::musttail]] static int i = f(); // expected-error {{'musttail' attribute cannot be applied to a declaration}}
+
+long g(int x);
+int h(long x);
+
+class Foo {
+ public:
+  int MemberFunction(int x);
+  int MemberFunction2();
+};
+
+int Func2(int x) {
+  // Param arity differs.
+  [[clang::musttail]] return Bar(); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+  // Return type differs.
+  [[clang::musttail]] return g(x); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+  // Param type differs.
+  [[clang::musttail]] return h(x); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+  // "this" pointer differs.
+  Foo foo;
+  [[clang::musttail]] return foo.MemberFunction(x); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+}
+
+int j = 0;
+
+class HasNonTrivialDestructor {
+ public:
+  ~HasNonTrivialDestructor() { j--; }
+};
+
+int ReturnsInt(int x);
+
+int Func3(int x) {
+  HasNonTrivialDestructor foo;  // expected-note {{jump exits scope of variable with non-trivial destructor}}
+  [[clang::musttail]] return ReturnsInt(x);  // expected-error {{musttail attribute does not allow any variables in scope that require destruction}}
+}
+
+int Func4(int x) {
+  HasNonTrivialDestructor foo;  // expected-note {{jump exits scope of variable with non-trivial destructor}}
+  {
+[[clang::musttail]] return ReturnsInt(x);  // expected-error {{musttail attribute does not allow any variables in scope that require destruction}}
+  }
+}
+
+int NonTrivialParam(HasNonTrivialDestructor x);
+
+int Func5(HasNonTrivialDestructor x) {
+  [[clang::musttail]] return NonTrivialParam(x);  // expected-error {{musttail attribute requires that the return value is a function call, which must not create or destroy any temporaries}}
+}
+
+HasNonTrivialDestructor ReturnsNonTrivialValue();
+
+HasNonTrivialDestructor Func6() {
+  [[clang::musttail]] return ReturnsNonTrivialValue();  // expected-error {{musttail attribute requires that the return value is a function call, which must not create or destroy any temporaries}}
+}
+
+int Func8(Foo* foo, int (Foo::*p_mem)()) {
+  [[clang::musttail]] return (foo->*p_mem)(); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+}
+
+int Func10(Foo* foo) {
+  [[clang::musttail]] return foo->MemberFunction2(); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+}
+
+void Func7() {
+  HasNonTrivialDestructor foo;
+  class Nested {
+__attribute__((noinline)) static int NestedMethod(int x) {
+  // This is ok.
+  [[clang::musttail]] return 

[PATCH] D98146: OpaquePtr: Turn inalloca into a type attribute

2021-03-29 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D98146#2654598 , @arsenm wrote:

> 4fefed65637ec46c8c2edad6b07b5569ac61e9e5 
> 

Please include the "Differential Revision: ..." line in the commit message - it 
automatically closes the review with the details of the commit (including 
updating to show what was committed/what changes were made between review and 
commit) and helps find the review from the commit, etc.


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

https://reviews.llvm.org/D98146

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


[PATCH] D99488: [SYCL][Doc] Add address space handling section to SYCL documentation

2021-03-29 Thread Victor Lomuller via Phabricator via cfe-commits
Naghasan added inline comments.



Comment at: clang/docs/SYCLSupport.md:914-919
+Default address space represents "Generic-memory", which is a virtual address
+space which overlaps the global, local and private address spaces. SYCL mode
+enables conversion to/from default address space from/to address space
+attributed type.
+
+SPIR target allocates SYCL namespace scope variables in global address space.

aaron.ballman wrote:
> 
I think this section should be extended.

Pointers to `Default` address space should get lowered into a pointer to a 
generic address space (or flat to reuse more general terminology).
But depending on the allocation context, the `default` address space of a 
non-pointer type is assigned to a specific address space. This is described in 
https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:commonAddressSpace.

This is also in line with the behaviour of CUDA (small example 
https://godbolt.org/z/veqTfo9PK).



Comment at: clang/docs/SYCLSupport.md:818-819
+
+SYCL specification uses C++ classes to represent pointers to disjoint memory
+regions on an accelerator to enable compilation with standard C++ toolchain and
+SYCL compiler toolchain. Section 3.8.2 of SYCL 2020 specification defines

Or more simply just `SYCL specification uses C++ wrapper classes`.

`multi_ptr` are not "pointers to" but a wrapper around the actual pointer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99488

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


[PATCH] D99338: [clang][parser] Allow GNU-style attributes in enum specifiers

2021-03-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

To be clear, this is expected to be an NFC change that allows D97362 
 to be applied without breaking bots? If so, 
it'd be helpful to have the changes as part of D97362 
 because they're critical to that review and 
so that we get appropriate CI pre-merge testing.


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

https://reviews.llvm.org/D99338

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


[PATCH] D99278: [clang][parser] Allow GNU-style attributes in struct declarations

2021-03-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

To be clear, this is expected to be an NFC change that allows D97362 
 to be applied without breaking bots? If so, 
it'd be helpful to have the changes as part of D97362 
 because they're critical to that review and 
so that we get appropriate CI pre-merge testing.


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

https://reviews.llvm.org/D99278

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


[clang] d3ff65d - [Clang] Fix line numbers in CHECK lines.

2021-03-29 Thread Florian Hahn via cfe-commits

Author: Florian Hahn
Date: 2021-03-29T17:37:48+01:00
New Revision: d3ff65dc11d797c39bb44621d64eb679c09207de

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

LOG: [Clang] Fix line numbers in CHECK lines.

Added: 


Modified: 
clang/test/Frontend/optimization-remark-options.c

Removed: 




diff  --git a/clang/test/Frontend/optimization-remark-options.c 
b/clang/test/Frontend/optimization-remark-options.c
index f222eff37a5e..3509a388d0f6 100644
--- a/clang/test/Frontend/optimization-remark-options.c
+++ b/clang/test/Frontend/optimization-remark-options.c
@@ -1,7 +1,7 @@
 // REQUIRES: x86-registered-target
 // RUN: %clang -O1 -fvectorize -target x86_64-unknown-unknown 
-Rpass-analysis=loop-vectorize -emit-llvm -S %s -o - 2>&1 | FileCheck %s
 
-// CHECK: {{.*}}:9:11: remark: loop not vectorized: cannot prove it is safe to 
reorder floating-point operations; allow reordering by specifying '#pragma 
clang loop vectorize(enable)' before the loop or by providing the compiler 
option '-ffast-math'.
+// CHECK: {{.*}}:10:11: remark: loop not vectorized: cannot prove it is safe 
to reorder floating-point operations; allow reordering by specifying '#pragma 
clang loop vectorize(enable)' before the loop or by providing the compiler 
option '-ffast-math'.
 
 double foo(int N) {
   double v = 0.0;
@@ -12,7 +12,7 @@ double foo(int N) {
   return v;
 }
 
-// CHECK: {{.*}}:17:3: remark: loop not vectorized: cannot prove it is safe to 
reorder memory operations; allow reordering by specifying '#pragma clang loop 
vectorize(enable)' before the loop. If the arrays will always be independent 
specify '#pragma clang loop vectorize(assume_safety)' before the loop or 
provide the '__restrict__' qualifier with the independent array arguments. 
Erroneous results will occur if these options are incorrectly applied!
+// CHECK: {{.*}}:18:3: remark: loop not vectorized: cannot prove it is safe to 
reorder memory operations; allow reordering by specifying '#pragma clang loop 
vectorize(enable)' before the loop. If the arrays will always be independent 
specify '#pragma clang loop vectorize(assume_safety)' before the loop or 
provide the '__restrict__' qualifier with the independent array arguments. 
Erroneous results will occur if these options are incorrectly applied!
 
 void foo2(int *dw, int *uw, int *A, int *B, int *C, int *D, int N) {
   for (long i = 0; i < N; i++) {



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


[PATCH] D99489: [clang] [PR49736] [C++2b] Correctly reject lambdas with requires clause and no parameter list

2021-03-29 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius updated this revision to Diff 333910.
curdeius added a comment.

- Hoist common code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99489

Files:
  clang/lib/Parse/ParseExprCXX.cpp
  clang/test/Parser/cxx-concepts-requires-clause.cpp
  clang/test/Parser/cxx2a-template-lambdas.cpp
  clang/test/Parser/cxx2b-lambdas.cpp

Index: clang/test/Parser/cxx2b-lambdas.cpp
===
--- clang/test/Parser/cxx2b-lambdas.cpp
+++ clang/test/Parser/cxx2b-lambdas.cpp
@@ -18,8 +18,8 @@
 auto L10 = [] noexcept { return true; };
 auto L11 = [] -> bool { return true; };
 auto L12 = [] consteval {};
-auto L13 = [] requires requires() { true; }
-{};
+auto L13 = []() requires true {};
+auto L14 = [] requires true() requires true {};
 auto L15 = [] [[maybe_unused]]{};
 
 auto XL0 = [] mutable constexpr mutable {};// expected-error{{cannot appear multiple times}}
@@ -32,3 +32,11 @@
// expected-note{{to match this '('}} \
// expected-error{{expected body}} \
// expected-warning{{duplicate 'constexpr'}}
+
+// http://llvm.org/PR49736
+auto XL4 = [] requires true() {}; // expected-error{{expected body}}
+auto XL5 = [] requires true {}; // expected-error{{expected body}}
+auto XL6 = [] requires true requires true {}; // expected-error{{expected body}}
+auto XL7 = [] requires true noexcept requires true {}; // expected-error{{expected body}}
+auto XL8 = [] requires true requires true {}; // expected-error{{expected body}}
+auto XL9 = [] requires true noexcept requires true {}; // expected-error{{expected body}}
Index: clang/test/Parser/cxx2a-template-lambdas.cpp
===
--- clang/test/Parser/cxx2a-template-lambdas.cpp
+++ clang/test/Parser/cxx2a-template-lambdas.cpp
@@ -7,3 +7,30 @@
 auto L2 = [](T1 arg1, T2 arg2) -> T1 { };
 auto L3 = [](auto arg) { T t; };
 auto L4 = []() { };
+
+// http://llvm.org/PR49736
+auto L5 = []{};
+auto L6 = [] noexcept {};
+#if __cplusplus <= 202002L
+// expected-warning@-2 {{is a C++2b extension}}
+#endif
+auto L7 = [] requires true {}; // ?
+auto L8 = [] requires true noexcept {};
+#if __cplusplus <= 202002L
+// expected-warning@-2 {{is a C++2b extension}}
+#endif
+
+auto L9 = [](){};
+auto L10 = []() noexcept {};
+auto L11 = [] requires true(){};
+auto L12 = [] requires true() noexcept {};
+auto L13 = [] requires true() noexcept requires true {};
+auto L14 = []() noexcept requires true {};
+auto L15 = [] requires true(){};
+
+auto XL0 = [] noexcept requires true {}; // expected-error {{expected body}}
+auto XL1 = [] noexcept requires true {}; // expected-error {{expected body}}
+#if __cplusplus <= 202002L
+// expected-warning@-3 {{is a C++2b extension}}
+// expected-warning@-3 {{is a C++2b extension}}
+#endif
Index: clang/test/Parser/cxx-concepts-requires-clause.cpp
===
--- clang/test/Parser/cxx-concepts-requires-clause.cpp
+++ clang/test/Parser/cxx-concepts-requires-clause.cpp
@@ -154,7 +154,9 @@
 
 auto lambda2 = [] (auto x) constexpr -> int requires (sizeof(decltype(x)) == 1) { return 0; };
 
-auto lambda3 = [] requires (sizeof(char) == 1) { };
+auto lambda3 = [] requires(sizeof(char) == 1){};
+
+auto lambda4 = [] requires(sizeof(char) == 1){}; // expected-error {{expected body}}
 #if __cplusplus <= 202002L
 // expected-warning@-2{{is a C++2b extension}}
 #endif
Index: clang/lib/Parse/ParseExprCXX.cpp
===
--- clang/lib/Parse/ParseExprCXX.cpp
+++ clang/lib/Parse/ParseExprCXX.cpp
@@ -1392,12 +1392,6 @@
 /*DeclsInPrototype=*/None, LParenLoc, FunLocalRangeEnd, D,
 TrailingReturnType, TrailingReturnTypeLoc, ),
 std::move(Attr), DeclEndLoc);
-
-// Parse requires-clause[opt].
-if (Tok.is(tok::kw_requires))
-  ParseTrailingRequiresClause(D);
-
-WarnIfHasCUDATargetAttr();
   };
 
   if (Tok.is(tok::l_paren)) {
@@ -1433,6 +1427,10 @@
 // Parse lambda-specifiers.
 ParseLambdaSpecifiers(LParenLoc, /*DeclEndLoc=*/T.getCloseLocation(),
   ParamInfo, EllipsisLoc);
+
+// Parse requires-clause[opt].
+if (Tok.is(tok::kw_requires))
+  ParseTrailingRequiresClause(D);
   } else if (Tok.isOneOf(tok::kw_mutable, tok::arrow, tok::kw___attribute,
  tok::kw_constexpr, tok::kw_consteval,
  tok::kw___private, tok::kw___global, tok::kw___local,
@@ -1453,6 +1451,8 @@
   EmptyParamInfo, /*EllipsisLoc=*/NoLoc);
   }
 
+  WarnIfHasCUDATargetAttr();
+
   // FIXME: Rename BlockScope -> ClosureScope if we decide to continue using
   // it.
   unsigned ScopeFlags = 

[clang] 9320ac9 - [Clang] Only run test when X86 backend is built.

2021-03-29 Thread Florian Hahn via cfe-commits

Author: Florian Hahn
Date: 2021-03-29T17:27:01+01:00
New Revision: 9320ac9b4965d769632398b620ca3e4af9b56b12

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

LOG: [Clang] Only run test when X86 backend is built.

After c773d0f97304 the remark is only emitted if the loop is profitable
to vectorize, but cannot be vectorized. Hence, it depends on
X86-specific cost-modeling.

Added: 


Modified: 
clang/test/Frontend/optimization-remark-options.c

Removed: 




diff  --git a/clang/test/Frontend/optimization-remark-options.c 
b/clang/test/Frontend/optimization-remark-options.c
index 38dbbfbaccec0..f222eff37a5ef 100644
--- a/clang/test/Frontend/optimization-remark-options.c
+++ b/clang/test/Frontend/optimization-remark-options.c
@@ -1,3 +1,4 @@
+// REQUIRES: x86-registered-target
 // RUN: %clang -O1 -fvectorize -target x86_64-unknown-unknown 
-Rpass-analysis=loop-vectorize -emit-llvm -S %s -o - 2>&1 | FileCheck %s
 
 // CHECK: {{.*}}:9:11: remark: loop not vectorized: cannot prove it is safe to 
reorder floating-point operations; allow reordering by specifying '#pragma 
clang loop vectorize(enable)' before the loop or by providing the compiler 
option '-ffast-math'.



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


[PATCH] D99297: [OPENMP]Fix PR49636: Assertion `(!Entry.getAddress() || Entry.getAddress() == Addr) && "Resetting with the new address."' failed.

2021-03-29 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

LGTM for CUDA.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99297

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


[PATCH] D99514: [NFC] clang-formatting zos-alignment.c

2021-03-29 Thread Fanbo Meng via Phabricator via cfe-commits
fanbo-meng created this revision.
fanbo-meng added a reviewer: abhina.sreeskantharajan.
fanbo-meng 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/D99514

Files:
  clang/test/CodeGen/SystemZ/zos-alignment.c

Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -13,8 +13,8 @@
 // DECL-NEXT: @v3 {{.*}} align 32
 
 const struct cs0 {
-  unsigned long   :0;
-  long longa;
+  unsigned long : 0;
+  long long a;
 } CS0 = {};
 // CHECK:  0 | struct cs0
 // CHECK-NEXT:   0:- |   unsigned long
@@ -22,8 +22,8 @@
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 volatile struct vs0 {
-  long:0;
-  short   a;
+  long : 0;
+  short a;
 } VS0;
 // CHECK:  0 | struct vs0
 // CHECK-NEXT:   0:- |   long
@@ -31,11 +31,11 @@
 // CHECK-NEXT:   | [sizeof=2, align=2]
 
 struct s0 {
-  short a:3;
-  long b:5;
-  int c:1;
-  long d:10;
-  char e:5;
+  short a : 3;
+  long b : 5;
+  int c : 1;
+  long d : 10;
+  char e : 5;
 } S0;
 // CHECK:  0 | struct s0
 // CHECK-NEXT: 0:0-2 |   short a
@@ -46,9 +46,9 @@
 // CHECK-NEXT:   | [sizeof=3, align=1]
 
 struct s1 {
-  char a:7;
-  long b:27;
-  int c:2;
+  char a : 7;
+  long b : 27;
+  int c : 2;
 } S1;
 // CHECK:  0 | struct s1
 // CHECK-NEXT: 0:0-6 |   char a
@@ -57,10 +57,10 @@
 // CHECK-NEXT:   | [sizeof=5, align=1]
 
 struct s2 {
-  char a:7;
-  char  :0;
-  short :0;
-  short :0;
+  char a : 7;
+  char : 0;
+  short : 0;
+  short : 0;
 } S2;
 // CHECK:  0 | struct s2
 // CHECK-NEXT: 0:0-6 |   char a
@@ -71,9 +71,9 @@
 
 struct s3 {
   int a;
-  int b:16;
-  char  :0;
-  char c:1;
+  int b : 16;
+  char : 0;
+  char c : 1;
 } S3;
 // CHECK:  0 | struct s3
 // CHECK-NEXT: 0 |   int a
@@ -83,7 +83,7 @@
 // CHECK-NEXT:   | [sizeof=12, align=4]
 
 struct s4 {
- unsigned int __attribute__((aligned(32))) a;
+  unsigned int __attribute__((aligned(32))) a;
 } S4;
 // CHECK:  0 | struct s4
 // CHECK-NEXT: 0 |   unsigned int a
@@ -91,10 +91,10 @@
 
 struct s5 {
   char a;
-  int  b:19 __attribute__((aligned(4)));
-  int  c:22 __attribute__((aligned(8)));
-  int  :0;
-  int  d:10;
+  int b : 19 __attribute__((aligned(4)));
+  int c : 22 __attribute__((aligned(8)));
+  int : 0;
+  int d : 10;
 } S5;
 // CHECK:  0 | struct s5
 // CHECK-NEXT: 0 |   char a
@@ -105,8 +105,8 @@
 // CHECK-NEXT:   | [sizeof=16, align=8]
 
 struct s6 {
-  char * a;
-  char * b[];
+  char *a;
+  char *b[];
 } S6;
 // CHECK:  0 | struct s6
 // CHECK-NEXT: 0 |   char * a
@@ -114,7 +114,7 @@
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 struct s7 {
-  long  :0;
+  long : 0;
   short a;
 } S7;
 // CHECK:  0 | struct s7
@@ -124,8 +124,8 @@
 
 #pragma pack(2)
 struct s8 {
-  unsigned long   :0;
-  long long   a;
+  unsigned long : 0;
+  long long a;
 } S8;
 #pragma pack()
 // CHECK:  0 | struct s8
@@ -134,8 +134,8 @@
 // CHECK-NEXT:   | [sizeof=8, align=2]
 
 struct s9 {
-  unsigned int   :0;
-  unsigned short :0;
+  unsigned int : 0;
+  unsigned short : 0;
 } S9;
 // CHECK:  0 | struct s9
 // CHECK-NEXT:   0:- |   unsigned int
@@ -143,7 +143,7 @@
 // CHECK-NEXT:   | [sizeof=0, align=1]
 
 struct s10 {
- unsigned int __attribute__((aligned)) a;
+  unsigned int __attribute__((aligned)) a;
 } S10;
 // CHECK:  0 | struct s10
 // CHECK-NEXT: 0 |   unsigned int a
@@ -151,7 +151,7 @@
 
 struct s11 {
   char a;
-  long :0;
+  long : 0;
   char b;
 } S11;
 // CHECK:  0 | struct s11
@@ -161,9 +161,9 @@
 // CHECK-NEXT:   | [sizeof=16, align=8]
 
 union u0 {
-  unsigned short d1 __attribute__((packed));
-  intd2:10;
-  long   d3;
+  unsigned short d1 __attribute__((packed));
+  int d2 : 10;
+  long d3;
 } U0 __attribute__((aligned(8)));
 // CHECK:  0 | union u0
 // CHECK-NEXT: 0 |   unsigned short d1
@@ -172,8 +172,8 @@
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 union u1 {
-  unsigned int:0;
-  short   a;
+  unsigned int : 0;
+  short a;
 } U1;
 // CHECK:  0 | union u1
 // CHECK-NEXT:   0:- |   unsigned int
@@ -181,8 +181,8 @@
 // CHECK-NEXT:   | [sizeof=4, align=4]
 
 union u2 {
-  long  :0;
-  short  a;
+  long : 0;
+  short a;
 } U2;
 // CHECK:  0 | union u2
 // CHECK-NEXT:   0:- |   long
@@ -190,8 +190,8 @@
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 union u3 {
-  unsigned char :0;
-  unsigned short :0;
+  unsigned char : 0;
+  unsigned short : 0;
 } U3;
 // CHECK:  0 | 

[PATCH] D99506: [OpenMP][NFC] Move the `noinline` to the parallel entry point

2021-03-29 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert updated this revision to Diff 333895.
jdoerfert added a comment.

Add test for nvptx codegen, including wrapper attribute check


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99506

Files:
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/OpenMP/nvptx_parallel_codegen.cpp


Index: clang/test/OpenMP/nvptx_parallel_codegen.cpp
===
--- clang/test/OpenMP/nvptx_parallel_codegen.cpp
+++ clang/test/OpenMP/nvptx_parallel_codegen.cpp
@@ -4,7 +4,7 @@
 // RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx64-unknown-unknown 
-fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-ppc-host.bc -o - -disable-llvm-optzns 
-fopenmp-cuda-parallel-target-regions | FileCheck %s --check-prefix CHECK 
--check-prefix CHECK-64 --check-prefix PAR
 // RUN: %clang_cc1 -verify -fopenmp -x c++ -triple i386-unknown-unknown 
-fopenmp-targets=nvptx-nvidia-cuda -emit-llvm-bc %s -o %t-x86-host.bc
 // RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx-unknown-unknown 
-fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-x86-host.bc -o - -disable-llvm-optzns | FileCheck 
%s --check-prefix CHECK --check-prefix CHECK-32 --check-prefix SEQ
-// RUN: %clang_cc1 -verify -fopenmp -fexceptions -fcxx-exceptions -x c++ 
-triple nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s 
-fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - 
-disable-llvm-optzns | FileCheck %s --check-prefix CHECK --check-prefix 
CHECK-32 --check-prefix SEQ
+// RUN: %clang_cc1 -verify -fopenmp -fexceptions -fcxx-exceptions -x c++ 
-triple nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s 
-fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - 
-disable-llvm-optzns -disable-O0-optnone | FileCheck %s --check-prefix CHECK 
--check-prefix CHECK-32 --check-prefix SEQ
 // RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx-unknown-unknown 
-fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-x86-host.bc -o - -disable-llvm-optzns 
-fopenmp-cuda-parallel-target-regions | FileCheck %s --check-prefix CHECK 
--check-prefix CHECK-32 --check-prefix PAR
 // RUN: %clang_cc1 -verify -fopenmp -fexceptions -fcxx-exceptions -x c++ 
-triple nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s 
-fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - 
-disable-llvm-optzns -fopenmp-cuda-parallel-target-regions | FileCheck %s 
--check-prefix CHECK --check-prefix CHECK-32 --check-prefix PAR
 // expected-no-diagnostics
@@ -318,7 +318,8 @@
 // CHECK: [[EXIT]]
 // CHECK: ret void
 
-// CHECK: define internal void [[PARALLEL_FN4]](
+// CHECK: noinline
+// CHECK-NEXT: define internal void [[PARALLEL_FN4]](
 // CHECK: [[A:%.+]] = alloca i[[SZ:32|64]],
 // CHECK: store i[[SZ]] 45, i[[SZ]]* %a,
 // CHECK: call void @__kmpc_barrier(%struct.ident_t* @{{.+}}, i32 %{{.+}})
@@ -326,6 +327,9 @@
 
 // CHECK: declare void @__kmpc_barrier(%struct.ident_t*, i32) #[[#CONVERGENT:]]
 
+// CHECK: Function Attrs: convergent noinline norecurse nounwind
+// CHECK-NEXT: [[PARALLEL_FN4]]_wrapper
+
 // CHECK-LABEL: define {{.*}}void 
{{@__omp_offloading_.+template.+l58}}_worker()
 // CHECK-LABEL: define {{.*}}void {{@__omp_offloading_.+template.+l58}}(
 // CHECK-32: [[A_ADDR:%.+]] = alloca i32,
@@ -373,7 +377,6 @@
 // CHECK:  store i32 [[NEW_CC_VAL]], i32* [[CC]],
 // CHECK:  br label
 
-
 // CHECK: declare i32 @__kmpc_warp_active_thread_mask() #[[#CONVERGENT:]]
 // CHECK: declare void @__kmpc_syncwarp(i32) #[[#CONVERGENT:]]
 
Index: clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
@@ -2093,14 +2093,6 @@
   // Force inline this outlined function at its call site.
   Fn->setLinkage(llvm::GlobalValue::InternalLinkage);
 
-  // Ensure we do not inline the function. This is trivially true for the ones
-  // passed to __kmpc_fork_call but the ones calles in serialized regions
-  // could be inlined. This is not a perfect but it is closer to the invariant
-  // we want, namely, every data environment starts with a new function.
-  // TODO: We should pass the if condition to the runtime function and do the
-  //   handling there. Much cleaner code.
-  cast(OutlinedFn)->addFnAttr(llvm::Attribute::NoInline);
-
   Address ZeroAddr = CGF.CreateDefaultAlignTempAlloca(CGF.Int32Ty,
   /*Name=*/".zero.addr");
   CGF.InitTempAlloca(ZeroAddr, CGF.Builder.getInt32(/*C*/ 0));
@@ -4216,6 +4208,15 @@
   auto *Fn = llvm::Function::Create(
   CGM.getTypes().GetFunctionType(CGFI), llvm::GlobalValue::InternalLinkage,
   

[PATCH] D99508: [SystemZ][z/OS] Add test of leading zero length bitfield in const/volatile struct

2021-03-29 Thread Fanbo Meng via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf1e0c7fdd720: [SystemZ][z/OS] Add test of leading zero 
length bitfield in const/volatile… (authored by fanbo-meng).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99508

Files:
  clang/test/CodeGen/SystemZ/zos-alignment.c


Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -12,6 +12,24 @@
 // DECL-NEXT: @v2 {{.*}} align 16
 // DECL-NEXT: @v3 {{.*}} align 32
 
+const struct cs0 {
+  unsigned long   :0;
+  long longa;
+} CS0 = {};
+// CHECK:  0 | struct cs0
+// CHECK-NEXT:   0:- |   unsigned long
+// CHECK-NEXT: 0 |   long long a
+// CHECK-NEXT:   | [sizeof=8, align=8]
+
+volatile struct vs0 {
+  long:0;
+  short   a;
+} VS0;
+// CHECK:  0 | struct vs0
+// CHECK-NEXT:   0:- |   long
+// CHECK-NEXT: 0 |   short a
+// CHECK-NEXT:   | [sizeof=2, align=2]
+
 struct s0 {
   short a:3;
   long b:5;


Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -12,6 +12,24 @@
 // DECL-NEXT: @v2 {{.*}} align 16
 // DECL-NEXT: @v3 {{.*}} align 32
 
+const struct cs0 {
+  unsigned long   :0;
+  long longa;
+} CS0 = {};
+// CHECK:  0 | struct cs0
+// CHECK-NEXT:   0:- |   unsigned long
+// CHECK-NEXT: 0 |   long long a
+// CHECK-NEXT:   | [sizeof=8, align=8]
+
+volatile struct vs0 {
+  long:0;
+  short   a;
+} VS0;
+// CHECK:  0 | struct vs0
+// CHECK-NEXT:   0:- |   long
+// CHECK-NEXT: 0 |   short a
+// CHECK-NEXT:   | [sizeof=2, align=2]
+
 struct s0 {
   short a:3;
   long b:5;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] f1e0c7f - [SystemZ][z/OS] Add test of leading zero length bitfield in const/volatile struct

2021-03-29 Thread Fanbo Meng via cfe-commits

Author: Fanbo Meng
Date: 2021-03-29T12:06:30-04:00
New Revision: f1e0c7fdd72026f62e2c38ee249705fbb9213a30

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

LOG: [SystemZ][z/OS] Add test of leading zero length bitfield in const/volatile 
struct

Reviewed By: abhina.sreeskantharajan

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

Added: 


Modified: 
clang/test/CodeGen/SystemZ/zos-alignment.c

Removed: 




diff  --git a/clang/test/CodeGen/SystemZ/zos-alignment.c 
b/clang/test/CodeGen/SystemZ/zos-alignment.c
index 9371a54403e4..b43968410cec 100644
--- a/clang/test/CodeGen/SystemZ/zos-alignment.c
+++ b/clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -12,6 +12,24 @@ int f0() { return v0 + v1 + v2 + v3; }
 // DECL-NEXT: @v2 {{.*}} align 16
 // DECL-NEXT: @v3 {{.*}} align 32
 
+const struct cs0 {
+  unsigned long   :0;
+  long longa;
+} CS0 = {};
+// CHECK:  0 | struct cs0
+// CHECK-NEXT:   0:- |   unsigned long
+// CHECK-NEXT: 0 |   long long a
+// CHECK-NEXT:   | [sizeof=8, align=8]
+
+volatile struct vs0 {
+  long:0;
+  short   a;
+} VS0;
+// CHECK:  0 | struct vs0
+// CHECK-NEXT:   0:- |   long
+// CHECK-NEXT: 0 |   short a
+// CHECK-NEXT:   | [sizeof=2, align=2]
+
 struct s0 {
   short a:3;
   long b:5;



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


[PATCH] D99488: [SYCL][Doc] Add address space handling section to SYCL documentation

2021-03-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Mostly grammar related review comments, nothing substantive.




Comment at: clang/docs/SYCLSupport.md:816
 
+### Address spaces handling
+





Comment at: clang/docs/SYCLSupport.md:818
+
+SYCL specification uses C++ classes to represent pointers to disjoint memory
+regions on an accelerator to enable compilation with standard C++ toolchain and





Comment at: clang/docs/SYCLSupport.md:819
+SYCL specification uses C++ classes to represent pointers to disjoint memory
+regions on an accelerator to enable compilation with standard C++ toolchain and
+SYCL compiler toolchain. Section 3.8.2 of SYCL 2020 specification defines





Comment at: clang/docs/SYCLSupport.md:825
+
+The main address space semantic difference of SYCL mode from OpenCL is that
+SYCL doesn't perform address space qualifier inference detailed in





Comment at: clang/docs/SYCLSupport.md:826
+The main address space semantic difference of SYCL mode from OpenCL is that
+SYCL doesn't perform address space qualifier inference detailed in
+[OpenCL C v3.0 
s6.7.8](https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#addr-spaces-inference).





Comment at: clang/docs/SYCLSupport.md:827
+SYCL doesn't perform address space qualifier inference detailed in
+[OpenCL C v3.0 
s6.7.8](https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#addr-spaces-inference).
+





Comment at: clang/docs/SYCLSupport.md:831
+OpenMP/CUDA/HIP, SYCL uses clang's "default" address space for types with no
+address space attributes. This design has two important features: keeps the 
type system consistent with C++ on one hand and enable tools for emitting 
device code aligned with SPIR memory model (and other GPU targets).
+

You should also re-wrap for 80 col (whenever we finish talking about what words 
to add).



Comment at: clang/docs/SYCLSupport.md:839
+
+SYCL device compiler turns into
+





Comment at: clang/docs/SYCLSupport.md:845
+
+OpenCL compiler turn into
+





Comment at: clang/docs/SYCLSupport.md:851
+
+Changing variable type has massive and destructive effect in C++. For instance
+this does not compile in C++ for OpenCL mode:





Comment at: clang/docs/SYCLSupport.md:899-900
+
+Depending on the compiler mode `multi_ptr` will either decorate internal data
+with address space attribute or not.
+





Comment at: clang/docs/SYCLSupport.md:902
+
+To utilize existing clang's functionality, we re-use following OpenCL address
+space attributes for decoration pointers implementation:





Comment at: clang/docs/SYCLSupport.md:903
+To utilize existing clang's functionality, we re-use following OpenCL address
+space attributes for decoration pointers implementation:
+





Comment at: clang/docs/SYCLSupport.md:914
+
+Default address space represents "Generic-memory", which is a virtual address
+space which overlaps the global, local and private address spaces. SYCL mode





Comment at: clang/docs/SYCLSupport.md:915
+Default address space represents "Generic-memory", which is a virtual address
+space which overlaps the global, local and private address spaces. SYCL mode
+enables conversion to/from default address space from/to address space





Comment at: clang/docs/SYCLSupport.md:916
+space which overlaps the global, local and private address spaces. SYCL mode
+enables conversion to/from default address space from/to address space
+attributed type.





Comment at: clang/docs/SYCLSupport.md:919
+
+SPIR target allocates SYCL namespace scope variables in global address space.
+




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99488

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


[PATCH] D99506: [OpenMP][NFC] Move the `noinline` to the parallel entry point

2021-03-29 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D99506#2655948 , @fhahn wrote:

> Is it possible to add a test?

There is a test for the presence of noinline, let me make it more explicit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99506

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


[PATCH] D99297: [OPENMP]Fix PR49636: Assertion `(!Entry.getAddress() || Entry.getAddress() == Addr) && "Resetting with the new address."' failed.

2021-03-29 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

Nice, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99297

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


[PATCH] D99508: [SystemZ][z/OS] Add test of leading zero length bitfield in const/volatile struct

2021-03-29 Thread Abhina Sree via Phabricator via cfe-commits
abhina.sreeskantharajan accepted this revision.
abhina.sreeskantharajan added a comment.
This revision is now accepted and ready to land.

LGTM, have a small nit




Comment at: clang/test/CodeGen/SystemZ/zos-alignment.c:26
+  long:0;
+  short   a;
+} VS0;

nit: spacing is off


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99508

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


[PATCH] D99199: Make -fcrash-diagnostics-dir control the Windows (mini-)dump location

2021-03-29 Thread Paul Robinson via Phabricator via cfe-commits
probinson marked 2 inline comments as done.
probinson added a comment.

Addressed comments.


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

https://reviews.llvm.org/D99199

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


[PATCH] D99199: Make -fcrash-diagnostics-dir control the Windows (mini-)dump location

2021-03-29 Thread Paul Robinson via Phabricator via cfe-commits
probinson updated this revision to Diff 333884.
probinson added a comment.

Remove ifdefs, tweak descriptions/comments.


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

https://reviews.llvm.org/D99199

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/crash-diagnostics-dir-2.c
  llvm/lib/Support/Signals.cpp
  llvm/lib/Support/Windows/Signals.inc


Index: llvm/lib/Support/Windows/Signals.inc
===
--- llvm/lib/Support/Windows/Signals.inc
+++ llvm/lib/Support/Windows/Signals.inc
@@ -766,16 +766,18 @@
 if (!GetDumpType(DefaultLocalDumpsKey, DumpType))
   DumpType = MiniDumpNormal;
 
-  // Look to see if a dump location is specified in the registry; first with 
the
+  // Look to see if a dump location is specified on the command line.  If not,
+  // look to see if a dump location is specified in the registry; first with 
the
   // app-specific key and failing that with the global key.  If none are found
   // we'll just create the dump file in the default temporary file location
   // (GetDumpFolder will return false either if the key is NULL or if there is
   // no valid DumpFolder value at its location).
   bool ExplicitDumpDirectorySet = true;
-  SmallString DumpDirectory;
-  if (!GetDumpFolder(AppSpecificKey, DumpDirectory))
-if (!GetDumpFolder(DefaultLocalDumpsKey, DumpDirectory))
-  ExplicitDumpDirectorySet = false;
+  SmallString DumpDirectory(CrashDiagnosticsDirectory);
+  if (DumpDirectory.empty())
+if (!GetDumpFolder(AppSpecificKey, DumpDirectory))
+  if (!GetDumpFolder(DefaultLocalDumpsKey, DumpDirectory))
+ExplicitDumpDirectorySet = false;
 
   int FD;
   SmallString DumpPath;
Index: llvm/lib/Support/Signals.cpp
===
--- llvm/lib/Support/Signals.cpp
+++ llvm/lib/Support/Signals.cpp
@@ -43,6 +43,11 @@
 DisableSymbolication("disable-symbolication",
  cl::desc("Disable symbolizing crash backtraces."),
  cl::location(DisableSymbolicationFlag), cl::Hidden);
+static std::string CrashDiagnosticsDirectory;
+static cl::opt
+CrashDiagnosticsDir("crash-diagnostics-dir", cl::value_desc("directory"),
+cl::desc("Directory for crash diagnostic files."),
+cl::location(CrashDiagnosticsDirectory), cl::Hidden);
 
 constexpr char DisableSymbolizationEnv[] = "LLVM_DISABLE_SYMBOLIZATION";
 constexpr char LLVMSymbolizerPathEnv[] = "LLVM_SYMBOLIZER_PATH";
Index: clang/test/Driver/crash-diagnostics-dir-2.c
===
--- /dev/null
+++ clang/test/Driver/crash-diagnostics-dir-2.c
@@ -0,0 +1,5 @@
+// RUN: %clang -### -fcrash-diagnostics-dir=mydumps -c %s 2>&1 \
+// RUN: | FileCheck %s --check-prefix=OPTION
+// OPTION: "-crash-diagnostics-dir=mydumps"
+// RUN: %clang -### -c %s 2>&1 | FileCheck %s --check-prefix=NOOPTION
+// NOOPTION-NOT: "-crash-diagnostics-dir
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5128,6 +5128,14 @@
   if (D.CCGenDiagnostics)
 CmdArgs.push_back("-disable-pragma-debug-crash");
 
+  // Allow backend to put its diagnostic files in the same place as frontend
+  // crash diagnostics files.
+  if (Args.hasArg(options::OPT_fcrash_diagnostics_dir)) {
+StringRef Dir = Args.getLastArgValue(options::OPT_fcrash_diagnostics_dir);
+CmdArgs.push_back("-mllvm");
+CmdArgs.push_back(Args.MakeArgString("-crash-diagnostics-dir=" + Dir));
+  }
+
   bool UseSeparateSections = isUseSeparateSections(Triple);
 
   if (Args.hasFlag(options::OPT_ffunction_sections,


Index: llvm/lib/Support/Windows/Signals.inc
===
--- llvm/lib/Support/Windows/Signals.inc
+++ llvm/lib/Support/Windows/Signals.inc
@@ -766,16 +766,18 @@
 if (!GetDumpType(DefaultLocalDumpsKey, DumpType))
   DumpType = MiniDumpNormal;
 
-  // Look to see if a dump location is specified in the registry; first with the
+  // Look to see if a dump location is specified on the command line.  If not,
+  // look to see if a dump location is specified in the registry; first with the
   // app-specific key and failing that with the global key.  If none are found
   // we'll just create the dump file in the default temporary file location
   // (GetDumpFolder will return false either if the key is NULL or if there is
   // no valid DumpFolder value at its location).
   bool ExplicitDumpDirectorySet = true;
-  SmallString DumpDirectory;
-  if (!GetDumpFolder(AppSpecificKey, DumpDirectory))
-if (!GetDumpFolder(DefaultLocalDumpsKey, DumpDirectory))
-  ExplicitDumpDirectorySet = false;
+  SmallString DumpDirectory(CrashDiagnosticsDirectory);
+  if (DumpDirectory.empty())
+if 

[PATCH] D99506: [OpenMP][NFC] Move the `noinline` to the parallel entry point

2021-03-29 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

Is it possible to add a test?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99506

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


[PATCH] D99489: [clang] [PR49736] [C++2b] Correctly reject lambdas with requires clause and no parameter list

2021-03-29 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius added inline comments.



Comment at: clang/lib/Parse/ParseExprCXX.cpp:1435
+
+WarnIfHasCUDATargetAttr();
   } else if (Tok.isOneOf(tok::kw_mutable, tok::arrow, tok::kw___attribute,

aaron.ballman wrote:
> Rather than add this in both branches, I'd say to hoist it out of the 
> branches and put it after the `else if` below (before the declaration of 
> `ScopeFlags`).
True. Will do soon.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99489

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


  1   2   >