date:20180126

[PATCH] D42581: [NVPTX] Emit debug info in DWARF-2 by default for Cuda devices.

2018-01-26 Thread Paul Robinson via Phabricator via cfe-commits

probinson added a comment.

If you want to force DWARF 2, probably clamping the version in LLVM would be 
simpler?  Although most of the debug-info tests are architecture-specific and 
wouldn't run for an NVPTX target anyway.


Repository:
  rC Clang

https://reviews.llvm.org/D42581



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

[PATCH] D42521: [CodeGen] Use the non-virtual alignment when emitting the base class subobject constructor

2018-01-26 Thread Akira Hatanaka via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rC323578: [CodeGen] Use the non-virtual alignment when 
emitting the base (authored by ahatanak, committed by ).

Repository:
  rC Clang

https://reviews.llvm.org/D42521

Files:
  lib/CodeGen/CGClass.cpp
  test/CodeGenCXX/virtual-bases.cpp


Index: lib/CodeGen/CGClass.cpp
===
--- lib/CodeGen/CGClass.cpp
+++ lib/CodeGen/CGClass.cpp
@@ -615,7 +615,14 @@
 
   llvm::Value *ThisPtr = CGF.LoadCXXThis();
   QualType RecordTy = CGF.getContext().getTypeDeclType(ClassDecl);
-  LValue LHS = CGF.MakeNaturalAlignAddrLValue(ThisPtr, RecordTy);
+  LValue LHS;
+
+  // If a base constructor is being emitted, create an LValue that has the
+  // non-virtual alignment.
+  if (CGF.CurGD.getCtorType() == Ctor_Base)
+LHS = CGF.MakeNaturalAlignPointeeAddrLValue(ThisPtr, RecordTy);
+  else
+LHS = CGF.MakeNaturalAlignAddrLValue(ThisPtr, RecordTy);
 
   EmitLValueForAnyFieldInitialization(CGF, MemberInit, LHS);
 
Index: test/CodeGenCXX/virtual-bases.cpp
===
--- test/CodeGenCXX/virtual-bases.cpp
+++ test/CodeGenCXX/virtual-bases.cpp
@@ -46,3 +46,37 @@
 D::D() { }
 
 }
+
+namespace virtualBaseAlignment {
+
+// Check that the store to B::x in the base constructor has an 8-byte 
alignment.
+
+// CHECK: define linkonce_odr void 
@_ZN20virtualBaseAlignment1BC1Ev(%[[STRUCT_B:.*]]* %[[THIS:.*]])
+// CHECK: %[[THIS_ADDR:.*]] = alloca %[[STRUCT_B]]*, align 8
+// CHECK: store %[[STRUCT_B]]* %[[THIS]], %[[STRUCT_B]]** %[[THIS_ADDR]], 
align 8
+// CHECK: %[[THIS1:.*]] = load %[[STRUCT_B]]*, %[[STRUCT_B]]** %[[THIS_ADDR]], 
align 8
+// CHECK: %[[X:.*]] = getelementptr inbounds %[[STRUCT_B]], %[[STRUCT_B]]* 
%[[THIS1]], i32 0, i32 2
+// CHECK: store i32 123, i32* %[[X]], align 16
+
+// CHECK: define linkonce_odr void 
@_ZN20virtualBaseAlignment1BC2Ev(%[[STRUCT_B]]* %[[THIS:.*]], i8** %{{.*}})
+// CHECK: %[[THIS_ADDR:.*]] = alloca %[[STRUCT_B]]*, align 8
+// CHECK: store %[[STRUCT_B]]* %[[THIS]], %[[STRUCT_B]]** %[[THIS_ADDR]], 
align 8
+// CHECK: %[[THIS1:.*]] = load %[[STRUCT_B]]*, %[[STRUCT_B]]** %[[THIS_ADDR]], 
align 8
+// CHECK: %[[X:.*]] = getelementptr inbounds %[[STRUCT_B]], %[[STRUCT_B]]* 
%[[THIS1]], i32 0, i32 2
+// CHECK: store i32 123, i32* %[[X]], align 8
+
+struct A {
+  __attribute__((aligned(16))) double data1;
+};
+
+struct B : public virtual A {
+  B() : x(123) {}
+  double a;
+  int x;
+};
+
+struct C : public virtual B {};
+
+void test() { B b; C c; }
+
+}


Index: lib/CodeGen/CGClass.cpp
===
--- lib/CodeGen/CGClass.cpp
+++ lib/CodeGen/CGClass.cpp
@@ -615,7 +615,14 @@
 
   llvm::Value *ThisPtr = CGF.LoadCXXThis();
   QualType RecordTy = CGF.getContext().getTypeDeclType(ClassDecl);
-  LValue LHS = CGF.MakeNaturalAlignAddrLValue(ThisPtr, RecordTy);
+  LValue LHS;
+
+  // If a base constructor is being emitted, create an LValue that has the
+  // non-virtual alignment.
+  if (CGF.CurGD.getCtorType() == Ctor_Base)
+LHS = CGF.MakeNaturalAlignPointeeAddrLValue(ThisPtr, RecordTy);
+  else
+LHS = CGF.MakeNaturalAlignAddrLValue(ThisPtr, RecordTy);
 
   EmitLValueForAnyFieldInitialization(CGF, MemberInit, LHS);
 
Index: test/CodeGenCXX/virtual-bases.cpp
===
--- test/CodeGenCXX/virtual-bases.cpp
+++ test/CodeGenCXX/virtual-bases.cpp
@@ -46,3 +46,37 @@
 D::D() { }
 
 }
