[PATCH] D86743: [analyzer] Ignore VLASizeChecker case that could cause crash

2021-01-04 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

I did not like this solution so I like it if we can omit this change and apply 
another fix (D69726 ).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86743

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


[PATCH] D91806: [InstCombine] Update valueCoversEntireFragment to use TypeSize

2021-01-04 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen added inline comments.



Comment at: llvm/test/Transforms/InstCombine/debuginfo-scalable-typesize.ll:13
+
+; ERR-NOT: TypeSize is not scalable
+

After your changes, what line causes this warning to be emitted? Does this test 
also pass with asserts enabled?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91806

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


[PATCH] D93095: Introduce -Wreserved-identifier

2021-01-04 Thread serge via Phabricator via cfe-commits
serge-sans-paille updated this revision to Diff 314329.
serge-sans-paille added a comment.

Rebased on main.


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

https://reviews.llvm.org/D93095

Files:
  clang/include/clang/AST/Decl.h
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/Sema/reserved-identifier.c
  clang/test/Sema/reserved-identifier.cpp

Index: clang/test/Sema/reserved-identifier.cpp
===
--- /dev/null
+++ clang/test/Sema/reserved-identifier.cpp
@@ -0,0 +1,59 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify -Wreserved-identifier %s
+
+int foo__bar() { return 0; }// expected-warning {{'foo__bar' is a reserved identifier}}
+static int _bar() { return 0; } // expected-warning {{'_bar' is a reserved identifier}}
+static int _Bar() { return 0; } // expected-warning {{'_Bar' is a reserved identifier}}
+int _barbouille() { return 0; } // expected-warning {{'_barbouille' is a reserved identifier}}
+
+void foo(unsigned int _Reserved) { // expected-warning {{'_Reserved' is a reserved identifier}}
+  unsigned int __1 =   // expected-warning {{'__1' is a reserved identifier}}
+  _Reserved;   // no-warning
+}
+
+// This one is explicitly skipped by -Wreserved-identifier
+void *_; // no-warning
+
+template  constexpr bool __toucan = true; // expected-warning {{'__toucan' is a reserved identifier}}
+
+template 
+concept _Barbotine = __toucan; // expected-warning {{'_Barbotine' is a reserved identifier}}
+
+template  // expected-warning {{'__' is a reserved identifier}}
+struct BarbeNoire {};
+
+template  // expected-warning {{'__' is a reserved identifier}}
+void BarbeRousse() {}
+
+namespace _Barbidur { // expected-warning {{'_Barbidur' is a reserved identifier}}
+
+struct __barbidou {}; // expected-warning {{'__barbidou' is a reserved identifier}}
+struct _barbidou {};  // no-warning
+
+int __barbouille; // expected-warning {{'__barbouille' is a reserved identifier}}
+int _barbouille;  // no-warning
+
+int __babar() { return 0; } // expected-warning {{'__babar' is a reserved identifier}}
+int _babar() { return 0; }  // no-warning
+
+} // namespace _Barbidur
+
+class __barbapapa { // expected-warning {{'__barbapapa' is a reserved identifier}}
+  void _barbabelle() {} // no-warning
+  int _Barbalala;   // expected-warning {{'_Barbalala' is a reserved identifier}}
+};
+
+enum class __menu { // expected-warning {{'__menu' is a reserved identifier}}
+  __some,   // expected-warning {{'__some' is a reserved identifier}}
+  _Other// expected-warning {{'_Other' is a reserved identifier}}
+};
+
+using _Barbamama = __barbapapa; // expected-warning {{'_Barbamama' is a reserved identifier}}
+
+int foobar() {
+  return foo__bar(); // no-warning
+}
+
+namespace {
+// we skip this one because it's not at top-level.
+int _barbatruc; // no-warning
+}
Index: clang/test/Sema/reserved-identifier.c
===
--- /dev/null
+++ clang/test/Sema/reserved-identifier.c
@@ -0,0 +1,48 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wreserved-identifier -Wno-visibility %s
+
+#define __oof foo__ // expected-warning {{macro name is a reserved identifier}}
+
+int foo__bar() { return 0; }// no-warning
+static int _bar() { return 0; } // expected-warning {{'_bar' is a reserved identifier}}
+static int _Bar() { return 0; } // expected-warning {{'_Bar' is a reserved identifier}}
+int _foo() { return 0; }// expected-warning {{'_foo' is a reserved identifier}}
+
+// This one is explicitly skipped by -Wreserved-identifier
+void *_; // no-warning
+
+void foo(unsigned int _Reserved) { // expected-warning {{'_Reserved' is a reserved identifier}}
+  unsigned int __1 =   // expected-warning {{'__1' is a reserved identifier}}
+  _Reserved;   // no-warning
+  goto __reserved;
+__reserved: // expected-warning {{'__reserved' is a reserved identifier}}
+;
+}
+
+enum __menu { // expected-warning {{'__menu' is a reserved identifier}}
+  __some, // expected-warning {{'__some' is a reserved identifier}}
+  _Other, // expected-warning {{'_Other' is a reserved identifier}}
+  _other  // no-warning
+};
+
+struct __babar { // expected-warning {{'__babar' is a reserved identifier}}
+};
+
+typedef struct {
+  int _Field; // expected-warning {{'_Field' is a reserved identifier}}
+  int _field; // no-warning
+} _Typedef;   // expected-warning {{'_Typedef' is a reserved identifier}}
+
+int foobar() {
+  return foo__bar(); // no-warning
+}
+
+struct _reserved { // expected-warning {{'_reserved' is a reserved identifier}}
+  int a;
+} cunf(void) {
+  return

[PATCH] D37479: run-clang-tidy: Report progress

2021-01-04 Thread Florian Berchtold via Phabricator via cfe-commits
florian.berchtold added a comment.

This looks like a cool feature, why is it blocked?


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

https://reviews.llvm.org/D37479

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


[clang] e43b3d1 - Revert "[Sema] Fix deleted function problem in implicitly movable test"

2021-01-04 Thread Yang Fan via cfe-commits

Author: Yang Fan
Date: 2021-01-04T17:21:19+08:00
New Revision: e43b3d1f5e05c6e5e07cff054df193cf0d0c6583

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

LOG: Revert "[Sema] Fix deleted function problem in implicitly movable test"

This reverts commit 89b0972a

Added: 


Modified: 
clang/lib/Sema/SemaInit.cpp
clang/lib/Sema/SemaStmt.cpp

Removed: 
clang/test/CXX/class/class.init/class.copy.elision/p3.cpp



diff  --git a/clang/lib/Sema/SemaInit.cpp b/clang/lib/Sema/SemaInit.cpp
index 4a965c60c74e..6d2e6094e79c 100644
--- a/clang/lib/Sema/SemaInit.cpp
+++ b/clang/lib/Sema/SemaInit.cpp
@@ -4119,9 +4119,7 @@ static void TryConstructorInitialization(Sema &S,
   InitializationSequence::FK_ListConstructorOverloadFailed 
:
   InitializationSequence::FK_ConstructorOverloadFailed,
 Result);
-
-if (Result != OR_Deleted)
-  return;
+return;
   }
 
   bool HadMultipleCandidates = (CandidateSet.size() > 1);
@@ -4142,45 +4140,31 @@ static void TryConstructorInitialization(Sema &S,
 return;
   }
 
+  // C++11 [dcl.init]p6:
+  //   If a program calls for the default initialization of an object
+  //   of a const-qualified type T, T shall be a class type with a
+  //   user-provided default constructor.
+  // C++ core issue 253 proposal:
+  //   If the implicit default constructor initializes all subobjects, no
+  //   initializer should be required.
+  // The 253 proposal is for example needed to process libstdc++ headers in 
5.x.
   CXXConstructorDecl *CtorDecl = cast(Best->Function);
-  if (Result != OR_Deleted) { // TODO: Support for more than one failure.
-// C++11 [dcl.init]p6:
-//   If a program calls for the default initialization of an object
-//   of a const-qualified type T, T shall be a class type with a
-//   user-provided default constructor.
-// C++ core issue 253 proposal:
-//   If the implicit default constructor initializes all subobjects, no
-//   initializer should be required.
-// The 253 proposal is for example needed to process libstdc++ headers
-// in 5.x.
-if (Kind.getKind() == InitializationKind::IK_Default &&
-Entity.getType().isConstQualified()) {
-  if (!CtorDecl->getParent()->allowConstDefaultInit()) {
-if (!maybeRecoverWithZeroInitialization(S, Sequence, Entity))
-  Sequence.SetFailed(InitializationSequence::FK_DefaultInitOfConst);
-return;
-  }
-}
-
-// C++11 [over.match.list]p1:
-//   In copy-list-initialization, if an explicit constructor is chosen, the
-//   initializer is ill-formed.
-if (IsListInit && !Kind.AllowExplicit() && CtorDecl->isExplicit()) {
-  Sequence.SetFailed(InitializationSequence::FK_ExplicitConstructor);
+  if (Kind.getKind() == InitializationKind::IK_Default &&
+  Entity.getType().isConstQualified()) {
+if (!CtorDecl->getParent()->allowConstDefaultInit()) {
+  if (!maybeRecoverWithZeroInitialization(S, Sequence, Entity))
+Sequence.SetFailed(InitializationSequence::FK_DefaultInitOfConst);
   return;
 }
   }
 
-  // [class.copy.elision]p3:
-  // In some copy-initialization contexts, a two-stage overload resolution
-  // is performed.
-  // If the first overload resolution selects a deleted function, we also
-  // need the initialization sequence to decide whether to perform the second
-  // overload resolution.
-  // For deleted functions in other contexts, there is no need to get the
-  // initialization sequence.
-  if (Result == OR_Deleted && Kind.getKind() != InitializationKind::IK_Copy)
+  // C++11 [over.match.list]p1:
+  //   In copy-list-initialization, if an explicit constructor is chosen, the
+  //   initializer is ill-formed.
+  if (IsListInit && !Kind.AllowExplicit() && CtorDecl->isExplicit()) {
+Sequence.SetFailed(InitializationSequence::FK_ExplicitConstructor);
 return;
+  }
 
   // Add the constructor initialization step. Any cv-qualification conversion 
is
   // subsumed by the initialization.
@@ -5276,16 +5260,7 @@ static void TryUserDefinedConversion(Sema &S,
 Sequence.SetOverloadFailure(
 
InitializationSequence::FK_UserConversionOverloadFailed,
 Result);
-
-// [class.copy.elision]p3:
-// In some copy-initialization contexts, a two-stage overload resolution
-// is performed.
-// If the first overload resolution selects a deleted function, we also
-// need the initialization sequence to decide whether to perform the second
-// overload resolution.
-if (!(Result == OR_Deleted &&
-  Kind.getKind() == InitializationKind::IK_Copy))
-  return;
+return;
   }
 
   FunctionDecl *Function = Best->Function

[PATCH] D92935: Introduce support for PowerPC devices with an Embedded Floating-point APU version 2 (efpu2)

2021-01-04 Thread Michael Kiausch via Phabricator via cfe-commits
kiausch added a comment.

Ping.


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

https://reviews.llvm.org/D92935

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


[PATCH] D91806: [InstCombine] Update valueCoversEntireFragment to use TypeSize

2021-01-04 Thread Peter Waller via Phabricator via cfe-commits
peterwaller-arm added inline comments.



Comment at: llvm/test/Transforms/InstCombine/debuginfo-scalable-typesize.ll:13
+
+; ERR-NOT: TypeSize is not scalable
+

sdesmalen wrote:
> After your changes, what line causes this warning to be emitted? Does this 
> test also pass with asserts enabled?
It's a -NOT check, so it's not being emitted. Yes, the test passes even with 
asserts enabled.

I assume the question is motivated by putting the check next to the line which 
causes the warning(?).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91806

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


[PATCH] D93101: [Clang][Codegen] Truncate initializers of union bitfield members

2021-01-04 Thread Tomas Matheson via Phabricator via cfe-commits
tmatheson added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93101

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


[PATCH] D93597: [X86][SSE] Enable constexpr on some basic SSE intrinsics (RFC)

2021-01-04 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon added a comment.

Does anyone have any feedback before I expand this to cover all the SSE2/AVX 
equivalents?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93597

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


[PATCH] D92935: Introduce support for PowerPC devices with an Embedded Floating-point APU version 2 (efpu2)

2021-01-04 Thread Qing Shan Zhang via Phabricator via cfe-commits
steven.zhang added a comment.

Some code style comments.




Comment at: clang/include/clang/Driver/Options.td:2603
 def mno_spe : Flag<["-"], "mno-spe">, Group;
+def mefpu2 : Flag<["-"], "mefpu2">, Group;
 def mabi_EQ_vec_extabi : Flag<["-"], "mabi=vec-extabi">, Group, 
Flags<[CC1Option]>,

Maybe, clang/docs/ClangCommandLineReference.rst need to be updated also ?



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.h:707
 
+bool hasEFPU2() const;
+

I think we don't need such wrap but just call Subtarget.hasEFPU2() directly.



Comment at: llvm/lib/Target/PowerPC/PPCSubtarget.h:103
   bool HasSPE;
+  bool HasEFPU2;
   bool HasVSX;

Miss to initialize it ?


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

https://reviews.llvm.org/D92935

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


[PATCH] D93298: [RISCV] add the MC layer support of Zfinx extension

2021-01-04 Thread Shao-Ce Sun via Phabricator via cfe-commits
achieveartificialintelligence updated this revision to Diff 314349.
achieveartificialintelligence marked 2 inline comments as done.
achieveartificialintelligence added a comment.

Including Zfinx, zdinx. Zfhinx.


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

https://reviews.llvm.org/D93298

Files:
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVInstrInfo.td
  llvm/lib/Target/RISCV/RISCVInstrInfoZfinx.td
  llvm/lib/Target/RISCV/RISCVRegisterInfo.td
  llvm/lib/Target/RISCV/RISCVSubtarget.cpp
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/MC/RISCV/rv32i-invalid.s
  llvm/test/MC/RISCV/rv32zdinx-invalid.s
  llvm/test/MC/RISCV/rv32zdinx-valid.s
  llvm/test/MC/RISCV/rv32zfhinx-invalid.s
  llvm/test/MC/RISCV/rv32zfhinx-valid.s
  llvm/test/MC/RISCV/rv32zfinx-invalid.s
  llvm/test/MC/RISCV/rv32zfinx-valid.s
  llvm/test/MC/RISCV/rv64zdinx-invalid.s
  llvm/test/MC/RISCV/rv64zdinx-valid.s
  llvm/test/MC/RISCV/rv64zfhinx-invalid.s
  llvm/test/MC/RISCV/rv64zfhinx-valid.s
  llvm/test/MC/RISCV/rv64zfinx-invalid.s
  llvm/test/MC/RISCV/rv64zfinx-valid.s
  llvm/test/MC/RISCV/rvzdinx-aliases-valid.s
  llvm/test/MC/RISCV/rvzfhinx-aliases-valid.s
  llvm/test/MC/RISCV/rvzfinx-aliases-valid.s

Index: llvm/test/MC/RISCV/rvzfinx-aliases-valid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rvzfinx-aliases-valid.s
@@ -0,0 +1,82 @@
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+experimental-zfinx -riscv-no-aliases \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+experimental-zfinx \
+# RUN: | FileCheck -check-prefix=CHECK-ALIAS %s
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+experimental-zfinx -riscv-no-aliases \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+experimental-zfinx \
+# RUN: | FileCheck -check-prefix=CHECK-ALIAS %s
+# RUN: llvm-mc -filetype=obj -triple riscv32 -mattr=+experimental-zfinx < %s \
+# RUN: | llvm-objdump -d --mattr=+experimental-zfinx -M no-aliases - \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+# RUN: llvm-mc -filetype=obj -triple riscv32 -mattr=+experimental-zfinx < %s \
+# RUN: | llvm-objdump -d --mattr=+experimental-zfinx - \
+# RUN: | FileCheck -check-prefix=CHECK-ALIAS %s
+# RUN: llvm-mc -filetype=obj -triple riscv64 -mattr=+experimental-zfinx < %s \
+# RUN: | llvm-objdump -d --mattr=+experimental-zfinx -M no-aliases - \
+# RUN: | FileCheck -check-prefix=CHECK-INST %s
+# RUN: llvm-mc -filetype=obj -triple riscv64 -mattr=+experimental-zfinx < %s \
+# RUN: | llvm-objdump -d --mattr=+experimental-zfinx - \
+# RUN: | FileCheck -check-prefix=CHECK-ALIAS %s
+
+##===--===##
+## Assembler Pseudo Instructions (User-Level ISA, Version 2.2, Chapter 20)
+##===--===##
+
+# CHECK-INST: fsgnjx.s s1, s2, s2
+# CHECK-ALIAS: fabs.s s1, s2
+fabs.s s1, s2
+# CHECK-INST: fsgnjn.s s2, s3, s3
+# CHECK-ALIAS: fneg.s s2, s3
+fneg.s s2, s3
+
+# CHECK-INST: flt.s tp, s6, s5
+# CHECK-ALIAS: flt.s tp, s6, s5
+fgt.s x4, s5, s6
+# CHECK-INST: fle.s t2, s1, s0
+# CHECK-ALIAS: fle.s t2, s1, s0
+fge.s x7, x8, x9
+
+##===--===##
+## Aliases which omit the rounding mode.
+##===--===##
+
+# CHECK-INST: fmadd.s a0, a1, a2, a3, dyn
+# CHECK-ALIAS: fmadd.s a0, a1, a2, a3{{[[:space:]]}}
+fmadd.s x10, x11, x12, x13
+# CHECK-INST: fmsub.s a4, a5, a6, a7, dyn
+# CHECK-ALIAS: fmsub.s a4, a5, a6, a7{{[[:space:]]}}
+fmsub.s x14, x15, x16, x17
+# CHECK-INST: fnmsub.s s2, s3, s4, s5, dyn
+# CHECK-ALIAS: fnmsub.s s2, s3, s4, s5{{[[:space:]]}}
+fnmsub.s x18, x19, x20, x21
+# CHECK-INST: fnmadd.s s6, s7, s8, s9, dyn
+# CHECK-ALIAS: fnmadd.s s6, s7, s8, s9{{[[:space:]]}}
+fnmadd.s x22, x23, x24, x25
+# CHECK-INST: fadd.s s10, s11, t3, dyn
+# CHECK-ALIAS: fadd.s s10, s11, t3{{[[:space:]]}}
+fadd.s x26, x27, x28
+# CHECK-INST: fsub.s t4, t5, t6, dyn
+# CHECK-ALIAS: fsub.s t4, t5, t6{{[[:space:]]}}
+fsub.s x29, x30, x31
+# CHECK-INST: fmul.s s0, s1, s2, dyn
+# CHECK-ALIAS: fmul.s s0, s1, s2{{[[:space:]]}}
+fmul.s s0, s1, s2
+# CHECK-INST: fdiv.s s3, s4, s5, dyn
+# CHECK-ALIAS: fdiv.s s3, s4, s5{{[[:space:]]}}
+fdiv.s s3, s4, s5
+# CHECK-INST: sqrt.s s6, s7, dyn
+# CHECK-ALIAS: sqrt.s s6, s7{{[[:space:]]}}
+fsqrt.s s6, s7
+# CHECK-INST: fcvt.w.s a0, s5, dyn
+# CHECK-ALIAS: fcvt.w.s a0, s5{{[[:space:]]}}
+fcvt.w.s a0, s5
+# CHECK-INST: fcvt.wu.s a1, s6, dyn
+# CHECK-ALIAS: fcvt.wu.s a1, s6{{[[:space:]]}}
+fcvt.wu.s a1, s6
+# CHECK-INST: fcvt.s.w t6, a4, dyn
+# CHECK-ALIAS: fcvt.s.w t6, a4{{[[:space:]]}}
+fcvt.s.w t6, a4
+# CHECK-INST: fcvt.s.wu s0, a5, d

[PATCH] D94011: [Sema] Fix deleted function problem in implicitly movable test

2021-01-04 Thread Yang Fan via Phabricator via cfe-commits
nullptr.cpp created this revision.
nullptr.cpp requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

In implicitly movable test, a two-stage overload resolution is performed.
If the first overload resolution selects a deleted function, Clang directly
performs the second overload resolution, without checking whether the
deleted function matches the additional criteria.

This patch fixes the above problem.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94011

Files:
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/test/CXX/class/class.init/class.copy.elision/p3.cpp

Index: clang/test/CXX/class/class.init/class.copy.elision/p3.cpp
===
--- /dev/null
+++ clang/test/CXX/class/class.init/class.copy.elision/p3.cpp
@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -fcxx-exceptions -verify=expected %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcxx-exceptions -verify=expected %s
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -fcxx-exceptions -verify=expected %s
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fcxx-exceptions -verify=expected %s
+
+namespace test_delete_function {
+struct A1 {
+  A1();
+  A1(const A1 &);
+  A1(A1 &&) = delete; // expected-note {{'A1' has been explicitly marked deleted here}}
+};
+A1 test1() {
+  A1 a;
+  return a; // expected-error {{call to deleted constructor of 'test_delete_function::A1'}}
+}
+
+struct A2 {
+  A2();
+  A2(const A2 &);
+
+private:
+  A2(A2 &&); // expected-note {{declared private here}}
+};
+A2 test2() {
+  A2 a;
+  return a; // expected-error {{calling a private constructor of class 'test_delete_function::A2'}}
+}
+
+struct C {};
+
+struct B1 {
+  B1(C &);
+  B1(C &&) = delete; // expected-note {{'B1' has been explicitly marked deleted here}}
+};
+B1 test3() {
+  C c;
+  return c; // expected-error {{conversion function from 'test_delete_function::C' to 'test_delete_function::B1' invokes a deleted function}}
+}
+
+struct B2 {
+  B2(C &);
+
+private:
+  B2(C &&); // expected-note {{declared private here}}
+};
+B2 test4() {
+  C c;
+  return c; // expected-error {{calling a private constructor of class 'test_delete_function::B2'}}
+}
+} // namespace test_delete_function
Index: clang/lib/Sema/SemaStmt.cpp
===
--- clang/lib/Sema/SemaStmt.cpp
+++ clang/lib/Sema/SemaStmt.cpp
@@ -3118,7 +3118,12 @@
 /// If move-initialization is not possible, such that we must fall back to
 /// treating the operand as an lvalue, we will leave Res in its original
 /// invalid state.
-static void TryMoveInitialization(Sema &S, const InitializedEntity &Entity,
+///
+/// \returns Whether we need to do the second overload resolution. If the first
+/// overload resolution fails, or if the first overload resolution succeeds but
+/// the selected constructor/operator doesn't match the additional criteria, we
+/// need to do the second overload resolution.
+static bool TryMoveInitialization(Sema &S, const InitializedEntity &Entity,
   const VarDecl *NRVOCandidate,
   QualType ResultType, Expr *&Value,
   bool ConvertingConstructorsOnly,
@@ -3133,8 +3138,10 @@
 
   InitializationSequence Seq(S, Entity, Kind, InitExpr);
 
-  if (!Seq)
-return;
+  bool NeedSecondOverloadResolution = true;
+  if (!Seq && Seq.getFailedOverloadResult() != OR_Deleted) {
+return NeedSecondOverloadResolution;
+  }
 
   for (const InitializationSequence::Step &Step : Seq.steps()) {
 if (Step.Kind != InitializationSequence::SK_ConstructorInitialization &&
@@ -3177,6 +3184,7 @@
   }
 }
 
+NeedSecondOverloadResolution = false;
 // Promote "AsRvalue" to the heap, since we now need this
 // expression node to persist.
 Value =
@@ -3187,6 +3195,8 @@
 // using the constructor we found.
 Res = Seq.Perform(S, Entity, Kind, Value);
   }
+
+  return NeedSecondOverloadResolution;
 }
 
 /// Perform the initialization of a potentially-movable value, which
@@ -3211,6 +3221,7 @@
   // select the constructor for the copy is first performed as if the object
   // were designated by an rvalue.
   ExprResult Res = ExprError();
+  bool NeedSecondOverloadResolution = true;
 
   if (AllowNRVO) {
 bool AffectedByCWG1579 = false;
@@ -3227,11 +3238,11 @@
 }
 
 if (NRVOCandidate) {
-  TryMoveInitialization(*this, Entity, NRVOCandidate, ResultType, Value,
-true, Res);
+  NeedSecondOverloadResolution = TryMoveInitialization(
+  *this, Entity, NRVOCandidate, ResultType, Value, true, Res);
 }
 
-if (!Res.isInvalid() && AffectedByCWG1579) {
+if (!NeedSecondOverloadResolution && AffectedByCWG1579) {
   QualType QT = NRVOCandidate->getType();
   if (QT.getNonReferenceType().getUnqualifiedType().isTriviallyCopyableType(

[PATCH] D93298: [RISCV] add the MC layer support of Zfinx extension

2021-01-04 Thread luxufan via Phabricator via cfe-commits
StephenFan added inline comments.



Comment at: llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp:983
+  }
+
   return Match_InvalidOperand;

It seems like that this function is not useful.


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

https://reviews.llvm.org/D93298

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


[PATCH] D92935: Introduce support for PowerPC devices with an Embedded Floating-point APU version 2 (efpu2)

2021-01-04 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai accepted this revision.
nemanjai added a comment.
This revision is now accepted and ready to land.

I don't really have any objections to this, but if there is a similar options 
to GCC, I would hope that they are the same. Please add a comment in the commit 
message to that end.
Other than that, LGTM.




Comment at: llvm/test/CodeGen/PowerPC/efpu2.ll:6
+; Single tests 
+; identical to tests in spe.ll
+

It might make sense to just add a RUN line in that test case rather than 
stating in a comment that they are identical (i.e. they may not be identical if 
the original one changes down the road).


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

https://reviews.llvm.org/D92935

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


[PATCH] D93298: [RISCV] add the MC layer support of Zfinx extension

2021-01-04 Thread Shao-Ce Sun via Phabricator via cfe-commits
achieveartificialintelligence marked an inline comment as done.
achieveartificialintelligence added a comment.

In D93298#2457925 , @kito-cheng wrote:

> Do you have implement register pair for rv32ifd_zfinx? I didn't saw the 
> related implementation, but I could be wrong since I am not LLVM expert, in 
> case you have implemented, you need a test case for that.

We have solved this now.


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

https://reviews.llvm.org/D93298

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


[PATCH] D93298: [RISCV] add the MC layer support of Zfinx extension

2021-01-04 Thread Jessica Clarke via Phabricator via cfe-commits
jrtc27 added a comment.

Your tests look like copies of the F/D/Zfh tests with not all the comments 
updated and instances of tests that just don't make sense for Zfinx. I only 
skimmed them and picked up a few issues, I haven't gone through them 
thoroughly, please do that yourself.




Comment at: llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp:341
 
+  bool isGPRasFPR() const { return isGPR() && IsGPRasFPR; }
+

as -> As everywhere



Comment at: llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp:975-977
+  // As the parser couldn't differentiate an GPRH, GPRF, GPRD, GPRPD from an
+  // GPR, coerce the register from GPR to these if necessary.
+  if (IsRegGPR && Kind == MCK_GPRPD && !isRV64()) {

Comment doesn't match what you do, and it's "a GPR" not "an GPR". Are there 
tests that demonstrate all these potentially-problematic cases as working?



Comment at: llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp:1663
 
+OperandMatchResultTy RISCVAsmParser::parseGPRasFPR(OperandVector &Operands) {
+  switch (getLexer().getKind()) {

Why can't you just use parseRegister?



Comment at: llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp:403
+!STI.getFeatureBits()[RISCV::Feature64Bit]) {
+  LLVM_DEBUG(dbgs() << "Trying RV32DZfinx table (Double in Integer and"
+  "rv32)\n");

RV32Zfdinx?



Comment at: llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp:414-416
+STI.getFeatureBits()[RISCV::FeatureExtZfhinx] ||
+(STI.getFeatureBits()[RISCV::FeatureExtZdinx] &&
+ STI.getFeatureBits()[RISCV::Feature64Bit])) {

Don't all these imply Zfinx? Should just need to check if Zfinx.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoZfinx.td:20
+
+def GPRasFPR : AsmOperandClass {
+  let Name = "GPRasFPR";

I don't see why the default `parseRegister` doesn't work, then you can ditch 
all these `AsmOperandClass`es.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoZfinx.td:35
+
+def GPRHOp : RegisterOperand {
+  let ParserMatchClass = GPRasFPR;

I don't like that all these exist, but not sure if there's a nice way to avoid 
them? If not, please use 16/32/64 suffixes like for FPRs rather than 
H/D/nothing, it gets confusing otherwise.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoZfinx.td:59
+let hasSideEffects = 0, mayLoad = 0, mayStore = 0 in
+class FPUnaryOpINX_r funct7, bits<3> funct3, RegisterOperand rdty,
+RegisterOperand rs1ty, string opcodestr>

Don't duplicate all these, they're identical to the normal floating point 
versions.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoZfinx.td:71
+
+// RV32/64 and zfh extension
+let hasSideEffects = 0, mayLoad = 0, mayStore = 0 in

Zfh



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoZfinx.td:119
+
+// RV64 D extension
+let hasSideEffects = 0, mayLoad = 0, mayStore = 0 in

Zfd



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoZfinx.td:177
+
+// instructions in zfh extension
+let Predicates = [HasStdExtZfhinx] in {

Instruction in Zfhinx extension



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoZfinx.td:177
+
+// instructions in zfh extension
+let Predicates = [HasStdExtZfhinx] in {

jrtc27 wrote:
> Instruction in Zfhinx extension
It'd be nicer if the file were split up into multiple separate files the same 
way as we do for F/D/Zfh rather than having a single big file with everything.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoZfinx.td:275
+
+// instructions in F extension and rv64
+let Predicates = [HasStdExtZfhinx, IsRV64] in {

Instructions in Zfhinx extension on RV64 / Instructions in RV64Zfhinx



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoZfinx.td:316
+
+// instructions in F extension, no matter rv32 or rv64
+let Predicates = [HasStdExtZfinx] in {

Instructions in Zfinx extension



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoZfinx.td:415
+
+// instructions that in F extention and rv64
+let Predicates = [HasStdExtZfinx, IsRV64] in {

etc, I won't keep repeating myself



Comment at: llvm/lib/Target/RISCV/RISCVRegisterInfo.td:113
[i32,  i64]>;
+def ZfinxLenVT : ValueTypeByHwMode<[RV32, RV64],
+   [f32, f64]>;

This doesn't seem to be used.



Comment at: llvm/lib/Target/RISCV/RISCVRegisterInfo.td:468
+   Reg.AltNames> {
+  let SubRegIndices = [sub_32, sub_32_hi];
+}

Does this hard-coding 

[PATCH] D92762: [clang][AArch64][SVE] Avoid going through memory for coerced VLST arguments

2021-01-04 Thread Joe Ellis via Phabricator via cfe-commits
joechrisellis updated this revision to Diff 314354.
joechrisellis marked 2 inline comments as done.
joechrisellis added a comment.

Address @c-rhodes's comments.

- Make comment clearer.
- Change structure of the if statements for better readability.
- Drop superfluous `this->`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92762

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.cpp
  clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c

Index: clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
===
--- clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
+++ clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
@@ -13,11 +13,8 @@
 
 // CHECK-LABEL: @to_svint32_t(
 // CHECK-NEXT:  entry:
-// CHECK-NEXT:[[TYPE:%.*]] = alloca <16 x i32>, align 16
-// CHECK-NEXT:[[TMP0:%.*]] = bitcast <16 x i32>* [[TYPE]] to *
-// CHECK-NEXT:store  [[TYPE_COERCE:%.*]], * [[TMP0]], align 16
-// CHECK-NEXT:[[TYPE1:%.*]] = load <16 x i32>, <16 x i32>* [[TYPE]], align 16, [[TBAA6:!tbaa !.*]]
-// CHECK-NEXT:[[CASTSCALABLESVE:%.*]] = call  @llvm.experimental.vector.insert.nxv4i32.v16i32( undef, <16 x i32> [[TYPE1]], i64 0)
+// CHECK-NEXT:[[TYPE:%.*]] = call <16 x i32> @llvm.experimental.vector.extract.v16i32.nxv4i32( [[X_COERCE:%.*]], i64 0)
+// CHECK-NEXT:[[CASTSCALABLESVE:%.*]] = call  @llvm.experimental.vector.insert.nxv4i32.v16i32( undef, <16 x i32> [[TYPE]], i64 0)
 // CHECK-NEXT:ret  [[CASTSCALABLESVE]]
 //
 svint32_t to_svint32_t(fixed_int32_t type) {
@@ -39,11 +36,8 @@
 
 // CHECK-LABEL: @to_svfloat64_t(
 // CHECK-NEXT:  entry:
-// CHECK-NEXT:[[TYPE:%.*]] = alloca <8 x double>, align 16
-// CHECK-NEXT:[[TMP0:%.*]] = bitcast <8 x double>* [[TYPE]] to *
-// CHECK-NEXT:store  [[TYPE_COERCE:%.*]], * [[TMP0]], align 16
-// CHECK-NEXT:[[TYPE1:%.*]] = load <8 x double>, <8 x double>* [[TYPE]], align 16, [[TBAA6]]
-// CHECK-NEXT:[[CASTSCALABLESVE:%.*]] = call  @llvm.experimental.vector.insert.nxv2f64.v8f64( undef, <8 x double> [[TYPE1]], i64 0)
+// CHECK-NEXT:[[TYPE:%.*]] = call <8 x double> @llvm.experimental.vector.extract.v8f64.nxv2f64( [[X_COERCE:%.*]], i64 0)
+// CHECK-NEXT:[[CASTSCALABLESVE:%.*]] = call  @llvm.experimental.vector.insert.nxv2f64.v8f64( undef, <8 x double> [[TYPE]], i64 0)
 // CHECK-NEXT:ret  [[CASTSCALABLESVE]]
 //
 svfloat64_t to_svfloat64_t(fixed_float64_t type) {
@@ -69,7 +63,7 @@
 // CHECK-NEXT:[[TYPE_ADDR:%.*]] = alloca <8 x i8>, align 16
 // CHECK-NEXT:[[TMP0:%.*]] = bitcast <8 x i8>* [[TYPE]] to *
 // CHECK-NEXT:store  [[TYPE_COERCE:%.*]], * [[TMP0]], align 16
-// CHECK-NEXT:[[TYPE1:%.*]] = load <8 x i8>, <8 x i8>* [[TYPE]], align 16, [[TBAA6]]
+// CHECK-NEXT:[[TYPE1:%.*]] = load <8 x i8>, <8 x i8>* [[TYPE]], align 16, [[TBAA6:!tbaa !.*]]
 // CHECK-NEXT:store <8 x i8> [[TYPE1]], <8 x i8>* [[TYPE_ADDR]], align 16, [[TBAA6]]
 // CHECK-NEXT:[[TMP1:%.*]] = bitcast <8 x i8>* [[TYPE_ADDR]] to *
 // CHECK-NEXT:[[TMP2:%.*]] = load , * [[TMP1]], align 16, [[TBAA6]]
@@ -130,11 +124,8 @@
 
 // CHECK-LABEL: @from_fixed_int32_t__to_gnu_int32_t(
 // CHECK-NEXT:  entry:
-// CHECK-NEXT:[[TYPE:%.*]] = alloca <16 x i32>, align 16
-// CHECK-NEXT:[[TMP0:%.*]] = bitcast <16 x i32>* [[TYPE]] to *
-// CHECK-NEXT:store  [[TYPE_COERCE:%.*]], * [[TMP0]], align 16
-// CHECK-NEXT:[[TYPE1:%.*]] = load <16 x i32>, <16 x i32>* [[TYPE]], align 16, [[TBAA6]]
-// CHECK-NEXT:store <16 x i32> [[TYPE1]], <16 x i32>* [[AGG_RESULT:%.*]], align 16, [[TBAA6]]
+// CHECK-NEXT:[[TYPE:%.*]] = call <16 x i32> @llvm.experimental.vector.extract.v16i32.nxv4i32( [[X_COERCE:%.*]], i64 0)
+// CHECK-NEXT:store <16 x i32> [[TYPE]], <16 x i32>* [[AGG_RESULT:%.*]], align 16, [[TBAA6]]
 // CHECK-NEXT:ret void
 //
 gnu_int32_t from_fixed_int32_t__to_gnu_int32_t(fixed_int32_t type) {
Index: clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
===
--- clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
+++ clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
@@ -24,17 +24,14 @@
 
 // CHECK-LABEL: @fixed_caller(
 // CHECK-NEXT:  entry:
-// CHECK-NEXT:[[X:%.*]] = alloca <16 x i32>, align 16
 // CHECK-NEXT:[[RETVAL_COERCE:%.*]] = alloca , align 16
-// CHECK-NEXT:[[TMP0:%.*]] = bitcast <16 x i32>* [[X]] to *
-// CHECK-NEXT:store  [[X_COERCE:%.*]], * [[TMP0]], align 16
-// CHECK-NEXT:[[X1:%.*]] = load <16 x i32>, <16 x i32>* [[X]], align 16, [[TBAA6:!tbaa !.*]]
-// CHECK-NEXT:[[CASTSCALABLESVE:%.*]] = call  @llvm.experimental.vector.insert.nxv4i32.v16i32( undef, <16 x i32> [[X1]], i64 0)
+// CHECK-NEXT:[[X:%.*]] = call <16 x i32>

[PATCH] D92751: [clang][aarch64] Precondition isHomogeneousAggregate on isCXX14Aggregate

2021-01-04 Thread David Truby via Phabricator via cfe-commits
DavidTruby updated this revision to Diff 314356.
DavidTruby added a comment.

Refactor based on review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92751

Files:
  clang/lib/CodeGen/ABIInfo.h
  clang/lib/CodeGen/CGCXXABI.cpp
  clang/lib/CodeGen/CGCXXABI.h
  clang/lib/CodeGen/MicrosoftCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGenCXX/homogeneous-aggregates.cpp
  llvm/test/CodeGen/AArch64/arm64-windows-calls.ll

Index: llvm/test/CodeGen/AArch64/arm64-windows-calls.ll
===
--- llvm/test/CodeGen/AArch64/arm64-windows-calls.ll
+++ llvm/test/CodeGen/AArch64/arm64-windows-calls.ll
@@ -98,3 +98,74 @@
   %this1 = load %class.C*, %class.C** %this.addr, align 8
   ret void
 }
+
+; The following tests correspond to tests in
+; clang/test/CodeGenCXX/microsoft-abi-sret-and-byval.cpp
+
+; Pod is a trivial HFA
+%struct.Pod = type { [2 x double] }
+; Not an aggregate according to C++14 spec => not HFA according to MSVC
+%struct.NotCXX14Aggregate  = type { %struct.Pod }
+; NotPod is a C++14 aggregate. But not HFA, because it contains
+; NotCXX14Aggregate (which itself is not HFA because it's not a C++14
+; aggregate).
+%struct.NotPod = type { %struct.NotCXX14Aggregate }
+
+define dso_local %struct.Pod @copy_pod(%struct.Pod* %x) {
+  %x1 = load %struct.Pod, %struct.Pod* %x, align 8
+  ret %struct.Pod %x1
+; CHECK: ldp d0, d1, [x0]
+}
+
+declare void @llvm.memcpy.p0i8.p0i8.i64(i8* noalias nocapture writeonly, i8* noalias nocapture readonly, i64, i1 immarg)
+
+define dso_local void
+@copy_notcxx14aggregate(%struct.NotCXX14Aggregate* inreg noalias sret(%struct.NotCXX14Aggregate) align 8 %agg.result,
+%struct.NotCXX14Aggregate* %x) {
+  %1 = bitcast %struct.NotCXX14Aggregate* %agg.result to i8*
+  %2 = bitcast %struct.NotCXX14Aggregate* %x to i8*
+  call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 8 %1, i8* align 8 %2, i64 16, i1 false)
+  ret void
+; CHECK: str q0, [x0]
+}
+
+define dso_local [2 x i64] @copy_notpod(%struct.NotPod* %x) {
+  %x1 = bitcast %struct.NotPod* %x to [2 x i64]*
+  %x2 = load [2 x i64], [2 x i64]* %x1
+  ret [2 x i64] %x2
+; CHECK: ldp x8, x1, [x0]
+; CHECK: mov x0, x8
+}
+
+@Pod = external global %struct.Pod
+
+define void @call_copy_pod() {
+  %x = call %struct.Pod @copy_pod(%struct.Pod* @Pod)
+  store %struct.Pod %x, %struct.Pod* @Pod
+  ret void
+  ; CHECK: bl copy_pod
+  ; CHECK-NEXT: stp d0, d1, [{{.*}}]
+}
+
+@NotCXX14Aggregate = external global %struct.NotCXX14Aggregate
+
+define void @call_copy_notcxx14aggregate() {
+  %x = alloca %struct.NotCXX14Aggregate
+  call void @copy_notcxx14aggregate(%struct.NotCXX14Aggregate* %x, %struct.NotCXX14Aggregate* @NotCXX14Aggregate)
+  %x1 = load %struct.NotCXX14Aggregate, %struct.NotCXX14Aggregate* %x
+  store %struct.NotCXX14Aggregate %x1, %struct.NotCXX14Aggregate* @NotCXX14Aggregate
+  ret void
+  ; CHECK: bl copy_notcxx14aggregate
+  ; CHECK-NEXT: ldp {{.*}}, {{.*}}, [sp]
+}
+
+@NotPod = external global %struct.NotPod
+
+define void @call_copy_notpod() {
+  %x = call [2 x i64] @copy_notpod(%struct.NotPod* @NotPod)
+  %notpod = bitcast %struct.NotPod* @NotPod to [2 x i64]*
+  store [2 x i64] %x, [2 x i64]* %notpod
+  ret void
+  ; CHECK: bl copy_notpod
+  ; CHECK-NEXT: stp x0, x1, [{{.*}}]
+}
Index: clang/test/CodeGenCXX/homogeneous-aggregates.cpp
===
--- clang/test/CodeGenCXX/homogeneous-aggregates.cpp
+++ clang/test/CodeGenCXX/homogeneous-aggregates.cpp
@@ -104,3 +104,66 @@
 // ARM32: define arm_aapcs_vfpcc void @_Z19with_empty_bitfield20HVAWithEmptyBitField(%struct.HVAWithEmptyBitField %a.coerce)
 // X64: define dso_local x86_vectorcallcc void @"\01_Z19with_empty_bitfield20HVAWithEmptyBitField@@16"(%struct.HVAWithEmptyBitField inreg %a.coerce)
 void CC with_empty_bitfield(HVAWithEmptyBitField a) {}
+
+namespace pr47611 {
+// MSVC on Arm includes "isCXX14Aggregate" as part of its definition of
+// Homogeneous Floating-point Aggregate (HFA). Additionally, it has a different
+// handling of C++14 aggregates, which can lead to confusion.
+
+// Pod is a trivial HFA.
+struct Pod {
+  double b[2];
+};
+// Not an aggregate according to C++14 spec => not HFA according to MSVC.
+struct NotCXX14Aggregate {
+  NotCXX14Aggregate();
+  Pod p;
+};
+// NotPod is a C++14 aggregate. But not HFA, because it contains
+// NotCXX14Aggregate (which itself is not HFA because it's not a C++14
+// aggregate).
+struct NotPod {
+  NotCXX14Aggregate x;
+};
+struct Empty {};
+// A class with a base is returned using the sret calling convetion by MSVC.
+struct HasEmptyBase : public Empty {
+  double b[2];
+};
+struct HasPodBase : public Pod {};
+// WOA64-LABEL: define dso_local %"struct.pr47611::Pod" @"?copy@pr47611@@YA?AUPod@1@PEAU21@@Z"(%"struct.pr47611::Pod"* %x)
+Pod copy(Pod *x) { return *x; } // MSVC: ldp d0,d1,[x0]

[PATCH] D92751: [clang][aarch64] Precondition isHomogeneousAggregate on isCXX14Aggregate

2021-01-04 Thread David Truby via Phabricator via cfe-commits
DavidTruby marked an inline comment as done.
DavidTruby added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:5158-5160
   // For compatibility with GCC, ignore empty bitfields in C++ mode.
   if (getContext().getLangOpts().CPlusPlus &&
   FD->isZeroLengthBitField(getContext()))

rnk wrote:
> This check seems suspect. I'd suggest constructing a test case involving zero 
> width bitfields to see if we are compatible with MSVC.
I can add tests for this but I think it should go into a separate patch as it's 
not behaviour changed by this patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92751

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


[PATCH] D92751: [clang][aarch64] Precondition isHomogeneousAggregate on isCXX14Aggregate

2021-01-04 Thread David Truby via Phabricator via cfe-commits
DavidTruby added inline comments.



Comment at: clang/test/CodeGenCXX/microsoft-abi-sret-and-byval.cpp:493
+struct Empty {};
+// A class with a base is returned in standard registers by MSVC
+struct HasEmptyBase : public Empty {

rnk wrote:
> This comment doesn't seem accurate to me, it's returned indirectly in memory, 
> right? The test for it below uses sret. In other words, this class never hits 
> the HVA codepath because the C++ ABI marks it indirect.
Yes, you're right. I wrote completely the opposite of what I meant here. I have 
corrected it now!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92751

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


[PATCH] D93298: [RISCV] add the MC layer support of Zfinx extension

2021-01-04 Thread Shao-Ce Sun via Phabricator via cfe-commits
achieveartificialintelligence added a comment.

In D93298#2477105 , @jrtc27 wrote:

> Your tests look like copies of the F/D/Zfh tests with not all the comments 
> updated and instances of tests that just don't make sense for Zfinx. I only 
> skimmed them and picked up a few issues, I haven't gone through them 
> thoroughly, please do that yourself.

Thanks for your advices. We will solve the issues you have mentioned above.


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

https://reviews.llvm.org/D93298

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


[PATCH] D92935: Introduce support for PowerPC devices with an Embedded Floating-point APU version 2 (efpu2)

2021-01-04 Thread Michael Kiausch via Phabricator via cfe-commits
kiausch added a comment.

Regarding similar GCC options:

AFAIK GCC has had the spe options -msingle-float and -mdouble-float until spe 
support was dropped after version 8.3.
These options would kind of match here, but they are already used as MIPS 
subtarget features in LLVM and I was not able to find out if and how it is 
possible to use identical target features for multiple targets and if this is a 
good idea at all? If somebody could point out how this can be done I'm happy to 
change the options...


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

https://reviews.llvm.org/D92935

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


[PATCH] D93298: [RISCV] add the MC layer support of Zfinx extension

2021-01-04 Thread luxufan via Phabricator via cfe-commits
StephenFan added inline comments.



Comment at: llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp:1663
 
+OperandMatchResultTy RISCVAsmParser::parseGPRasFPR(OperandVector &Operands) {
+  switch (getLexer().getKind()) {

jrtc27 wrote:
> Why can't you just use parseRegister?
use the default parseRegister will make the test cases in other files fail. For 
example:

```
fcvt.d.l a3, ft3 # CHECK: :[[@LINE]]:10: error: invalid operand for instruction
```
this is the test case in rv64d-invalid.s. If uses the default parseRegister. 
the invalid operand is in column 14 (ft3 operand) instead of 10 (a3 operand).



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoZfinx.td:59
+let hasSideEffects = 0, mayLoad = 0, mayStore = 0 in
+class FPUnaryOpINX_r funct7, bits<3> funct3, RegisterOperand rdty,
+RegisterOperand rs1ty, string opcodestr>

jrtc27 wrote:
> Don't duplicate all these, they're identical to the normal floating point 
> versions.
Because of normal floating point version only support RegisterClass, but we use 
the RegisterOperand, so we change this. Or if there is more convenient way to 
resolve this?



Comment at: llvm/lib/Target/RISCV/RISCVRegisterInfo.td:468
+   Reg.AltNames> {
+  let SubRegIndices = [sub_32, sub_32_hi];
+}

jrtc27 wrote:
> Does this hard-coding of 32 cause issues on RV64?
I don't known if it will cause issues on RV64. But the zfinx spec specifies 
that register pairs are only used in RV32


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

https://reviews.llvm.org/D93298

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


[PATCH] D92751: [clang][aarch64] Precondition isHomogeneousAggregate on isCXX14Aggregate

2021-01-04 Thread David Truby via Phabricator via cfe-commits
DavidTruby updated this revision to Diff 314357.
DavidTruby added a comment.

Switch from CHECK to CHECK-LABEL in tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92751

Files:
  clang/lib/CodeGen/ABIInfo.h
  clang/lib/CodeGen/CGCXXABI.cpp
  clang/lib/CodeGen/CGCXXABI.h
  clang/lib/CodeGen/MicrosoftCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGenCXX/homogeneous-aggregates.cpp
  llvm/test/CodeGen/AArch64/arm64-windows-calls.ll

Index: llvm/test/CodeGen/AArch64/arm64-windows-calls.ll
===
--- llvm/test/CodeGen/AArch64/arm64-windows-calls.ll
+++ llvm/test/CodeGen/AArch64/arm64-windows-calls.ll
@@ -98,3 +98,74 @@
   %this1 = load %class.C*, %class.C** %this.addr, align 8
   ret void
 }
+
+; The following tests correspond to tests in
+; clang/test/CodeGenCXX/microsoft-abi-sret-and-byval.cpp
+
+; Pod is a trivial HFA
+%struct.Pod = type { [2 x double] }
+; Not an aggregate according to C++14 spec => not HFA according to MSVC
+%struct.NotCXX14Aggregate  = type { %struct.Pod }
+; NotPod is a C++14 aggregate. But not HFA, because it contains
+; NotCXX14Aggregate (which itself is not HFA because it's not a C++14
+; aggregate).
+%struct.NotPod = type { %struct.NotCXX14Aggregate }
+
+define dso_local %struct.Pod @copy_pod(%struct.Pod* %x) {
+  %x1 = load %struct.Pod, %struct.Pod* %x, align 8
+  ret %struct.Pod %x1
+; CHECK-LABEL: ldp d0, d1, [x0]
+}
+
+declare void @llvm.memcpy.p0i8.p0i8.i64(i8* noalias nocapture writeonly, i8* noalias nocapture readonly, i64, i1 immarg)
+
+define dso_local void
+@copy_notcxx14aggregate(%struct.NotCXX14Aggregate* inreg noalias sret(%struct.NotCXX14Aggregate) align 8 %agg.result,
+%struct.NotCXX14Aggregate* %x) {
+  %1 = bitcast %struct.NotCXX14Aggregate* %agg.result to i8*
+  %2 = bitcast %struct.NotCXX14Aggregate* %x to i8*
+  call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 8 %1, i8* align 8 %2, i64 16, i1 false)
+  ret void
+; CHECK-LABEL: str q0, [x0]
+}
+
+define dso_local [2 x i64] @copy_notpod(%struct.NotPod* %x) {
+  %x1 = bitcast %struct.NotPod* %x to [2 x i64]*
+  %x2 = load [2 x i64], [2 x i64]* %x1
+  ret [2 x i64] %x2
+; CHECK-LABEL: ldp x8, x1, [x0]
+; CHECK: mov x0, x8
+}
+
+@Pod = external global %struct.Pod
+
+define void @call_copy_pod() {
+  %x = call %struct.Pod @copy_pod(%struct.Pod* @Pod)
+  store %struct.Pod %x, %struct.Pod* @Pod
+  ret void
+  ; CHECK-LABEL: bl copy_pod
+  ; CHECK-NEXT: stp d0, d1, [{{.*}}]
+}
+
+@NotCXX14Aggregate = external global %struct.NotCXX14Aggregate
+
+define void @call_copy_notcxx14aggregate() {
+  %x = alloca %struct.NotCXX14Aggregate
+  call void @copy_notcxx14aggregate(%struct.NotCXX14Aggregate* %x, %struct.NotCXX14Aggregate* @NotCXX14Aggregate)
+  %x1 = load %struct.NotCXX14Aggregate, %struct.NotCXX14Aggregate* %x
+  store %struct.NotCXX14Aggregate %x1, %struct.NotCXX14Aggregate* @NotCXX14Aggregate
+  ret void
+  ; CHECK-LABEL: bl copy_notcxx14aggregate
+  ; CHECK-NEXT: ldp {{.*}}, {{.*}}, [sp]
+}
+
+@NotPod = external global %struct.NotPod
+
+define void @call_copy_notpod() {
+  %x = call [2 x i64] @copy_notpod(%struct.NotPod* @NotPod)
+  %notpod = bitcast %struct.NotPod* @NotPod to [2 x i64]*
+  store [2 x i64] %x, [2 x i64]* %notpod
+  ret void
+  ; CHECK-LABEL: bl copy_notpod
+  ; CHECK-NEXT: stp x0, x1, [{{.*}}]
+}
Index: clang/test/CodeGenCXX/homogeneous-aggregates.cpp
===
--- clang/test/CodeGenCXX/homogeneous-aggregates.cpp
+++ clang/test/CodeGenCXX/homogeneous-aggregates.cpp
@@ -104,3 +104,66 @@
 // ARM32: define arm_aapcs_vfpcc void @_Z19with_empty_bitfield20HVAWithEmptyBitField(%struct.HVAWithEmptyBitField %a.coerce)
 // X64: define dso_local x86_vectorcallcc void @"\01_Z19with_empty_bitfield20HVAWithEmptyBitField@@16"(%struct.HVAWithEmptyBitField inreg %a.coerce)
 void CC with_empty_bitfield(HVAWithEmptyBitField a) {}
+
+namespace pr47611 {
+// MSVC on Arm includes "isCXX14Aggregate" as part of its definition of
+// Homogeneous Floating-point Aggregate (HFA). Additionally, it has a different
+// handling of C++14 aggregates, which can lead to confusion.
+
+// Pod is a trivial HFA.
+struct Pod {
+  double b[2];
+};
+// Not an aggregate according to C++14 spec => not HFA according to MSVC.
+struct NotCXX14Aggregate {
+  NotCXX14Aggregate();
+  Pod p;
+};
+// NotPod is a C++14 aggregate. But not HFA, because it contains
+// NotCXX14Aggregate (which itself is not HFA because it's not a C++14
+// aggregate).
+struct NotPod {
+  NotCXX14Aggregate x;
+};
+struct Empty {};
+// A class with a base is returned using the sret calling convetion by MSVC.
+struct HasEmptyBase : public Empty {
+  double b[2];
+};
+struct HasPodBase : public Pod {};
+// WOA64-LABEL: define dso_local %"struct.pr47611::Pod" @"?copy@pr47611@@YA?AUPod@1@PEAU21@@Z"(%"struct.pr47611::Pod"* %x)
+Pod copy(P

[PATCH] D93298: [RISCV] add the MC layer support of Zfinx extension

2021-01-04 Thread luxufan via Phabricator via cfe-commits
StephenFan added inline comments.



Comment at: llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp:1663
 
+OperandMatchResultTy RISCVAsmParser::parseGPRasFPR(OperandVector &Operands) {
+  switch (getLexer().getKind()) {

StephenFan wrote:
> jrtc27 wrote:
> > Why can't you just use parseRegister?
> use the default parseRegister will make the test cases in other files fail. 
> For example:
> 
> ```
> fcvt.d.l a3, ft3 # CHECK: :[[@LINE]]:10: error: invalid operand for 
> instruction
> ```
> this is the test case in rv64d-invalid.s. If uses the default parseRegister. 
> the invalid operand is in column 14 (ft3 operand) instead of 10 (a3 operand).
> Why can't you just use parseRegister?

use the default parseRegister will make the test cases in other files fail. For 
example:

```
fcvt.d.l a3, ft3 # CHECK: :[[@LINE]]:10: error: invalid operand for instruction
```
this is the test case in rv64d-invalid.s. If uses the default parseRegister. 
the invalid operand is in column 14 (ft3 operand) instead of 10 (a3 operand).



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoZfinx.td:59
+let hasSideEffects = 0, mayLoad = 0, mayStore = 0 in
+class FPUnaryOpINX_r funct7, bits<3> funct3, RegisterOperand rdty,
+RegisterOperand rs1ty, string opcodestr>

StephenFan wrote:
> jrtc27 wrote:
> > Don't duplicate all these, they're identical to the normal floating point 
> > versions.
> Because of normal floating point version only support RegisterClass, but we 
> use the RegisterOperand, so we change this. Or if there is more convenient 
> way to resolve this?
> Because of normal floating point version only support RegisterClass, but we 
> use the RegisterOperand, so we change this. Or if there is more convenient 
> way to resolve this?

Because of normal floating point version only support RegisterClass, but we use 
the RegisterOperand, so we change this. Or if there is more convenient way to 
resolve this?



Comment at: llvm/lib/Target/RISCV/RISCVRegisterInfo.td:468
+   Reg.AltNames> {
+  let SubRegIndices = [sub_32, sub_32_hi];
+}

StephenFan wrote:
> jrtc27 wrote:
> > Does this hard-coding of 32 cause issues on RV64?
> I don't known if it will cause issues on RV64. But the zfinx spec specifies 
> that register pairs are only used in RV32
> Does this hard-coding of 32 cause issues on RV64?

I don't known if it will cause issues on RV64. But the zfinx spec specifies 
that register pairs are only used in RV32


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

https://reviews.llvm.org/D93298

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


[PATCH] D84673: [clang][cli] Port DiagnosticOpts to new option parsing system

2021-01-04 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added inline comments.



Comment at: llvm/utils/TableGen/OptParserEmitter.cpp:102-107
+  std::string getMacroName() const {
+if (KeyPath.startswith("DiagnosticOpts."))
+  return (Twine("DIAG_") + MarshallingInfo::MacroName).str();
+
+return MarshallingInfo::MacroName;
+  }

dexonsmith wrote:
> This seems like a bit of a semantic layering violation. It'd be pretty 
> unexpected if someone renamed `DiagnosticOpts` in clang that they'd have to 
> update this code in llvm. Is there another way to solve this problem?
I don't like it either, but the alternatives I can think of are worse.

We could add a `string MacroPrefix;` field to LLVM's `Option` class and 
populate it in Clang's TableGen file:
1. Via something like an `IsDiag` multiclass that we'd need to remember to 
apply to each diagnostic option. I don't like it as it seems error prone and 
introduces duplication.
2. Put all diagnostic options into a single `let MacroPrefix = "DIAG_" in { ... 
}` block. This removes the duplication, but doesn't ensure an option is in that 
block iff it's a diagnostic option with `"DiagnosticOpts.*"` keypath.
3. More involved approach would be to duplicate the LLVM's `Option` and related 
stuff in Clang. That would get us a place to put the custom 
`KeyPath.startswith("DiagnosticOpts.")` logic and then forward to LLVM's 
`Option` with the appropriate `MacroPrefix`.

I'll think some more about it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84673

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


[PATCH] D93986: [clang-format] Add the possibility to align assignments spanning empty lines or comments

2021-01-04 Thread Lukas Barth via Phabricator via cfe-commits
tinloaf updated this revision to Diff 314361.
tinloaf added a comment.

Address reviewer comments, noteworthy changes:

- Add an option to span alignment only across comments, not across newlines
- Factor out spanning options to `AlignTokens` to an enum




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93986

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

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -11330,7 +11330,7 @@
"*/\n"
"}",
Tab));
-  Tab.AlignConsecutiveAssignments = true;
+  Tab.AlignConsecutiveAssignments = FormatStyle::ACA_Consecutive;
   Tab.AlignConsecutiveDeclarations = true;
   Tab.TabWidth = 4;
   Tab.IndentWidth = 4;
@@ -11569,7 +11569,7 @@
"*/\n"
"}",
Tab));
-  Tab.AlignConsecutiveAssignments = true;
+  Tab.AlignConsecutiveAssignments = FormatStyle::ACA_Consecutive;
   Tab.AlignConsecutiveDeclarations = true;
   Tab.TabWidth = 4;
   Tab.IndentWidth = 4;
@@ -12271,7 +12271,7 @@
 
 TEST_F(FormatTest, AlignConsecutiveMacros) {
   FormatStyle Style = getLLVMStyle();
-  Style.AlignConsecutiveAssignments = true;
+  Style.AlignConsecutiveAssignments = FormatStyle::ACA_Consecutive;
   Style.AlignConsecutiveDeclarations = true;
   Style.AlignConsecutiveMacros = false;
 
@@ -12364,10 +12364,486 @@
Style);
 }
 
+TEST_F(FormatTest, AlignConsecutiveAssignmentsAcrossEmptyLines) {
+  FormatStyle Alignment = getLLVMStyle();
+  Alignment.AlignConsecutiveMacros = true;
+  Alignment.AlignConsecutiveAssignments = FormatStyle::ACA_AcrossEmptyLines;
+
+  Alignment.MaxEmptyLinesToKeep = 10;
+  /* Test alignment across empty lines */
+  EXPECT_EQ("int a   = 5;\n"
+"\n"
+"int oneTwoThree = 123;",
+format("int a   = 5;\n"
+   "\n"
+   "int oneTwoThree= 123;",
+   Alignment));
+  EXPECT_EQ("int a   = 5;\n"
+"int one = 1;\n"
+"\n"
+"int oneTwoThree = 123;",
+format("int a = 5;\n"
+   "int one = 1;\n"
+   "\n"
+   "int oneTwoThree = 123;",
+   Alignment));
+  EXPECT_EQ("int a   = 5;\n"
+"int one = 1;\n"
+"\n"
+"int oneTwoThree = 123;\n"
+"int oneTwo  = 12;",
+format("int a = 5;\n"
+   "int one = 1;\n"
+   "\n"
+   "int oneTwoThree = 123;\n"
+   "int oneTwo = 12;",
+   Alignment));
+
+  /* Test across comments */
+  EXPECT_EQ("int a = 5;\n"
+"/* block comment */\n"
+"int oneTwoThree = 123;",
+format("int a = 5;\n"
+   "/* block comment */\n"
+   "int oneTwoThree=123;",
+   Alignment));
+
+  EXPECT_EQ("int a = 5;\n"
+"// line comment\n"
+"int oneTwoThree = 123;",
+format("int a = 5;\n"
+   "// line comment\n"
+   "int oneTwoThree=123;",
+   Alignment));
+
+  /* Test across comments and newlines */
+  EXPECT_EQ("int a = 5;\n"
+"\n"
+"/* block comment */\n"
+"int oneTwoThree = 123;",
+format("int a = 5;\n"
+   "\n"
+   "/* block comment */\n"
+   "int oneTwoThree=123;",
+   Alignment));
+
+  EXPECT_EQ("int a = 5;\n"
+"\n"
+"// line comment\n"
+"int oneTwoThree = 123;",
+format("int a = 5;\n"
+   "\n"
+   "// line comment\n"
+   "int oneTwoThree=123;",
+   Alignment));
+}
+
+TEST_F(FormatTest, AlignConsecutiveAssignmentsAcrossComments) {
+  FormatStyle Alignment = getLLVMStyle();
+  Alignment.AlignConsecutiveMacros = true;
+  Alignment.AlignConsecutiveAssignments = FormatStyle::ACA_AcrossComments;
+
+  Alignment.MaxEmptyLinesToKeep = 10;
+  /* Test alignment across empty lines */
+  EXPECT_EQ("int a = 5;\n"
+"\n"
+"int oneTwoThree = 123;",
+format("int a   = 5;\n"
+   "\n"
+   "int oneTwoThree= 123;",
+   Alignment));
+  EXPECT_EQ("int a   = 5;\n"
+"int one = 1;\n"
+"\n"
+"int oneTwoThree = 123;",
+format("int a = 5;\n"
+   "int one = 1;\n"
+   "\n"
+   "int oneTw

[PATCH] D92762: [clang][AArch64][SVE] Avoid going through memory for coerced VLST arguments

2021-01-04 Thread Cullen Rhodes via Phabricator via cfe-commits
c-rhodes accepted this revision.
c-rhodes added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/CodeGen/CGCall.cpp:2706
+
ArgVals.push_back(ParamValue::forDirect(Builder.CreateExtractVector(
+VecTyTo, Coerced, Zero, "castScalableSve")));
+break;

nit: I know we've used `castSve` for `Name` in a couple of 
places already and it's not very descriptive, but I think it describes the type 
being cast to, in which case this should be `castFixedSve`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92762

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


[PATCH] D93986: [clang-format] Add the possibility to align assignments spanning empty lines or comments

2021-01-04 Thread Lukas Barth via Phabricator via cfe-commits
tinloaf marked 5 inline comments as done.
tinloaf added inline comments.



Comment at: clang/include/clang/Format/Format.h:130
+/// \endcode
+ACA_AcrossComments
+  };

MyDeveloperDay wrote:
> tinloaf wrote:
> > MyDeveloperDay wrote:
> > > Is there a case for aligning over empty lines and comments?
> > > 
> > > ```
> > > int a   = 5;
> > > 
> > > /* comment */
> > > int oneTwoThree = 123;
> > > ```
> > Not sure I understand what you mean. Currently, the Option `AcrossComments` 
> > includes 'across empty lines'. So, there currently is no case for "across 
> > comments, but not across empty lines". I'm not sure if that is really 
> > something people want to do. Do you think so? I can add it. 
> I could see a case where you might want to begin a new "alignment group" by 
> leaving a blank line.
> 
> ```
> /* align these 3 */
> int a = 5;
> /* align these 3 */
> int b = 6;
> /* align these 3 */
> int c = 7;
> 
> /* align these 2 which are longer */
> int d   = 5
> /* align these 2 which are longer */
> int oneTwoThree = 123;
> ```
Yes, good point. I've added the option `AlignAcrossEmptyLinesAndComments`, and 
made `AlignAcrossComments` do what the name suggests.



Comment at: clang/lib/Format/WhitespaceManager.cpp:367
+unsigned StartAt, bool AcrossEmpty = false,
+bool AcrossComments = false) {
   unsigned MinColumn = 0;

MyDeveloperDay wrote:
> could this be an enum?
> 
> ```
> enum {
> None
> AcrossEmptyLines,
> AcrossComments,
> AcrossEmptyLinesAndComments,
> }
> ```
Yes, that's probably cleaner, though that means I need a rather ugly `switch` 
statement to convert one enum into the other where `AlignTokens` is called. 
Maybe one could address this with some template magic, but that's probably not 
less ugly than the switch statement.



Comment at: clang/lib/Format/WhitespaceManager.cpp:421
   // matching token, the sequence ends here.
-  if (Changes[i].NewlinesBefore > 1 || !FoundMatchOnLine)
+  if (((Changes[i].NewlinesBefore > 1) && (!AcrossEmpty)) ||
+  (!FoundMatchOnLine && (!(LineIsComment && AcrossComments

curdeius wrote:
> Nit: unnecessary parentheses around !AcrossEmpty.
> Same around !(LineIsComment && AcrossComments).
> Maybe you might factor out a bool variable for this condition?
Good point. I factored this out into two booleans, which should improve 
readability.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93986

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


[PATCH] D92762: [clang][AArch64][SVE] Avoid going through memory for coerced VLST arguments

2021-01-04 Thread Joe Ellis via Phabricator via cfe-commits
joechrisellis updated this revision to Diff 314365.
joechrisellis added a comment.

Address @c-rhodes's comment.

- Use name `castFixedSve` instead of `castScalableSve`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92762

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.cpp
  clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c

Index: clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
===
--- clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
+++ clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
@@ -13,11 +13,8 @@
 
 // CHECK-LABEL: @to_svint32_t(
 // CHECK-NEXT:  entry:
-// CHECK-NEXT:[[TYPE:%.*]] = alloca <16 x i32>, align 16
-// CHECK-NEXT:[[TMP0:%.*]] = bitcast <16 x i32>* [[TYPE]] to *
-// CHECK-NEXT:store  [[TYPE_COERCE:%.*]], * [[TMP0]], align 16
-// CHECK-NEXT:[[TYPE1:%.*]] = load <16 x i32>, <16 x i32>* [[TYPE]], align 16, [[TBAA6:!tbaa !.*]]
-// CHECK-NEXT:[[CASTSCALABLESVE:%.*]] = call  @llvm.experimental.vector.insert.nxv4i32.v16i32( undef, <16 x i32> [[TYPE1]], i64 0)
+// CHECK-NEXT:[[TYPE:%.*]] = call <16 x i32> @llvm.experimental.vector.extract.v16i32.nxv4i32( [[X_COERCE:%.*]], i64 0)
+// CHECK-NEXT:[[CASTSCALABLESVE:%.*]] = call  @llvm.experimental.vector.insert.nxv4i32.v16i32( undef, <16 x i32> [[TYPE]], i64 0)
 // CHECK-NEXT:ret  [[CASTSCALABLESVE]]
 //
 svint32_t to_svint32_t(fixed_int32_t type) {
@@ -39,11 +36,8 @@
 
 // CHECK-LABEL: @to_svfloat64_t(
 // CHECK-NEXT:  entry:
-// CHECK-NEXT:[[TYPE:%.*]] = alloca <8 x double>, align 16
-// CHECK-NEXT:[[TMP0:%.*]] = bitcast <8 x double>* [[TYPE]] to *
-// CHECK-NEXT:store  [[TYPE_COERCE:%.*]], * [[TMP0]], align 16
-// CHECK-NEXT:[[TYPE1:%.*]] = load <8 x double>, <8 x double>* [[TYPE]], align 16, [[TBAA6]]
-// CHECK-NEXT:[[CASTSCALABLESVE:%.*]] = call  @llvm.experimental.vector.insert.nxv2f64.v8f64( undef, <8 x double> [[TYPE1]], i64 0)
+// CHECK-NEXT:[[TYPE:%.*]] = call <8 x double> @llvm.experimental.vector.extract.v8f64.nxv2f64( [[X_COERCE:%.*]], i64 0)
+// CHECK-NEXT:[[CASTSCALABLESVE:%.*]] = call  @llvm.experimental.vector.insert.nxv2f64.v8f64( undef, <8 x double> [[TYPE]], i64 0)
 // CHECK-NEXT:ret  [[CASTSCALABLESVE]]
 //
 svfloat64_t to_svfloat64_t(fixed_float64_t type) {
@@ -69,7 +63,7 @@
 // CHECK-NEXT:[[TYPE_ADDR:%.*]] = alloca <8 x i8>, align 16
 // CHECK-NEXT:[[TMP0:%.*]] = bitcast <8 x i8>* [[TYPE]] to *
 // CHECK-NEXT:store  [[TYPE_COERCE:%.*]], * [[TMP0]], align 16
-// CHECK-NEXT:[[TYPE1:%.*]] = load <8 x i8>, <8 x i8>* [[TYPE]], align 16, [[TBAA6]]
+// CHECK-NEXT:[[TYPE1:%.*]] = load <8 x i8>, <8 x i8>* [[TYPE]], align 16, [[TBAA6:!tbaa !.*]]
 // CHECK-NEXT:store <8 x i8> [[TYPE1]], <8 x i8>* [[TYPE_ADDR]], align 16, [[TBAA6]]
 // CHECK-NEXT:[[TMP1:%.*]] = bitcast <8 x i8>* [[TYPE_ADDR]] to *
 // CHECK-NEXT:[[TMP2:%.*]] = load , * [[TMP1]], align 16, [[TBAA6]]
@@ -130,11 +124,8 @@
 
 // CHECK-LABEL: @from_fixed_int32_t__to_gnu_int32_t(
 // CHECK-NEXT:  entry:
-// CHECK-NEXT:[[TYPE:%.*]] = alloca <16 x i32>, align 16
-// CHECK-NEXT:[[TMP0:%.*]] = bitcast <16 x i32>* [[TYPE]] to *
-// CHECK-NEXT:store  [[TYPE_COERCE:%.*]], * [[TMP0]], align 16
-// CHECK-NEXT:[[TYPE1:%.*]] = load <16 x i32>, <16 x i32>* [[TYPE]], align 16, [[TBAA6]]
-// CHECK-NEXT:store <16 x i32> [[TYPE1]], <16 x i32>* [[AGG_RESULT:%.*]], align 16, [[TBAA6]]
+// CHECK-NEXT:[[TYPE:%.*]] = call <16 x i32> @llvm.experimental.vector.extract.v16i32.nxv4i32( [[X_COERCE:%.*]], i64 0)
+// CHECK-NEXT:store <16 x i32> [[TYPE]], <16 x i32>* [[AGG_RESULT:%.*]], align 16, [[TBAA6]]
 // CHECK-NEXT:ret void
 //
 gnu_int32_t from_fixed_int32_t__to_gnu_int32_t(fixed_int32_t type) {
Index: clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
===
--- clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
+++ clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
@@ -24,17 +24,14 @@
 
 // CHECK-LABEL: @fixed_caller(
 // CHECK-NEXT:  entry:
-// CHECK-NEXT:[[X:%.*]] = alloca <16 x i32>, align 16
 // CHECK-NEXT:[[RETVAL_COERCE:%.*]] = alloca , align 16
-// CHECK-NEXT:[[TMP0:%.*]] = bitcast <16 x i32>* [[X]] to *
-// CHECK-NEXT:store  [[X_COERCE:%.*]], * [[TMP0]], align 16
-// CHECK-NEXT:[[X1:%.*]] = load <16 x i32>, <16 x i32>* [[X]], align 16, [[TBAA6:!tbaa !.*]]
-// CHECK-NEXT:[[CASTSCALABLESVE:%.*]] = call  @llvm.experimental.vector.insert.nxv4i32.v16i32( undef, <16 x i32> [[X1]], i64 0)
+// CHECK-NEXT:[[X:%.*]] = call <16 x i32> @llvm.experimental.vector.extract.v16i32.nxv4i32( [[X_COERCE:%.*]], i64 0)
+// CHECK-NEXT:[[CASTSCALABLES

[PATCH] D92762: [clang][AArch64][SVE] Avoid going through memory for coerced VLST arguments

2021-01-04 Thread Joe Ellis via Phabricator via cfe-commits
joechrisellis marked an inline comment as done.
joechrisellis added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2671-2673
+  // See if this is a VLST coerced to a VLAT at the function boundary and
+  // the types match up. If so, use llvm.experimental.vector.extract to
+  // perform the conversion.

c-rhodes wrote:
> this is slightly confusing since the coercion done in TargetInfo is from 
> fixed -> scalable so VLSTs are represented as scalable vectors in functions 
> args/return, yet this is casting back to fixed in the function prolog using 
> `llvm.experimental.vector.extract` like you mention in the commit message, 
> could this comment clarify that?
I am a bit unsure what you mean in this comment, but I have tried to reword the 
comment to be a bit clearer about what's happening. Let me know if you still 
think it needs clarifying. 😄 



Comment at: clang/lib/CodeGen/CGCall.cpp:2674
+  // perform the conversion.
+  if (Ty->getAs()) {
+auto *Coerced = Fn->getArg(FirstIRArg);

c-rhodes wrote:
> Do we want to check `VT->getVectorKind() == 
> VectorType::SveFixedLengthDataVector` and 
> `isa(Coerced->getType());`?
Do we not also want to account for predicate vectors here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92762

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


[PATCH] D93701: [clang][cli] NFC: Make Diags optional in normalizer

2021-01-04 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added a comment.

This will make more sense after looking at D84673 
. In short: parsing of diagnostic options can 
happen outside of `CompilerInvocation::createFromArgs`, that's why 
`ParseDiagnosticArgs` is a free function. Ideally, we'd like to reuse the 
existing marshalling infrastructure here as well.

`ParseDiagnosticArgs` is usually called with `DiagnosticEngine *Diags = 
nullptr`. That's because the call happens early on during compiler execution, 
where we don't have a diagnostic engine yet. This call needs to happen first, 
to obtain the diagnostic options that are necessary for the engine 
instantiation.

This patch accommodates this free function by turning all `DiagnosticEngine` 
references to pointers. Another solution would be to create a "dummy" 
`DiagnosticsEngine` for the `ParseDiagnosticArgs` calls, but I didn't find a 
way to do that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93701

___
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-01-04 Thread John Paul Adrian Glaubitz via Phabricator via cfe-commits
glaubitz added a comment.

In D52050#2468424 , @jrtc27 wrote:

>> However, that's not the same as whether we're on an x86_64 system or on an 
>> x32 system determines which GNU triplet to use and which include and library 
>> search paths are our primary ones.
>
> But `Triple.getEnvironment()` will give you `llvm::Triple::GNUX32` that you 
> can check?

Yes, but we have to differentiate four scenarios:

- On x86_64, targeting x86_64
- On x86_64, targeting x32
- On x32, targeting x32
- On x32, targeting x86_64

On x86 it's clear because "x86" is an architecture on its own from clang's 
point of view. But that doesn't apply for x32 (at least for clang) and hence I 
don't know how to differentiate these four scenarios.


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] D93702: [clang][cli] NFC: Make marshalling macros reusable

2021-01-04 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added inline comments.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3040
 
-#define OPTION_WITH_MARSHALLING(   
\
-PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,
\
-HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  
\
-IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, 
\
-TABLE_INDEX)   
\
-  if ((FLAGS)&options::CC1Option) {
\
-this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  
\
-if (IMPLIED_CHECK) 
\
-  this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);
\
-if (auto MaybeValue =  
\
-NORMALIZER(OPT_##ID, TABLE_INDEX, Args, Diags, Success))   
\
-  this->KEYPATH = MERGER(  
\
-  this->KEYPATH, static_castKEYPATH)>(*MaybeValue));   
\
-  }
-
+#define OPTION_WITH_MARSHALLING PARSE_OPTION_WITH_MARSHALLING
 #include "clang/Driver/Options.inc"

dexonsmith wrote:
> One concern I have with this change is that the macro is using local variable 
> names; it really would be better to have the macro content local to the 
> function(s) where the variables are defined.
> 
> Can you give more context about why this has to be called from another place? 
> Maybe there's another way to solve the problem.
I've provided more context here: D93701.

We can solve the problem with implicit use of local variables inside the macro 
by promoting them to macro parameters.
This will make the forwarding call from `OPTION_WITH_MARSHALLING` to 
`PARSE_OPTION_WITH_MARSHALLING` longer, as it will need to spell out all 
parameters, but it would solve your concern I think.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93702

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


[PATCH] D92762: [clang][AArch64][SVE] Avoid going through memory for coerced VLST arguments

2021-01-04 Thread Cullen Rhodes via Phabricator via cfe-commits
c-rhodes added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2674
+  // perform the conversion.
+  if (Ty->getAs()) {
+auto *Coerced = Fn->getArg(FirstIRArg);

joechrisellis wrote:
> c-rhodes wrote:
> > Do we want to check `VT->getVectorKind() == 
> > VectorType::SveFixedLengthDataVector` and 
> > `isa(Coerced->getType());`?
> Do we not also want to account for predicate vectors here?
> Do we not also want to account for predicate vectors here?

I think so, but as mentioned on D92761 it'll require more thought since the 
insert/extract intrinsics require the element type to be identical which they 
aren't for predicates (`i8` for VLST and `i1` for scalable).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92762

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


[PATCH] D93637: [libTooling] Add support for smart pointers to releveant Transformer `Stencil`s.

2021-01-04 Thread Tom Lokovic via Phabricator via cfe-commits
tdl-g added inline comments.



Comment at: clang/unittests/Tooling/StencilTest.cpp:273
+  std::string Snippet = R"cc(
+Smart x;
+x;

You're only testing the "QuacksLike" case.  I suspect you should have tests 
that validate the "KnownSmartPointers".

Admittedly, it's a bit redundant since the known smart pointers also QuackLike 
pointers.  Which, I guess, raises the question of why you have the hard-coded 
list of KnownSmartPointers if they are covered by the QuacksLike behavior and 
thus can't be meaningfully tested independently.

What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93637

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


[PATCH] D93597: [X86][SSE] Enable constexpr on some basic SSE intrinsics (RFC)

2021-01-04 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei added inline comments.



Comment at: clang/test/CodeGen/X86/sse-builtins.c:815
+// Test constexpr handling.
+#if defined(__cplusplus) && (__cplusplus >= 201103L)
+constexpr __m128 test_constexpr_mm_add_ps(__m128 A, __m128 B) {

What are these tests testing for?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93597

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


[PATCH] D93301: [flang][driver] Add support for `-c` and `-emit-obj`

2021-01-04 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93301

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


[PATCH] D93630: [Attr] Apply GNU-style attributes to expression statements

2021-01-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D93630#2470048 , @vsavchenko wrote:

> In D93630#2468853 , @aaron.ballman 
> wrote:
>
>> Yeah, I kind of figured that might be the cause. I'm not 100% convinced (one 
>> way or the other) if the suppress attribute should get a GNU spelling. The 
>> `[[]]` spellings are available in all language modes (we have 
>> `-fdouble-square-bracket-attributes` to enable this) and don't run afoul of 
>> the "guess what this attribute appertains to" problem that GNU-style 
>> attributes do.
>
> I don't think that we can force our users into adding this flag.

You don't have to -- ObjC could always imply the flag is set (and I imagine 
ObjC will eventually update to C23 as the base language, where it'll be 
supported anyway).

> Also, Obj-C codebases already use a good amount of GNU-style attributes, so 
> it is pretty natural there.

IIRC, those attributes are often hidden behind macros, so I'm not certain how 
critical this is if the `-fdouble-square-bracket-attributes` feature was 
enabled in ObjC mode.




Comment at: clang/lib/Parse/ParseStmt.cpp:213
  ParsedStmtContext()) &&
-(GNUAttributeLoc.isValid() || isDeclarationStatement())) {
+((GNUAttributeLoc.isValid() && !Attrs.back().isStmtAttr()) ||
+ isDeclarationStatement())) {

vsavchenko wrote:
> aaron.ballman wrote:
> > I think you need to ensure there's at least one attribute before checking 
> > `!Attrs.back().isStmtAttr()` as this may cause problems if the user does 
> > something odd like `__attribute__(()) int x;` (I don't know if this will 
> > result in a valid `GNUAttributeLoc` with no attributes or not.)
> > 
> > I'm not certain that logic is perfect either. It would be pretty mysterious 
> > to handle these cases differently:
> > ```
> > __attribute__((stmt_attr, decl_attr)) int a, b, c;
> > __attribute__((decl_attr, stmt_attr)) int x, y, z;
> > ```
> Yep, my bad.  I changed it so that ALL the attributes in the front should be 
> statement attributes.
I think this is a better approach but it still doesn't leave us a clean way to 
handle attributes that are both declaration and statement attributes. I'm 
nervous about this in the same way I'm nervous about GNU attributes sliding 
around in general -- it doesn't always work out the way a user might expect.

`nomerge` is a good example. You currently cannot write this code:
```
int f(void);

void func(void) {
  __attribute__((nomerge)) static int i = f();
}
```
because of the way GNU attributes start a declaration. However, I think this 
could also be considered a bug because `nomerge` on a statement (which this 
also is) will ensure that the call expression to `f()` is not merged during 
optimization.

If we now say "GNU attribute can now be used at the start of an arbitrary 
statement", we have to late parse the attribute until we know what kind of 
statement we have. Because the user could have written:
```
void func(void) {
  __attribute__((nomerge)) extern void f(void), g(int), h(void);
}
```
which is currently accepted today and would change meaning if we treated 
`nomerge` as a statement attribute.



Comment at: clang/test/Parser/stmt-attributes.c:89
+
+__attribute__((nomerge)) static int i; // expected-error {{'nomerge' attribute 
cannot be applied to a declaration}}

This is a semi-good example of the kind of behavior I was worried about -- 
`nomerge` can be applied to a declaration or a statement, just not *this* kind 
of declaration, and so the diagnostic is confusing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93630

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


[clang] 9f8c0d1 - DeclCXX - Fix getAs<> null-dereference static analyzer warnings. NFCI.

2021-01-04 Thread Simon Pilgrim via cfe-commits

Author: Simon Pilgrim
Date: 2021-01-04T15:12:55Z
New Revision: 9f8c0d15c7f706a124ba29e8f40dc1937cd5bd49

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

LOG: DeclCXX - Fix getAs<> null-dereference static analyzer warnings. NFCI.

getAs<> can return null if the cast is invalid, which can lead to null pointer 
deferences. Use castAs<> instead which will assert that the cast is valid.

Added: 


Modified: 
clang/lib/AST/DeclCXX.cpp

Removed: 




diff  --git a/clang/lib/AST/DeclCXX.cpp b/clang/lib/AST/DeclCXX.cpp
index 16eb8206dba2..b806adf36bfb 100644
--- a/clang/lib/AST/DeclCXX.cpp
+++ b/clang/lib/AST/DeclCXX.cpp
@@ -1508,7 +1508,7 @@ CXXMethodDecl *CXXRecordDecl::getLambdaCallOperator() 
const {
 
 CXXMethodDecl* CXXRecordDecl::getLambdaStaticInvoker() const {
   CXXMethodDecl *CallOp = getLambdaCallOperator();
-  CallingConv CC = CallOp->getType()->getAs()->getCallConv();
+  CallingConv CC = CallOp->getType()->castAs()->getCallConv();
   return getLambdaStaticInvoker(CC);
 }
 
@@ -1532,8 +1532,8 @@ CXXMethodDecl 
*CXXRecordDecl::getLambdaStaticInvoker(CallingConv CC) const {
   DeclContext::lookup_result Invoker = getLambdaStaticInvokers(*this);
 
   for (NamedDecl *ND : Invoker) {
-const FunctionType *FTy =
-cast(ND->getAsFunction())->getType()->getAs();
+const auto *FTy =
+
cast(ND->getAsFunction())->getType()->castAs();
 if (FTy->getCallConv() == CC)
   return getInvokerAsMethod(ND);
   }



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


[PATCH] D93986: [clang-format] Add the possibility to align assignments spanning empty lines or comments

2021-01-04 Thread Lukas Barth via Phabricator via cfe-commits
tinloaf updated this revision to Diff 314377.
tinloaf marked 3 inline comments as done.
tinloaf added a comment.

Fix bogus default case reported by clang-tidy.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93986

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

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -11330,7 +11330,7 @@
"*/\n"
"}",
Tab));
-  Tab.AlignConsecutiveAssignments = true;
+  Tab.AlignConsecutiveAssignments = FormatStyle::ACA_Consecutive;
   Tab.AlignConsecutiveDeclarations = true;
   Tab.TabWidth = 4;
   Tab.IndentWidth = 4;
@@ -11569,7 +11569,7 @@
"*/\n"
"}",
Tab));
-  Tab.AlignConsecutiveAssignments = true;
+  Tab.AlignConsecutiveAssignments = FormatStyle::ACA_Consecutive;
   Tab.AlignConsecutiveDeclarations = true;
   Tab.TabWidth = 4;
   Tab.IndentWidth = 4;
@@ -12271,7 +12271,7 @@
 
 TEST_F(FormatTest, AlignConsecutiveMacros) {
   FormatStyle Style = getLLVMStyle();
-  Style.AlignConsecutiveAssignments = true;
+  Style.AlignConsecutiveAssignments = FormatStyle::ACA_Consecutive;
   Style.AlignConsecutiveDeclarations = true;
   Style.AlignConsecutiveMacros = false;
 
@@ -12364,10 +12364,486 @@
Style);
 }
 
+TEST_F(FormatTest, AlignConsecutiveAssignmentsAcrossEmptyLines) {
+  FormatStyle Alignment = getLLVMStyle();
+  Alignment.AlignConsecutiveMacros = true;
+  Alignment.AlignConsecutiveAssignments = FormatStyle::ACA_AcrossEmptyLines;
+
+  Alignment.MaxEmptyLinesToKeep = 10;
+  /* Test alignment across empty lines */
+  EXPECT_EQ("int a   = 5;\n"
+"\n"
+"int oneTwoThree = 123;",
+format("int a   = 5;\n"
+   "\n"
+   "int oneTwoThree= 123;",
+   Alignment));
+  EXPECT_EQ("int a   = 5;\n"
+"int one = 1;\n"
+"\n"
+"int oneTwoThree = 123;",
+format("int a = 5;\n"
+   "int one = 1;\n"
+   "\n"
+   "int oneTwoThree = 123;",
+   Alignment));
+  EXPECT_EQ("int a   = 5;\n"
+"int one = 1;\n"
+"\n"
+"int oneTwoThree = 123;\n"
+"int oneTwo  = 12;",
+format("int a = 5;\n"
+   "int one = 1;\n"
+   "\n"
+   "int oneTwoThree = 123;\n"
+   "int oneTwo = 12;",
+   Alignment));
+
+  /* Test across comments */
+  EXPECT_EQ("int a = 5;\n"
+"/* block comment */\n"
+"int oneTwoThree = 123;",
+format("int a = 5;\n"
+   "/* block comment */\n"
+   "int oneTwoThree=123;",
+   Alignment));
+
+  EXPECT_EQ("int a = 5;\n"
+"// line comment\n"
+"int oneTwoThree = 123;",
+format("int a = 5;\n"
+   "// line comment\n"
+   "int oneTwoThree=123;",
+   Alignment));
+
+  /* Test across comments and newlines */
+  EXPECT_EQ("int a = 5;\n"
+"\n"
+"/* block comment */\n"
+"int oneTwoThree = 123;",
+format("int a = 5;\n"
+   "\n"
+   "/* block comment */\n"
+   "int oneTwoThree=123;",
+   Alignment));
+
+  EXPECT_EQ("int a = 5;\n"
+"\n"
+"// line comment\n"
+"int oneTwoThree = 123;",
+format("int a = 5;\n"
+   "\n"
+   "// line comment\n"
+   "int oneTwoThree=123;",
+   Alignment));
+}
+
+TEST_F(FormatTest, AlignConsecutiveAssignmentsAcrossComments) {
+  FormatStyle Alignment = getLLVMStyle();
+  Alignment.AlignConsecutiveMacros = true;
+  Alignment.AlignConsecutiveAssignments = FormatStyle::ACA_AcrossComments;
+
+  Alignment.MaxEmptyLinesToKeep = 10;
+  /* Test alignment across empty lines */
+  EXPECT_EQ("int a = 5;\n"
+"\n"
+"int oneTwoThree = 123;",
+format("int a   = 5;\n"
+   "\n"
+   "int oneTwoThree= 123;",
+   Alignment));
+  EXPECT_EQ("int a   = 5;\n"
+"int one = 1;\n"
+"\n"
+"int oneTwoThree = 123;",
+format("int a = 5;\n"
+   "int one = 1;\n"
+   "\n"
+   "int oneTwoThree = 123;",
+   Alignment));
+
+  /* Test across comments */
+  EXPECT_EQ("

[PATCH] D92634: [Analyzer] Diagnose signed integer overflow

2021-01-04 Thread Daniel Marjamäki via Phabricator via cfe-commits
danielmarjamaki added a comment.

> However, the mainstream compilers like GCC and Clang implement this as the 
> overflowed value, and some programmers also use this feature to do some 
> tricky things.

hmm.. you mean if some -fwrapv flag is used right. yes I should disable this 
checking then.

For information, I am not very worried about signed integer overflow. I am 
mostly worried about the compiler optimisations. If the compiler determines 
that there is signed integer overflow in a execution path and removes all code 
in that path.

I was inspired by this blog post:  https://www.airs.com/blog/archives/120

This function:

  int f(int x) { return 0x7ff0 < x && x + 32 < 0x7fff; }

might be optimized to:

  int f(int x) { return 0; }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92634

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


[PATCH] D93356: [libomptarget][amdgpu] Call into deviceRTL instead of ockl

2021-01-04 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield updated this revision to Diff 314379.
JonChesterfield added a comment.

- update test, fix whitespace


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93356

Files:
  clang/lib/CodeGen/CGOpenMPRuntimeAMDGCN.cpp
  clang/test/OpenMP/amdgcn_target_codegen.cpp
  openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
  openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip


Index: openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
===
--- openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
+++ openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
@@ -144,6 +144,10 @@
   return __builtin_amdgcn_mbcnt_hi(~0u, __builtin_amdgcn_mbcnt_lo(~0u, 0u));
 }
 
+EXTERN uint32_t __kmpc_amdgcn_gpu_num_threads() {
+  return GetNumberOfThreadsInBlock();
+}
+
 // Stub implementations
-DEVICE void *__kmpc_impl_malloc(size_t ) { return nullptr }
+DEVICE void *__kmpc_impl_malloc(size_t) { return nullptr; }
 DEVICE void __kmpc_impl_free(void *) {}
Index: openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
===
--- openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
+++ openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
@@ -15,4 +15,6 @@
 typedef uint64_t __kmpc_impl_lanemask_t;
 typedef uint32_t omp_lock_t; /* arbitrary type of the right length */
 
+EXTERN uint32_t __kmpc_amdgcn_gpu_num_threads();
+
 #endif
Index: clang/test/OpenMP/amdgcn_target_codegen.cpp
===
--- clang/test/OpenMP/amdgcn_target_codegen.cpp
+++ clang/test/OpenMP/amdgcn_target_codegen.cpp
@@ -13,9 +13,8 @@
 
   int arr[N];
 
-// CHECK: [[NUM_THREADS:%.+]] = call i64 @__ockl_get_local_size(i32 0)
-// CHECK-NEXT: [[VAR:%.+]] = trunc i64 [[NUM_THREADS]] to i32
-// CHECK-NEXT: sub nuw i32 [[VAR]], 64
+// CHECK: [[NUM_THREADS:%.+]] = call i32 @__kmpc_amdgcn_gpu_num_threads()
+// CHECK: sub nuw i32 [[NUM_THREADS]], 64
 // CHECK: call i32 @llvm.amdgcn.workitem.id.x()
 #pragma omp target
   for (int i = 0; i < N; i++) {
@@ -30,9 +29,8 @@
 
   int arr[N];
 
-// CHECK: [[NUM_THREADS:%.+]] = call i64 @__ockl_get_local_size(i32 0)
-// CHECK-NEXT: [[VAR:%.+]] = trunc i64 [[NUM_THREADS]] to i32
-// CHECK-NEXT: call void @__kmpc_spmd_kernel_init(i32 [[VAR]], i16 0)
+// CHECK: [[NUM_THREADS:%.+]] = call i32 @__kmpc_amdgcn_gpu_num_threads()
+// CHECK: call void @__kmpc_spmd_kernel_init(i32 [[NUM_THREADS]], i16 0)
 #pragma omp target simd
   for (int i = 0; i < N; i++) {
 arr[i] = 1;
Index: clang/lib/CodeGen/CGOpenMPRuntimeAMDGCN.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntimeAMDGCN.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntimeAMDGCN.cpp
@@ -49,13 +49,12 @@
 llvm::Value *CGOpenMPRuntimeAMDGCN::getGPUNumThreads(CodeGenFunction &CGF) {
   CGBuilderTy &Bld = CGF.Builder;
   llvm::Module *M = &CGF.CGM.getModule();
-  const char *LocSize = "__ockl_get_local_size";
+  const char *LocSize = "__kmpc_amdgcn_gpu_num_threads";
   llvm::Function *F = M->getFunction(LocSize);
   if (!F) {
 F = llvm::Function::Create(
-llvm::FunctionType::get(CGF.Int64Ty, {CGF.Int32Ty}, false),
+llvm::FunctionType::get(CGF.Int32Ty, llvm::None, false),
 llvm::GlobalVariable::ExternalLinkage, LocSize, &CGF.CGM.getModule());
   }
-  return Bld.CreateTrunc(
-  Bld.CreateCall(F, {Bld.getInt32(0)}, "nvptx_num_threads"), CGF.Int32Ty);
+  return Bld.CreateCall(F, llvm::None, "nvptx_num_threads");
 }


Index: openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
===
--- openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
+++ openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
@@ -144,6 +144,10 @@
   return __builtin_amdgcn_mbcnt_hi(~0u, __builtin_amdgcn_mbcnt_lo(~0u, 0u));
 }
 
+EXTERN uint32_t __kmpc_amdgcn_gpu_num_threads() {
+  return GetNumberOfThreadsInBlock();
+}
+
 // Stub implementations
-DEVICE void *__kmpc_impl_malloc(size_t ) { return nullptr }
+DEVICE void *__kmpc_impl_malloc(size_t) { return nullptr; }
 DEVICE void __kmpc_impl_free(void *) {}
Index: openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
===
--- openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
+++ openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
@@ -15,4 +15,6 @@
 typedef uint64_t __kmpc_impl_lanemask_t;
 typedef uint32_t omp_lock_t; /* arbitrary type of the right length */
 
+EXTERN uint32_t __kmpc_amdgcn_gpu_num_threads();
+
 #endif
Index: clang/test/OpenMP/amdgcn_target_codegen.cpp
===
--- clang/test/OpenMP/amdgcn_target_codegen.cpp
+++ clang/test/OpenMP/amdgcn_target_codegen

[PATCH] D92445: [PowerPC] Enable OpenMP for powerpcle target. [5/5]

2021-01-04 Thread Brandon Bergren via Phabricator via cfe-commits
Bdragon28 updated this revision to Diff 314247.
Bdragon28 added a comment.

Forcing retest again.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92445

Files:
  clang/test/Driver/ppc-features.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  llvm/lib/Frontend/OpenMP/OMPContext.cpp


Index: llvm/lib/Frontend/OpenMP/OMPContext.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPContext.cpp
+++ llvm/lib/Frontend/OpenMP/OMPContext.cpp
@@ -40,6 +40,7 @@
   case Triple::mips64:
   case Triple::mips64el:
   case Triple::ppc:
+  case Triple::ppcle:
   case Triple::ppc64:
   case Triple::ppc64le:
   case Triple::x86:
Index: llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
===
--- llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
+++ llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
@@ -1033,6 +1033,7 @@
 __OMP_TRAIT_PROPERTY(device, arch, aarch64_be)
 __OMP_TRAIT_PROPERTY(device, arch, aarch64_32)
 __OMP_TRAIT_PROPERTY(device, arch, ppc)
+__OMP_TRAIT_PROPERTY(device, arch, ppcle)
 __OMP_TRAIT_PROPERTY(device, arch, ppc64)
 __OMP_TRAIT_PROPERTY(device, arch, ppc64le)
 __OMP_TRAIT_PROPERTY(device, arch, x86)
Index: clang/test/Driver/ppc-features.cpp
===
--- clang/test/Driver/ppc-features.cpp
+++ clang/test/Driver/ppc-features.cpp
@@ -167,6 +167,7 @@
 
 // OpenMP features
 // RUN: %clang -target powerpc-unknown-linux-gnu %s -### -fopenmp=libomp -o 
%t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
+// RUN: %clang -target powerpcle-unknown-linux-gnu %s -### -fopenmp=libomp -o 
%t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
 // RUN: %clang -target powerpc64-unknown-linux-gnu %s -### -fopenmp=libomp -o 
%t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
 // RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -fopenmp=libomp 
-o %t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
 // CHECK_OPENMP_TLS-NOT: "-fnoopenmp-use-tls"


Index: llvm/lib/Frontend/OpenMP/OMPContext.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPContext.cpp
+++ llvm/lib/Frontend/OpenMP/OMPContext.cpp
@@ -40,6 +40,7 @@
   case Triple::mips64:
   case Triple::mips64el:
   case Triple::ppc:
+  case Triple::ppcle:
   case Triple::ppc64:
   case Triple::ppc64le:
   case Triple::x86:
Index: llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
===
--- llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
+++ llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
@@ -1033,6 +1033,7 @@
 __OMP_TRAIT_PROPERTY(device, arch, aarch64_be)
 __OMP_TRAIT_PROPERTY(device, arch, aarch64_32)
 __OMP_TRAIT_PROPERTY(device, arch, ppc)
+__OMP_TRAIT_PROPERTY(device, arch, ppcle)
 __OMP_TRAIT_PROPERTY(device, arch, ppc64)
 __OMP_TRAIT_PROPERTY(device, arch, ppc64le)
 __OMP_TRAIT_PROPERTY(device, arch, x86)
Index: clang/test/Driver/ppc-features.cpp
===
--- clang/test/Driver/ppc-features.cpp
+++ clang/test/Driver/ppc-features.cpp
@@ -167,6 +167,7 @@
 
 // OpenMP features
 // RUN: %clang -target powerpc-unknown-linux-gnu %s -### -fopenmp=libomp -o %t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
+// RUN: %clang -target powerpcle-unknown-linux-gnu %s -### -fopenmp=libomp -o %t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
 // RUN: %clang -target powerpc64-unknown-linux-gnu %s -### -fopenmp=libomp -o %t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
 // RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -fopenmp=libomp -o %t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
 // CHECK_OPENMP_TLS-NOT: "-fnoopenmp-use-tls"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D92445: [PowerPC] Enable OpenMP for powerpcle target. [5/5]

2021-01-04 Thread Brandon Bergren via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG2288319733cd: [PowerPC] Enable OpenMP for powerpcle target. 
[5/5] (authored by Bdragon28).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92445

Files:
  clang/test/Driver/ppc-features.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  llvm/lib/Frontend/OpenMP/OMPContext.cpp


Index: llvm/lib/Frontend/OpenMP/OMPContext.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPContext.cpp
+++ llvm/lib/Frontend/OpenMP/OMPContext.cpp
@@ -40,6 +40,7 @@
   case Triple::mips64:
   case Triple::mips64el:
   case Triple::ppc:
+  case Triple::ppcle:
   case Triple::ppc64:
   case Triple::ppc64le:
   case Triple::x86:
Index: llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
===
--- llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
+++ llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
@@ -1033,6 +1033,7 @@
 __OMP_TRAIT_PROPERTY(device, arch, aarch64_be)
 __OMP_TRAIT_PROPERTY(device, arch, aarch64_32)
 __OMP_TRAIT_PROPERTY(device, arch, ppc)
+__OMP_TRAIT_PROPERTY(device, arch, ppcle)
 __OMP_TRAIT_PROPERTY(device, arch, ppc64)
 __OMP_TRAIT_PROPERTY(device, arch, ppc64le)
 __OMP_TRAIT_PROPERTY(device, arch, x86)
Index: clang/test/Driver/ppc-features.cpp
===
--- clang/test/Driver/ppc-features.cpp
+++ clang/test/Driver/ppc-features.cpp
@@ -167,6 +167,7 @@
 
 // OpenMP features
 // RUN: %clang -target powerpc-unknown-linux-gnu %s -### -fopenmp=libomp -o 
%t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
+// RUN: %clang -target powerpcle-unknown-linux-gnu %s -### -fopenmp=libomp -o 
%t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
 // RUN: %clang -target powerpc64-unknown-linux-gnu %s -### -fopenmp=libomp -o 
%t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
 // RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -fopenmp=libomp 
-o %t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
 // CHECK_OPENMP_TLS-NOT: "-fnoopenmp-use-tls"


Index: llvm/lib/Frontend/OpenMP/OMPContext.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPContext.cpp
+++ llvm/lib/Frontend/OpenMP/OMPContext.cpp
@@ -40,6 +40,7 @@
   case Triple::mips64:
   case Triple::mips64el:
   case Triple::ppc:
+  case Triple::ppcle:
   case Triple::ppc64:
   case Triple::ppc64le:
   case Triple::x86:
Index: llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
===
--- llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
+++ llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
@@ -1033,6 +1033,7 @@
 __OMP_TRAIT_PROPERTY(device, arch, aarch64_be)
 __OMP_TRAIT_PROPERTY(device, arch, aarch64_32)
 __OMP_TRAIT_PROPERTY(device, arch, ppc)
+__OMP_TRAIT_PROPERTY(device, arch, ppcle)
 __OMP_TRAIT_PROPERTY(device, arch, ppc64)
 __OMP_TRAIT_PROPERTY(device, arch, ppc64le)
 __OMP_TRAIT_PROPERTY(device, arch, x86)
Index: clang/test/Driver/ppc-features.cpp
===
--- clang/test/Driver/ppc-features.cpp
+++ clang/test/Driver/ppc-features.cpp
@@ -167,6 +167,7 @@
 
 // OpenMP features
 // RUN: %clang -target powerpc-unknown-linux-gnu %s -### -fopenmp=libomp -o %t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
+// RUN: %clang -target powerpcle-unknown-linux-gnu %s -### -fopenmp=libomp -o %t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
 // RUN: %clang -target powerpc64-unknown-linux-gnu %s -### -fopenmp=libomp -o %t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
 // RUN: %clang -target powerpc64le-unknown-linux-gnu %s -### -fopenmp=libomp -o %t.o 2>&1 | FileCheck -check-prefix=CHECK_OPENMP_TLS %s
 // CHECK_OPENMP_TLS-NOT: "-fnoopenmp-use-tls"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D93401: [flang][driver] Add support for `-D`, `-U`

2021-01-04 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski accepted this revision.
awarzynski added a comment.
This revision is now accepted and ready to land.

Thank you for working on this @FarisRehman , LGTM! From what I can tell you 
also addressed the point that @tskeith raised (updated commit msg and added a 
dedicated test). Ccould you wait another day or two before merging? Just in 
case people have some other comments/suggestions.




Comment at: clang/lib/Driver/ToolChains/Flang.h:27-31
+  /// Add the specified preprocessing options from Args to CmdArgs,
+  /// claiming the arguments used.
+  ///
+  /// \param Args The list of input arguments
+  /// \param CmdArgs The list of output arguments

awarzynski wrote:
> 1. Could you clarify the difference between `Args` and `CmdArgs`?
> 2. Could you use doxygen's syntax to specify the parameter _direction_? E.g.:
> ```
>   /// \param [in] Args The list of input arguments
>   /// \param [out] CmdArgs The list of output arguments
> ```
> See https://www.doxygen.nl/manual/commands.html#cmdparam.
[nit] One minor suggestion:
```
  /// \param Args The list of input driver arguments
  /// \param CmdArgs The list of output command arguments
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93401

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


[PATCH] D93356: [libomptarget][amdgpu] Call into deviceRTL instead of ockl

2021-01-04 Thread Ron Lieberman via Phabricator via cfe-commits
ronlieb accepted this revision.
ronlieb 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/D93356/new/

https://reviews.llvm.org/D93356

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


[PATCH] D92954: [clang-offload-bundler] Add option -list

2021-01-04 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

ping


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

https://reviews.llvm.org/D92954

___
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-01-04 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

ping


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] D93986: [clang-format] Add the possibility to align assignments spanning empty lines or comments

2021-01-04 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.
This revision is now accepted and ready to land.

This LGTM, I'm not sure if others have any further comments

Ideally we should add a comment to the release notes, (which you could do via a 
separate NFC commit if you wanted)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93986

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


[clang] 76bfbb7 - [libomptarget][amdgpu] Call into deviceRTL instead of ockl

2021-01-04 Thread Jon Chesterfield via cfe-commits

Author: Jon Chesterfield
Date: 2021-01-04T16:48:47Z
New Revision: 76bfbb74d38b611f150e8e1a4becc11be95703da

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

LOG: [libomptarget][amdgpu] Call into deviceRTL instead of ockl

[libomptarget][amdgpu] Call into deviceRTL instead of ockl

Amdgpu codegen presently emits a call into ockl. The same functionality
is already present in the deviceRTL. Adds an amdgpu specific entry point
to avoid the dependency. This lets simple openmp code (specifically, that
which doesn't use libm) run without rocm device libraries installed.

Reviewed By: ronlieb

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

Added: 


Modified: 
clang/lib/CodeGen/CGOpenMPRuntimeAMDGCN.cpp
clang/test/OpenMP/amdgcn_target_codegen.cpp
openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntimeAMDGCN.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntimeAMDGCN.cpp
index ccffdf43549f..33d4ab838af1 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntimeAMDGCN.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntimeAMDGCN.cpp
@@ -49,13 +49,12 @@ llvm::Value 
*CGOpenMPRuntimeAMDGCN::getGPUThreadID(CodeGenFunction &CGF) {
 llvm::Value *CGOpenMPRuntimeAMDGCN::getGPUNumThreads(CodeGenFunction &CGF) {
   CGBuilderTy &Bld = CGF.Builder;
   llvm::Module *M = &CGF.CGM.getModule();
-  const char *LocSize = "__ockl_get_local_size";
+  const char *LocSize = "__kmpc_amdgcn_gpu_num_threads";
   llvm::Function *F = M->getFunction(LocSize);
   if (!F) {
 F = llvm::Function::Create(
-llvm::FunctionType::get(CGF.Int64Ty, {CGF.Int32Ty}, false),
+llvm::FunctionType::get(CGF.Int32Ty, llvm::None, false),
 llvm::GlobalVariable::ExternalLinkage, LocSize, &CGF.CGM.getModule());
   }
-  return Bld.CreateTrunc(
-  Bld.CreateCall(F, {Bld.getInt32(0)}, "nvptx_num_threads"), CGF.Int32Ty);
+  return Bld.CreateCall(F, llvm::None, "nvptx_num_threads");
 }

diff  --git a/clang/test/OpenMP/amdgcn_target_codegen.cpp 
b/clang/test/OpenMP/amdgcn_target_codegen.cpp
index 85ef69942a50..416ed06083b0 100644
--- a/clang/test/OpenMP/amdgcn_target_codegen.cpp
+++ b/clang/test/OpenMP/amdgcn_target_codegen.cpp
@@ -13,9 +13,8 @@ int test_amdgcn_target_tid_threads() {
 
   int arr[N];
 
-// CHECK: [[NUM_THREADS:%.+]] = call i64 @__ockl_get_local_size(i32 0)
-// CHECK-NEXT: [[VAR:%.+]] = trunc i64 [[NUM_THREADS]] to i32
-// CHECK-NEXT: sub nuw i32 [[VAR]], 64
+// CHECK: [[NUM_THREADS:%.+]] = call i32 @__kmpc_amdgcn_gpu_num_threads()
+// CHECK: sub nuw i32 [[NUM_THREADS]], 64
 // CHECK: call i32 @llvm.amdgcn.workitem.id.x()
 #pragma omp target
   for (int i = 0; i < N; i++) {
@@ -30,9 +29,8 @@ int test_amdgcn_target_tid_threads_simd() {
 
   int arr[N];
 
-// CHECK: [[NUM_THREADS:%.+]] = call i64 @__ockl_get_local_size(i32 0)
-// CHECK-NEXT: [[VAR:%.+]] = trunc i64 [[NUM_THREADS]] to i32
-// CHECK-NEXT: call void @__kmpc_spmd_kernel_init(i32 [[VAR]], i16 0)
+// CHECK: [[NUM_THREADS:%.+]] = call i32 @__kmpc_amdgcn_gpu_num_threads()
+// CHECK: call void @__kmpc_spmd_kernel_init(i32 [[NUM_THREADS]], i16 0)
 #pragma omp target simd
   for (int i = 0; i < N; i++) {
 arr[i] = 1;

diff  --git a/openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h 
b/openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
index f7c75c09362a..80409d611f6f 100644
--- a/openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
+++ b/openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
@@ -15,4 +15,6 @@
 typedef uint64_t __kmpc_impl_lanemask_t;
 typedef uint32_t omp_lock_t; /* arbitrary type of the right length */
 
+EXTERN uint32_t __kmpc_amdgcn_gpu_num_threads();
+
 #endif

diff  --git a/openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip 
b/openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
index 9fbdc67b56ab..3e70beb85d5b 100644
--- a/openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
+++ b/openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
@@ -144,6 +144,10 @@ DEVICE unsigned GetLaneId() {
   return __builtin_amdgcn_mbcnt_hi(~0u, __builtin_amdgcn_mbcnt_lo(~0u, 0u));
 }
 
+EXTERN uint32_t __kmpc_amdgcn_gpu_num_threads() {
+  return GetNumberOfThreadsInBlock();
+}
+
 // Stub implementations
-DEVICE void *__kmpc_impl_malloc(size_t ) { return nullptr }
+DEVICE void *__kmpc_impl_malloc(size_t) { return nullptr; }
 DEVICE void __kmpc_impl_free(void *) {}



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


[PATCH] D93356: [libomptarget][amdgpu] Call into deviceRTL instead of ockl

2021-01-04 Thread Jon Chesterfield 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 rG76bfbb74d38b: [libomptarget][amdgpu] Call into deviceRTL 
instead of ockl (authored by JonChesterfield).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93356

Files:
  clang/lib/CodeGen/CGOpenMPRuntimeAMDGCN.cpp
  clang/test/OpenMP/amdgcn_target_codegen.cpp
  openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
  openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip


Index: openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
===
--- openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
+++ openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
@@ -144,6 +144,10 @@
   return __builtin_amdgcn_mbcnt_hi(~0u, __builtin_amdgcn_mbcnt_lo(~0u, 0u));
 }
 
+EXTERN uint32_t __kmpc_amdgcn_gpu_num_threads() {
+  return GetNumberOfThreadsInBlock();
+}
+
 // Stub implementations
-DEVICE void *__kmpc_impl_malloc(size_t ) { return nullptr }
+DEVICE void *__kmpc_impl_malloc(size_t) { return nullptr; }
 DEVICE void __kmpc_impl_free(void *) {}
Index: openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
===
--- openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
+++ openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
@@ -15,4 +15,6 @@
 typedef uint64_t __kmpc_impl_lanemask_t;
 typedef uint32_t omp_lock_t; /* arbitrary type of the right length */
 
+EXTERN uint32_t __kmpc_amdgcn_gpu_num_threads();
+
 #endif
Index: clang/test/OpenMP/amdgcn_target_codegen.cpp
===
--- clang/test/OpenMP/amdgcn_target_codegen.cpp
+++ clang/test/OpenMP/amdgcn_target_codegen.cpp
@@ -13,9 +13,8 @@
 
   int arr[N];
 
-// CHECK: [[NUM_THREADS:%.+]] = call i64 @__ockl_get_local_size(i32 0)
-// CHECK-NEXT: [[VAR:%.+]] = trunc i64 [[NUM_THREADS]] to i32
-// CHECK-NEXT: sub nuw i32 [[VAR]], 64
+// CHECK: [[NUM_THREADS:%.+]] = call i32 @__kmpc_amdgcn_gpu_num_threads()
+// CHECK: sub nuw i32 [[NUM_THREADS]], 64
 // CHECK: call i32 @llvm.amdgcn.workitem.id.x()
 #pragma omp target
   for (int i = 0; i < N; i++) {
@@ -30,9 +29,8 @@
 
   int arr[N];
 
-// CHECK: [[NUM_THREADS:%.+]] = call i64 @__ockl_get_local_size(i32 0)
-// CHECK-NEXT: [[VAR:%.+]] = trunc i64 [[NUM_THREADS]] to i32
-// CHECK-NEXT: call void @__kmpc_spmd_kernel_init(i32 [[VAR]], i16 0)
+// CHECK: [[NUM_THREADS:%.+]] = call i32 @__kmpc_amdgcn_gpu_num_threads()
+// CHECK: call void @__kmpc_spmd_kernel_init(i32 [[NUM_THREADS]], i16 0)
 #pragma omp target simd
   for (int i = 0; i < N; i++) {
 arr[i] = 1;
Index: clang/lib/CodeGen/CGOpenMPRuntimeAMDGCN.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntimeAMDGCN.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntimeAMDGCN.cpp
@@ -49,13 +49,12 @@
 llvm::Value *CGOpenMPRuntimeAMDGCN::getGPUNumThreads(CodeGenFunction &CGF) {
   CGBuilderTy &Bld = CGF.Builder;
   llvm::Module *M = &CGF.CGM.getModule();
-  const char *LocSize = "__ockl_get_local_size";
+  const char *LocSize = "__kmpc_amdgcn_gpu_num_threads";
   llvm::Function *F = M->getFunction(LocSize);
   if (!F) {
 F = llvm::Function::Create(
-llvm::FunctionType::get(CGF.Int64Ty, {CGF.Int32Ty}, false),
+llvm::FunctionType::get(CGF.Int32Ty, llvm::None, false),
 llvm::GlobalVariable::ExternalLinkage, LocSize, &CGF.CGM.getModule());
   }
-  return Bld.CreateTrunc(
-  Bld.CreateCall(F, {Bld.getInt32(0)}, "nvptx_num_threads"), CGF.Int32Ty);
+  return Bld.CreateCall(F, llvm::None, "nvptx_num_threads");
 }


Index: openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
===
--- openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
+++ openmp/libomptarget/deviceRTLs/amdgcn/src/target_impl.hip
@@ -144,6 +144,10 @@
   return __builtin_amdgcn_mbcnt_hi(~0u, __builtin_amdgcn_mbcnt_lo(~0u, 0u));
 }
 
+EXTERN uint32_t __kmpc_amdgcn_gpu_num_threads() {
+  return GetNumberOfThreadsInBlock();
+}
+
 // Stub implementations
-DEVICE void *__kmpc_impl_malloc(size_t ) { return nullptr }
+DEVICE void *__kmpc_impl_malloc(size_t) { return nullptr; }
 DEVICE void __kmpc_impl_free(void *) {}
Index: openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
===
--- openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
+++ openmp/libomptarget/deviceRTLs/amdgcn/src/amdgcn_interface.h
@@ -15,4 +15,6 @@
 typedef uint64_t __kmpc_impl_lanemask_t;
 typedef uint32_t omp_lock_t; /* arbitrary type of the right length */
 
+EXTERN uint32_t __kmpc_amdgcn_gpu_num_threads();
+
 #endif
Index: clang/test/OpenMP/amdgcn_target_codegen.cpp

[PATCH] D93014: [Clang] Add AArch64 VCMLA LANE variants.

2021-01-04 Thread Florian Hahn via Phabricator via cfe-commits
fhahn updated this revision to Diff 314389.
fhahn added a comment.

Add comment to tblgen change, remove trailing whitespace.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93014

Files:
  clang/include/clang/Basic/arm_neon.td
  clang/test/CodeGen/aarch64-neon-vcmla.c
  clang/utils/TableGen/NeonEmitter.cpp

Index: clang/utils/TableGen/NeonEmitter.cpp
===
--- clang/utils/TableGen/NeonEmitter.cpp
+++ clang/utils/TableGen/NeonEmitter.cpp
@@ -1690,14 +1690,18 @@
 
 std::pair Intrinsic::DagEmitter::emitDagDupTyped(DagInit *DI) {
   assert_with_loc(DI->getNumArgs() == 2, "dup_typed() expects two arguments");
-  std::pair A =
-  emitDagArg(DI->getArg(0), std::string(DI->getArgNameStr(0)));
   std::pair B =
   emitDagArg(DI->getArg(1), std::string(DI->getArgNameStr(1)));
   assert_with_loc(B.first.isScalar(),
   "dup_typed() requires a scalar as the second argument");
+  Type T;
+  // If the type argument is a constant string, construct the type directly.
+  if (StringInit *SI = dyn_cast(DI->getArg(0))) {
+T = Type::fromTypedefName(SI->getAsUnquotedString());
+assert_with_loc(!T.isVoid(), "Unknown typedef");
+  } else
+T = emitDagArg(DI->getArg(0), std::string(DI->getArgNameStr(0))).first;
 
-  Type T = A.first;
   assert_with_loc(T.isVector(), "dup_typed() used but target type is scalar!");
   std::string S = "(" + T.str() + ") {";
   for (unsigned I = 0; I < T.getNumElements(); ++I) {
Index: clang/test/CodeGen/aarch64-neon-vcmla.c
===
--- clang/test/CodeGen/aarch64-neon-vcmla.c
+++ clang/test/CodeGen/aarch64-neon-vcmla.c
@@ -144,3 +144,83 @@
 float64x2_t test_vcmlaq_rot270_f64(float64x2_t acc, float64x2_t lhs, float64x2_t rhs) {
   return vcmlaq_rot270_f64(acc, lhs, rhs);
 }
+
+// CHECK-LABEL: @test_vcmla_lane_f16(
+// CHECK: [[CPLX:%.*]] = bitcast <4 x half> %rhs to <2 x i32>
+// CHECK: [[DUP:%.*]] = shufflevector <2 x i32> [[CPLX]], <2 x i32> undef, <2 x i32> 
+// CHECK: [[DUP_FLT:%.*]] = bitcast <2 x i32> [[DUP]] to <4 x half>
+// CHECK: [[RES:%.*]] = call <4 x half> @llvm.aarch64.neon.vcmla.rot0.v4f16(<4 x half> %acc, <4 x half> %lhs, <4 x half> [[DUP_FLT]])
+// CHECK: ret <4 x half> [[RES]]
+float16x4_t test_vcmla_lane_f16(float16x4_t acc, float16x4_t lhs, float16x4_t rhs) {
+  return vcmla_lane_f16(acc, lhs, rhs, 1);
+}
+
+// ACLE says this exists, but it won't map to a single instruction if lane > 1.
+// CHECK-LABEL: @test_vcmla_laneq_f16(
+// CHECK: [[CPLX:%.*]] = bitcast <8 x half> %rhs to <4 x i32>
+// CHECK: [[DUP:%.*]] = shufflevector <4 x i32> [[CPLX]], <4 x i32> undef, <2 x i32> 
+// CHECK: [[DUP_FLT:%.*]] = bitcast <2 x i32> [[DUP]] to <4 x half>
+// CHECK: [[RES:%.*]] = call <4 x half> @llvm.aarch64.neon.vcmla.rot0.v4f16(<4 x half> %acc, <4 x half> %lhs, <4 x half> [[DUP_FLT]])
+// CHECK: ret <4 x half> [[RES]]
+float16x4_t test_vcmla_laneq_f16(float16x4_t acc, float16x4_t lhs, float16x8_t rhs) {
+  return vcmla_laneq_f16(acc, lhs, rhs, 3);
+}
+
+// CHECK-LABEL: @test_vcmlaq_lane_f16(
+// CHECK: [[CPLX:%.*]] = bitcast <4 x half> %rhs to <2 x i32>
+// CHECK: [[DUP:%.*]] = shufflevector <2 x i32> [[CPLX]], <2 x i32> undef, <4 x i32> 
+// CHECK: [[DUP_FLT:%.*]] = bitcast <4 x i32> [[DUP]] to <8 x half>
+// CHECK: [[RES:%.*]] = call <8 x half> @llvm.aarch64.neon.vcmla.rot0.v8f16(<8 x half> %acc, <8 x half> %lhs, <8 x half> [[DUP_FLT]])
+// CHECK: ret <8 x half> [[RES]]
+float16x8_t test_vcmlaq_lane_f16(float16x8_t acc, float16x8_t lhs, float16x4_t rhs) {
+  return vcmlaq_lane_f16(acc, lhs, rhs, 1);
+}
+
+// CHECK-LABEL: @test_vcmlaq_laneq_f16(
+// CHECK: [[CPLX:%.*]] = bitcast <8 x half> %rhs to <4 x i32>
+// CHECK: [[DUP:%.*]] = shufflevector <4 x i32> [[CPLX]], <4 x i32> undef, <4 x i32> 
+// CHECK: [[DUP_FLT:%.*]] = bitcast <4 x i32> [[DUP]] to <8 x half>
+// CHECK: [[RES:%.*]] = call <8 x half> @llvm.aarch64.neon.vcmla.rot0.v8f16(<8 x half> %acc, <8 x half> %lhs, <8 x half> [[DUP_FLT]])
+// CHECK: ret <8 x half> [[RES]]
+float16x8_t test_vcmlaq_laneq_f16(float16x8_t acc, float16x8_t lhs, float16x8_t rhs) {
+  return vcmlaq_laneq_f16(acc, lhs, rhs, 3);
+}
+
+// CHECK-LABEL: @test_vcmla_lane_f32(
+// CHECK: [[RES:%.*]] = call <2 x float> @llvm.aarch64.neon.vcmla.rot0.v2f32(<2 x float> %acc, <2 x float> %lhs, <2 x float> %rhs)
+// CHECK: ret <2 x float> [[RES]]
+float32x2_t test_vcmla_lane_f32(float32x2_t acc, float32x2_t lhs, float32x2_t rhs) {
+  return vcmla_lane_f32(acc, lhs, rhs, 0);
+}
+
+// ACLE says this exists, but it won't map to a single instruction if lane > 1.
+// CHECK-LABEL: @test_vcmla_laneq_f32(
+// CHECK: [[CPLX:%.*]] = bitcast <4 x float> %rhs to <2 x i64>
+// CHECK: [[DUP:%.*]] = shufflevector <2 x i64> [[CPLX]], <2 x i64> undef, <1 x i32> 
+// CHECK: [[DUP_FLT:%.*]] = bitcast <1 x i64> [[DUP]] to <2 x float>
+// CHECK: [[RES:%.*]] = 

[PATCH] D93014: [Clang] Add AArch64 VCMLA LANE variants.

2021-01-04 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer added inline comments.



Comment at: clang/include/clang/Basic/arm_neon.td:1911
+// vcmlaq{ROT}_lane
+def : SOpInst<"vcmla" # ROT # "_lane", "...qI", "Q" # type, Op<(call 
"vcmla" # ROT, $p0, $p1,
+   (bitcast $p0, (dup_typed laneqty , (call "vget_lane", (bitcast 
lanety, $p2), $p3>>;

I have looked only quickly at this, but I was expecting the `"q"` to appear 
here somewhere?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93014

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


[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

2021-01-04 Thread Hongtao Yu via Phabricator via cfe-commits
hoy updated this revision to Diff 314393.
hoy added a comment.

Replacing linkage names for debug declaration as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93747

Files:
  llvm/include/llvm/IR/DebugInfoMetadata.h
  llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
  llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll

Index: llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
===
--- llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
+++ llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
@@ -3,8 +3,10 @@
 ; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
 ; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
 ; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+; RUN: opt -S -passes=unique-internal-linkage-names -unqiue-debug-linkage-names=0 < %s -o - | FileCheck %s --check-prefix=NODBG
+; RUN: opt -S -passes=unique-internal-linkage-names < %s -o - | FileCheck %s --check-prefix=DBG
 
-define internal i32 @foo() {
+define internal i32 @foo() !dbg !15 {
 entry:
   ret i32 0
 }
@@ -14,6 +16,21 @@
   ret i32 (...)* bitcast (i32 ()* @foo to i32 (...)*)
 }
 
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, enums: !2)
+!1 = !DIFile(filename: "test.c", directory: "")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!13 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!15 = distinct !DISubprogram(name: "foo", scope: !1, file: !1, line: 5, type: !16, scopeLine: 5, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: !18, retainedNodes: !2)
+!16 = !DISubroutineType(types: !17)
+!17 = !{!13}
+!18 = !DISubprogram(name: "foo", scope: !1, isDefinition: false, flags: DIFlagPrototyped, spFlags: DISPFlagOptimized)
+
 ; O0: Running pass: UniqueInternalLinkageNamesPass
 
 ;; Check UniqueInternalLinkageNamesPass is scheduled before SampleProfileProbePass.
@@ -22,3 +39,8 @@
 
 ; UNIQUE: define internal i32 @foo.__uniq.{{[0-9a-f]+}}()
 ; UNIQUE: ret {{.*}} @foo.__uniq.{{[0-9a-f]+}} {{.*}}
+
+; NODBG: distinct !DISubprogram(name: "foo", scope: ![[#]]
+; NODBG: !DISubprogram(name: "foo", scope: ![[#]]
+; DBG: distinct !DISubprogram(name: "foo", linkageName: "foo.__uniq.{{[0-9a-f]+}}", scope: ![[#]]
+; DBG: !DISubprogram(name: "foo", linkageName: "foo.__uniq.{{[0-9a-f]+}}", scope: ![[#]]
Index: llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
===
--- llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
+++ llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
@@ -13,13 +13,21 @@
 
 #include "llvm/Transforms/Utils/UniqueInternalLinkageNames.h"
 #include "llvm/ADT/SmallString.h"
+#include "llvm/IR/DebugInfoMetadata.h"
+#include "llvm/IR/MDBuilder.h"
 #include "llvm/IR/Module.h"
 #include "llvm/InitializePasses.h"
+#include "llvm/Support/CommandLine.h"
 #include "llvm/Support/MD5.h"
 #include "llvm/Transforms/Utils/ModuleUtils.h"
 
 using namespace llvm;
 
+static cl::opt
+UniqueDebugLinakgeNames("unqiue-debug-linkage-names", cl::init(true),
+cl::Hidden,
+cl::desc("Uniqueify debug linkage Names"));
+
 static bool uniqueifyInternalLinkageNames(Module &M) {
   llvm::MD5 Md5;
   Md5.update(M.getSourceFileName());
@@ -31,11 +39,21 @@
   // this symbol is of internal linkage type.
   std::string ModuleNameHash = (Twine(".__uniq.") + Twine(Str)).str();
   bool Changed = false;
+  MDBuilder MDB(M.getContext());
 
   // Append the module hash to all internal linkage functions.
   for (auto &F : M) {
 if (F.hasInternalLinkage()) {
   F.setName(F.getName() + ModuleNameHash);
+  // Replace linkage names in the debug metadata.
+  if (UniqueDebugLinakgeNames) {
+if (DISubprogram *SP = F.getSubprogram()) {
+  auto *Name = MDB.createString(F.getName());
+  SP->replaceRawLinkageName(Name);
+  if (DISubprogram *SPDecl = SP->getDeclaration())
+SPDecl->replaceRawLinkageName(Name);
+}
+  }
   Changed = true;
 }
   }
Index: llvm/include/llvm/IR/DebugInfoMetadata.h
===
--- llvm/include/llvm/IR/DebugInfoMetadata.h
+++

[PATCH] D93453: [flang][driver] Add support for `-I`

2021-01-04 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added a comment.

I left a few nits, but otherwise LGTM!




Comment at: clang/lib/Driver/ToolChains/Flang.cpp:25
   Args.AddAllArgs(CmdArgs, {options::OPT_D, options::OPT_U});
+  Args.AddAllArgs(CmdArgs, options::OPT_I);
 }

[nit] This probably can be merged with the line above.



Comment at: flang/include/flang/Frontend/PreprocessorOptions.h:13
   std::vector> Macros;
+  std::vector SearchDirectoriesFromI;
 

awarzynski wrote:
> [nit] I'd be tempted to be more explicit here, e.g. 
> `SearchDirectoriesFromDashI;`.
I think that once the new driver supports more search-path related options 
(rather than just `-I`), it will make sense to extract these into a separate 
class. That's not really needed just now, but it's probably worth adding a 
comment. Perhaps something like this:
```
// TODO: When adding support for more options related to search paths, consider 
collecting them in a separate aggregate. For now we keep it here as there is no 
point creating a class for just one field.
```



Comment at: flang/lib/Frontend/CompilerInvocation.cpp:264-267
+  for (const auto &searchDirectoryFromI :
+  preprocessorOptions.searchDirectoriesFromDashI) {
+fortranOptions.searchDirectories.emplace_back(searchDirectoryFromI);
+  }

If these are `std::vector`s (which I believe is the case), then you can 
simplify:
```
fortranOptions.searchDirectories.insert(
fortranOptions.searchDirectories.end(), 
preprocessorOptions.searchDirectoriesFromDashI.begin(),
preprocessorOptions.searchDirectoriesFromDashI.end());
```



Comment at: flang/test/Flang-Driver/driver-help.f90:27
 ! HELP-NEXT: -help  Display available options
+! HELP-NEXT: -IAdd directory to include search path. If 
there are multiple -I options, these directories are searched in the order they 
are given before the standard system directories are searched. If the same 
directory is in the SYSTEM include search paths, for example if also specified 
with -isystem, the -I option will be ignored
 ! HELP-NEXT: -o   Write output to 

The help message for `-I` is _very_ long :) I wonder, perhaps you could just 
keep `Add directory to include search path.`?

The purpose of this test file is to verify that `-help` only displays the 
supported options. Technically speaking only `-I` is needed for that :) (but 
that could be _too_ short)



Comment at: flang/test/Flang-Driver/include_header.f90:33
+
+#include 
+#ifdef X

[nit] IMO the naming is a bit unfortunate, e.g. there's `include` and 
`included` on one line. Perhaps: `basic-test-header.h`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93453

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


[PATCH] D93986: [clang-format] Add the possibility to align assignments spanning empty lines or comments

2021-01-04 Thread Lukas Barth via Phabricator via cfe-commits
tinloaf added a comment.

In D93986#2477383 , @MyDeveloperDay 
wrote:

> Ideally we should add a comment to the release notes, (which you could do via 
> a separate NFC commit if you wanted)

Thank, I'll do that. But before that, I will create a revision that adds the 
same feature for the other three alignment types.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93986

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


[PATCH] D93232: [AArch64] Adding ACLE intrinsics for the LS64 extension

2021-01-04 Thread Lucas Prates via Phabricator via cfe-commits
pratlucas added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93232

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


[PATCH] D93846: [clang-format] PR16518 Add flag to suppress empty line insertion before access modifier

2021-01-04 Thread Albertas Vyšniauskas via Phabricator via cfe-commits
thezbyg marked an inline comment as done.
thezbyg added inline comments.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:1221
+if (Style.EmptyLineBeforeAccessModifier &&
+PreviousLine->Last->isOneOf(tok::semi, tok::r_brace) &&
+RootToken.NewlinesBefore == 1)

MyDeveloperDay wrote:
> maybe I don't understand the logic but why is this `r_brace` and shouldn't we 
> be looking at the "Last Non Comment" token?
I think that the logic is to only add empty line when access modifier is after 
member function body (`r_brace` indicates this) or declaration of 
field/function. If this check is changed to look at "last non comment" token, 
then empty line will be inserted in code like this:
```
struct Foo {
  int i;
  //comment
private:
  int j;
}
```


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

https://reviews.llvm.org/D93846

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


[PATCH] D93597: [X86][SSE] Enable constexpr on some basic SSE intrinsics (RFC)

2021-01-04 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon added inline comments.



Comment at: clang/test/CodeGen/X86/sse-builtins.c:815
+// Test constexpr handling.
+#if defined(__cplusplus) && (__cplusplus >= 201103L)
+constexpr __m128 test_constexpr_mm_add_ps(__m128 A, __m128 B) {

pengfei wrote:
> What are these tests testing for?
These are the more basic c++11 tests to ensure that the intrinsics can be used 
in a constexpr - without c++14 we can't actually create a __m128 type, so 
everything is on-the-fly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93597

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


[PATCH] D93688: [ASTMatchers] Ensure that we can match inside lambdas

2021-01-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/ASTMatchers/ASTMatchFinder.cpp:478-487
+} else if (auto *LE = dyn_cast(S)) {
+
+  for (unsigned I = 0, N = LE->capture_size(); I != N; ++I) {
+const auto *C = LE->capture_begin() + I;
+{
+  ASTNodeNotSpelledInSourceScope RAII(
+  this, TraversingASTNodeNotSpelledInSource || !C->isExplicit());





Comment at: clang/lib/ASTMatchers/ASTMatchFinder.cpp:512-513
+  // Visit parameters.
+  for (unsigned I = 0, N = Proto.getNumParams(); I != N; ++I)
+TraverseDecl(Proto.getParam(I));
+}





Comment at: clang/lib/ASTMatchers/ASTMatchFinder.cpp:516
+
+auto *T = Proto.getTypePtr();
+for (const auto &E : T->exceptions())





Comment at: clang/lib/ASTMatchers/ASTMatchFinder.cpp:526
+TraverseStmt(LE->getTrailingRequiresClause());
+
+TraverseStmt(LE->getBody());

Do we also need to traverse attributes of the lambda?



Comment at: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:3069
+
+  Code = R"cpp(
+void foo() {

Do we have other test coverage for the rest of lambda matching, or should you 
add coverage for things like parameters, trailing requires clauses, etc?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93688

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


[PATCH] D93785: [OpenMP][FIX] Ensure the isa trait is evaluated last

2021-01-04 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

2021 ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93785

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


[PATCH] D91000: [clang-tidy] CERT MSC24-C Obsolescent Functions check

2021-01-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D91000#2469898 , @lebedev.ri wrote:

> I think the question is, *why* are these checks being implemented?
> Just to claim that for some particular rule there is a check, and cross it 
> off a list?
> Or for them to be actually used?

We have an existing CERT module for CERT-specific checks. When the check is 
honoring a published coding standard, that's usually sufficient justification 
-- but I do think the check should implement what the CERT recommendation says. 
If the CERT recommendation seems deficient in some way, it's reasonable to 
reach out to the authors (they allow comments on their wiki and are pretty good 
about responding to those comments) for clarification or to discuss potential 
improvements to the recommendation that would make the check more palatable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91000

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


[PATCH] D93765: [NFC, Refactor] Modernize StorageClass from Specifiers.h to a scoped enum (II)

2021-01-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM aside from some minor nits.




Comment at: clang/include/clang/AST/Decl.h:1078
 
-return getStorageClass() >= SC_Auto;
+return getStorageClass() >= StorageClass::Auto;
   }

You changed the definition of `isLegalForFunction()` to use a `switch` 
statement rather than use `<=` -- should this one be changed to a `switch` or 
the other one changed back to `<=` (or is there a reason to not be consistent)?



Comment at: clang/lib/Serialization/ASTReaderDecl.cpp:1416
+  VD->VarDeclBits.SClass =
+  static_cast(static_cast(Record.readInt()));
   VD->VarDeclBits.TSCSpec = Record.readInt();

Is there a benefit to the two-layer of casts as opposed to storing the read 
value directly into `SClass`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93765

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


[PATCH] D94019: Switching Clang UniqueInternalLinkageNamesPass scheduling to using the LLVM one with newpm.

2021-01-04 Thread Hongtao Yu via Phabricator via cfe-commits
hoy created this revision.
Herald added a subscriber: wenlei.
hoy requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

As a follow-up to D93656 , I'm switching the 
Clang UniqueInternalLinkageNamesPass scheduling to using the LLVM one with 
newpm.

Test Plan:


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94019

Files:
  clang/lib/CodeGen/BackendUtil.cpp


Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1145,6 +1145,7 @@
   // non-integrated assemblers don't recognize .cgprofile section.
   PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;
   PTO.Coroutines = LangOpts.Coroutines;
+  PTO.UniqueLinkageNames = CodeGenOpts.UniqueInternalLinkageNames;
 
   PassInstrumentationCallbacks PIC;
   StandardInstrumentations SI(CodeGenOpts.DebugPassManager);
@@ -1326,11 +1327,6 @@
   MPM = PB.buildPerModuleDefaultPipeline(Level);
 }
 
-// Add UniqueInternalLinkageNames Pass which renames internal linkage
-// symbols with unique names.
-if (CodeGenOpts.UniqueInternalLinkageNames)
-  MPM.addPass(UniqueInternalLinkageNamesPass());
-
 if (!CodeGenOpts.MemoryProfileOutput.empty()) {
   MPM.addPass(createModuleToFunctionPassAdaptor(MemProfilerPass()));
   MPM.addPass(ModuleMemProfilerPass());


Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1145,6 +1145,7 @@
   // non-integrated assemblers don't recognize .cgprofile section.
   PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;
   PTO.Coroutines = LangOpts.Coroutines;
+  PTO.UniqueLinkageNames = CodeGenOpts.UniqueInternalLinkageNames;
 
   PassInstrumentationCallbacks PIC;
   StandardInstrumentations SI(CodeGenOpts.DebugPassManager);
@@ -1326,11 +1327,6 @@
   MPM = PB.buildPerModuleDefaultPipeline(Level);
 }
 
-// Add UniqueInternalLinkageNames Pass which renames internal linkage
-// symbols with unique names.
-if (CodeGenOpts.UniqueInternalLinkageNames)
-  MPM.addPass(UniqueInternalLinkageNamesPass());
-
 if (!CodeGenOpts.MemoryProfileOutput.empty()) {
   MPM.addPass(createModuleToFunctionPassAdaptor(MemProfilerPass()));
   MPM.addPass(ModuleMemProfilerPass());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D93988: [ASTMatchers] Make tests explicit about mode-dependence

2021-01-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Could you give me a bit more background about why you want to make this change?

There are tests which I would expect to match in any traversal mode (e.g., 
`EXPECT_TRUE(matches("class X {};", traverse(TK_AsIs, HasClassX)));`) so 
there's a part of me that wonders if we should add helper functionality to test 
the various traversal modes as part of this change. e.g., we specify an 
explicit traversal mode for the situations where only one mode should be 
tested, and we specify a helper function that tests both traversal modes on the 
same code. WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93988

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


[PATCH] D91898: [attributes] Add a facility for defining and enforcing a Trusted Computing Base.

2021-01-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:5681
+  trusted compute base (TCB) does not call out of the TCB. This generates a
+  warning everytime a function not marked with an enforce_tcb attribute is
+  called from a function with the enforce_tcb attribute. A function may be a





Comment at: clang/include/clang/Basic/AttrDocs.td:5682
+  warning everytime a function not marked with an enforce_tcb attribute is
+  called from a function with the enforce_tcb attribute. A function may be a
+  part of multiple TCBs. Invocations through function pointers are currently





Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11087
+// TCB warnings
+def err_tcb_conflicting_attributes : Error<
+  "attributes '%0(\"%2\")' and '%1(\"%2\")' are mutually exclusive">;

NoQ wrote:
> Do i understand correctly that while "unknown attribute" is a warning ("must 
> be an attribute for some other compiler, let's ignore"), misuse of a known 
> attribute is typically an error ("ok, whatever you meant here, i have an 
> opinion about what this really means and i don't like it")?
It depends strongly on the attribute and the problem at hand. My usual rule of 
thumb is: if the attribute is being ignored because the code makes no sense, 
it's an error, but if the attribute can still be useful (perhaps after some 
adjustment), then warn. e.g., putting a calling convention attribute on a 
variable of type `int` makes no sense -- that should probably err rather than 
warn and ignore because the user did something baffling.

I could go either way on this one. Giving an error and forcing the user to say 
what they mean is appealing, but it would also be defensible to warn about the 
conflicting attribute and ignore just that one (retaining the original 
attribute). I would say leave it as an error and we can downgrade to a warning 
later if there's feedback from compelling real world use cases.



Comment at: clang/test/Sema/attr-enforce-tcb-errors.cpp:23
+void both_tcb_and_tcb_leaf_on_separate_redeclarations();
+__attribute__((enforce_tcb_leaf("x"))) // FIXME: This should be an error.
+void both_tcb_and_tcb_leaf_on_separate_redeclarations() {}

NoQ wrote:
> Unfortunately the new facility doesn't catch this case because in 
> `handleEnforceTCBAttr()` the function doesn't yet know that it's a 
> redeclaration. I think this case is more important to catch than the 
> straightforward case (because it's very easy to make this mistake), so i'll 
> try to find a better place to emit the error. Is it ok if this goes into a 
> follow-up patch?
I was about to comment on the code in SemaDeclAttr.cpp but skipped down here to 
see if you had a redeclaration test first, and found this comment instead. :-D 
I think you need to follow the `mergeFooAttr` pattern to enforce this properly 
(and I think it probably should be done in the initial patch, but it shouldn't 
be too painful hopefully). The basic idea is that you change 
`mergeDeclAttribute()` in SemaDecl.cpp to call `S.mergeEnforceTCBAttr()` that 
checks whether there are conflicting attributes or not. Then in 
`handleEnforceTCBAttr()` in SemaDeclAttr.cpp, you can call 
`mergeEnforceTCBAttr()` to handle the straightforward case.


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

https://reviews.llvm.org/D91898

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


[PATCH] D93375: [clang][driver] Add -ansi option to CompileOnly group

2021-01-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

This seems reasonable to me, but I wonder if there's a way we can add test 
coverage for the change?


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

https://reviews.llvm.org/D93375

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


[PATCH] D94021: [OpenCL] Add clang extension for function pointers

2021-01-04 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia created this revision.
Anastasia added a reviewer: mantognini.
Herald added subscribers: ebevhan, kerbowa, yaxunl, nhaehnle, jvesely, 
jholewinski.
Anastasia requested review of this revision.

This feature is primarily important in C++ mode because it opens up more 
opportunities to describe metaprogramming algorithms with function types. It 
can also be used to facilitate virtual functions.

This is clang and not a vendor extension and therefore it is only intended for 
internal or experimental use. The full feature will require changes in vendor 
toolchains that can be provided in the future via either vendor extensions or 
Khronos extensions.


https://reviews.llvm.org/D94021

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/OpenCLExtensions.def
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/Misc/amdgcn.languageOptsOpenCL.cl
  clang/test/Misc/nvptx.languageOptsOpenCL.cl
  clang/test/Misc/r600.languageOptsOpenCL.cl
  clang/test/Parser/opencl-cxx-virtual.cl
  clang/test/SemaOpenCL/extension-version.cl
  clang/test/SemaOpenCL/func.cl
  clang/test/SemaOpenCLCXX/members.cl

Index: clang/test/SemaOpenCLCXX/members.cl
===
--- clang/test/SemaOpenCLCXX/members.cl
+++ clang/test/SemaOpenCLCXX/members.cl
@@ -1,6 +1,13 @@
 //RUN: %clang_cc1 %s -triple spir -cl-std=clc++ -verify -fsyntax-only
+//RUN: %clang_cc1 %s -triple spir -cl-std=clc++ -verify -fsyntax-only -DFUNCPTREXT
+
+#ifdef FUNCPTREXT
+#pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
+//expected-no-diagnostics
+#endif
 
 // Check that pointer to member functions are diagnosed
+// unless specific clang extension is enabled.
 struct C {
   void f(int n);
 };
@@ -12,11 +19,25 @@
 
 template 
 void templ_test() {
-  typename remove_reference::type *ptr; //expected-error{{pointers to functions are not allowed}}
+  typename remove_reference::type *ptr;
+#ifndef FUNCPTREXT
+  //expected-error@-2{{pointers to functions are not allowed}}
+#endif
 }
 
 void test() {
-  void (C::*p)(int);   //expected-error{{pointers to functions are not allowed}}
-  p_t p1;  //expected-error{{pointers to functions are not allowed}}
-  templ_test(); //expected-note{{in instantiation of function template specialization}}
+  void (C::*p)(int);
+#ifndef FUNCPTREXT
+//expected-error@-2{{pointers to functions are not allowed}}
+#endif
+
+  p_t p1;
+#ifndef FUNCPTREXT
+//expected-error@-2{{pointers to functions are not allowed}}
+#endif
+
+  templ_test();
+#ifndef FUNCPTREXT
+//expected-note@-2{{in instantiation of function template specialization}}
+#endif
 }
Index: clang/test/SemaOpenCL/func.cl
===
--- clang/test/SemaOpenCL/func.cl
+++ clang/test/SemaOpenCL/func.cl
@@ -1,16 +1,26 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple spir-unknown-unknown
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple spir-unknown-unknown -DFUNCPTREXT
+
+#ifdef FUNCPTREXT
+#pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
+#endif
 
 // Variadic functions
 void vararg_f(int, ...);// expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
 void __vararg_f(int, ...);
 typedef void (*vararg_fptr_t)(int, ...);// expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
-// expected-error@-1{{pointers to functions are not allowed}}
+#ifndef FUNCPTREXT
+// expected-error@-2 {{pointers to functions are not allowed}}
+#endif
 int printf(__constant const char *st, ...); // expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
 
 // Struct type with function pointer field
 typedef struct s
 {
-   void (*f)(struct s *self, int *i);   // expected-error{{pointers to functions are not allowed}}
+   void (*f)(struct s *self, int *i);
+#ifndef FUNCPTREXT
+// expected-error@-2 {{pointers to functions are not allowed}}
+#endif
 } s_t;
 
 //Function pointer
@@ -22,7 +32,10 @@
 void bar()
 {
   // declaring a function pointer is an error
-  void (*fptr)(int); // expected-error{{pointers to functions are not allowed}}
+  void (*fptr)(int);
+#ifndef FUNCPTREXT
+  // expected-error@-2 {{pointers to functions are not allowed}}
+#endif
 
   // taking the address of a function is an error
   foo((void*)foo); // expected-error{{taking address of function is not allowed}}
Index: clang/test/SemaOpenCL/extension-version.cl
===
--- clang/test/SemaOpenCL/extension-version.cl
+++ clang/test/SemaOpenCL/extension-version.cl
@@ -17,7 +17,12 @@
 #ifndef cl_clang_storage_class_specifiers
 #error "Missing cl_clang_storage_class_specifiers define"
 #endif
-#pragma OPENCL EXTEN

[PATCH] D90507: [Driver] Add DWARF64 flag: -gdwarf64

2021-01-04 Thread Alexander Yermolovich via Phabricator via cfe-commits
ayermolo updated this revision to Diff 314413.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90507

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Driver/debug-options.c

Index: clang/test/Driver/debug-options.c
===
--- clang/test/Driver/debug-options.c
+++ clang/test/Driver/debug-options.c
@@ -374,3 +374,19 @@
 // RUN:| FileCheck -check-prefix=NO_DEBUG_UNUSED_TYPES %s
 // NO_DEBUG_UNUSED_TYPES: "-debug-info-kind={{limited|line-tables-only|standalone}}"
 // NO_DEBUG_UNUSED_TYPES-NOT: "-debug-info-kind=unused-types"
+//
+// RUN: %clang -### -c -gdwarf-5 -gdwarf64 -target x86_64 %s 2>&1 | FileCheck -check-prefix=GDWARF64_ON %s
+// RUN: %clang -### -c -gdwarf-4 -gdwarf64 -target x86_64 %s 2>&1 | FileCheck -check-prefix=GDWARF64_ON %s
+// RUN: %clang -### -c -gdwarf-3 -gdwarf64 -target x86_64 %s 2>&1 | FileCheck -check-prefix=GDWARF64_ON %s
+// RUN: %clang -### -c -gdwarf-2 -gdwarf64 -target x86_64 %s 2>&1 | FileCheck -check-prefix=GDWARF64_VER %s
+// RUN: %clang -### -c -gdwarf-4 -gdwarf64 -target x86_64 -target x86_64 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=GDWARF64_ON %s
+// RUN: %clang -### -c -gdwarf-4 -gdwarf64 -target i386-linux-gnu %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=GDWARF64_32ARCH %s
+// RUN: %clang -### -c -gdwarf-4 -gdwarf64 -target x86_64-apple-darwin %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=GDWARF64_ELF %s
+//
+// GDWARF64_ON:  "-gdwarf64"
+// GDWARF64_VER:  error: invalid argument '-gdwarf64' only allowed with 'DWARFv3 or greater'
+// GDWARF64_32ARCH: error: invalid argument '-gdwarf64' only allowed with '64 bit architecture'
+// GDWARF64_ELF: error: invalid argument '-gdwarf64' only allowed with 'ELF platforms'
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1058,6 +1058,7 @@
   Opts.CXXCtorDtorAliases = Args.hasArg(OPT_mconstructor_aliases);
   Opts.CodeModel = TargetOpts.CodeModel;
   Opts.DebugPass = std::string(Args.getLastArgValue(OPT_mdebug_pass));
+  Opts.Dwarf64 = Args.hasArg(OPT_gdwarf64);
 
   // Handle -mframe-pointer option.
   if (Arg *A = Args.getLastArg(OPT_mframe_pointer_EQ)) {
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4017,6 +4017,25 @@
   if (DebuggerTuning == llvm::DebuggerKind::SCE)
 CmdArgs.push_back("-dwarf-explicit-import");
 
+  auto *DwarfFormatArg =
+  Args.getLastArg(options::OPT_gdwarf64, options::OPT_gdwarf32);
+  if (DwarfFormatArg &&
+  DwarfFormatArg->getOption().matches(options::OPT_gdwarf64)) {
+const llvm::Triple &RawTriple = TC.getTriple();
+if (EffectiveDWARFVersion < 3)
+  D.Diag(diag::err_drv_argument_only_allowed_with)
+  << DwarfFormatArg->getAsString(Args) << "DWARFv3 or greater";
+else if (!RawTriple.isArch64Bit())
+  D.Diag(diag::err_drv_argument_only_allowed_with)
+  << DwarfFormatArg->getAsString(Args) << "64 bit architecture";
+else if (!RawTriple.isOSBinFormatELF())
+  D.Diag(diag::err_drv_argument_only_allowed_with)
+  << DwarfFormatArg->getAsString(Args) << "ELF platforms";
+  }
+
+  if (DwarfFormatArg)
+DwarfFormatArg->render(Args, CmdArgs);
+
   RenderDebugInfoCompressionArgs(Args, CmdArgs, D, TC);
 }
 
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -571,6 +571,7 @@
   Options.MCOptions.MCFatalWarnings = CodeGenOpts.FatalWarnings;
   Options.MCOptions.MCNoWarn = CodeGenOpts.NoWarn;
   Options.MCOptions.AsmVerbose = CodeGenOpts.AsmVerbose;
+  Options.MCOptions.Dwarf64 = CodeGenOpts.Dwarf64;
   Options.MCOptions.PreserveAsmComments = CodeGenOpts.PreserveAsmComments;
   Options.MCOptions.ABIName = TargetOpts.ABI;
   for (const auto &Entry : HSOpts.UserEntries)
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2427,6 +2427,10 @@
   HelpText<"Generate source-level debug information with dwarf version 4">;
 def gdwarf_5 : Flag<["-"], "gdwarf-5">, Group,
   HelpText<"Generate source-level debug information with dwarf version 5">;
+def gdwarf64 : Flag<["-"], "gdwarf64">, Group, Flags<[CC1Option]>,
+  HelpText<"Enables DWARF64 format for ELF binaries, if debug information emission is enabled.">;
+def gdwarf32 : Fla

[PATCH] D87702: [Frontend] Add pragma align natural and sort out pragma pack stack effect

2021-01-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:858
+def err_pragma_pack_invalid_alignment : Error<
+  "expected #pragma pack parameter to be '1', '2', '4', '8', or '16'">;
 def warn_pragma_pack_non_default_at_include : Warning<





Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:893
+def warn_pragma_pack_identifer_not_supported : Warning<
+  "specifying an identifier within pragma pack is not supported, identifier is 
ignored">,
+  InGroup;

If the user wrote an identifier, it seems like there's a strong chance that 
ignoring the identifier will result in incorrect behavior that would lead to 
hard-to-find ODR issues. Should this scenario be an error rather than a warning 
where the identifier is ignored?



Comment at: clang/include/clang/Sema/Sema.h:486
+: PackAttr(true), AlignMode(M), PackNumber(Num), XLStack(IsXL) {
+  assert(Num == PackNumber && "Unexpected value.");
+}

The string literal here doesn't really convey what's being asserted -- it took 
me a while to figure out that this is trying to catch truncation issues when 
`Num` cannot be represented by an `unsigned char`.



Comment at: clang/include/clang/Sema/Sema.h:494
+
+AlignPackInfo(bool IsXL) : AlignPackInfo(Native, IsXL) {}
+





Comment at: clang/include/clang/Sema/Sema.h:512
+static AlignPackInfo getFromRawEncoding(unsigned Encoding) {
+  static_assert(sizeof(AlignPackInfo) == sizeof(uint32_t),
+"Size is not correct");

I would feel more comfortable with this assertion if the class was using 
bit-fields to pack the values together. As it stands, we're kind of hoping that 
`bool`, `Mode`, and `unsigned char` will all pack in a particular way (and 
`bool`'s representation is implementation-defined).



Comment at: clang/include/clang/Sema/Sema.h:527
+
+unsigned char getPackNumber() const { return PackNumber; }
+

Given that the ctor takes an `int` for this value, should this be returning an 
`int`?



Comment at: clang/lib/AST/RecordLayoutBuilder.cpp:1314
 void ItaniumRecordLayoutBuilder::InitializeLayout(const Decl *D) {
+
   if (const RecordDecl *RD = dyn_cast(D)) {

Unintended whitespace change?



Comment at: clang/lib/Sema/SemaAttr.cpp:69-71
+  if (IsXLPragma && M == AlignPackInfo::Natural) {
+RD->addAttr(AlignNaturalAttr::CreateImplicit(Context));
   }





Comment at: clang/test/Sema/aix-pragma-pack-and-align.c:231
+
+// expected-no-warning

Is this comment intentional?


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

https://reviews.llvm.org/D87702

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


[PATCH] D92936: [Sema] Fix deleted function problem in implicitly movable test

2021-01-04 Thread dmajor via Phabricator via cfe-commits
dmajor added a comment.

Before the revert, our bots hit the following issue where we only error out 
when `-Wall` is given, so there's definitely something strange going on. Also 
happens with @Quuxplusone's suggested change applied.

  $ cat test.cpp
  template < class > class RefPtr {
  public:
~RefPtr();
template < typename d > RefPtr(d);
operator int() &;
operator int() && = delete;
  };
  class X;
  bool e() {
RefPtr< X > frame(0);
return frame;
  }
  
  $ clang -cc1 -std=c++17 test.cpp
  $ clang -cc1 -std=c++17 test.cpp -Wall
  test.cpp:11:10: error: conversion function from 'RefPtr' to 'bool' invokes 
a deleted function
return frame;
   ^
  test.cpp:6:3: note: 'operator int' has been explicitly marked deleted here
operator int() && = delete;
^
  1 error generated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92936

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


[clang] 4034f92 - Switching Clang UniqueInternalLinkageNamesPass scheduling to using the LLVM one with newpm.

2021-01-04 Thread Hongtao Yu via cfe-commits

Author: Hongtao Yu
Date: 2021-01-04T12:04:46-08:00
New Revision: 4034f9273edacbb1c37acf19139594a226c8bdac

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

LOG: Switching Clang UniqueInternalLinkageNamesPass scheduling to using the 
LLVM one with newpm.

As a follow-up to D93656, I'm switching the Clang 
UniqueInternalLinkageNamesPass scheduling to using the LLVM one with newpm.

Test Plan:

Reviewed By: aeubanks, tmsriram

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

Added: 


Modified: 
clang/lib/CodeGen/BackendUtil.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index b326c643738f..296b111feb2d 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -1145,6 +1145,7 @@ void EmitAssemblyHelper::EmitAssemblyWithNewPassManager(
   // non-integrated assemblers don't recognize .cgprofile section.
   PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;
   PTO.Coroutines = LangOpts.Coroutines;
+  PTO.UniqueLinkageNames = CodeGenOpts.UniqueInternalLinkageNames;
 
   PassInstrumentationCallbacks PIC;
   StandardInstrumentations SI(CodeGenOpts.DebugPassManager);
@@ -1326,11 +1327,6 @@ void EmitAssemblyHelper::EmitAssemblyWithNewPassManager(
   MPM = PB.buildPerModuleDefaultPipeline(Level);
 }
 
-// Add UniqueInternalLinkageNames Pass which renames internal linkage
-// symbols with unique names.
-if (CodeGenOpts.UniqueInternalLinkageNames)
-  MPM.addPass(UniqueInternalLinkageNamesPass());
-
 if (!CodeGenOpts.MemoryProfileOutput.empty()) {
   MPM.addPass(createModuleToFunctionPassAdaptor(MemProfilerPass()));
   MPM.addPass(ModuleMemProfilerPass());



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


[PATCH] D94019: Switching Clang UniqueInternalLinkageNamesPass scheduling to using the LLVM one with newpm.

2021-01-04 Thread Hongtao Yu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4034f9273eda: Switching Clang UniqueInternalLinkageNamesPass 
scheduling to using the LLVM one… (authored by hoy).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94019

Files:
  clang/lib/CodeGen/BackendUtil.cpp


Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1145,6 +1145,7 @@
   // non-integrated assemblers don't recognize .cgprofile section.
   PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;
   PTO.Coroutines = LangOpts.Coroutines;
+  PTO.UniqueLinkageNames = CodeGenOpts.UniqueInternalLinkageNames;
 
   PassInstrumentationCallbacks PIC;
   StandardInstrumentations SI(CodeGenOpts.DebugPassManager);
@@ -1326,11 +1327,6 @@
   MPM = PB.buildPerModuleDefaultPipeline(Level);
 }
 
-// Add UniqueInternalLinkageNames Pass which renames internal linkage
-// symbols with unique names.
-if (CodeGenOpts.UniqueInternalLinkageNames)
-  MPM.addPass(UniqueInternalLinkageNamesPass());
-
 if (!CodeGenOpts.MemoryProfileOutput.empty()) {
   MPM.addPass(createModuleToFunctionPassAdaptor(MemProfilerPass()));
   MPM.addPass(ModuleMemProfilerPass());


Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1145,6 +1145,7 @@
   // non-integrated assemblers don't recognize .cgprofile section.
   PTO.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;
   PTO.Coroutines = LangOpts.Coroutines;
+  PTO.UniqueLinkageNames = CodeGenOpts.UniqueInternalLinkageNames;
 
   PassInstrumentationCallbacks PIC;
   StandardInstrumentations SI(CodeGenOpts.DebugPassManager);
@@ -1326,11 +1327,6 @@
   MPM = PB.buildPerModuleDefaultPipeline(Level);
 }
 
-// Add UniqueInternalLinkageNames Pass which renames internal linkage
-// symbols with unique names.
-if (CodeGenOpts.UniqueInternalLinkageNames)
-  MPM.addPass(UniqueInternalLinkageNamesPass());
-
 if (!CodeGenOpts.MemoryProfileOutput.empty()) {
   MPM.addPass(createModuleToFunctionPassAdaptor(MemProfilerPass()));
   MPM.addPass(ModuleMemProfilerPass());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D73413: [clang-tidy] Add check to detect external definitions with no header declaration

2021-01-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/misc/MissingHeaderFileDeclarationCheck.cpp:34
+std::is_base_of, T>::value
+&&std::is_base_of::value;
+





Comment at: 
clang-tools-extra/clang-tidy/misc/MissingHeaderFileDeclarationCheck.cpp:84
+if (!Check.checkCorrespongdingHeader())
+  return; // Found a good candidate for matching decl
+StringRef ThisStem = path::stem(SM.getFilename(BeginLoc));





Comment at: 
clang-tools-extra/clang-tidy/misc/MissingHeaderFileDeclarationCheck.cpp:87
+if (!ThisStem.empty() && Stem.startswith_lower(ThisStem))
+  return; // Found a good candidate for matching decl
+  }





Comment at: 
clang-tools-extra/clang-tidy/misc/MissingHeaderFileDeclarationCheck.cpp:162
+
+static NameAndFixMode getNameAndFixMode(TagTypeKind Kind, bool CPlusPlus) {
+  FixMode Mode = CPlusPlus ? FixMode::AnonNamespace : FixMode::None;

clang-tidy diagnostics do not start with a capital letter, so these string 
literals should all be lowercase.



Comment at: 
clang-tools-extra/clang-tidy/misc/MissingHeaderFileDeclarationCheck.cpp:190
+  utils::defaultFileExtensionDelimiters())) {
+llvm::errs() << "Invalid implementation file extension: "
+ << RawStringImplementationFileExtensions << "\n";

Should this be using `configurationDiag()` instead of `llvm::errs()`?



Comment at: 
clang-tools-extra/clang-tidy/misc/MissingHeaderFileDeclarationCheck.cpp:232-234
+checkDecl(*this, *VD, *Result.Context, {"Variable", FixMode::Static});
+  else if (const auto *FD = Result.Nodes.getNodeAs("FD"))
+checkDecl(*this, *FD, *Result.Context, {"Function", FixMode::Static});

These string literals should also be lowercased.



Comment at: 
clang-tools-extra/clang-tidy/misc/MissingHeaderFileDeclarationCheck.cpp:253
+  // Disable running this check on a file that isn't classed as an
+  // implementation file. can occur when running in clangd.
+  if (!isImplementationFile(getCurrentMainFile()))





Comment at: 
clang-tools-extra/test/clang-tidy/checkers/misc-missing-header-file-declaration.cpp:12
+extern bool DeclInSource;
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: Variable 'DeclInSource' is 
declared as extern in a source file
+// CHECK-FIXES: {{^\s*}}bool DeclInSource;

Warning on this construct worries me -- it's not uncommon to use extern 
declarations in some language modes. For instance, in C, you'll still find 
plenty of older code bases that use an extern declaration of a system function 
rather than `#include`'ing the standard library header. Also, folks will use 
extern definitions as a way to smuggle data between TUs without exposing a 
public interface (not always the best of practices, but it is an approach to 
hiding implementation details).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73413

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


[PATCH] D92751: [clang][aarch64] Precondition isHomogeneousAggregate on isCXX14Aggregate

2021-01-04 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

Thank for the update, apologies for not providing these suggestions the first 
time.




Comment at: clang/lib/CodeGen/CGCXXABI.cpp:320-321
+  //   No virtual functions
+  // Additionally, we need to ensure that there is a trivial copy assignment
+  // operator, a trivial destructor and no user-provided constructors.
+  if (RD->hasProtectedFields() || RD->hasPrivateFields())

rnk wrote:
> I realize now that the name I chose (`ixCXX14Aggregate`) isn't very good 
> because this routine also checks for trivial copy assignment and trivial 
> destruction.
We still need a better name for this. Something like, 
`isTrivialForAArch64MSVC`. This isn't a test for C++14 aggregate-ness, it's the 
test that a specific compiler uses to decide if a record may be passed in 
registers.

---

After thinking about this more, making this a virtual CGCXXABI method, as I 
suggest below, makes more sense, because then the CGCXXABI class doesn't need 
to expose this very MSVC-specific method, and we don't need to hoist this code 
out of MicrosoftCXXABI.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:5123
 
 // If this is a C++ record, check the bases first.
 if (const CXXRecordDecl *CXXRD = dyn_cast(RD)) {

This comment is stale. We're looking for something more along the lines of, 
"... check the C++ properties of the record, such as base classes."



Comment at: clang/lib/CodeGen/TargetInfo.cpp:5137
+
+  if (!isHomogeneousAggregateForABI(CXXRD))
+return false;

Apologies for moving the goalposts, but after re-reading the code, I feel like 
it would make more sense to make this a CGCXXABI virtual method. This code then 
would read:
  if (!getCXXABI().isPermittedToBeHomogeneousAggregate(CXXRD))
return false;

IMO it also makes sense to move this up before checking bases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92751

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


[PATCH] D90173: [PowerPC] Exploit splat instruction xxsplti32dx in Power10

2021-01-04 Thread Albion Fung via Phabricator via cfe-commits
Conanap updated this revision to Diff 314431.
Conanap marked 4 inline comments as done.
Conanap added a comment.

Addressed some comments for formatting and style


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

https://reviews.llvm.org/D90173

Files:
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/test/CodeGen/PowerPC/p10-splatImm-CPload-pcrel.ll
  llvm/test/CodeGen/PowerPC/p10-splatImm32.ll

Index: llvm/test/CodeGen/PowerPC/p10-splatImm32.ll
===
--- llvm/test/CodeGen/PowerPC/p10-splatImm32.ll
+++ llvm/test/CodeGen/PowerPC/p10-splatImm32.ll
@@ -118,3 +118,39 @@
   %vecins1 = shufflevector <4 x i32> , <4 x i32> %a, <4 x i32> 
   ret <4 x i32> %vecins1
 }
+
+define dso_local <2 x double> @test_xxsplti32dx_8() {
+; CHECK-LABEL: test_xxsplti32dx_8
+; CHECK-LE-LABEL: test_xxsplti32dx_8:
+; CHECK-LE:   # %bb.0: # %entry
+; CHECK-LE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-LE-NEXT:xxsplti32dx vs34, 1, 1082660167
+; CHECK-LE-NEXT:blr
+;
+; CHECK-BE-LABEL: test_xxsplti32dx_8:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-BE-NEXT:xxsplti32dx vs34, 1, 1082660167
+; CHECK-BE-NEXT:blr
+; CHECK: blr
+entry:
+  ret <2 x double> 
+}
+
+define dso_local <8 x i16> @test_xxsplti32dx_9() {
+; CHECK-LABEL: test_xxsplti32dx_9
+; CHECK-LE-LABEL: test_xxsplti32dx_9:
+; CHECK-LE:   # %bb.0: # %entry
+; CHECK-LE-NEXT:xxsplti32dx vs34, 0, 65827
+; CHECK-LE-NEXT:xxsplti32dx vs34, 1, 23855277
+; CHECK-LE-NEXT:blr
+;
+; CHECK-BE-LABEL: test_xxsplti32dx_9:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:xxsplti32dx vs34, 0, 11338092
+; CHECK-BE-NEXT:xxsplti32dx vs34, 1, 19070977
+; CHECK-BE-NEXT:blr
+; CHECK: blr
+entry:
+  ret <8 x i16> 
+}
Index: llvm/test/CodeGen/PowerPC/p10-splatImm-CPload-pcrel.ll
===
--- llvm/test/CodeGen/PowerPC/p10-splatImm-CPload-pcrel.ll
+++ llvm/test/CodeGen/PowerPC/p10-splatImm-CPload-pcrel.ll
@@ -1,114 +1,216 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu -O2 \
-; RUN: -ppc-asm-full-reg-names -mcpu=pwr10 < %s | FileCheck %s
+; RUN: -ppc-asm-full-reg-names -mcpu=pwr10 < %s | FileCheck %s --check-prefixes=CHECK-LE
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu -O2 \
 ; RUN: -ppc-asm-full-reg-names -mcpu=pwr10 < %s | FileCheck %s \
-; RUN: --check-prefix=CHECK-NOPCREL
+; RUN: --check-prefixes=CHECK-NOPCREL-BE
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu -O2 \
 ; RUN: -mattr=-pcrelative-memops -ppc-asm-full-reg-names -mcpu=pwr10 < %s | \
-; RUN: FileCheck %s --check-prefix=CHECK-NOPCREL
+; RUN: FileCheck %s --check-prefixes=CHECK-NOPCREL-LE
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu -O2 \
 ; RUN: -mattr=-prefix-instrs -ppc-asm-full-reg-names -mcpu=pwr10 < %s | \
-; RUN: FileCheck %s --check-prefix=CHECK-NOPCREL
+; RUN: FileCheck %s --check-prefixes=CHECK-NOPREFIX
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu -O2 \
 ; RUN: -ppc-asm-full-reg-names -target-abi=elfv2 -mcpu=pwr10 < %s | \
-; RUN: FileCheck %s
+; RUN: FileCheck %s --check-prefixes=CHECK-BE
 
 define dso_local <2 x double> @testDoubleToDoubleFail() local_unnamed_addr {
-; CHECK-LABEL: testDoubleToDoubleFail:
-; CHECK:   # %bb.0: # %entry
-; CHECK-NEXT:plxv vs34, .LCPI0_0@PCREL(0), 1
-; CHECK-NEXT:blr
-;
-; CHECK-NOPCREL-LABEL: testDoubleToDoubleFail:
-; CHECK-NOPCREL:   # %bb.0: # %entry
-; CHECK-NOPCREL-NEXT:addis r3, r2, .LCPI0_0@toc@ha
-; CHECK-NOPCREL-NEXT:addi r3, r3, .LCPI0_0@toc@l
-; CHECK-NOPCREL-NEXT:lxvx vs34, 0, r3
-; CHECK-NOPCREL-NEXT:blr
-
+; CHECK-LE-LABEL: testDoubleToDoubleFail:
+; CHECK-LE:   # %bb.0: # %entry
+; CHECK-LE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-LE-NEXT:xxsplti32dx vs34, 1, 1081435463
+; CHECK-LE-NEXT:blr
+;
+; CHECK-NOPCREL-BE-LABEL: testDoubleToDoubleFail:
+; CHECK-NOPCREL-BE:   # %bb.0: # %entry
+; CHECK-NOPCREL-BE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-NOPCREL-BE-NEXT:xxsplti32dx vs34, 1, 1081435463
+; CHECK-NOPCREL-BE-NEXT:blr
+;
+; CHECK-NOPCREL-LE-LABEL: testDoubleToDoubleFail:
+; CHECK-NOPCREL-LE:   # %bb.0: # %entry
+; CHECK-NOPCREL-LE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-NOPCREL-LE-NEXT:xxsplti32dx vs34, 1, 1081435463
+; CHECK-NOPCREL-LE-NEXT:blr
+;
+; CHECK-NOPREFIX-LABEL: testDoubleToDoubleFail:
+; CHECK-NOPREFIX:   # %bb.0: # %entry
+; CHECK-NOPREFIX-NEXT:addis r3, r2, .LCPI0_0@toc@ha
+; CHECK-NOPREFIX-NEXT:addi r3, r3, .LCPI0_0@toc@l
+; CHECK-NOPREFIX-NEXT:lxvx vs34, 0, r3
+; CHECK-NOPREFIX-NEXT:blr
+;
+; C

[PATCH] D94027: [OpenCL] Add clang extension for variadic function

2021-01-04 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia created this revision.
Anastasia added a reviewer: mantognini.
Herald added subscribers: ebevhan, kerbowa, yaxunl, nhaehnle, jvesely, 
jholewinski.
Anastasia requested review of this revision.

This feature is primarily important in C++ mode because it opens up more 
opportunities to describe metaprogramming algorithms with function types.

This is clang and not a vendor extension and therefore it is only intended for 
internal or experimental use. The full feature will require changes in vendor 
toolchains that can be provided in the future via either vendor extensions or 
Khronos extensions.

This patch is implemented on top of related extension: 
https://reviews.llvm.org/D94021


https://reviews.llvm.org/D94027

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/OpenCLExtensions.def
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Sema/SemaType.cpp
  clang/test/Misc/amdgcn.languageOptsOpenCL.cl
  clang/test/Misc/nvptx.languageOptsOpenCL.cl
  clang/test/Misc/r600.languageOptsOpenCL.cl
  clang/test/SemaOpenCL/func.cl

Index: clang/test/SemaOpenCL/func.cl
===
--- clang/test/SemaOpenCL/func.cl
+++ clang/test/SemaOpenCL/func.cl
@@ -1,18 +1,31 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple spir-unknown-unknown
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple spir-unknown-unknown -DFUNCPTREXT
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple spir-unknown-unknown -DVARARG
 
 #ifdef FUNCPTREXT
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
 #endif
+#ifdef VARARGEXT
+#pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+#endif
 
 // Variadic functions
-void vararg_f(int, ...);// expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
+void vararg_f(int, ...);
+#ifndef VARARGEXT
+// expected-error@-2 {{invalid prototype, variadic arguments are not allowed in OpenCL}}
+#endif
 void __vararg_f(int, ...);
-typedef void (*vararg_fptr_t)(int, ...);// expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
+typedef void (*vararg_fptr_t)(int, ...);
+#ifndef VARARGEXT
+// expected-error@-2 {{invalid prototype, variadic arguments are not allowed in OpenCL}}
+#endif
 #ifndef FUNCPTREXT
-// expected-error@-2 {{pointers to functions are not allowed}}
+// expected-error@-5 {{pointers to functions are not allowed}}
+#endif
+int printf(__constant const char *st, ...);
+#ifndef VARARGEXT
+// expected-error@-2 {{invalid prototype, variadic arguments are not allowed in OpenCL}}
 #endif
-int printf(__constant const char *st, ...); // expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
 
 // Struct type with function pointer field
 typedef struct s
Index: clang/test/Misc/r600.languageOptsOpenCL.cl
===
--- clang/test/Misc/r600.languageOptsOpenCL.cl
+++ clang/test/Misc/r600.languageOptsOpenCL.cl
@@ -35,6 +35,11 @@
 #endif
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
 
+#ifndef __cl_clang_variadic_functions
+#error "Missing __cl_clang_variadic_functions define"
+#endif
+#pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+
 #ifdef cl_khr_fp16
 #error "Incorrect cl_khr_fp16 define"
 #endif
Index: clang/test/Misc/nvptx.languageOptsOpenCL.cl
===
--- clang/test/Misc/nvptx.languageOptsOpenCL.cl
+++ clang/test/Misc/nvptx.languageOptsOpenCL.cl
@@ -27,6 +27,11 @@
 #endif
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
 
+#ifndef __cl_clang_variadic_functions
+#error "Missing __cl_clang_variadic_functions define"
+#endif
+#pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+
 #ifdef cl_khr_fp16
 #error "Incorrect cl_khr_fp16 define"
 #endif
Index: clang/test/Misc/amdgcn.languageOptsOpenCL.cl
===
--- clang/test/Misc/amdgcn.languageOptsOpenCL.cl
+++ clang/test/Misc/amdgcn.languageOptsOpenCL.cl
@@ -19,6 +19,11 @@
 #endif
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
 
+#ifndef __cl_clang_variadic_functions
+#error "Missing __cl_clang_variadic_functions define"
+#endif
+#pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+
 #ifndef cl_khr_fp16
 #error "Missing cl_khr_fp16 define"
 #endif
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -5019,6 +5019,7 @@
 // (s6.9.e and s6.12.5 OpenCL v2.0) except for printf.
 // We also allow here any toolchain reserved identifiers.
 if (FTI.isVariadic &&
+!S.getOpenCLOptions().isEnabled("__cl_clang_variadic_functions") &&
 !(D.getIdentifier() &&
   ((D.getId

[PATCH] D90173: [PowerPC] Exploit splat instruction xxsplti32dx in Power10

2021-01-04 Thread Albion Fung via Phabricator via cfe-commits
Conanap marked an inline comment as done.
Conanap added a comment.

initialize as a form of undef instead


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

https://reviews.llvm.org/D90173

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


[PATCH] D93986: [clang-format] Add the possibility to align assignments spanning empty lines or comments

2021-01-04 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks requested changes to this revision.
HazardyKnusperkeks added a comment.
This revision now requires changes to proceed.

In D93986#2477474 , @tinloaf wrote:

> In D93986#2477383 , @MyDeveloperDay 
> wrote:
>
>> Ideally we should add a comment to the release notes, (which you could do 
>> via a separate NFC commit if you wanted)
>
> Thank, I'll do that. But before that, I will create a revision that adds the 
> same feature for the other three alignment types.

I think it should happen in this revision so that it is atomically.

But I'm willing to be overruled.

Apart from the 2 comments and the release notes nice change! (And I really have 
to think about what my new setting will be.)




Comment at: clang/include/clang/Format/Format.h:117
+///   int b= 23;
+///
+///   int ccc  = 23;

You are adding a Tab here, or do I misinterpret this? Shouldn't that be fixed 
by clang-format itself?



Comment at: clang/lib/Format/WhitespaceManager.cpp:630
 void WhitespaceManager::alignConsecutiveAssignments() {
-  if (!Style.AlignConsecutiveAssignments)
+  TokenAlignmentStyle tas;
+  switch (Style.AlignConsecutiveAssignments) {

All other variables start with an upper case char, maybe we should keep it that 
way?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93986

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


[PATCH] D89490: Introduce __attribute__((darwin_abi))

2021-01-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Some minor nits while double-checking the attribute bits.




Comment at: clang/include/clang/Basic/AttrDocs.td:2334
+
+Here is the list of whatthis attribute supports, quoting the aformentioned
+document:





Comment at: clang/test/CodeGen/darwin_abi.c:1
+// RUN: %clang_cc1 -triple aarch64-pc-linux %s -emit-llvm -o - |FileCheck %s
+// Checks that correct LLVM IR is generated for functions that target





Comment at: clang/test/CodeGen/darwin_abi_empty_structs.cpp:4
+// empty structures unless those structures have a nontrivial destructor or
+// copy constructor." when using darwin_abi
+





Comment at: clang/test/CodeGen/darwin_abi_vaarg.c:1
+// RUN: %clang_cc1 -triple aarch64-pc-linux -emit-llvm %s -o - |FileCheck %s
+// Check that va_arg used inside a function with the darwin_abi attribute still





Comment at: clang/test/Sema/callingconv-darwin_abi.c:10
+
+void(__attribute__((darwin_abi)) * pfoo2)(void) = foo; // 
expected-warning{{incompatible function pointer types}}

You should also add some tests like:
```
__attribute__((darwin_abi)) int i; // error
__attribute__((darwin_abi(12))) void func(void); // error
```


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

https://reviews.llvm.org/D89490

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


[PATCH] D93846: [clang-format] PR16518 Add flag to suppress empty line insertion before access modifier

2021-01-04 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added inline comments.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:1221
+if (Style.EmptyLineBeforeAccessModifier &&
+PreviousLine->Last->isOneOf(tok::semi, tok::r_brace) &&
+RootToken.NewlinesBefore == 1)

thezbyg wrote:
> MyDeveloperDay wrote:
> > maybe I don't understand the logic but why is this `r_brace` and shouldn't 
> > we be looking at the "Last Non Comment" token?
> I think that the logic is to only add empty line when access modifier is 
> after member function body (`r_brace` indicates this) or declaration of 
> field/function. If this check is changed to look at "last non comment" token, 
> then empty line will be inserted in code like this:
> ```
> struct Foo {
>   int i;
>   //comment
> private:
>   int j;
> }
> ```
But with the given Name it should add an empty line there! Otherwise you should 
use an enum and not a bool to control wether a comment should suppress the 
empty line or not. Also you should make the exception(s) clear with unit tests.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:1222-1223
+PreviousLine->Last->isOneOf(tok::semi, tok::r_brace) &&
+RootToken.NewlinesBefore == 1)
+  ++Newlines;
+else if (!Style.EmptyLineBeforeAccessModifier &&

A tab?



Comment at: clang/unittests/Format/FormatTest.cpp:8612-8625
+  verifyFormat("struct foo {\n"
+   "#ifdef FOO\n"
+   "private:\n"
+   "#endif\n"
+   "  int i;\n"
+   "  int j;\n"
+   "}\n",

Just curios, any reason why the struct is repeated? I don't seem to notice a 
difference.

And by the way, you are missing the `;` at the end of the definition, I don't 
know if that affects clang-format.


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

https://reviews.llvm.org/D93846

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


[PATCH] D90173: [PowerPC] Exploit splat instruction xxsplti32dx in Power10

2021-01-04 Thread Albion Fung via Phabricator via cfe-commits
Conanap updated this revision to Diff 314439.
Conanap added a comment.

Removed unecessary ternary


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

https://reviews.llvm.org/D90173

Files:
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/test/CodeGen/PowerPC/p10-splatImm-CPload-pcrel.ll
  llvm/test/CodeGen/PowerPC/p10-splatImm32.ll

Index: llvm/test/CodeGen/PowerPC/p10-splatImm32.ll
===
--- llvm/test/CodeGen/PowerPC/p10-splatImm32.ll
+++ llvm/test/CodeGen/PowerPC/p10-splatImm32.ll
@@ -118,3 +118,39 @@
   %vecins1 = shufflevector <4 x i32> , <4 x i32> %a, <4 x i32> 
   ret <4 x i32> %vecins1
 }
+
+define dso_local <2 x double> @test_xxsplti32dx_8() {
+; CHECK-LABEL: test_xxsplti32dx_8
+; CHECK-LE-LABEL: test_xxsplti32dx_8:
+; CHECK-LE:   # %bb.0: # %entry
+; CHECK-LE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-LE-NEXT:xxsplti32dx vs34, 1, 1082660167
+; CHECK-LE-NEXT:blr
+;
+; CHECK-BE-LABEL: test_xxsplti32dx_8:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-BE-NEXT:xxsplti32dx vs34, 1, 1082660167
+; CHECK-BE-NEXT:blr
+; CHECK: blr
+entry:
+  ret <2 x double> 
+}
+
+define dso_local <8 x i16> @test_xxsplti32dx_9() {
+; CHECK-LABEL: test_xxsplti32dx_9
+; CHECK-LE-LABEL: test_xxsplti32dx_9:
+; CHECK-LE:   # %bb.0: # %entry
+; CHECK-LE-NEXT:xxsplti32dx vs34, 0, 65827
+; CHECK-LE-NEXT:xxsplti32dx vs34, 1, 23855277
+; CHECK-LE-NEXT:blr
+;
+; CHECK-BE-LABEL: test_xxsplti32dx_9:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:xxsplti32dx vs34, 0, 11338092
+; CHECK-BE-NEXT:xxsplti32dx vs34, 1, 19070977
+; CHECK-BE-NEXT:blr
+; CHECK: blr
+entry:
+  ret <8 x i16> 
+}
Index: llvm/test/CodeGen/PowerPC/p10-splatImm-CPload-pcrel.ll
===
--- llvm/test/CodeGen/PowerPC/p10-splatImm-CPload-pcrel.ll
+++ llvm/test/CodeGen/PowerPC/p10-splatImm-CPload-pcrel.ll
@@ -1,114 +1,216 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu -O2 \
-; RUN: -ppc-asm-full-reg-names -mcpu=pwr10 < %s | FileCheck %s
+; RUN: -ppc-asm-full-reg-names -mcpu=pwr10 < %s | FileCheck %s --check-prefixes=CHECK-LE
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu -O2 \
 ; RUN: -ppc-asm-full-reg-names -mcpu=pwr10 < %s | FileCheck %s \
-; RUN: --check-prefix=CHECK-NOPCREL
+; RUN: --check-prefixes=CHECK-NOPCREL-BE
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu -O2 \
 ; RUN: -mattr=-pcrelative-memops -ppc-asm-full-reg-names -mcpu=pwr10 < %s | \
-; RUN: FileCheck %s --check-prefix=CHECK-NOPCREL
+; RUN: FileCheck %s --check-prefixes=CHECK-NOPCREL-LE
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu -O2 \
 ; RUN: -mattr=-prefix-instrs -ppc-asm-full-reg-names -mcpu=pwr10 < %s | \
-; RUN: FileCheck %s --check-prefix=CHECK-NOPCREL
+; RUN: FileCheck %s --check-prefixes=CHECK-NOPREFIX
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu -O2 \
 ; RUN: -ppc-asm-full-reg-names -target-abi=elfv2 -mcpu=pwr10 < %s | \
-; RUN: FileCheck %s
+; RUN: FileCheck %s --check-prefixes=CHECK-BE
 
 define dso_local <2 x double> @testDoubleToDoubleFail() local_unnamed_addr {
-; CHECK-LABEL: testDoubleToDoubleFail:
-; CHECK:   # %bb.0: # %entry
-; CHECK-NEXT:plxv vs34, .LCPI0_0@PCREL(0), 1
-; CHECK-NEXT:blr
-;
-; CHECK-NOPCREL-LABEL: testDoubleToDoubleFail:
-; CHECK-NOPCREL:   # %bb.0: # %entry
-; CHECK-NOPCREL-NEXT:addis r3, r2, .LCPI0_0@toc@ha
-; CHECK-NOPCREL-NEXT:addi r3, r3, .LCPI0_0@toc@l
-; CHECK-NOPCREL-NEXT:lxvx vs34, 0, r3
-; CHECK-NOPCREL-NEXT:blr
-
+; CHECK-LE-LABEL: testDoubleToDoubleFail:
+; CHECK-LE:   # %bb.0: # %entry
+; CHECK-LE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-LE-NEXT:xxsplti32dx vs34, 1, 1081435463
+; CHECK-LE-NEXT:blr
+;
+; CHECK-NOPCREL-BE-LABEL: testDoubleToDoubleFail:
+; CHECK-NOPCREL-BE:   # %bb.0: # %entry
+; CHECK-NOPCREL-BE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-NOPCREL-BE-NEXT:xxsplti32dx vs34, 1, 1081435463
+; CHECK-NOPCREL-BE-NEXT:blr
+;
+; CHECK-NOPCREL-LE-LABEL: testDoubleToDoubleFail:
+; CHECK-NOPCREL-LE:   # %bb.0: # %entry
+; CHECK-NOPCREL-LE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-NOPCREL-LE-NEXT:xxsplti32dx vs34, 1, 1081435463
+; CHECK-NOPCREL-LE-NEXT:blr
+;
+; CHECK-NOPREFIX-LABEL: testDoubleToDoubleFail:
+; CHECK-NOPREFIX:   # %bb.0: # %entry
+; CHECK-NOPREFIX-NEXT:addis r3, r2, .LCPI0_0@toc@ha
+; CHECK-NOPREFIX-NEXT:addi r3, r3, .LCPI0_0@toc@l
+; CHECK-NOPREFIX-NEXT:lxvx vs34, 0, r3
+; CHECK-NOPREFIX-NEXT:blr
+;
+; CHECK-BE-LABEL: testDoubleToDoubleFail:
+; CHECK-BE:   # %bb.

[PATCH] D93597: [X86][SSE] Enable constexpr on some basic SSE intrinsics (RFC)

2021-01-04 Thread Thorsten via Phabricator via cfe-commits
tschuett added a comment.

But LLVM is C++14:
https://github.com/llvm/llvm-project/blob/main/llvm/docs/CodingStandards.rst#id13


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93597

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


[PATCH] D93597: [X86][SSE] Enable constexpr on some basic SSE intrinsics (RFC)

2021-01-04 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D93597#2477890 , @tschuett wrote:

> But LLVM is C++14:
> https://github.com/llvm/llvm-project/blob/main/llvm/docs/CodingStandards.rst#id13

The compiler _IS_ compiled with C++14, but the tests are not necessarily 
compiled as such.  The Clang compiler still supports compiling all the way down 
to C++98.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93597

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


[PATCH] D72235: [clang-tidy] new altera unroll loops check

2021-01-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp:40
+   "kernel performance could be improved by unrolling this loop with a 
"
+   "#pragma unroll directive");
+  break;





Comment at: clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp:43
+case PartiallyUnrolled:
+  // Loop already partially unrolled, do nothing
+  break;





Comment at: clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp:51-52
+   "cannot be fully unrolled; to partially unroll this loop, use "
+   "the #pragma unroll  directive");
+  return;
+}





Comment at: clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp:58
+   "full unrolling requested, but loop bounds are not known; to "
+   "partially unroll this loop, use the #pragma unroll  "
+   "directive");





Comment at: clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp:85
+return NotUnrolled;
+  return NotUnrolled;
+  }

This looks like dead code (it's still inside the switch statement).



Comment at: clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp:111
+const Expr *UnrollLoopsCheck::getCondExpr(const Stmt *Statement) {
+  if (const auto *ForLoop = dyn_cast(Statement))
+return ForLoop->getCond();

Should we also handle `CXXForRangeStmt`? I'm thinking of cases like: `for (int 
i : {1, 2, 3, 4}) {}` or other cases where there's a known bounds.



Comment at: clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp:145
+// safe.
+// The following assumes values go from 0 to Val in increments of 1.
+return Result.Val.getInt() > MaxLoopIterations;

If the check won't work too well if the value is decremented rather than 
incremented, or if it uses an induction variable that increases by something 
other than `1` or `-1`, we should probably document the limitations and 
consider whether we want to note that scenario in the code and bail out (rather 
than produce incorrect diagnostics, assuming we do).



Comment at: clang-tools-extra/docs/clang-tidy/checks/altera-unroll-loops.rst:4
+altera-unroll-loops
+=
+





Comment at: 
clang-tools-extra/test/clang-tidy/checkers/altera-unroll-loops.cpp:359
+}
+// There are no fix-its for this check

Can you also add some test cases where the loop is decrementing rather than 
incrementing, and some tests where the increment is by more than 1?


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

https://reviews.llvm.org/D72235

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


[PATCH] D89490: Introduce __attribute__((darwin_abi))

2021-01-04 Thread Ed Maste via Phabricator via cfe-commits
emaste added a comment.

> For now, only Linux/ARM64 is supported/tested.

Is there any reason this is Linux-specific (as far as support; I understand if 
it's not easy for you to test on non-Linux arm64).


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

https://reviews.llvm.org/D89490

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


[PATCH] D90173: [PowerPC] Exploit splat instruction xxsplti32dx in Power10

2021-01-04 Thread Albion Fung via Phabricator via cfe-commits
Conanap updated this revision to Diff 314443.
Conanap added a comment.

Fixed a typo that prevented successful builds


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

https://reviews.llvm.org/D90173

Files:
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/test/CodeGen/PowerPC/p10-splatImm-CPload-pcrel.ll
  llvm/test/CodeGen/PowerPC/p10-splatImm32.ll

Index: llvm/test/CodeGen/PowerPC/p10-splatImm32.ll
===
--- llvm/test/CodeGen/PowerPC/p10-splatImm32.ll
+++ llvm/test/CodeGen/PowerPC/p10-splatImm32.ll
@@ -118,3 +118,39 @@
   %vecins1 = shufflevector <4 x i32> , <4 x i32> %a, <4 x i32> 
   ret <4 x i32> %vecins1
 }
+
+define dso_local <2 x double> @test_xxsplti32dx_8() {
+; CHECK-LABEL: test_xxsplti32dx_8
+; CHECK-LE-LABEL: test_xxsplti32dx_8:
+; CHECK-LE:   # %bb.0: # %entry
+; CHECK-LE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-LE-NEXT:xxsplti32dx vs34, 1, 1082660167
+; CHECK-LE-NEXT:blr
+;
+; CHECK-BE-LABEL: test_xxsplti32dx_8:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-BE-NEXT:xxsplti32dx vs34, 1, 1082660167
+; CHECK-BE-NEXT:blr
+; CHECK: blr
+entry:
+  ret <2 x double> 
+}
+
+define dso_local <8 x i16> @test_xxsplti32dx_9() {
+; CHECK-LABEL: test_xxsplti32dx_9
+; CHECK-LE-LABEL: test_xxsplti32dx_9:
+; CHECK-LE:   # %bb.0: # %entry
+; CHECK-LE-NEXT:xxsplti32dx vs34, 0, 65827
+; CHECK-LE-NEXT:xxsplti32dx vs34, 1, 23855277
+; CHECK-LE-NEXT:blr
+;
+; CHECK-BE-LABEL: test_xxsplti32dx_9:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:xxsplti32dx vs34, 0, 11338092
+; CHECK-BE-NEXT:xxsplti32dx vs34, 1, 19070977
+; CHECK-BE-NEXT:blr
+; CHECK: blr
+entry:
+  ret <8 x i16> 
+}
Index: llvm/test/CodeGen/PowerPC/p10-splatImm-CPload-pcrel.ll
===
--- llvm/test/CodeGen/PowerPC/p10-splatImm-CPload-pcrel.ll
+++ llvm/test/CodeGen/PowerPC/p10-splatImm-CPload-pcrel.ll
@@ -1,114 +1,216 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu -O2 \
-; RUN: -ppc-asm-full-reg-names -mcpu=pwr10 < %s | FileCheck %s
+; RUN: -ppc-asm-full-reg-names -mcpu=pwr10 < %s | FileCheck %s --check-prefixes=CHECK-LE
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu -O2 \
 ; RUN: -ppc-asm-full-reg-names -mcpu=pwr10 < %s | FileCheck %s \
-; RUN: --check-prefix=CHECK-NOPCREL
+; RUN: --check-prefixes=CHECK-NOPCREL-BE
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu -O2 \
 ; RUN: -mattr=-pcrelative-memops -ppc-asm-full-reg-names -mcpu=pwr10 < %s | \
-; RUN: FileCheck %s --check-prefix=CHECK-NOPCREL
+; RUN: FileCheck %s --check-prefixes=CHECK-NOPCREL-LE
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu -O2 \
 ; RUN: -mattr=-prefix-instrs -ppc-asm-full-reg-names -mcpu=pwr10 < %s | \
-; RUN: FileCheck %s --check-prefix=CHECK-NOPCREL
+; RUN: FileCheck %s --check-prefixes=CHECK-NOPREFIX
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu -O2 \
 ; RUN: -ppc-asm-full-reg-names -target-abi=elfv2 -mcpu=pwr10 < %s | \
-; RUN: FileCheck %s
+; RUN: FileCheck %s --check-prefixes=CHECK-BE
 
 define dso_local <2 x double> @testDoubleToDoubleFail() local_unnamed_addr {
-; CHECK-LABEL: testDoubleToDoubleFail:
-; CHECK:   # %bb.0: # %entry
-; CHECK-NEXT:plxv vs34, .LCPI0_0@PCREL(0), 1
-; CHECK-NEXT:blr
-;
-; CHECK-NOPCREL-LABEL: testDoubleToDoubleFail:
-; CHECK-NOPCREL:   # %bb.0: # %entry
-; CHECK-NOPCREL-NEXT:addis r3, r2, .LCPI0_0@toc@ha
-; CHECK-NOPCREL-NEXT:addi r3, r3, .LCPI0_0@toc@l
-; CHECK-NOPCREL-NEXT:lxvx vs34, 0, r3
-; CHECK-NOPCREL-NEXT:blr
-
+; CHECK-LE-LABEL: testDoubleToDoubleFail:
+; CHECK-LE:   # %bb.0: # %entry
+; CHECK-LE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-LE-NEXT:xxsplti32dx vs34, 1, 1081435463
+; CHECK-LE-NEXT:blr
+;
+; CHECK-NOPCREL-BE-LABEL: testDoubleToDoubleFail:
+; CHECK-NOPCREL-BE:   # %bb.0: # %entry
+; CHECK-NOPCREL-BE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-NOPCREL-BE-NEXT:xxsplti32dx vs34, 1, 1081435463
+; CHECK-NOPCREL-BE-NEXT:blr
+;
+; CHECK-NOPCREL-LE-LABEL: testDoubleToDoubleFail:
+; CHECK-NOPCREL-LE:   # %bb.0: # %entry
+; CHECK-NOPCREL-LE-NEXT:xxsplti32dx vs34, 0, -1374389535
+; CHECK-NOPCREL-LE-NEXT:xxsplti32dx vs34, 1, 1081435463
+; CHECK-NOPCREL-LE-NEXT:blr
+;
+; CHECK-NOPREFIX-LABEL: testDoubleToDoubleFail:
+; CHECK-NOPREFIX:   # %bb.0: # %entry
+; CHECK-NOPREFIX-NEXT:addis r3, r2, .LCPI0_0@toc@ha
+; CHECK-NOPREFIX-NEXT:addi r3, r3, .LCPI0_0@toc@l
+; CHECK-NOPREFIX-NEXT:lxvx vs34, 0, r3
+; CHECK-NOPREFIX-NEXT:blr
+;
+; CHECK-BE-LABEL: testDoubleToDoubleFail:
+; CHE

[PATCH] D90507: [Driver] Add DWARF64 flag: -gdwarf64

2021-01-04 Thread Alexander Yermolovich via Phabricator via cfe-commits
ayermolo added a comment.

@dblaikie @MaskRay Anything else do I need to change, all good?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90507

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


[PATCH] D93688: [ASTMatchers] Ensure that we can match inside lambdas

2021-01-04 Thread Stephen Kelly via Phabricator via cfe-commits
steveire updated this revision to Diff 314445.
steveire added a comment.

Update


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93688

Files:
  clang/include/clang/ASTMatchers/ASTMatchersInternal.h
  clang/lib/ASTMatchers/ASTMatchFinder.cpp
  clang/lib/ASTMatchers/ASTMatchersInternal.cpp
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -3065,6 +3065,33 @@
   traverse(TK_IgnoreUnlessSpelledInSource,
functionDecl(hasName("func14"), hasDescendant(floatLiteral(,
   langCxx20OrLater()));
+
+  Code = R"cpp(
+void foo() {
+int explicit_captured = 0;
+int implicit_captured = 0;
+auto l = [&, explicit_captured](int i) {
+if (i || explicit_captured || implicit_captured) return;
+};
+}
+)cpp";
+
+  EXPECT_TRUE(matches(Code, traverse(TK_AsIs, ifStmt(;
+  EXPECT_TRUE(
+  matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, ifStmt(;
+
+  auto lambdaExplicitCapture = declRefExpr(
+  to(varDecl(hasName("explicit_captured"))), unless(hasAncestor(ifStmt(;
+  auto lambdaImplicitCapture = declRefExpr(
+  to(varDecl(hasName("implicit_captured"))), unless(hasAncestor(ifStmt(;
+
+  EXPECT_TRUE(matches(Code, traverse(TK_AsIs, lambdaExplicitCapture)));
+  EXPECT_TRUE(matches(
+  Code, traverse(TK_IgnoreUnlessSpelledInSource, lambdaExplicitCapture)));
+
+  EXPECT_TRUE(matches(Code, traverse(TK_AsIs, lambdaImplicitCapture)));
+  EXPECT_FALSE(matches(
+  Code, traverse(TK_IgnoreUnlessSpelledInSource, lambdaImplicitCapture)));
 }
 
 TEST(IgnoringImpCasts, MatchesImpCasts) {
Index: clang/lib/ASTMatchers/ASTMatchersInternal.cpp
===
--- clang/lib/ASTMatchers/ASTMatchersInternal.cpp
+++ clang/lib/ASTMatchers/ASTMatchersInternal.cpp
@@ -293,6 +293,10 @@
   Finder->IsMatchingInASTNodeNotSpelledInSource())
 return false;
 
+  if (!Finder->isTraversalIgnoringImplicitNodes() &&
+  Finder->IsMatchingInASTNodeNotAsIs())
+return false;
+
   auto N =
   Finder->getASTContext().getParentMapContext().traverseIgnored(DynNode);
 
@@ -317,6 +321,10 @@
   Finder->IsMatchingInASTNodeNotSpelledInSource())
 return false;
 
+  if (!Finder->isTraversalIgnoringImplicitNodes() &&
+  Finder->IsMatchingInASTNodeNotAsIs())
+return false;
+
   auto N =
   Finder->getASTContext().getParentMapContext().traverseIgnored(DynNode);
 
Index: clang/lib/ASTMatchers/ASTMatchFinder.cpp
===
--- clang/lib/ASTMatchers/ASTMatchFinder.cpp
+++ clang/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -475,6 +475,55 @@
 }
   }
   return true;
+} else if (auto *LE = dyn_cast(S)) {
+  for (auto I : llvm::zip(LE->captures(), LE->capture_inits())) {
+auto C = std::get<0>(I);
+ASTNodeNotSpelledInSourceScope RAII(
+this, TraversingASTNodeNotSpelledInSource || !C.isExplicit());
+TraverseLambdaCapture(LE, &C, std::get<1>(I));
+  }
+
+  {
+ASTNodeNotSpelledInSourceScope RAII(this, true);
+TraverseDecl(LE->getLambdaClass());
+  }
+  {
+ASTNodeNotAsIsSourceScope RAII(this, true);
+
+// We need to poke around to find the bits that might be explicitly
+// written.
+TypeLoc TL = LE->getCallOperator()->getTypeSourceInfo()->getTypeLoc();
+FunctionProtoTypeLoc Proto = TL.getAsAdjusted();
+
+if (auto *TPL = LE->getTemplateParameterList()) {
+  for (NamedDecl *D : *TPL) {
+TraverseDecl(D);
+  }
+  if (Expr *RequiresClause = TPL->getRequiresClause()) {
+TraverseStmt(RequiresClause);
+  }
+}
+
+if (LE->hasExplicitParameters()) {
+  // Visit parameters.
+  for (ParmVarDecl *Param : Proto.getParams())
+TraverseDecl(Param);
+}
+
+auto *T = Proto.getTypePtr();
+for (const auto &E : T->exceptions())
+  TraverseType(E);
+
+if (Expr *NE = T->getNoexceptExpr())
+  TraverseStmt(NE, Queue);
+
+if (LE->hasExplicitResultType())
+  TraverseTypeLoc(Proto.getReturnLoc());
+TraverseStmt(LE->getTrailingRequiresClause());
+
+TraverseStmt(LE->getBody());
+  }
+  return true;
 }
 return RecursiveASTVisitor::dataTraverseNode(S, Queue);
   }
@@ -617,6 +666,9 @@
   bool IsMatchingInASTNodeNotSpelledInSource() const override {
 return TraversingASTNodeNotSpelledInSource;
   }
+  bool IsMatchingInASTNodeNotAsIs() const override {
+return TraversingASTNodeNotAsIs;
+  }
 
   bool TraverseTemplateInstantia

[PATCH] D93688: [ASTMatchers] Ensure that we can match inside lambdas

2021-01-04 Thread Stephen Kelly via Phabricator via cfe-commits
steveire updated this revision to Diff 314446.
steveire marked 2 inline comments as done.
steveire added a comment.

Update


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93688

Files:
  clang/include/clang/ASTMatchers/ASTMatchersInternal.h
  clang/lib/ASTMatchers/ASTMatchFinder.cpp
  clang/lib/ASTMatchers/ASTMatchersInternal.cpp
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -3065,6 +3065,33 @@
   traverse(TK_IgnoreUnlessSpelledInSource,
functionDecl(hasName("func14"), hasDescendant(floatLiteral(,
   langCxx20OrLater()));
+
+  Code = R"cpp(
+void foo() {
+int explicit_captured = 0;
+int implicit_captured = 0;
+auto l = [&, explicit_captured](int i) {
+if (i || explicit_captured || implicit_captured) return;
+};
+}
+)cpp";
+
+  EXPECT_TRUE(matches(Code, traverse(TK_AsIs, ifStmt(;
+  EXPECT_TRUE(
+  matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, ifStmt(;
+
+  auto lambdaExplicitCapture = declRefExpr(
+  to(varDecl(hasName("explicit_captured"))), unless(hasAncestor(ifStmt(;
+  auto lambdaImplicitCapture = declRefExpr(
+  to(varDecl(hasName("implicit_captured"))), unless(hasAncestor(ifStmt(;
+
+  EXPECT_TRUE(matches(Code, traverse(TK_AsIs, lambdaExplicitCapture)));
+  EXPECT_TRUE(matches(
+  Code, traverse(TK_IgnoreUnlessSpelledInSource, lambdaExplicitCapture)));
+
+  EXPECT_TRUE(matches(Code, traverse(TK_AsIs, lambdaImplicitCapture)));
+  EXPECT_FALSE(matches(
+  Code, traverse(TK_IgnoreUnlessSpelledInSource, lambdaImplicitCapture)));
 }
 
 TEST(IgnoringImpCasts, MatchesImpCasts) {
Index: clang/lib/ASTMatchers/ASTMatchersInternal.cpp
===
--- clang/lib/ASTMatchers/ASTMatchersInternal.cpp
+++ clang/lib/ASTMatchers/ASTMatchersInternal.cpp
@@ -293,6 +293,10 @@
   Finder->IsMatchingInASTNodeNotSpelledInSource())
 return false;
 
+  if (!Finder->isTraversalIgnoringImplicitNodes() &&
+  Finder->IsMatchingInASTNodeNotAsIs())
+return false;
+
   auto N =
   Finder->getASTContext().getParentMapContext().traverseIgnored(DynNode);
 
@@ -317,6 +321,10 @@
   Finder->IsMatchingInASTNodeNotSpelledInSource())
 return false;
 
+  if (!Finder->isTraversalIgnoringImplicitNodes() &&
+  Finder->IsMatchingInASTNodeNotAsIs())
+return false;
+
   auto N =
   Finder->getASTContext().getParentMapContext().traverseIgnored(DynNode);
 
Index: clang/lib/ASTMatchers/ASTMatchFinder.cpp
===
--- clang/lib/ASTMatchers/ASTMatchFinder.cpp
+++ clang/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -475,6 +475,55 @@
 }
   }
   return true;
+} else if (auto *LE = dyn_cast(S)) {
+  for (auto I : llvm::zip(LE->captures(), LE->capture_inits())) {
+auto C = std::get<0>(I);
+ASTNodeNotSpelledInSourceScope RAII(
+this, TraversingASTNodeNotSpelledInSource || !C.isExplicit());
+TraverseLambdaCapture(LE, &C, std::get<1>(I));
+  }
+
+  {
+ASTNodeNotSpelledInSourceScope RAII(this, true);
+TraverseDecl(LE->getLambdaClass());
+  }
+  {
+ASTNodeNotAsIsSourceScope RAII(this, true);
+
+// We need to poke around to find the bits that might be explicitly
+// written.
+TypeLoc TL = LE->getCallOperator()->getTypeSourceInfo()->getTypeLoc();
+FunctionProtoTypeLoc Proto = TL.getAsAdjusted();
+
+if (auto *TPL = LE->getTemplateParameterList()) {
+  for (NamedDecl *D : *TPL) {
+TraverseDecl(D);
+  }
+  if (Expr *RequiresClause = TPL->getRequiresClause()) {
+TraverseStmt(RequiresClause);
+  }
+}
+
+if (LE->hasExplicitParameters()) {
+  // Visit parameters.
+  for (ParmVarDecl *Param : Proto.getParams())
+TraverseDecl(Param);
+}
+
+const auto *T = Proto.getTypePtr();
+for (const auto &E : T->exceptions())
+  TraverseType(E);
+
+if (Expr *NE = T->getNoexceptExpr())
+  TraverseStmt(NE, Queue);
+
+if (LE->hasExplicitResultType())
+  TraverseTypeLoc(Proto.getReturnLoc());
+TraverseStmt(LE->getTrailingRequiresClause());
+
+TraverseStmt(LE->getBody());
+  }
+  return true;
 }
 return RecursiveASTVisitor::dataTraverseNode(S, Queue);
   }
@@ -617,6 +666,9 @@
   bool IsMatchingInASTNodeNotSpelledInSource() const override {
 return TraversingASTNodeNotSpelledInSource;
   }
+  bool IsMatchingInASTNodeNotAsIs() const override {
+return TraversingASTNode

[PATCH] D92936: [Sema] Fix deleted function problem in implicitly movable test

2021-01-04 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added a comment.

In D92936#2477764 , @dmajor wrote:

> Before the revert, our bots hit the following issue where we only error out 
> when `-Wall` is given, so there's definitely something strange going on.

https://godbolt.org/z/P1dv9f
Yeah, I see what's happening here. `-Wall` turns on `-Wreturn-std-move`, which 
in C++17 mode does a preliminary overload resolution "as if by std::move" just 
to see what would happen. This preliminary overload resolution finds a deleted 
function, and apparently this is a hard error — we're not doing whatever dance 
Clang requires in order to suppress/defer diagnostics during "speculative" 
compilation. (The difficulty of speculatively compiling things is one of my pet 
peeves with Clang.)

Here's an example using Clang trunk to produce a hard error from the guts of 
`-Wreturn-std-move` (left-hand pane) but no error if you don't enable that 
warning (right-hand pane).
https://godbolt.org/z/e6zPsb
However, this might be Clang-trunk-including-Yang's-patch, I'm not sure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92936

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


[PATCH] D93688: [ASTMatchers] Ensure that we can match inside lambdas

2021-01-04 Thread Stephen Kelly via Phabricator via cfe-commits
steveire marked an inline comment as done.
steveire added inline comments.



Comment at: clang/lib/ASTMatchers/ASTMatchFinder.cpp:526
+TraverseStmt(LE->getTrailingRequiresClause());
+
+TraverseStmt(LE->getBody());

aaron.ballman wrote:
> Do we also need to traverse attributes of the lambda?
At least RAV doesn't do so. It would be a new feature which is orthogonal to 
this MR/patch.



Comment at: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:3069
+
+  Code = R"cpp(
+void foo() {

aaron.ballman wrote:
> Do we have other test coverage for the rest of lambda matching, or should you 
> add coverage for things like parameters, trailing requires clauses, etc?
Yep, there's other lambda-related tests higher up in this test function.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93688

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


[PATCH] D93988: [ASTMatchers] Make tests explicit about mode-dependence

2021-01-04 Thread Stephen Kelly via Phabricator via cfe-commits
steveire added a comment.

In D93988#2477602 , @aaron.ballman 
wrote:

> Could you give me a bit more background about why you want to make this 
> change?

This change makes it explicit so that we can see which tests work in only one 
mode, and if we want to change the default, this part is already compatible 
with the change.

But, this is not very important.

> There are tests which I would expect to match in any traversal mode (e.g., 
> `EXPECT_TRUE(matches("class X {};", traverse(TK_AsIs, HasClassX)));`)

Given that

  HasClassX = recordDecl(has(recordDecl(hasName("X"

which matches the implicit `RecordDecl` within the `RecordDecl`, it shouldn't 
match in `Ignore...` mode.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93988

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


[PATCH] D94029: [clang-tidy] Add extra tests

2021-01-04 Thread Stephen Kelly via Phabricator via cfe-commits
steveire created this revision.
steveire added a reviewer: aaron.ballman.
Herald added a subscriber: xazax.hun.
steveire requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

By default, check_clang_tidy runs tests in c++11-or-later mode.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94029

Files:
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-suspicious-semicolon-constexpr.cpp
  clang-tools-extra/test/clang-tidy/checkers/bugprone-unused-raii.cpp
  clang-tools-extra/test/clang-tidy/checkers/bugprone-use-after-move.cpp
  clang-tools-extra/test/clang-tidy/checkers/modernize-raw-string-literal.cpp
  clang-tools-extra/test/clang-tidy/checkers/modernize-use-nodiscard.cpp
  
clang-tools-extra/test/clang-tidy/checkers/performance-unnecessary-value-param-header.cpp
  
clang-tools-extra/test/clang-tidy/checkers/readability-avoid-const-params-in-decls.cpp
  clang-tools-extra/test/clang-tidy/checkers/readability-delete-null-pointer.cpp
  
clang-tools-extra/test/clang-tidy/checkers/readability-redundant-string-init.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-redundant-string-init.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/readability-redundant-string-init.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/readability-redundant-string-init.cpp
@@ -1,9 +1,8 @@
-// RUN: %check_clang_tidy -std=c++11,c++14 %s readability-redundant-string-init %t \
+// RUN: %check_clang_tidy %s readability-redundant-string-init %t \
 // RUN:   -config="{CheckOptions: \
 // RUN: [{key: readability-redundant-string-init.StringNames, \
 // RUN:   value: '::std::basic_string;::std::basic_string_view;our::TestString'}] \
 // RUN: }"
-// FIXME: Fix the checker to work in C++17 mode.
 
 namespace std {
 template 
Index: clang-tools-extra/test/clang-tidy/checkers/readability-delete-null-pointer.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/readability-delete-null-pointer.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/readability-delete-null-pointer.cpp
@@ -2,6 +2,41 @@
 
 #define NULL 0
 
+template 
+struct Templ {
+  void foo() {
+// t1
+if (mem) // t2
+  delete mem;
+// CHECK-MESSAGES: :[[@LINE-2]]:5: warning: 'if' statement is unnecessary;
+// CHECK-FIXES: // t1
+// CHECK-FIXES-NEXT: {{^}}// t2
+// CHECK-FIXES-NEXT: delete mem;
+  }
+  T mem;
+};
+
+template 
+struct TemplPtr {
+  void foo() {
+// t3
+if (mem) // t4
+  delete mem;
+// CHECK-MESSAGES: :[[@LINE-2]]:5: warning: 'if' statement is unnecessary;
+// CHECK-FIXES: // t3
+// CHECK-FIXES-NEXT: {{^}}// t4
+// CHECK-FIXES-NEXT: delete mem;
+  }
+  T *mem;
+};
+
+void instantiate() {
+  Templ ti2;
+  ti2.foo();
+  TemplPtr ti3;
+  ti3.foo();
+}
+
 void f() {
   int *ps = 0;
   if (ps /**/) // #0
Index: clang-tools-extra/test/clang-tidy/checkers/readability-avoid-const-params-in-decls.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/readability-avoid-const-params-in-decls.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/readability-avoid-const-params-in-decls.cpp
@@ -81,6 +81,29 @@
 };
 FooT f(1);
 
+template 
+struct BingT {
+  BingT(const T i);
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: parameter 'i'
+  // CHECK-FIXES: BingT(T i);
+
+  void operator()(const T i);
+  // CHECK-MESSAGES: :[[@LINE-1]]:19: warning: parameter 'i'
+  // CHECK-FIXES: void operator()(T i);
+};
+BingT f2(1);
+
+template 
+struct NeverInstantiatedT {
+  NeverInstantiatedT(const T i);
+  // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: parameter 'i'
+  // CHECK-FIXES: NeverInstantiatedT(T i);
+
+  void operator()(const T i);
+  // CHECK-MESSAGES: :[[@LINE-1]]:19: warning: parameter 'i'
+  // CHECK-FIXES: void operator()(T i);
+};
+
 // Do not match on definitions
 void NF1(const int i) {}
 void NF2(const int *const i) {}
@@ -109,6 +132,13 @@
   void operator()(const int i) {}
 };
 BarT b(1);
+template 
+struct BatT {
+  BatT(const T i) {}
+
+  void operator()(const T i) {}
+};
+BatT b2(1);
 
 // Do not match on other stuff
 void NF(const alias_type& i);
Index: clang-tools-extra/test/clang-tidy/checkers/performance-unnecessary-value-param-header.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/performance-unnecessary-value-param-header.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/performance-unnecessary-value-param-header.cpp
@@ -1,9 +1,8 @@
 // RUN: rm -rf %t
 // RUN: mkdir %t
 // RUN: cp %S/Inputs/performance-unnecessary-value-param/header.h %t/header.h
-// RUN: %check_clang_tidy -std=c++11 %s performance-unnecessary-value-param %t/temp -- -- -I %t
+// RUN: %check_clang_tidy %s performance-unnecessary-value-param %t/temp -

[PATCH] D94030: [ASTMatchers] Fix traversal matchers with explicit and defaulted methods

2021-01-04 Thread Stephen Kelly via Phabricator via cfe-commits
steveire created this revision.
steveire added a reviewer: aaron.ballman.
steveire 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/D94030

Files:
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/include/clang/ASTMatchers/ASTMatchersInternal.h
  clang/lib/ASTMatchers/ASTMatchFinder.cpp
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -2706,6 +2706,52 @@
 EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
 EXPECT_FALSE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
   }
+  Code = R"cpp(
+struct A
+{
+~A();
+private:
+int i;
+};
+
+A::~A() = default;
+)cpp";
+  {
+auto M = cxxDestructorDecl(isDefaulted(),
+   ofClass(cxxRecordDecl(has(fieldDecl();
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_TRUE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
+  Code = R"cpp(
+struct S
+{
+static constexpr bool getTrue() { return true; }
+};
+
+struct A
+{
+explicit(S::getTrue()) A();
+};
+
+A::A() = default;
+)cpp";
+  {
+EXPECT_TRUE(matchesConditionally(
+Code,
+traverse(TK_AsIs,
+ cxxConstructorDecl(
+ isDefaulted(),
+ hasExplicitSpecifier(expr(ignoringImplicit(
+ callExpr(has(ignoringImplicit(declRefExpr(),
+true, {"-std=c++20"}));
+EXPECT_TRUE(matchesConditionally(
+Code,
+traverse(TK_IgnoreUnlessSpelledInSource,
+ cxxConstructorDecl(
+ isDefaulted(),
+ hasExplicitSpecifier(callExpr(has(declRefExpr()),
+true, {"-std=c++20"}));
+  }
 }
 
 template 
Index: clang/lib/ASTMatchers/ASTMatchFinder.cpp
===
--- clang/lib/ASTMatchers/ASTMatchFinder.cpp
+++ clang/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -666,6 +666,13 @@
   bool IsMatchingInASTNodeNotSpelledInSource() const override {
 return TraversingASTNodeNotSpelledInSource;
   }
+  bool IsMatchingChildrenNotSpelledInSource() const override {
+return TraversingASTChildrenNotSpelledInSource;
+  }
+  void SetMatchingChildrenNotSpelledInSource(bool Set) override {
+TraversingASTChildrenNotSpelledInSource = Set;
+  }
+
   bool IsMatchingInASTNodeNotAsIs() const override {
 return TraversingASTNodeNotAsIs;
   }
@@ -719,20 +726,6 @@
 bool MB;
   };
 
-  struct ASTChildrenNotSpelledInSource {
-ASTChildrenNotSpelledInSource(MatchASTVisitor *V, bool B)
-: MV(V), MB(V->TraversingASTChildrenNotSpelledInSource) {
-  V->TraversingASTChildrenNotSpelledInSource = B;
-}
-~ASTChildrenNotSpelledInSource() {
-  MV->TraversingASTChildrenNotSpelledInSource = MB;
-}
-
-  private:
-MatchASTVisitor *MV;
-bool MB;
-  };
-
   class TimeBucketRegion {
   public:
 TimeBucketRegion() : Bucket(nullptr) {}
@@ -1168,7 +1161,7 @@
   }
 
   ASTNodeNotSpelledInSourceScope RAII1(this, ScopedTraversal);
-  ASTChildrenNotSpelledInSource RAII2(this, ScopedChildren);
+  ASTChildrenNotSpelledInSourceScope RAII2(this, ScopedChildren);
 
   match(*DeclNode);
   return RecursiveASTVisitor::TraverseDecl(DeclNode);
Index: clang/include/clang/ASTMatchers/ASTMatchersInternal.h
===
--- clang/include/clang/ASTMatchers/ASTMatchersInternal.h
+++ clang/include/clang/ASTMatchers/ASTMatchersInternal.h
@@ -723,6 +723,9 @@
 
   virtual bool IsMatchingInASTNodeNotSpelledInSource() const = 0;
 
+  virtual bool IsMatchingChildrenNotSpelledInSource() const = 0;
+  virtual void SetMatchingChildrenNotSpelledInSource(bool Set) = 0;
+
   virtual bool IsMatchingInASTNodeNotAsIs() const = 0;
 
   bool isTraversalIgnoringImplicitNodes() const;
@@ -744,6 +747,20 @@
  AncestorMatchMode MatchMode) = 0;
 };
 
+struct ASTChildrenNotSpelledInSourceScope {
+  ASTChildrenNotSpelledInSourceScope(ASTMatchFinder *V, bool B)
+  : MV(V), MB(V->IsMatchingChildrenNotSpelledInSource()) {
+V->SetMatchingChildrenNotSpelledInSource(B);
+  }
+  ~ASTChildrenNotSpelledInSourceScope() {
+MV->SetMatchingChildrenNotSpelledInSource(MB);
+  }
+
+private:
+  ASTMatchFinder *MV;
+  bool MB;
+};
+
 /// Specialization of the conversion functions for QualType.
 ///
 /// This specialization provides the Matcher->Matcher
Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -5490,

[PATCH] D94031: [ASTMatchers] Fix child traversal over range-for loops

2021-01-04 Thread Stephen Kelly via Phabricator via cfe-commits
steveire created this revision.
steveire added a reviewer: aaron.ballman.
steveire 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/D94031

Files:
  clang/lib/ASTMatchers/ASTMatchFinder.cpp
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp


Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -2537,7 +2537,9 @@
 int arr[2];
 for (auto i : arr)
 {
-
+  if (true)
+  {
+  }
 }
   }
   )cpp";
@@ -2580,6 +2582,33 @@
 EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
 EXPECT_TRUE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
   }
+  {
+auto M = cxxForRangeStmt(hasDescendant(ifStmt()));
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_TRUE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
+  {
+EXPECT_TRUE(matches(
+Code, traverse(TK_AsIs, cxxForRangeStmt(has(declStmt(
+hasSingleDecl(varDecl(hasName("i");
+EXPECT_TRUE(
+matches(Code, traverse(TK_IgnoreUnlessSpelledInSource,
+   cxxForRangeStmt(has(varDecl(hasName("i")));
+  }
+  {
+EXPECT_TRUE(matches(
+Code, traverse(TK_AsIs, cxxForRangeStmt(has(declStmt(hasSingleDecl(
+varDecl(hasInitializer(declRefExpr(
+to(varDecl(hasName("arr");
+EXPECT_TRUE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource,
+   cxxForRangeStmt(has(declRefExpr(
+   to(varDecl(hasName("arr");
+  }
+  {
+auto M = cxxForRangeStmt(has(compoundStmt()));
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_TRUE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
   {
 auto M = binaryOperator(hasOperatorName("!="));
 EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
Index: clang/lib/ASTMatchers/ASTMatchFinder.cpp
===
--- clang/lib/ASTMatchers/ASTMatchFinder.cpp
+++ clang/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -236,6 +236,17 @@
 ScopedIncrement ScopedDepth(&CurrentDepth);
 return traverse(TAL);
   }
+  bool TraverseCXXForRangeStmt(CXXForRangeStmt *Node) {
+if (!Finder->isTraversalIgnoringImplicitNodes())
+  return VisitorBase::TraverseCXXForRangeStmt(Node);
+if (!Node)
+  return true;
+ScopedIncrement ScopedDepth(&CurrentDepth);
+if (!match(*Node->getLoopVariable()) || !match(*Node->getRangeInit()) ||
+!match(*Node->getBody()))
+  return false;
+return VisitorBase::TraverseStmt(Node->getBody());
+  }
   bool TraverseLambdaExpr(LambdaExpr *Node) {
 if (!Finder->isTraversalIgnoringImplicitNodes())
   return VisitorBase::TraverseLambdaExpr(Node);
@@ -575,8 +586,6 @@
 
 if (isTraversalIgnoringImplicitNodes()) {
   IgnoreImplicitChildren = true;
-  if (Node.get())
-ScopedTraversal = true;
 }
 
 ASTNodeNotSpelledInSourceScope RAII(this, ScopedTraversal);


Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -2537,7 +2537,9 @@
 int arr[2];
 for (auto i : arr)
 {
-
+  if (true)
+  {
+  }
 }
   }
   )cpp";
@@ -2580,6 +2582,33 @@
 EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
 EXPECT_TRUE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
   }
+  {
+auto M = cxxForRangeStmt(hasDescendant(ifStmt()));
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_TRUE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
+  {
+EXPECT_TRUE(matches(
+Code, traverse(TK_AsIs, cxxForRangeStmt(has(declStmt(
+hasSingleDecl(varDecl(hasName("i");
+EXPECT_TRUE(
+matches(Code, traverse(TK_IgnoreUnlessSpelledInSource,
+   cxxForRangeStmt(has(varDecl(hasName("i")));
+  }
+  {
+EXPECT_TRUE(matches(
+Code, traverse(TK_AsIs, cxxForRangeStmt(has(declStmt(hasSingleDecl(
+varDecl(hasInitializer(declRefExpr(
+to(varDecl(hasName("arr");
+EXPECT_TRUE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource,
+   cxxForRangeStmt(has(declRefExpr(
+   to(varDecl(hasName("arr");
+  }
+  {
+auto M =

[PATCH] D94032: [ASTMatchers] Omit methods from explicit template instantations

2021-01-04 Thread Stephen Kelly via Phabricator via cfe-commits
steveire created this revision.
steveire added a reviewer: aaron.ballman.
steveire 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/D94032

Files:
  clang/lib/ASTMatchers/ASTMatchFinder.cpp
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp


Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -2201,10 +2201,18 @@
   TemplStruct() {}
   ~TemplStruct() {}
 
+  void outOfLine(T);
+
 private:
   T m_t;
 };
 
+template
+void TemplStruct::outOfLine(T)
+{
+
+}
+
 template
 T timesTwo(T input)
 {
@@ -2278,6 +2286,7 @@
 EXPECT_TRUE(matches(Code, traverse(TK_AsIs, MTempl)));
 // TODO: If we could match on explicit instantiations of function 
templates,
 // this would be EXPECT_TRUE.
+// See Sema::ActOnExplicitInstantiation,
 EXPECT_FALSE(
 matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, MTempl)));
   }
@@ -2324,6 +2333,14 @@
 EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
 EXPECT_FALSE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
   }
+  {
+// Instantiated, out-of-line methods are not matchable
+auto M =
+cxxMethodDecl(hasName("outOfLine"), isDefinition(),
+  hasParameter(0, 
parmVarDecl(hasType(asString("float");
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_FALSE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
   {
 // Explicit specialization is written in source and it matches:
 auto M = classTemplateSpecializationDecl(
Index: clang/lib/ASTMatchers/ASTMatchFinder.cpp
===
--- clang/lib/ASTMatchers/ASTMatchFinder.cpp
+++ clang/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -1167,6 +1167,8 @@
   } else if (const auto *FD = dyn_cast(DeclNode)) {
 if (FD->isDefaulted())
   ScopedChildren = true;
+if (FD->isTemplateInstantiation())
+  ScopedTraversal = true;
   }
 
   ASTNodeNotSpelledInSourceScope RAII1(this, ScopedTraversal);


Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -2201,10 +2201,18 @@
   TemplStruct() {}
   ~TemplStruct() {}
 
+  void outOfLine(T);
+
 private:
   T m_t;
 };
 
+template
+void TemplStruct::outOfLine(T)
+{
+
+}
+
 template
 T timesTwo(T input)
 {
@@ -2278,6 +2286,7 @@
 EXPECT_TRUE(matches(Code, traverse(TK_AsIs, MTempl)));
 // TODO: If we could match on explicit instantiations of function templates,
 // this would be EXPECT_TRUE.
+// See Sema::ActOnExplicitInstantiation,
 EXPECT_FALSE(
 matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, MTempl)));
   }
@@ -2324,6 +2333,14 @@
 EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
 EXPECT_FALSE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
   }
+  {
+// Instantiated, out-of-line methods are not matchable
+auto M =
+cxxMethodDecl(hasName("outOfLine"), isDefinition(),
+  hasParameter(0, parmVarDecl(hasType(asString("float");
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_FALSE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
   {
 // Explicit specialization is written in source and it matches:
 auto M = classTemplateSpecializationDecl(
Index: clang/lib/ASTMatchers/ASTMatchFinder.cpp
===
--- clang/lib/ASTMatchers/ASTMatchFinder.cpp
+++ clang/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -1167,6 +1167,8 @@
   } else if (const auto *FD = dyn_cast(DeclNode)) {
 if (FD->isDefaulted())
   ScopedChildren = true;
+if (FD->isTemplateInstantiation())
+  ScopedTraversal = true;
   }
 
   ASTNodeNotSpelledInSourceScope RAII1(this, ScopedTraversal);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D93014: [Clang] Add AArch64 VCMLA LANE variants.

2021-01-04 Thread Florian Hahn via Phabricator via cfe-commits
fhahn updated this revision to Diff 314452.
fhahn added a comment.

Add tests for rotated lane variants.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93014

Files:
  clang/include/clang/Basic/arm_neon.td
  clang/test/CodeGen/aarch64-neon-vcmla.c
  clang/utils/TableGen/NeonEmitter.cpp

Index: clang/utils/TableGen/NeonEmitter.cpp
===
--- clang/utils/TableGen/NeonEmitter.cpp
+++ clang/utils/TableGen/NeonEmitter.cpp
@@ -1690,14 +1690,18 @@
 
 std::pair Intrinsic::DagEmitter::emitDagDupTyped(DagInit *DI) {
   assert_with_loc(DI->getNumArgs() == 2, "dup_typed() expects two arguments");
-  std::pair A =
-  emitDagArg(DI->getArg(0), std::string(DI->getArgNameStr(0)));
   std::pair B =
   emitDagArg(DI->getArg(1), std::string(DI->getArgNameStr(1)));
   assert_with_loc(B.first.isScalar(),
   "dup_typed() requires a scalar as the second argument");
+  Type T;
+  // If the type argument is a constant string, construct the type directly.
+  if (StringInit *SI = dyn_cast(DI->getArg(0))) {
+T = Type::fromTypedefName(SI->getAsUnquotedString());
+assert_with_loc(!T.isVoid(), "Unknown typedef");
+  } else
+T = emitDagArg(DI->getArg(0), std::string(DI->getArgNameStr(0))).first;
 
-  Type T = A.first;
   assert_with_loc(T.isVector(), "dup_typed() used but target type is scalar!");
   std::string S = "(" + T.str() + ") {";
   for (unsigned I = 0; I < T.getNumElements(); ++I) {
Index: clang/test/CodeGen/aarch64-neon-vcmla.c
===
--- clang/test/CodeGen/aarch64-neon-vcmla.c
+++ clang/test/CodeGen/aarch64-neon-vcmla.c
@@ -144,3 +144,323 @@
 float64x2_t test_vcmlaq_rot270_f64(float64x2_t acc, float64x2_t lhs, float64x2_t rhs) {
   return vcmlaq_rot270_f64(acc, lhs, rhs);
 }
+
+// CHECK-LABEL: @test_vcmla_lane_f16(
+// CHECK: [[CPLX:%.*]] = bitcast <4 x half> %rhs to <2 x i32>
+// CHECK: [[DUP:%.*]] = shufflevector <2 x i32> [[CPLX]], <2 x i32> undef, <2 x i32> 
+// CHECK: [[DUP_FLT:%.*]] = bitcast <2 x i32> [[DUP]] to <4 x half>
+// CHECK: [[RES:%.*]] = call <4 x half> @llvm.aarch64.neon.vcmla.rot0.v4f16(<4 x half> %acc, <4 x half> %lhs, <4 x half> [[DUP_FLT]])
+// CHECK: ret <4 x half> [[RES]]
+float16x4_t test_vcmla_lane_f16(float16x4_t acc, float16x4_t lhs, float16x4_t rhs) {
+  return vcmla_lane_f16(acc, lhs, rhs, 1);
+}
+
+// ACLE says this exists, but it won't map to a single instruction if lane > 1.
+// CHECK-LABEL: @test_vcmla_laneq_f16(
+// CHECK: [[CPLX:%.*]] = bitcast <8 x half> %rhs to <4 x i32>
+// CHECK: [[DUP:%.*]] = shufflevector <4 x i32> [[CPLX]], <4 x i32> undef, <2 x i32> 
+// CHECK: [[DUP_FLT:%.*]] = bitcast <2 x i32> [[DUP]] to <4 x half>
+// CHECK: [[RES:%.*]] = call <4 x half> @llvm.aarch64.neon.vcmla.rot0.v4f16(<4 x half> %acc, <4 x half> %lhs, <4 x half> [[DUP_FLT]])
+// CHECK: ret <4 x half> [[RES]]
+float16x4_t test_vcmla_laneq_f16(float16x4_t acc, float16x4_t lhs, float16x8_t rhs) {
+  return vcmla_laneq_f16(acc, lhs, rhs, 3);
+}
+
+// CHECK-LABEL: @test_vcmlaq_lane_f16(
+// CHECK: [[CPLX:%.*]] = bitcast <4 x half> %rhs to <2 x i32>
+// CHECK: [[DUP:%.*]] = shufflevector <2 x i32> [[CPLX]], <2 x i32> undef, <4 x i32> 
+// CHECK: [[DUP_FLT:%.*]] = bitcast <4 x i32> [[DUP]] to <8 x half>
+// CHECK: [[RES:%.*]] = call <8 x half> @llvm.aarch64.neon.vcmla.rot0.v8f16(<8 x half> %acc, <8 x half> %lhs, <8 x half> [[DUP_FLT]])
+// CHECK: ret <8 x half> [[RES]]
+float16x8_t test_vcmlaq_lane_f16(float16x8_t acc, float16x8_t lhs, float16x4_t rhs) {
+  return vcmlaq_lane_f16(acc, lhs, rhs, 1);
+}
+
+// CHECK-LABEL: @test_vcmlaq_laneq_f16(
+// CHECK: [[CPLX:%.*]] = bitcast <8 x half> %rhs to <4 x i32>
+// CHECK: [[DUP:%.*]] = shufflevector <4 x i32> [[CPLX]], <4 x i32> undef, <4 x i32> 
+// CHECK: [[DUP_FLT:%.*]] = bitcast <4 x i32> [[DUP]] to <8 x half>
+// CHECK: [[RES:%.*]] = call <8 x half> @llvm.aarch64.neon.vcmla.rot0.v8f16(<8 x half> %acc, <8 x half> %lhs, <8 x half> [[DUP_FLT]])
+// CHECK: ret <8 x half> [[RES]]
+float16x8_t test_vcmlaq_laneq_f16(float16x8_t acc, float16x8_t lhs, float16x8_t rhs) {
+  return vcmlaq_laneq_f16(acc, lhs, rhs, 3);
+}
+
+// CHECK-LABEL: @test_vcmla_lane_f32(
+// CHECK: [[RES:%.*]] = call <2 x float> @llvm.aarch64.neon.vcmla.rot0.v2f32(<2 x float> %acc, <2 x float> %lhs, <2 x float> %rhs)
+// CHECK: ret <2 x float> [[RES]]
+float32x2_t test_vcmla_lane_f32(float32x2_t acc, float32x2_t lhs, float32x2_t rhs) {
+  return vcmla_lane_f32(acc, lhs, rhs, 0);
+}
+
+// ACLE says this exists, but it won't map to a single instruction if lane > 1.
+// CHECK-LABEL: @test_vcmla_laneq_f32(
+// CHECK: [[CPLX:%.*]] = bitcast <4 x float> %rhs to <2 x i64>
+// CHECK: [[DUP:%.*]] = shufflevector <2 x i64> [[CPLX]], <2 x i64> undef, <1 x i32> 
+// CHECK: [[DUP_FLT:%.*]] = bitcast <1 x i64> [[DUP]] to <2 x float>
+// CHECK: [[RES:%.*]] = call <2 x float> @ll

[PATCH] D93014: [Clang] Add AArch64 VCMLA LANE variants.

2021-01-04 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added inline comments.



Comment at: clang/include/clang/Basic/arm_neon.td:1911
+// vcmlaq{ROT}_lane
+def : SOpInst<"vcmla" # ROT # "_lane", "...qI", "Q" # type, Op<(call 
"vcmla" # ROT, $p0, $p1,
+   (bitcast $p0, (dup_typed laneqty , (call "vget_lane", (bitcast 
lanety, $p2), $p3>>;

SjoerdMeijer wrote:
> I have looked only quickly at this, but I was expecting the `"q"` to appear 
> here somewhere?
Yes that is indeed a bit surprising. But the tablegen emitter has code that 
inserts the `q` automatically, if required, which kicks in here. 
(https://github.com/llvm/llvm-project/blob/main/clang/utils/TableGen/NeonEmitter.cpp#L1087)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93014

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


  1   2   >