+
+namespace virtualBaseAlignment {
+
+// Check that the store to B::x in the base constructor has an 8-byte alignment.
+
+// CHECK: define linkonce_odr void @_ZN20virtualBaseAlignment1BC1Ev(%[[STRUCT_B:.*]]* %[[THIS:.*]])
+// CHECK: %[[THIS_ADDR:.*]] = alloca %[[STRUCT_B]]*, align 8
+// CHECK: store %[[STRUCT_B]]* %[[THIS]], %[[STRUCT_B]]** %[[THIS_ADDR]], align 8
+// CHECK: %[[THIS1:.*]] = load %[[STRUCT_B]]*, %[[STRUCT_B]]** %[[THIS_ADDR]], align 8
+// CHECK: %[[X:.*]] = getelementptr inbounds %[[STRUCT_B]], %[[STRUCT_B]]* %[[THIS1]], i32 0, i32 2
+// CHECK: store i32 123, i32* %[[X]], align 16
+
+// CHECK: define linkonce_odr void @_ZN20virtualBaseAlignment1BC2Ev(%[[STRUCT_B]]* %[[THIS:.*]], i8** %{{.*}})
+// CHECK: %[[THIS_ADDR:.*]] = alloca %[[STRUCT_B]]*, align 8
+// CHECK: store %[[STRUCT_B]]* %[[THIS]], %[[STRUCT_B]]** %[[THIS_ADDR]], align 8
+// CHECK: %[[THIS1:.*]] = load %[[STRUCT_B]]*, %[[STRUCT_B]]** %[[THIS_ADDR]], align 8
+// CHECK: %[[X:.*]] = getelementptr inbounds %[[STRUCT_B]], %[[STRUCT_B]]* %[[THIS1]], i32 0, i32 2
+// CHECK: store i32 123, i32* %[[X]], align 8
+
+struct A {
+  __attribute__((aligned(16))) double data1;
+};
+
+struct B : public virtual A {
+  B() : x(123) {}
+  double a;
+  int x;
+};
+
+struct C : public virtual B {};
+
+void test() { B b; C c; }
+
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

r323578 - [CodeGen] Use the non-virtual alignment when emitting the base

2018-01-26 Thread Akira Hatanaka via cfe-commits

Author: ahatanak
Date: Fri Jan 26 16:34:09 2018
New Revision: 323578

URL: http://llvm.org/viewvc/llvm-project?rev=323578=rev
Log:
[CodeGen] Use the non-virtual alignment when emitting the base
constructor.

Previously, clang would emit an over-aligned (16-byte) store to
initialize B::x in B's base constructor when compiling the following
code:

struct A {
  __attribute__((aligned(16))) double data1;
};

struct B : public virtual A {
  B() : x(123) {}
  double a;
  int x;
};

struct C : public virtual B {};

void test() { B b; C c; }

This was happening because the code in IRGen that does member
initialization was using the alignment of a complete object instead of
the non-virtual alignment.

This commit fixes the bug.

rdar://problem/36382481

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

Modified:
cfe/trunk/lib/CodeGen/CGClass.cpp
cfe/trunk/test/CodeGenCXX/virtual-bases.cpp

Modified: cfe/trunk/lib/CodeGen/CGClass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGClass.cpp?rev=323578=323577=323578=diff
==
--- cfe/trunk/lib/CodeGen/CGClass.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGClass.cpp Fri Jan 26 16:34:09 2018
@@ -615,7 +615,14 @@ static void EmitMemberInitializer(CodeGe
 
   llvm::Value *ThisPtr = CGF.LoadCXXThis();
   QualType RecordTy = CGF.getContext().getTypeDeclType(ClassDecl);
-  LValue LHS = CGF.MakeNaturalAlignAddrLValue(ThisPtr, RecordTy);
+  LValue LHS;
+
+  // If a base constructor is being emitted, create an LValue that has the
+  // non-virtual alignment.
+  if (CGF.CurGD.getCtorType() == Ctor_Base)
+LHS = CGF.MakeNaturalAlignPointeeAddrLValue(ThisPtr, RecordTy);
+  else
+LHS = CGF.MakeNaturalAlignAddrLValue(ThisPtr, RecordTy);
 
   EmitLValueForAnyFieldInitialization(CGF, MemberInit, LHS);
 

Modified: cfe/trunk/test/CodeGenCXX/virtual-bases.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/virtual-bases.cpp?rev=323578=323577=323578=diff
==
--- cfe/trunk/test/CodeGenCXX/virtual-bases.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/virtual-bases.cpp Fri Jan 26 16:34:09 2018
@@ -46,3 +46,37 @@ struct D : B, C  {
 D::D() { }
 
 }
+
+namespace virtualBaseAlignment {
+
+// Check that the store to B::x in the base constructor has an 8-byte 
alignment.
+
+// CHECK: define linkonce_odr void 
@_ZN20virtualBaseAlignment1BC1Ev(%[[STRUCT_B:.*]]* %[[THIS:.*]])
+// CHECK: %[[THIS_ADDR:.*]] = alloca %[[STRUCT_B]]*, align 8
+// CHECK: store %[[STRUCT_B]]* %[[THIS]], %[[STRUCT_B]]** %[[THIS_ADDR]], 
align 8
+// CHECK: %[[THIS1:.*]] = load %[[STRUCT_B]]*, %[[STRUCT_B]]** %[[THIS_ADDR]], 
align 8
+// CHECK: %[[X:.*]] = getelementptr inbounds %[[STRUCT_B]], %[[STRUCT_B]]* 
%[[THIS1]], i32 0, i32 2
+// CHECK: store i32 123, i32* %[[X]], align 16
+
+// CHECK: define linkonce_odr void 
@_ZN20virtualBaseAlignment1BC2Ev(%[[STRUCT_B]]* %[[THIS:.*]], i8** %{{.*}})
+// CHECK: %[[THIS_ADDR:.*]] = alloca %[[STRUCT_B]]*, align 8
+// CHECK: store %[[STRUCT_B]]* %[[THIS]], %[[STRUCT_B]]** %[[THIS_ADDR]], 
align 8
+// CHECK: %[[THIS1:.*]] = load %[[STRUCT_B]]*, %[[STRUCT_B]]** %[[THIS_ADDR]], 
align 8
+// CHECK: %[[X:.*]] = getelementptr inbounds %[[STRUCT_B]], %[[STRUCT_B]]* 
%[[THIS1]], i32 0, i32 2
+// CHECK: store i32 123, i32* %[[X]], align 8
+
+struct A {
+  __attribute__((aligned(16))) double data1;
+};
+
+struct B : public virtual A {
+  B() : x(123) {}
+  double a;
+  int x;
+};
+
+struct C : public virtual B {};
+
+void test() { B b; C c; }
+
+}


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

[PATCH] D42248: Always allow "#pragma region".

2018-01-26 Thread Matt Davis via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rC323577: Always allow #pragma region. (authored 
by mattd, committed by ).

Repository:
  rC Clang

https://reviews.llvm.org/D42248

Files:
  lib/Lex/Pragma.cpp
  test/Frontend/region-pragmas.c


Index: test/Frontend/region-pragmas.c
===
--- test/Frontend/region-pragmas.c
+++ test/Frontend/region-pragmas.c
@@ -0,0 +1,5 @@
+// RUN: %clang_cc1 -Wall -verify %s
+// expected-no-diagnostics
+
+#pragma region foo
+#pragma endregion foo
Index: lib/Lex/Pragma.cpp
===
--- lib/Lex/Pragma.cpp
+++ lib/Lex/Pragma.cpp
@@ -1776,13 +1776,15 @@
   ModuleHandler->AddPragma(new PragmaModuleEndHandler());
   ModuleHandler->AddPragma(new PragmaModuleBuildHandler());
   ModuleHandler->AddPragma(new PragmaModuleLoadHandler());
+
+  // Add region pragmas.
+  AddPragmaHandler(new PragmaRegionHandler("region"));
+  AddPragmaHandler(new PragmaRegionHandler("endregion"));
 
   // MS extensions.
   if (LangOpts.MicrosoftExt) {
 AddPragmaHandler(new PragmaWarningHandler());
 AddPragmaHandler(new PragmaIncludeAliasHandler());
-AddPragmaHandler(new PragmaRegionHandler("region"));
-AddPragmaHandler(new PragmaRegionHandler("endregion"));
   }
 
   // Pragmas added by plugins


Index: test/Frontend/region-pragmas.c
===
--- test/Frontend/region-pragmas.c
+++ test/Frontend/region-pragmas.c
@@ -0,0 +1,5 @@
+// RUN: %clang_cc1 -Wall -verify %s
+// expected-no-diagnostics
+
+#pragma region foo
+#pragma endregion foo
Index: lib/Lex/Pragma.cpp
===
--- lib/Lex/Pragma.cpp
+++ lib/Lex/Pragma.cpp
@@ -1776,13 +1776,15 @@
   ModuleHandler->AddPragma(new PragmaModuleEndHandler());
   ModuleHandler->AddPragma(new PragmaModuleBuildHandler());
   ModuleHandler->AddPragma(new PragmaModuleLoadHandler());
+
+  // Add region pragmas.
+  AddPragmaHandler(new PragmaRegionHandler("region"));
+  AddPragmaHandler(new PragmaRegionHandler("endregion"));
 
   // MS extensions.
   if (LangOpts.MicrosoftExt) {
 AddPragmaHandler(new PragmaWarningHandler());
 AddPragmaHandler(new PragmaIncludeAliasHandler());
-AddPragmaHandler(new PragmaRegionHandler("region"));
-AddPragmaHandler(new PragmaRegionHandler("endregion"));
   }
 
   // Pragmas added by plugins
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r323577 - Always allow "#pragma region".

2018-01-26 Thread Matt Davis via cfe-commits

Author: mattd
Date: Fri Jan 26 16:25:29 2018
New Revision: 323577

URL: http://llvm.org/viewvc/llvm-project?rev=323577=rev
Log:
Always allow "#pragma region".

Summary:
Both MS and PS4 targets are capable of recognizing the
existence of:  #pragma region, #pragma endregion.

Since this pragma is only a hint for certain editors, and has no logic,
it seems helpful to permit this pragma in all cases, not just MS compatibility 
mode.



Reviewers: rnk, rsmith, majnemer

Reviewed By: majnemer

Subscribers: Quuxplusone, probinson, majnemer, cfe-commits

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

Added:
cfe/trunk/test/Frontend/region-pragmas.c
Modified:
cfe/trunk/lib/Lex/Pragma.cpp

Modified: cfe/trunk/lib/Lex/Pragma.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Pragma.cpp?rev=323577=323576=323577=diff
==
--- cfe/trunk/lib/Lex/Pragma.cpp (original)
+++ cfe/trunk/lib/Lex/Pragma.cpp Fri Jan 26 16:25:29 2018
@@ -1776,13 +1776,15 @@ void Preprocessor::RegisterBuiltinPragma
   ModuleHandler->AddPragma(new PragmaModuleEndHandler());
   ModuleHandler->AddPragma(new PragmaModuleBuildHandler());
   ModuleHandler->AddPragma(new PragmaModuleLoadHandler());
+
+  // Add region pragmas.
+  AddPragmaHandler(new PragmaRegionHandler("region"));
+  AddPragmaHandler(new PragmaRegionHandler("endregion"));
 
   // MS extensions.
   if (LangOpts.MicrosoftExt) {
 AddPragmaHandler(new PragmaWarningHandler());
 AddPragmaHandler(new PragmaIncludeAliasHandler());
-AddPragmaHandler(new PragmaRegionHandler("region"));
-AddPragmaHandler(new PragmaRegionHandler("endregion"));
   }
 
   // Pragmas added by plugins

Added: cfe/trunk/test/Frontend/region-pragmas.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/region-pragmas.c?rev=323577=auto
==
--- cfe/trunk/test/Frontend/region-pragmas.c (added)
+++ cfe/trunk/test/Frontend/region-pragmas.c Fri Jan 26 16:25:29 2018
@@ -0,0 +1,5 @@
+// RUN: %clang_cc1 -Wall -verify %s
+// expected-no-diagnostics
+
+#pragma region foo
+#pragma endregion foo


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

[PATCH] D42608: Driver: Prefer vendor supplied gcc toolchain

2018-01-26 Thread Tom Stellard via Phabricator via cfe-commits

tstellar created this revision.
Herald added a subscriber: srhines.

This patch fixes an issue on Fedora where if you had the x86_64 cross
compiler installed on your x86_64 system, then clang would use that compiler
as the default toolchain.  This was happening because the cross compiler
is installed to /usr/lib/gcc/x86_64-linux-gnu/ and this directory comes before
the default compiler directory (/usr/lib/gcc/x86_64-redhat-linux/) in the search
list.

This patch re-orders the search list so that vendor supplied gcc toolchains
are selected before toolchains with a generic target, which should prevent
these kind of issues on other OSes too.


Repository:
  rC Clang

https://reviews.llvm.org/D42608

Files:
  lib/Driver/ToolChains/Gnu.cpp


Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -1809,40 +1809,41 @@
   // lifetime or initialization issues.
   static const char *const AArch64LibDirs[] = {"/lib64", "/lib"};
   static const char *const AArch64Triples[] = {
-  "aarch64-none-linux-gnu", "aarch64-linux-gnu", "aarch64-linux-android",
-  "aarch64-redhat-linux", "aarch64-suse-linux"};
+  "aarch64-redhat-linux", "aarch64-suse-linux",
+  "aarch64-none-linux-gnu", "aarch64-linux-gnu", "aarch64-linux-android"};
   static const char *const AArch64beLibDirs[] = {"/lib"};
   static const char *const AArch64beTriples[] = {"aarch64_be-none-linux-gnu",
  "aarch64_be-linux-gnu"};
 
   static const char *const ARMLibDirs[] = {"/lib"};
   static const char *const ARMTriples[] = {"arm-linux-gnueabi",
"arm-linux-androideabi"};
-  static const char *const ARMHFTriples[] = {"arm-linux-gnueabihf",
- "armv7hl-redhat-linux-gnueabi",
+  static const char *const ARMHFTriples[] = {"armv7hl-redhat-linux-gnueabi",
  "armv6hl-suse-linux-gnueabi",
- "armv7hl-suse-linux-gnueabi"};
+ "armv7hl-suse-linux-gnueabi",
+ "arm-linux-gnueabihf",
+  };
   static const char *const ARMebLibDirs[] = {"/lib"};
   static const char *const ARMebTriples[] = {"armeb-linux-gnueabi",
  "armeb-linux-androideabi"};
   static const char *const ARMebHFTriples[] = {
   "armeb-linux-gnueabihf", "armebv7hl-redhat-linux-gnueabi"};
 
   static const char *const X86_64LibDirs[] = {"/lib64", "/lib"};
   static const char *const X86_64Triples[] = {
-  "x86_64-linux-gnu",   "x86_64-unknown-linux-gnu",
-  "x86_64-pc-linux-gnu","x86_64-redhat-linux6E",
-  "x86_64-redhat-linux","x86_64-suse-linux",
-  "x86_64-manbo-linux-gnu", "x86_64-linux-gnu",
-  "x86_64-slackware-linux", "x86_64-linux-android",
+  "x86_64-redhat-linux6E","x86_64-redhat-linux",
+  "x86_64-suse-linux","x86_64-slackware-linux",
+  "x86_64-manbo-linux-gnu",   "x86_64-linux-gnu",
+  "x86_64-unknown-linux-gnu", "x86_64-pc-linux-gnu",
+  "x86_64-linux-gnu", "x86_64-linux-android",
   "x86_64-unknown-linux"};
   static const char *const X32LibDirs[] = {"/libx32"};
   static const char *const X86LibDirs[] = {"/lib32", "/lib"};
   static const char *const X86Triples[] = {
-  "i686-linux-gnu",   "i686-pc-linux-gnu", "i486-linux-gnu",
-  "i386-linux-gnu",   "i386-redhat-linux6E",   "i686-redhat-linux",
-  "i586-redhat-linux","i386-redhat-linux", "i586-suse-linux",
-  "i486-slackware-linux", "i686-montavista-linux", "i686-linux-android",
+  "i386-redhat-linux6E",   "i686-redhat-linux", "i586-redhat-linuxll",
+  "i386-redhat-linux", "i586-suse-linux",   "i486-slackware-linux",
+  "i686-montavista-linux", "i686-linux-gnu","i686-pc-linux-gnu",
+  "i486-linux-gnu","i386-linux-gnu","i686-linux-android",
   "i586-linux-gnu"};
 
   static const char *const MIPSLibDirs[] = {"/lib"};
@@ -1872,16 +1873,16 @@
 
   static const char *const PPCLibDirs[] = {"/lib32", "/lib"};
   static const char *const PPCTriples[] = {
-  "powerpc-linux-gnu", "powerpc-unknown-linux-gnu", "powerpc-linux-gnuspe",
-  "powerpc-suse-linux", "powerpc-montavista-linuxspe"};
+  "powerpc-suse-linux", "powerpc-montavista-linuxspe",
+  "powerpc-linux-gnu", "powerpc-unknown-linux-gnu", 
"powerpc-linux-gnuspe"};
   static const char *const PPC64LibDirs[] = {"/lib64", "/lib"};
   static const char *const PPC64Triples[] = {
-  "powerpc64-linux-gnu", "powerpc64-unknown-linux-gnu",
-  "powerpc64-suse-linux", "ppc64-redhat-linux"};
+  "powerpc64-suse-linux", "ppc64-redhat-linux",
+  "powerpc64-linux-gnu", "powerpc64-unknown-linux-gnu"};
   static const char *const PPC64LELibDirs[] =

[PATCH] D42606: [Coroutines] Use allocator overload when available

2018-01-26 Thread Brian Gesiak via Phabricator via cfe-commits

modocache created this revision.
modocache added reviewers: rsmith, GorNishanov, eric_niebler.
Herald added a subscriber: EricWF.

Depends on https://reviews.llvm.org/D42605.

An implementation of the behavior described in `[dcl.fct.def.coroutine]/7`:
when a promise type overloads `operator new` using a "placement new"
that takes the same argument types as the coroutine function, that
overload is used when allocating the coroutine frame.

Simply passing references to the coroutine function parameters directly
to `operator new` results in invariant violations in LLVM's coroutine
splitting pass, so this implementation modifies Clang codegen to
produce allocator-specific alloc/store/loads for each parameter being
forwarded to the allocator.

Test Plan: `check-clang`


Repository:
  rC Clang

https://reviews.llvm.org/D42606

Files:
  lib/CodeGen/CGCoroutine.cpp
  lib/Sema/SemaCoroutine.cpp
  test/CodeGenCoroutines/coro-alloc.cpp

Index: test/CodeGenCoroutines/coro-alloc.cpp
===
--- test/CodeGenCoroutines/coro-alloc.cpp
+++ test/CodeGenCoroutines/coro-alloc.cpp
@@ -106,6 +106,34 @@
   co_return;
 }
 
+struct promise_matching_placement_new_tag {};
+
+template<>
+struct std::experimental::coroutine_traits {
+  struct promise_type {
+void *operator new(unsigned long, promise_matching_placement_new_tag,
+   int, float, double);
+void get_return_object() {}
+suspend_always initial_suspend() { return {}; }
+suspend_always final_suspend() { return {}; }
+void return_void() {}
+  };
+};
+
+// CHECK-LABEL: f1a(
+extern "C" void f1a(promise_matching_placement_new_tag, int x, float y , double z) {
+  // CHECK: %[[ID:.+]] = call token @llvm.coro.id(i32 16
+  // CHECK: %[[SIZE:.+]] = call i64 @llvm.coro.size.i64()
+  // CHECK: store i32 %x, i32* %coro.allocate.x.addr, align 4
+  // CHECK: %[[INT:.+]] = load i32, i32* %coro.allocate.x.addr, align 4
+  // CHECK: store float %y, float* %coro.allocate.y.addr, align 4
+  // CHECK: %[[FLOAT:.+]] = load float, float* %coro.allocate.y.addr, align 4
+  // CHECK: store double %z, double* %coro.allocate.z.addr, align 8
+  // CHECK: %[[DOUBLE:.+]] = load double, double* %coro.allocate.z.addr, align 8
+  // CHECK: call i8* @_ZNSt12experimental16coroutine_traitsIJv34promise_matching_placement_new_tagifdEE12promise_typenwEmS1_ifd(i64 %[[SIZE]], i32 %[[INT]], float %[[FLOAT]], double %[[DOUBLE]])
+  co_return;
+}
+
 struct promise_delete_tag {};
 
 template<>
Index: lib/Sema/SemaCoroutine.cpp
===
--- lib/Sema/SemaCoroutine.cpp
+++ lib/Sema/SemaCoroutine.cpp
@@ -1050,18 +1050,54 @@
 
   const bool RequiresNoThrowAlloc = ReturnStmtOnAllocFailure != nullptr;
 
-  // FIXME: Add support for stateful allocators.
+  // [dcl.fct.def.coroutine]/7
+  // Lookup allocation functions using a parameter list composed of the
+  // requested size of the coroutine state being allocated, followed by
+  // the coroutine function's arguments. If a matching allocation function
+  // exists, use it. Otherwise, use an allocation function that just takes
+  // the requested size.
 
   FunctionDecl *OperatorNew = nullptr;
   FunctionDecl *OperatorDelete = nullptr;
   FunctionDecl *UnusedResult = nullptr;
   bool PassAlignment = false;
   SmallVector PlacementArgs;
 
+  // [dcl.fct.def.coroutine]/7
+  // "The allocation function’s name is looked up in the scope of P.
+  // [...] If the lookup finds an allocation function in the scope of P,
+  // overload resolution is performed on a function call created by assembling
+  // an argument list."
+  for (auto *PD : FD.parameters()) {
+if (PD->getType()->isDependentType())
+  continue;
+
+// Build a reference to the parameter.
+auto PDLoc = PD->getLocation();
+ExprResult PDRefExpr =
+S.BuildDeclRefExpr(PD, PD->getOriginalType().getNonReferenceType(),
+   ExprValueKind::VK_LValue, PDLoc);
+if (PDRefExpr.isInvalid())
+  return false;
+
+PlacementArgs.push_back(PDRefExpr.get());
+  }
   S.FindAllocationFunctions(Loc, SourceRange(),
 /*UseGlobal*/ false, PromiseType,
 /*isArray*/ false, PassAlignment, PlacementArgs,
-OperatorNew, UnusedResult);
+OperatorNew, UnusedResult, /*Diagnose*/ false);
+
+  // [dcl.fct.def.coroutine]/7
+  // "If no matching function is found, overload resolution is performed again
+  // on a function call created by passing just the amount of space required as
+  // an argument of type std::size_t."
+  if (!OperatorNew && !PlacementArgs.empty()) {
+PlacementArgs.clear();
+S.FindAllocationFunctions(Loc, SourceRange(),
+  /*UseGlobal*/ false, PromiseType,
+  /*isArray*/ false, PassAlignment,

[PATCH] D42605: [Sema] Toggle diags when finding allocators (NFCI)

2018-01-26 Thread Brian Gesiak via Phabricator via cfe-commits

modocache created this revision.
modocache added reviewers: rsmith, GorNishanov, eric_niebler.

Many methods in Sema take a `bool Diagnose` parameter. Examples of such
methods include `Sema::FindDeallocationFunction` and
`Sema::SpecialMemberIsTrivial`. Calling these methods with
`Diagnose = false` allows callers to, for instance, check for the
existence of a deallocation function, without that check resulting in
error diagnostics being emitted if no matching deallocation function exists.

Add a similar `bool Diagnose` to the `Sema::FindAllocationFunctions`
method, so that checks for the existence of allocation functions can be
made without triggering error diagnostics.

This allows `SemaCoroutine.cpp`, in its implementation of the
Coroutines TS, to check for the existence of a particular `operator new`
overload, but then without error fall back to a default `operator new`
if no matching overload exists.

Test Plan: `check-clang`


Repository:
  rC Clang

https://reviews.llvm.org/D42605

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

Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -2137,12 +2137,10 @@
   return false;
 }
 
-static bool
-resolveAllocationOverload(Sema , LookupResult , SourceRange Range,
-  SmallVectorImpl , bool ,
-  FunctionDecl *,
-  OverloadCandidateSet *AlignedCandidates = nullptr,
-  Expr *AlignArg = nullptr) {
+static bool resolveAllocationOverload(
+Sema , LookupResult , SourceRange Range, SmallVectorImpl ,
+bool , FunctionDecl *,
+OverloadCandidateSet *AlignedCandidates, Expr *AlignArg, bool Diagnose) {
   OverloadCandidateSet Candidates(R.getNameLoc(),
   OverloadCandidateSet::CSK_Normal);
   for (LookupResult::iterator Alloc = R.begin(), AllocEnd = R.end();
@@ -2188,7 +2186,8 @@
   AlignArg = Args[1];
   Args.erase(Args.begin() + 1);
   return resolveAllocationOverload(S, R, Range, Args, PassAlignment,
-   Operator, , AlignArg);
+   Operator, , AlignArg,
+   Diagnose);
 }
 
 // MSVC will fall back on trying to find a matching global operator new
@@ -2204,11 +2203,13 @@
   S.LookupQualifiedName(R, S.Context.getTranslationUnitDecl());
   // FIXME: This will give bad diagnostics pointing at the wrong functions.
   return resolveAllocationOverload(S, R, Range, Args, PassAlignment,
-   Operator, nullptr);
+   Operator, /*Candidates=*/nullptr,
+   /*AlignArg=*/nullptr, Diagnose);
 }
 
-S.Diag(R.getNameLoc(), diag::err_ovl_no_viable_function_in_call)
-  << R.getLookupName() << Range;
+if (Diagnose)
+  S.Diag(R.getNameLoc(), diag::err_ovl_no_viable_function_in_call)
+  << R.getLookupName() << Range;
 
 // If we have aligned candidates, only note the align_val_t candidates
 // from AlignedCandidates and the non-align_val_t candidates from
@@ -2234,18 +2235,20 @@
 return true;
 
   case OR_Ambiguous:
-S.Diag(R.getNameLoc(), diag::err_ovl_ambiguous_call)
-  << R.getLookupName() << Range;
-Candidates.NoteCandidates(S, OCD_ViableCandidates, Args);
+if (Diagnose) {
+  S.Diag(R.getNameLoc(), diag::err_ovl_ambiguous_call)
+  << R.getLookupName() << Range;
+  Candidates.NoteCandidates(S, OCD_ViableCandidates, Args);
+}
 return true;
 
   case OR_Deleted: {
-S.Diag(R.getNameLoc(), diag::err_ovl_deleted_call)
-  << Best->Function->isDeleted()
-  << R.getLookupName()
-  << S.getDeletedOrUnavailableSuffix(Best->Function)
-  << Range;
-Candidates.NoteCandidates(S, OCD_AllCandidates, Args);
+if (Diagnose) {
+  S.Diag(R.getNameLoc(), diag::err_ovl_deleted_call)
+  << Best->Function->isDeleted() << R.getLookupName()
+  << S.getDeletedOrUnavailableSuffix(Best->Function) << Range;
+  Candidates.NoteCandidates(S, OCD_AllCandidates, Args);
+}
 return true;
   }
   }
@@ -2260,7 +2263,8 @@
bool IsArray, bool ,
MultiExprArg PlaceArgs,
FunctionDecl *,
-   FunctionDecl *) {
+   FunctionDecl *,
+   bool Diagnose) {
   // --- Choosing an allocation function ---
   // C++ 5.3.4p8 - 14 & 18
   // 1) If UseGlobal is true, only look in the global scope. Else, also look
@@ -2335,7 +2339,8 @@
 R.suppressDiagnostics();
 
 if (resolveAllocationOverload(*this, R, Range, AllocArgs, PassAlignment,
-  OperatorNew))
+

[PATCH] D42508: AST: support protocol conformances on id/class/interfaces in MS ABI

2018-01-26 Thread Saleem Abdulrasool via Phabricator via cfe-commits

compnerd closed this revision.
compnerd added a comment.

SVN r323547


Repository:
  rC Clang

https://reviews.llvm.org/D42508



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

[PATCH] D41720: [clang-tidy] Add a -show-color flag.

2018-01-26 Thread Ian Tessier via Phabricator via cfe-commits

itessier added inline comments.



Comment at: clang-tidy/ClangTidyOptions.h:93
+  /// \brief Show color diagnostics.
+  llvm::Optional ShowColor;
+

alexfh wrote:
> This doesn't belong to ClangTidyOptions. It's specific to the CLI, but CLI is 
> not the only frontend for clang-tidy.
Since we have to propagate the value to the ErrorReporter, how about adding a 
bool param to the ErrorReporter ctor? We could add a setter instead, but that 
would require moving a diag printer call out of the ctor since it uses the 
DiagOpts instance.

The colour logic would then be moved into either clangTidyMain or handleErrors.



Comment at: clang-tidy/tool/ClangTidyMain.cpp:150-152
+Show color diagnostics. If not specified,
+defaults to on when a color-capable terminal
+is detected.)"),

itessier wrote:
> aaron.ballman wrote:
> > I think this raw string can be reflowed a bit?
> > 
> > Instead of "defaults to on", how about "Defaults to true when a 
> > color-capable terminal is detected."?
> I copied that part from the -fcolor-diagnostics flag to be consistent. I 
> don't changing "on" to "true" if you prefer that instead.
That should have read "I don't mind changing..."


https://reviews.llvm.org/D41720



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

Re: [PATCH] D35338: Add the -fdestroy-globals flag

2018-01-26 Thread Vedant Kumar via cfe-commits

Yeah, I think we have internal users who would be happy to use this flag as 
well.

Stepping back a bit. It's been a while since I followed the discussion on 
cfe-dev, but I don't recall there being any objections to the flag name or to 
using it for particular targets.

IIRC the objections are about deviating from the language standard. I'm not 
sure where I stand on the issue. I think if there's evidence -fdestroy-globals 
gives significant space savings, I'm happy to defer to users.

vedant

> On Jan 26, 2018, at 1:10 PM, Nico Weber via cfe-commits 
>  wrote:
> 
> I'd love to use this flag in non-firmware code FWIW.
> 
> On Fri, Jan 26, 2018 at 4:07 PM, Ian Tessier via Phabricator via cfe-commits 
> > wrote:
> itessier added a comment.
> 
> > That seems like a nice win and I like the convenience of this approach. 
> > That said I've just remembered that there's a thread on cfe-dev about this:
> > [RFC] Suppress C++ static destructor registration
> > I don't think a consensus was reached. From what I gather, some people 
> > think that the convenience of this flag makes it worth adding to clang, 
> > while others think that adding a non-standard compiler-specific flag is 
> > asking for trouble.
> 
> Given that firmware is a much different (or controlled) environment than a 
> binary running on a full blown OS, would it be acceptable to name the flag 
> -fbaremetal-destroy-globals, and only allow its use if the target triple's OS 
> is set to none (e.g.: arm-**none**-eabi)?
> 
> 
> https://reviews.llvm.org/D35338 
> 
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits 
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[PATCH] D42513: [CUDA] Added partial support for CUDA-9.1

2018-01-26 Thread Artem Belevich via Phabricator via cfe-commits

tra updated this revision to Diff 131650.
tra added a comment.

Addressed Justin's comments.


https://reviews.llvm.org/D42513

Files:
  clang/include/clang/Basic/Cuda.h
  clang/lib/Basic/Cuda.cpp
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/__clang_cuda_device_functions.h
  clang/lib/Headers/__clang_cuda_libdevice_declares.h
  clang/lib/Headers/__clang_cuda_runtime_wrapper.h

Index: clang/lib/Headers/__clang_cuda_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_cuda_runtime_wrapper.h
+++ clang/lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -62,7 +62,7 @@
 #include "cuda.h"
 #if !defined(CUDA_VERSION)
 #error "cuda.h did not define CUDA_VERSION"
-#elif CUDA_VERSION < 7000 || CUDA_VERSION > 9000
+#elif CUDA_VERSION < 7000 || CUDA_VERSION > 9010
 #error "Unsupported CUDA version!"
 #endif
 
@@ -84,6 +84,9 @@
 #define __DEVICE_FUNCTIONS_H__
 #define __MATH_FUNCTIONS_H__
 #define __COMMON_FUNCTIONS_H__
+// device_functions_decls is replaced by __clang_cuda_device_functions.h
+// included below.
+#define __DEVICE_FUNCTIONS_DECLS_H__
 
 #undef __CUDACC__
 #if CUDA_VERSION < 9000
@@ -137,20 +140,22 @@
 }
 #endif
 
-// We need decls for functions in CUDA's libdevice with __device__
-// attribute only. Alas they come either as __host__ __device__ or
-// with no attributes at all. To work around that, define __CUDA_RTC__
-// which produces HD variant and undef __host__ which gives us desided
-// decls with __device__ attribute.
-#pragma push_macro("__host__")
-#define __host__
-#define __CUDACC_RTC__
-#include "device_functions_decls.h"
-#undef __CUDACC_RTC__
+// CUDA 9.1 no longer provides declarations for libdevice functions, so we need
+// to provide our own.
+#include <__clang_cuda_libdevice_declares.h>
 
-// Temporarily poison __host__ macro to ensure it's not used by any of
-// the headers we're about to include.
-#define __host__ UNEXPECTED_HOST_ATTRIBUTE
+// Wrappers for many device-side standard library functions became compiler
+// builtins in CUDA-9 and have been removed from the CUDA headers. Clang now
+// provides its own implementation of the wrappers.
+#if CUDA_VERSION >= 9000
+#include <__clang_cuda_device_functions.h>
+#endif
+
+// __THROW is redefined to be empty by device_functions_decls.h in CUDA. Clang's
+// counterpart does not do it, so we need to make it empty here to keep
+// following CUDA includes happy.
+#undef __THROW
+#define __THROW
 
 // CUDA 8.0.41 relies on __USE_FAST_MATH__ and __CUDA_PREC_DIV's values.
 // Previous versions used to check whether they are defined or not.
@@ -167,24 +172,20 @@
 #endif
 #endif
 
+// Temporarily poison __host__ macro to ensure it's not used by any of
+// the headers we're about to include.
+#pragma push_macro("__host__")
+#define __host__ UNEXPECTED_HOST_ATTRIBUTE
+
 // device_functions.hpp and math_functions*.hpp use 'static
 // __forceinline__' (with no __device__) for definitions of device
 // functions. Temporarily redefine __forceinline__ to include
 // __device__.
 #pragma push_macro("__forceinline__")
 #define __forceinline__ __device__ __inline__ __attribute__((always_inline))
-
-#pragma push_macro("__float2half_rn")
-#if CUDA_VERSION >= 9000
-// CUDA-9 has conflicting prototypes for __float2half_rn(float f) in
-// cuda_fp16.h[pp] and device_functions.hpp. We need to get the one in
-// device_functions.hpp out of the way.
-#define __float2half_rn  __float2half_rn_disabled
-#endif
-
+#if CUDA_VERSION < 9000
 #include "device_functions.hpp"
-#pragma pop_macro("__float2half_rn")
-
+#endif
 
 // math_function.hpp uses the __USE_FAST_MATH__ macro to determine whether we
 // get the slow-but-accurate or fast-but-inaccurate versions of functions like
@@ -196,17 +197,27 @@
 #if defined(__CLANG_CUDA_APPROX_TRANSCENDENTALS__)
 #define __USE_FAST_MATH__ 1
 #endif
+
+#if CUDA_VERSION >= 9000
+#include "crt/math_functions.hpp"
+#else
 #include "math_functions.hpp"
+#endif
+
 #pragma pop_macro("__USE_FAST_MATH__")
 
+#if CUDA_VERSION < 9000
 #include "math_functions_dbl_ptx3.hpp"
+#endif
 #pragma pop_macro("__forceinline__")
 
 // Pull in host-only functions that are only available when neither
 // __CUDACC__ nor __CUDABE__ are defined.
 #undef __MATH_FUNCTIONS_HPP__
 #undef __CUDABE__
+#if CUDA_VERSION < 9000
 #include "math_functions.hpp"
+#endif
 // Alas, additional overloads for these functions are hard to get to.
 // Considering that we only need these overloads for a few functions,
 // we can provide them here.
@@ -222,22 +233,36 @@
 static inline float normcdf(float __a) { return normcdff(__a); }
 static inline float erfcx(float __a) { return erfcxf(__a); }
 
+#if CUDA_VERSION < 9000
 // For some reason single-argument variant is not always declared by
 // CUDA headers. Alas, device_functions.hpp included below needs it.
 static inline __device__ void __brkpt(int __c) { __brkpt(); }
+#endif
 
 // Now

[PATCH] D42493: [clang-format] Fix ObjC message arguments formatting.

2018-01-26 Thread Ben Hamilton via Phabricator via cfe-commits

benhamilton accepted this revision.
benhamilton added inline comments.
This revision is now accepted and ready to land.



Comment at: lib/Format/TokenAnnotator.cpp:419
   StartsObjCMethodExpr = true;
+  Left->ParameterCount = 0;
   Contexts.back().ColonIsObjCMethodExpr = true;

What does this line do? Seems like it's initialized to 0 already, right?


Repository:
  rC Clang

https://reviews.llvm.org/D42493



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

[PATCH] D42395: [clang-format] Fix bug where -dump-config failed on ObjC header

2018-01-26 Thread Ben Hamilton via Phabricator via cfe-commits

benhamilton requested review of this revision.
benhamilton marked 2 inline comments as done.
benhamilton added inline comments.



Comment at: test/Format/lit.local.cfg:1
+# Suffixes supported by clang-format.
+config.suffixes = ['.c', '.cc', '.cpp', '.h', '.m', '.mm', '.java', '.js',

krasimir wrote:
> Why is this needed?
'.h' is not in the list of file suffixes which lit is configured to look for:

https://github.com/llvm-mirror/clang/blob/master/test/lit.cfg.py#L28

So, we need to provide our own list of file suffixes here.

Other tests do the same:

https://github.com/llvm-mirror/clang/search?utf8=%E2%9C%93=%22config.suffixes%22=

so I think it's OK to do so here as well.


Repository:
  rC Clang

https://reviews.llvm.org/D42395



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

[libcxx] r323563 - Fix the BinaryPredicate form of std::is_permutation to not rely on operator==

2018-01-26 Thread Peter Collingbourne via cfe-commits

Author: pcc
Date: Fri Jan 26 13:23:27 2018
New Revision: 323563

URL: http://llvm.org/viewvc/llvm-project?rev=323563=rev
Log:
Fix the BinaryPredicate form of std::is_permutation to not rely on operator==

According to [1], forms 2 and 4 of std::is_permutation should use the passed in
binary predicate to compare elements. operator== should only be used for forms
1 and 3 which do not take a binary predicate.

This CL fixes forms 2 and 4 which relied on operator== for some comparisons.

[1] http://en.cppreference.com/w/cpp/algorithm/is_permutation

Patch by Thomas Anderson!

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

Modified:
libcxx/trunk/include/algorithm

libcxx/trunk/test/std/algorithms/alg.nonmodifying/alg.is_permutation/is_permutation_pred.pass.cpp

Modified: libcxx/trunk/include/algorithm
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/algorithm?rev=323563=323562=323563=diff
==
--- libcxx/trunk/include/algorithm (original)
+++ libcxx/trunk/include/algorithm Fri Jan 26 13:23:27 2018
@@ -1418,7 +1418,11 @@ is_permutation(_ForwardIterator1 __first
 for (_ForwardIterator1 __i = __first1; __i != __last1; ++__i)
 {
 //  Have we already counted the number of *__i in [f1, l1)?
-if (find(__first1, __i, *__i) == __i) {
+_ForwardIterator1 __match = __first1;
+for (; __match != __i; ++__match)
+if (__pred(*__match, *__i))
+break;
+if (__match == __i) {
 // Count number of *__i in [f2, l2)
 _D1 __c2 = 0;
 for (_ForwardIterator2 __j = __first2; __j != __last2; ++__j)
@@ -1479,7 +1483,11 @@ __is_permutation(_ForwardIterator1 __fir
 for (_ForwardIterator1 __i = __first1; __i != __last1; ++__i)
 {
 //  Have we already counted the number of *__i in [f1, l1)?
-if (find(__first1, __i, *__i) == __i) {
+_ForwardIterator1 __match = __first1;
+for (; __match != __i; ++__match)
+if (__pred(*__match, *__i))
+break;
+if (__match == __i) {
 // Count number of *__i in [f2, l2)
 _D1 __c2 = 0;
 for (_ForwardIterator2 __j = __first2; __j != __last2; ++__j)

Modified: 
libcxx/trunk/test/std/algorithms/alg.nonmodifying/alg.is_permutation/is_permutation_pred.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/algorithms/alg.nonmodifying/alg.is_permutation/is_permutation_pred.pass.cpp?rev=323563=323562=323563=diff
==
--- 
libcxx/trunk/test/std/algorithms/alg.nonmodifying/alg.is_permutation/is_permutation_pred.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/algorithms/alg.nonmodifying/alg.is_permutation/is_permutation_pred.pass.cpp
 Fri Jan 26 13:23:27 2018
@@ -738,6 +738,30 @@ int main()
std::equal_to()) == false);
 #endif
 }
+{
+  struct S {
+  S(int i) : i_(i) {}
+  bool operator==(const S& other) = delete;
+  int i_;
+  };
+  struct eq {
+  bool operator()(const S& a, const S) { return a.i_ == b.i_; }
+  };
+  const S a[] = {S(0), S(1)};
+  const S b[] = {S(1), S(0)};
+  const unsigned sa = sizeof(a)/sizeof(a[0]);
+  assert(std::is_permutation(forward_iterator(a),
+ forward_iterator(a + sa),
+ forward_iterator(b),
+ eq()));
+#if TEST_STD_VER >= 14
+  assert(std::is_permutation(forward_iterator(a),
+ forward_iterator(a + sa),
+ forward_iterator(b),
+ forward_iterator(b + sa),
+ eq()));
+#endif
+}
 
 #if TEST_STD_VER > 17
 static_assert(test_constexpr());


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

Re: [PATCH] D35338: Add the -fdestroy-globals flag

2018-01-26 Thread Nico Weber via cfe-commits

I'd love to use this flag in non-firmware code FWIW.

On Fri, Jan 26, 2018 at 4:07 PM, Ian Tessier via Phabricator via
cfe-commits  wrote:

> itessier added a comment.
>
> > That seems like a nice win and I like the convenience of this approach.
> That said I've just remembered that there's a thread on cfe-dev about this:
> > [RFC] Suppress C++ static destructor registration
> > I don't think a consensus was reached. From what I gather, some people
> think that the convenience of this flag makes it worth adding to clang,
> while others think that adding a non-standard compiler-specific flag is
> asking for trouble.
>
> Given that firmware is a much different (or controlled) environment than a
> binary running on a full blown OS, would it be acceptable to name the flag
> -fbaremetal-destroy-globals, and only allow its use if the target triple's
> OS is set to none (e.g.: arm-**none**-eabi)?
>
>
> https://reviews.llvm.org/D35338
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D35338: Add the -fdestroy-globals flag

2018-01-26 Thread Ian Tessier via Phabricator via cfe-commits

itessier added a comment.

> That seems like a nice win and I like the convenience of this approach. That 
> said I've just remembered that there's a thread on cfe-dev about this:
> [RFC] Suppress C++ static destructor registration
> I don't think a consensus was reached. From what I gather, some people think 
> that the convenience of this flag makes it worth adding to clang, while 
> others think that adding a non-standard compiler-specific flag is asking for 
> trouble.

Given that firmware is a much different (or controlled) environment than a 
binary running on a full blown OS, would it be acceptable to name the flag 
-fbaremetal-destroy-globals, and only allow its use if the target triple's OS 
is set to none (e.g.: arm-**none**-eabi)?


https://reviews.llvm.org/D35338



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

Re: [libcxx] r323453 - [cmake] [libcxx] Call llvm_setup_rpath() when adding shared libraries.

2018-01-26 Thread Don Hinton via cfe-commits

On Thu, Jan 25, 2018 at 5:20 PM, Duncan P. N. Exon Smith <
dexonsm...@apple.com> wrote:

>
>
> On Jan 25, 2018, at 17:09, Don Hinton  wrote:
>
>
>
> On Thu, Jan 25, 2018 at 4:21 PM, Duncan P. N. Exon Smith <
> dexonsm...@apple.com> wrote:
>
>>
>>
>> On Jan 25, 2018, at 16:18, Duncan P. N. Exon Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>
>>
>> On Jan 25, 2018, at 13:07, Don Hinton  wrote:
>>
>> On Thu, Jan 25, 2018 at 12:54 PM, Chris Bieneman  wrote:
>>
>>> Historically we have supported building libcxx without llvm-config
>>> available on the system.
>>>
>>> In all likelihood the bots didn't fail because the bots do have
>>> llvm-config because we usually require an llvm build or source checkout in
>>> order to build and run the tests since tests depend on lit and gtest.
>>>
>>
>> Ah, okay, but if the bots don't test/enforce this, does it make sense to
>> continue to support building without llvm-config?
>>
>>
>> I didn't realize we didn't have a bot enforcing this.  I just made one:
>> http://lab.llvm.org:8080/green/view/Libcxx/job/libcxx_master
>> _cmake_standalone
>>
>> I don't want to break upstream users, but the alternative is to duplicate
>> this logic across multiple sub-projects.  (see http://lists.llvm.org/pip
>> ermail/llvm-dev/2018-January/120707.html for a related rpath issue).
>>
>>
>> It's temporary though.  In the brave new world on GitHub with monorepo,
>> the runtime libraries will be able to access a shared set of CMake
>> configuration scripts.
>>
>>
>> Note that there's other stuff duplicated in the runtime libraries, such
>> as preprocessor definitions (LLVM_... => __LIBCXX_...), that we'll never
>> really be able to collapse.
>>
>
> Great, I've changed it to this:
>
> +  if(LLVM_FOUND)
> +llvm_setup_rpath(cxx_shared)
> +  endif()
>
> Which should work for both cases.  Is that okay?
>
>
> SGTM.
>

Turns out LLVM_FOUND doesn't cover all cases, i.e., it's only set by libcxx
and libcxxabi when doing out-of-tree builds.  A better solution is to check
if the command is actually available:

-  if(LLVM_FOUND)
+  if(COMMAND llvm_setup_rpath)
 llvm_setup_rpath(cxx_shared)
   endif()


>
>
>
>>
>>
>>
>>
>>>
>>>
>>> -Chris
>>>
>>>
>>> On Jan 25, 2018, at 12:51 PM, Don Hinton  wrote:
>>>
>>> On Thu, Jan 25, 2018 at 12:29 PM, Duncan P. N. Exon Smith <
>>> dexonsm...@apple.com> wrote:
>>>
 I don't really understand why, but our bots seemed to survive this:
 http://lab.llvm.org:8080/green/view/Libcxx/job/libcxx_master
 _cmake/2137/

 Console output is here:
 http://lab.llvm.org:8080/green/view/Libcxx/job/libcxx_master
 _cmake/2137/consoleFull

 That doesn't necessarily mean it's safe.  Does anyone know why this
 might have "worked"?

>>>
>>> I'm not an expert, but llvm installs all of these cmake modules along
>>> side llvm-config, so if you find llvm-config, you find these modules.
>>>
>>> So, unless I'm missing something, it looks like AddLLVM.cmake is always
>>> available.
>>>
>>>

 On Jan 25, 2018, at 11:02, Shoaib Meenai  wrote:

 This is going to break building libc++ standalone (i.e. without any
 LLVM repository or even its CMake modules), right? Some upstream users care
 a lot about that use case (CC beanz and Duncan).

 *From: *cfe-commits  on behalf of
 Don Hinton via cfe-commits 
 *Reply-To: *Don Hinton 
 *Date: *Thursday, January 25, 2018 at 10:15 AM
 *To: *"cfe-commits@lists.llvm.org" 
 *Subject: *[libcxx] r323453 - [cmake] [libcxx] Call llvm_setup_rpath()
 when adding shared libraries.

 Author: dhinton
 Date: Thu Jan 25 10:13:26 2018
 New Revision: 323453

 URL: https://urldefense.proofpoint.com/v2/url?u=http-3A__llv
 m.org_viewvc_llvm-2Dproject-3Frev-3D323453-26view-3Drev=Dw
 IGaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=zwv
 Smk9ZIfMARYg3JvYvNuA0Iz-PEq3H2i_ICF6vsR8=LDCu89byjNdZWoCIY
 HGHaPr3IamIdHLF0JwbnYE92vM=
 Log:
 [cmake] [libcxx] Call llvm_setup_rpath() when adding shared libraries.

 Clang and llvm already use llvm_setup_rpath(), so this change will
 help standarize rpath usage across all projects.

 Differential Revision: https://urldefense.p
 roofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D42459=D
 wIGaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=zw
 vSmk9ZIfMARYg3JvYvNuA0Iz-PEq3H2i_ICF6vsR8=YCR-YJBua5p-4IK0
 5GjHoZUU7aN8UJAFzL2xaz7byyw=

 Modified:
 libcxx/trunk/lib/CMakeLists.txt

 Modified: libcxx/trunk/lib/CMakeLists.txt
 URL: https://urldefense.proofpoint.com/v2/url?u=http-3A__llv
 m.org_viewvc_llvm-2Dproject_libcxx_trunk_lib_CMakeLists.txt-
 3Frev-3D323453-26r1-3D323452-26r2-3D323453-26view-3Ddiff=D

[PATCH] D16403: Add scope information to CFG

2018-01-26 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ added a comment.

> Do we need to have one-to-one mapping between ScopeBegins and corresponding 
> ScopeEnds or is it OK to assume that ScopeEnd can terminate several nested 
> scopes?

It's fine if `ScopeEnds` terminates multiple scopes - as long as it is easy to 
find out what scopes are being terminated by looking at it. Because in the 
analyzer we need to put the scope on the stack when we enter it and pop it from 
the stack when we leave it, and those must match no matter what. So imagine 
that we look at the current `ScopeEnd` and at the stack of scopes we currently 
have. Once we have that, we should be able to figure out what scopes are 
ending, without using `ParentMap` or `CFGStmtMap` or re-visiting a large chunk 
of the AST recursively - ideally by a direct lookup.


Repository:
  rL LLVM

https://reviews.llvm.org/D16403



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

[PATCH] D16403: Add scope information to CFG

2018-01-26 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ added a comment.

Hmm. @m.ostapenko @szepet @mgehre - I think it might be a good time to figure 
out if `ScopeBegin`/`ScopeEnd`, `LoopEntrance`/`LoopExit`, `LifetimeEnds`, 
`AutomaticObjectDtor` elements work nicely together. How should they be ordered 
with respect to each other? Is any of these scope representation a superset of 
another scope representation, or maybe fully covered by other two or three 
other scope representations? Would anybody be willing to produce some pictures 
(`-analyzer-checker debug.ViewCFG` and attach here) with current and/or 
intended behavior? Not sure, i guess `LifetimeEnds` is mostly used in 
`clang-tidy` so it does not necessarily need to work together with 
analyzer-specific elements (or maybe it's so great that we should switch to 
using it), but it would still be great if we had a single scope representation 
which would be rich enough to satisfy all needs.


Repository:
  rL LLVM

https://reviews.llvm.org/D16403



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

r323554 - Try to unbreak 32 bit builds after r323528.

2018-01-26 Thread Benjamin Kramer via cfe-commits

Author: d0k
Date: Fri Jan 26 12:01:13 2018
New Revision: 323554

URL: http://llvm.org/viewvc/llvm-project?rev=323554=rev
Log:
Try to unbreak 32 bit builds after r323528.

Modified:
cfe/trunk/include/clang/AST/Decl.h

Modified: cfe/trunk/include/clang/AST/Decl.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=323554=323553=323554=diff
==
--- cfe/trunk/include/clang/AST/Decl.h (original)
+++ cfe/trunk/include/clang/AST/Decl.h Fri Jan 26 12:01:13 2018
@@ -83,7 +83,7 @@ class VarTemplateDecl;
 /// TypeLoc TL = TypeSourceInfo->getTypeLoc();
 /// TL.getStartLoc().print(OS, SrcMgr);
 /// @endcode
-class TypeSourceInfo {
+class LLVM_ALIGNAS(8) TypeSourceInfo {
   // Contains a memory block after the class, used for type source information,
   // allocated by ASTContext.
   friend class ASTContext;
@@ -2813,7 +2813,10 @@ public:
 
 /// Base class for declarations which introduce a typedef-name.
 class TypedefNameDecl : public TypeDecl, public Redeclarable {
-  using ModedTInfo = std::pair;
+  struct LLVM_ALIGNAS(8) ModedTInfo {
+TypeSourceInfo *first;
+QualType second;
+  };
 
   /// If int part is 0, we have not computed IsTransparentTag.
   /// Otherwise, IsTransparentTag is (getInt() >> 1).
@@ -2877,7 +2880,7 @@ public:
 
   void setModedTypeSourceInfo(TypeSourceInfo *unmodedTSI, QualType modedTy) {
 MaybeModedTInfo.setPointer(new (getASTContext(), 8)
-   ModedTInfo(unmodedTSI, modedTy));
+   ModedTInfo({unmodedTSI, modedTy}));
   }
 
   /// Retrieves the canonical declaration of this typedef-name.


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

Re: r323528 - [AST] Use bit packing to reduce sizeof(TypedefNameDecl) from 88 to 80.

2018-01-26 Thread Vlad Tsyrklevich via cfe-commits

This change has broken a number of buildbots, e.g.
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/23163

On Fri, Jan 26, 2018 at 6:15 AM Benjamin Kramer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: d0k
> Date: Fri Jan 26 06:14:11 2018
> New Revision: 323528
>
> URL: http://llvm.org/viewvc/llvm-project?rev=323528=rev
> Log:
> [AST] Use bit packing to reduce sizeof(TypedefNameDecl) from 88 to 80.
>
> We can stash the cached transparent tag bit in existing pointer padding.
> Everything coming out of ASTContext is always aligned to a multiple of
> 8, so we have 8 spare bits.
>
> Modified:
> cfe/trunk/include/clang/AST/Decl.h
> cfe/trunk/lib/AST/Decl.cpp
>
> Modified: cfe/trunk/include/clang/AST/Decl.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=323528=323527=323528=diff
>
> ==
> --- cfe/trunk/include/clang/AST/Decl.h (original)
> +++ cfe/trunk/include/clang/AST/Decl.h Fri Jan 26 06:14:11 2018
> @@ -2814,12 +2814,12 @@ public:
>  /// Base class for declarations which introduce a typedef-name.
>  class TypedefNameDecl : public TypeDecl, public
> Redeclarable {
>using ModedTInfo = std::pair;
> -  llvm::PointerUnion MaybeModedTInfo;
>
> -  // FIXME: This can be packed into the bitfields in Decl.
> -  /// If 0, we have not computed IsTransparentTag.
> -  /// Otherwise, IsTransparentTag is (CacheIsTransparentTag >> 1).
> -  mutable unsigned CacheIsTransparentTag : 2;
> +  /// If int part is 0, we have not computed IsTransparentTag.
> +  /// Otherwise, IsTransparentTag is (getInt() >> 1).
> +  mutable llvm::PointerIntPair<
> +  llvm::PointerUnion, 2>
> +  MaybeModedTInfo;
>
>void anchor() override;
>
> @@ -2828,7 +2828,7 @@ protected:
>SourceLocation StartLoc, SourceLocation IdLoc,
>IdentifierInfo *Id, TypeSourceInfo *TInfo)
>: TypeDecl(DK, DC, IdLoc, Id, StartLoc), redeclarable_base(C),
> -MaybeModedTInfo(TInfo), CacheIsTransparentTag(0) {}
> +MaybeModedTInfo(TInfo, 0) {}
>
>using redeclarable_base = Redeclarable;
>
> @@ -2855,26 +2855,29 @@ public:
>using redeclarable_base::getMostRecentDecl;
>using redeclarable_base::isFirstDecl;
>
> -  bool isModed() const { return MaybeModedTInfo.is(); }
> +  bool isModed() const {
> +return MaybeModedTInfo.getPointer().is();
> +  }
>
>TypeSourceInfo *getTypeSourceInfo() const {
> -return isModed()
> -  ? MaybeModedTInfo.get()->first
> -  : MaybeModedTInfo.get();
> +return isModed() ? MaybeModedTInfo.getPointer().get *>()->first
> + : MaybeModedTInfo.getPointer().get *>();
>}
>
>QualType getUnderlyingType() const {
> -return isModed()
> -  ? MaybeModedTInfo.get()->second
> -  : MaybeModedTInfo.get()->getType();
> +return isModed() ? MaybeModedTInfo.getPointer().get *>()->second
> + : MaybeModedTInfo.getPointer()
> +   .get()
> +   ->getType();
>}
>
>void setTypeSourceInfo(TypeSourceInfo *newType) {
> -MaybeModedTInfo = newType;
> +MaybeModedTInfo.setPointer(newType);
>}
>
>void setModedTypeSourceInfo(TypeSourceInfo *unmodedTSI, QualType
> modedTy) {
> -MaybeModedTInfo = new (getASTContext()) ModedTInfo(unmodedTSI,
> modedTy);
> +MaybeModedTInfo.setPointer(new (getASTContext(), 8)
> +   ModedTInfo(unmodedTSI, modedTy));
>}
>
>/// Retrieves the canonical declaration of this typedef-name.
> @@ -2891,8 +2894,8 @@ public:
>/// Determines if this typedef shares a name and spelling location with
> its
>/// underlying tag type, as is the case with the NS_ENUM macro.
>bool isTransparentTag() const {
> -if (CacheIsTransparentTag)
> -  return CacheIsTransparentTag & 0x2;
> +if (MaybeModedTInfo.getInt())
> +  return MaybeModedTInfo.getInt() & 0x2;
>  return isTransparentTagSlow();
>}
>
>
> Modified: cfe/trunk/lib/AST/Decl.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=323528=323527=323528=diff
>
> ==
> --- cfe/trunk/lib/AST/Decl.cpp (original)
> +++ cfe/trunk/lib/AST/Decl.cpp Fri Jan 26 06:14:11 2018
> @@ -4372,9 +4372,7 @@ bool TypedefNameDecl::isTransparentTagSl
>};
>
>bool isTransparent = determineIsTransparent();
> -  CacheIsTransparentTag = 1;
> -  if (isTransparent)
> -CacheIsTransparentTag |= 0x2;
> +  MaybeModedTInfo.setInt((isTransparent << 1) | 1);
>return isTransparent;
>  }
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___

[PATCH] D42573: [wip] The new threading implementation

2018-01-26 Thread Sam McCall via Phabricator via cfe-commits

sammccall added a comment.

OK, here's a braindump, probably nothing surprising after our offline 
discussion.

TL;DR: the only design I *know* is extensible in ways we care about is the one 
that basically shards Scheduler into a bunch of per-TU schedulers.
I think that's probably the way to go, but if you can show how to cleanly 
extend one of the other options, we should compare those on the merits.

I think if we do adopt and stick with the sharding design, then a public API 
that reflects it is slightly nicer overall.
But it's not that important to me, tastes may vary, and above all I don't want 
to block the API patch on coming to a decision on the question above.
So I think we should agree on a name and then land the API patch with the 
interface it has now.




Comment at: clangd/ClangdServer.cpp:192
+
 Scheduler::Scheduler(unsigned AsyncThreadsCount, bool StorePreamblesInMemory,
  ASTParsedCallback ASTCallback)

So... scheduler and the queue abstraction.
This works pretty well for the functionality that's in this patch, which is at 
least as good as what's in the live version.
However I think we want to e.g. debounce diagnostic requests, and likely other 
such things, e.g. Indexing is a nice candidate for debouncing *and* preemption.

(Current diagnostics behavior: we compute and send diagnostics for the syntax 
error introduced by the first keystroke. This is wasted load, and increases 
latency for diagnostics on the *last* keystroke, since we have to wait for the 
previous one to finish)

So we should consider some other options...



Comment at: clangd/ClangdServer.cpp:193
 Scheduler::Scheduler(unsigned AsyncThreadsCount, bool StorePreamblesInMemory,
  ASTParsedCallback ASTCallback)
+: Data{StorePreamblesInMemory, std::make_shared(),

Option 1: Put all timing-related logic in scheduler.

I think this probably means Scheduler itself gets a thread whose job it is to 
wake up at certain times and schedule or cancel tasks on the queues.
`update` would set an alarm to add a task on the queue, which would be 
invalidated by any subsequent update. The easiest way to implement this is 
probably to track a version number that increments on update calls and is 
captured by the alarm.

This gets complicated by reads after updates that haven't finished yet - you 
need force the update to  happen now, so you need to schedule the thing and 
prevent the alarm from scheduling it.
It seems like in general trying to do nontrivial things may end up with a bunch 
of interacting actors and shared data structures that are hard to reason about 
and verify.



Comment at: clangd/ClangdServer.cpp:194
  ASTParsedCallback ASTCallback)
-: Units(StorePreamblesInMemory, std::make_shared(),
-std::move(ASTCallback)),
+: Data{StorePreamblesInMemory, std::make_shared(),
+   std::move(ASTCallback)},

Option 2: Share timing-related additions between scheduler and queue, but keep 
the tasks opaque to the queue.
This means extending the queue abstraction e.g. instead of just tasks, 
understand (delay, priority, task) tuples.

This isn't all that different from option 1, but moving some of the pieces out 
of scheduler might reduce the ball of hair to a manageable size, and add some 
conceptual clarity.



Comment at: clangd/ClangdServer.cpp:195
+: Data{StorePreamblesInMemory, std::make_shared(),
+   std::move(ASTCallback)},
   Executor(AsyncThreadsCount) {}

Option 3: extend the responsibilities of Queue so this is naturally its concern.
It needs to understand the timing, dependencies between tasks, and it probably 
makes sense to know when they become redundant etc too.

The easiest way to express this is that Queue owns a thread and implements the 
run-loop for actions on a single TU, and Scheduler's operations basically 
delegate to Queue. 

FWIW, this can be transformed into a version without dedicated threads. First 
we write the thread version in this form:

```
runLoop() {
  while (!shutdown) {
nextThing = decideWhatToDo(); // either action, or a sleep duration
if (nextThing.action)
  nextThing.action();
else
  interrupt.wait(nextThing.sleepDuration); // any update(), withAST etc 
interrupts
  }
}
```

I don't think it'd be hard to write a threadpool-based executor that runs 
"workloads" defined by their decideWhatToDo() function and their interactions 
with the `interrupt` condition variable. (I don't know exactly what a nice API 
would look like, but details...)

That said, I definitely think the thread/runloop based one is an easier place 
to start, and suspect it would be good enough.



Comment at: clangd/ClangdServer.cpp:196
+   std::move(ASTCallback)},
   Executor(AsyncThreadsCount) {}
 

My conclusion (feel free to

[PATCH] D42593: GCC compatibility: Ignore -fstack-clash-protection

2018-01-26 Thread Tom Stellard via Phabricator via cfe-commits

tstellar created this revision.
tstellar added a reviewer: sylvestre.ledru.

Repository:
  rC Clang

https://reviews.llvm.org/D42593

Files:
  include/clang/Driver/Options.td
  test/Driver/clang_f_opts.c


Index: test/Driver/clang_f_opts.c
===
--- test/Driver/clang_f_opts.c
+++ test/Driver/clang_f_opts.c
@@ -284,6 +284,7 @@
 // RUN: -ffriend-injection\
 // RUN: -fno-implement-inlines -fimplement-inlines\
 // RUN: -fstack-check \
+// RUN: -fstack-clash-protection  \
 // RUN: -fforce-addr  \
 // RUN: -malign-functions=100 \
 // RUN: -malign-loops=100 \
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -2705,6 +2705,7 @@
 Group;
 defm spec_constr_count : BooleanFFlag<"spec-constr-count">, 
Group;
 defm stack_check : BooleanFFlag<"stack-check">, Group;
+defm stack_clash_protection : BooleanFFlag<"stack-clash-protection">, 
Group;
 defm strength_reduce :
 BooleanFFlag<"strength-reduce">, 
Group;
 defm tls_model : BooleanFFlag<"tls-model">, Group;


Index: test/Driver/clang_f_opts.c
===
--- test/Driver/clang_f_opts.c
+++ test/Driver/clang_f_opts.c
@@ -284,6 +284,7 @@
 // RUN: -ffriend-injection\
 // RUN: -fno-implement-inlines -fimplement-inlines\
 // RUN: -fstack-check \
+// RUN: -fstack-clash-protection  \
 // RUN: -fforce-addr  \
 // RUN: -malign-functions=100 \
 // RUN: -malign-loops=100 \
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -2705,6 +2705,7 @@
 Group;
 defm spec_constr_count : BooleanFFlag<"spec-constr-count">, Group;
 defm stack_check : BooleanFFlag<"stack-check">, Group;
+defm stack_clash_protection : BooleanFFlag<"stack-clash-protection">, Group;
 defm strength_reduce :
 BooleanFFlag<"strength-reduce">, Group;
 defm tls_model : BooleanFFlag<"tls-model">, Group;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r323552 - [X86] Add 'rdrnd' feature to silvermont to match recent gcc bug fix.

2018-01-26 Thread Craig Topper via cfe-commits

Author: ctopper
Date: Fri Jan 26 11:34:45 2018
New Revision: 323552

URL: http://llvm.org/viewvc/llvm-project?rev=323552=rev
Log:
[X86] Add 'rdrnd' feature to silvermont to match recent gcc bug fix.

gcc recently fixed this bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83546

Modified:
cfe/trunk/lib/Basic/Targets/X86.cpp
cfe/trunk/test/Preprocessor/predefined-arch-macros.c

Modified: cfe/trunk/lib/Basic/Targets/X86.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/X86.cpp?rev=323552=323551=323552=diff
==
--- cfe/trunk/lib/Basic/Targets/X86.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/X86.cpp Fri Jan 26 11:34:45 2018
@@ -239,7 +239,6 @@ bool X86TargetInfo::initFeatureMap(
 
   case CK_Goldmont:
 setFeatureEnabledImpl(Features, "sha", true);
-setFeatureEnabledImpl(Features, "rdrnd", true);
 setFeatureEnabledImpl(Features, "rdseed", true);
 setFeatureEnabledImpl(Features, "xsave", true);
 setFeatureEnabledImpl(Features, "xsaveopt", true);
@@ -250,6 +249,7 @@ bool X86TargetInfo::initFeatureMap(
 setFeatureEnabledImpl(Features, "fsgsbase", true);
 LLVM_FALLTHROUGH;
   case CK_Silvermont:
+setFeatureEnabledImpl(Features, "rdrnd", true);
 setFeatureEnabledImpl(Features, "aes", true);
 setFeatureEnabledImpl(Features, "pclmul", true);
 setFeatureEnabledImpl(Features, "sse4.2", true);

Modified: cfe/trunk/test/Preprocessor/predefined-arch-macros.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/predefined-arch-macros.c?rev=323552=323551=323552=diff
==
--- cfe/trunk/test/Preprocessor/predefined-arch-macros.c (original)
+++ cfe/trunk/test/Preprocessor/predefined-arch-macros.c Fri Jan 26 11:34:45 
2018
@@ -1272,6 +1272,7 @@
 // CHECK_SLM_M32: #define __PCLMUL__ 1
 // CHECK_SLM_M32: #define __POPCNT__ 1
 // CHECK_SLM_M32: #define __PRFCHW__ 1
+// CHECK_SLM_M32: #define __RDRND__ 1
 // CHECK_SLM_M32: #define __SSE2__ 1
 // CHECK_SLM_M32: #define __SSE3__ 1
 // CHECK_SLM_M32: #define __SSE4_1__ 1
@@ -1293,6 +1294,7 @@
 // CHECK_SLM_M64: #define __PCLMUL__ 1
 // CHECK_SLM_M64: #define __POPCNT__ 1
 // CHECK_SLM_M64: #define __PRFCHW__ 1
+// CHECK_SLM_M64: #define __RDRND__ 1
 // CHECK_SLM_M64: #define __SSE2_MATH__ 1
 // CHECK_SLM_M64: #define __SSE2__ 1
 // CHECK_SLM_M64: #define __SSE3__ 1


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

[PATCH] D42588: [index] Fix crash when indexing a C++14 PCH/module related to TemplateTemplateParmDecls of alias templates

2018-01-26 Thread Phabricator via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL323549: [index] Fix crash when indexing a C++14 PCH/module 
related to… (authored by akirtzidis, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D42588?vs=131620=131629#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D42588

Files:
  cfe/trunk/lib/Index/IndexDecl.cpp
  cfe/trunk/lib/Serialization/ASTWriter.cpp
  cfe/trunk/test/Index/Core/index-pch.cpp


Index: cfe/trunk/lib/Serialization/ASTWriter.cpp
===
--- cfe/trunk/lib/Serialization/ASTWriter.cpp
+++ cfe/trunk/lib/Serialization/ASTWriter.cpp
@@ -5537,7 +5537,9 @@
 return;
   // FIXME: ParmVarDecls that are part of a function type of a parameter of
   // a function/objc method, should not have TU as lexical context.
-  if (isa(D))
+  // TemplateTemplateParmDecls that are part of an alias template, should not
+  // have TU as lexical context.
+  if (isa(D) || isa(D))
 return;
 
   SourceManager  = Context->getSourceManager();
Index: cfe/trunk/lib/Index/IndexDecl.cpp
===
--- cfe/trunk/lib/Index/IndexDecl.cpp
+++ cfe/trunk/lib/Index/IndexDecl.cpp
@@ -664,8 +664,11 @@
 
   bool VisitTemplateDecl(const TemplateDecl *D) {
 
-// Index the default values for the template parameters.
 const NamedDecl *Parent = D->getTemplatedDecl();
+if (!Parent)
+  return true;
+
+// Index the default values for the template parameters.
 if (D->getTemplateParameters() &&
 shouldIndexTemplateParameterDefaultValue(Parent)) {
   const TemplateParameterList *Params = D->getTemplateParameters();
@@ -684,7 +687,7 @@
   }
 }
 
-return Visit(D->getTemplatedDecl());
+return Visit(Parent);
   }
 
   bool VisitFriendDecl(const FriendDecl *D) {
Index: cfe/trunk/test/Index/Core/index-pch.cpp
===
--- cfe/trunk/test/Index/Core/index-pch.cpp
+++ cfe/trunk/test/Index/Core/index-pch.cpp
@@ -0,0 +1,17 @@
+// RUN: c-index-test core -print-source-symbols -- %s -std=c++14 | FileCheck %s
+// RUN: %clang_cc1 -emit-pch %s -std=c++14 -o %t.pch
+// RUN: c-index-test core -print-source-symbols -module-file %t.pch | 
FileCheck %s
+
+// CHECK: [[@LINE+2]]:8 | struct(Gen)/C++ | DETECTOR | [[DETECTOR_USR:.*]] | 
{{.*}} | Def | rel: 0
+template  class _Op, 
class... _Args>
+struct DETECTOR {
+ using value_t = int;
+};
+
+struct nonesuch {};
+
+// CHECK: [[@LINE+4]]:9 | type-alias/C++ | is_detected
+// CHECK: [[@LINE+3]]:32 | struct(Gen)/C++ | DETECTOR | [[DETECTOR_USR]] | 
{{.*}} | Ref,RelCont | rel: 1
+// CHECK-NEXT: RelCont | is_detected
+template

80 matches

Mail list logo