[PATCH] D36363: [test] Remove an unintentional -x cl flag in an aarch64-windows test

2017-08-06 Thread Mandeep Singh Grang via Phabricator via cfe-commits 
mgrang accepted this revision.
mgrang added a comment.
This revision is now accepted and ready to land.

LGTM.


https://reviews.llvm.org/D36363



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

[PATCH] D36371: [Clang][x86][Inline Asm] support for GCC style inline asm - Y constraints

2017-08-06 Thread coby via Phabricator via cfe-commits 
coby created this revision.

This patch is intended to enable the use of basic double letter constraints 
used in GCC extended inline asm {Yi Y2 Yz Y0 Ym Yt}.
Supersedes https://reviews.llvm.org/D32505
llvm counterpart: https://reviews.llvm.org/D36369


Repository:
  rL LLVM

https://reviews.llvm.org/D36371

Files:
  lib/Basic/Targets/X86.cpp
  lib/Basic/Targets/X86.h
  lib/CodeGen/TargetInfo.cpp


Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -22,6 +22,7 @@
 #include "clang/CodeGen/SwiftCallingConv.h"
 #include "clang/Frontend/CodeGenOptions.h"
 #include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringSwitch.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/IR/DataLayout.h"
 #include "llvm/IR/Type.h"
@@ -865,7 +866,10 @@
 static llvm::Type* X86AdjustInlineAsmType(CodeGen::CodeGenFunction &CGF,
   StringRef Constraint,
   llvm::Type* Ty) {
-  if ((Constraint == "y" || Constraint == "&y") && Ty->isVectorTy()) {
+  bool IsMMXCons = llvm::StringSwitch(Constraint)
+ .Cases("y", "&y", "^Ym", true)
+ .Default(false);
+  if (IsMMXCons && Ty->isVectorTy()) {
 if (cast(Ty)->getBitWidth() != 64) {
   // Invalid MMX constraint
   return nullptr;
Index: lib/Basic/Targets/X86.cpp
===
--- lib/Basic/Targets/X86.cpp
+++ lib/Basic/Targets/X86.cpp
@@ -1346,7 +1346,9 @@
 switch (*Name) {
 default:
   return false;
+case 'z':
 case '0': // First SSE register.
+case '2':
 case 't': // Any SSE register, when SSE2 is enabled.
 case 'i': // Any SSE register, when SSE2 and inter-unit moves enabled.
 case 'm': // Any MMX register, when inter-unit moves enabled.
@@ -1435,12 +1437,19 @@
   return Size <= 64;
 case 'i':
 case 't':
-  // 'Yi' and 'Yt' are synonymous with 'x' when SSE2 is enabled.
+case '2':
+  // 'Yi','Yt','Y2' are synonymous with 'x' when SSE2 is enabled.
+  // Any SSE register when SSE2 and up is available
   if (SSELevel >= AVX512F)
 return Size <= 512U;
   else if (SSELevel >= AVX)
 return Size <= 256U;
   return SSELevel >= SSE2 && Size <= 128U;
+case 'z':
+case '0':
+  // XMM0
+  if (SSELevel >= SSE1)
+return Size <= 128U;
 }
   }
 
@@ -1475,6 +1484,12 @@
   // the return string.
   break;
 case 'k':
+case 'm':
+case 'i':
+case 't':
+case 'z':
+case '0':
+case '2':
   // "^" hints llvm that this is a 2 letter constraint.
   // "Constraint++" is used to promote the string iterator
   // to the next constraint.
Index: lib/Basic/Targets/X86.h
===
--- lib/Basic/Targets/X86.h
+++ lib/Basic/Targets/X86.h
@@ -435,9 +435,12 @@
 // In case the constraint is 'r' we need to return Expression
 case 'r':
   return Expression;
+// Double letters Y constraints
+case 'Y':
+  if ((++I != E) && ((*I == '0') || (*I == 'z')))
+return "xmm0";
 default:
-  // Default value if there is no constraint for the register
-  return "";
+  LLVM_FALLTHROUGH;
 }
 return "";
   }


Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -22,6 +22,7 @@
 #include "clang/CodeGen/SwiftCallingConv.h"
 #include "clang/Frontend/CodeGenOptions.h"
 #include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringSwitch.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/IR/DataLayout.h"
 #include "llvm/IR/Type.h"
@@ -865,7 +866,10 @@
 static llvm::Type* X86AdjustInlineAsmType(CodeGen::CodeGenFunction &CGF,
   StringRef Constraint,
   llvm::Type* Ty) {
-  if ((Constraint == "y" || Constraint == "&y") && Ty->isVectorTy()) {
+  bool IsMMXCons = llvm::StringSwitch(Constraint)
+ .Cases("y", "&y", "^Ym", true)
+ .Default(false);
+  if (IsMMXCons && Ty->isVectorTy()) {
 if (cast(Ty)->getBitWidth() != 64) {
   // Invalid MMX constraint
   return nullptr;
Index: lib/Basic/Targets/X86.cpp
===
--- lib/Basic/Targets/X86.cpp
+++ lib/Basic/Targets/X86.cpp
@@ -1346,7 +1346,9 @@
 switch (*Name) {
 default:
   return false;
+case 'z':
 case '0': // First SSE register.
+case '2':
 case 't': // Any SSE register, when SSE2 is enabled.
 case 'i': // Any SSE register, when SSE2 and inter-unit moves enabled.
 case 'm': // Any MMX register, when inter-unit moves enabled.
@@ -1435,12 +1437,19 @@
   return Size <= 64;
 case 'i':
 case 't':
-

[PATCH] D36364: [AArch64] Add support for a MinGW AArch64 target

2017-08-06 Thread Martin Storsjö via Phabricator via cfe-commits 
mstorsjo added inline comments.



Comment at: lib/Driver/ToolChains/MinGW.cpp:122-131
   if (TC.getArch() == llvm::Triple::x86)
 CmdArgs.push_back("i386pe");
-  if (TC.getArch() == llvm::Triple::x86_64)
+  else if (TC.getArch() == llvm::Triple::x86_64)
 CmdArgs.push_back("i386pep");
-  if (TC.getArch() == llvm::Triple::arm)
+  else if (TC.getArch() == llvm::Triple::arm)
 CmdArgs.push_back("thumb2pe");
+  else if (TC.getArch() == llvm::Triple::aarch64)

compnerd wrote:
> Can you use a switch here instead?
Sure, I can change that.

What do you think about the `llvm_unreachable` part btw? There's nothing 
stopping a user from trigger that with e.g. `-target mips-windows-gnu`, and in 
release builds, such a `default: llvm_unreachable()` case usually ends up as 
just running one of the existing cases. Should it be changed into a real 
runtime error that isn't optimized out from release builds?


https://reviews.llvm.org/D36364



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

[PATCH] D36364: [AArch64] Add support for a MinGW AArch64 target

2017-08-06 Thread Martell Malone via Phabricator via cfe-commits 
martell added inline comments.



Comment at: lib/Driver/ToolChains/MinGW.cpp:129
+  else if (TC.getArch() == llvm::Triple::aarch64)
+CmdArgs.push_back("arm64pe");
+  else

I believe the reason I used thumb2pe for the arm triple is because MS gave us a 
watered down thumb environment.
If I remember correctly there was also an armce environment in binutils called 
thumbpe because it was thumb 1 mode.
Anyway, I assume aarch64 on windows is a fully fledged arm64 environment that 
doesn't use thumb mode over arm64?
I know we don't have any real sdk for this but are you able to tell from 
link.exe martin?
On arm the branch for a dll call would always set the bit for thumb mode in the 
instruction.
Although when I think about it arm64pe is probably the most suitable name 
anyway because we already use thumb2pe



https://reviews.llvm.org/D36364



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

[PATCH] D36364: [AArch64] Add support for a MinGW AArch64 target

2017-08-06 Thread Martin Storsjö via Phabricator via cfe-commits 
mstorsjo updated this revision to Diff 109916.
mstorsjo added a comment.

Updated to use a switch, added a mapping of a missed case of thumb while 
reformatting the if to a switch.


https://reviews.llvm.org/D36364

Files:
  lib/Basic/Targets.cpp
  lib/Basic/Targets/AArch64.cpp
  lib/Basic/Targets/AArch64.h
  lib/Driver/ToolChains/CrossWindows.cpp
  lib/Driver/ToolChains/MinGW.cpp
  test/Preprocessor/predefined-macros.c

Index: test/Preprocessor/predefined-macros.c
===
--- test/Preprocessor/predefined-macros.c
+++ test/Preprocessor/predefined-macros.c
@@ -199,3 +199,13 @@
 // CHECK-ARM64-WIN: #define _M_ARM64 1
 // CHECK-ARM64-WIN: #define _WIN32 1
 // CHECK-ARM64-WIN: #define _WIN64 1
+
+// RUN: %clang_cc1 -triple aarch64-windows-gnu %s -E -dM -o - \
+// RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-ARM64-MINGW
+
+// CHECK-ARM64-MINGW-NOT: #define _M_ARM64 1
+// CHECK-ARM64-MINGW: #define WIN32 1
+// CHECK-ARM64-MINGW: #define WIN64 1
+// CHECK-ARM64-MINGW: #define _WIN32 1
+// CHECK-ARM64-MINGW: #define _WIN64 1
+// CHECK-ARM64-MINGW: #define __aarch64__ 1
Index: lib/Driver/ToolChains/MinGW.cpp
===
--- lib/Driver/ToolChains/MinGW.cpp
+++ lib/Driver/ToolChains/MinGW.cpp
@@ -119,12 +119,23 @@
 CmdArgs.push_back("-s");
 
   CmdArgs.push_back("-m");
-  if (TC.getArch() == llvm::Triple::x86)
+  switch (TC.getArch()) {
+  case llvm::Triple::x86:
 CmdArgs.push_back("i386pe");
-  if (TC.getArch() == llvm::Triple::x86_64)
+break;
+  case llvm::Triple::x86_64:
 CmdArgs.push_back("i386pep");
-  if (TC.getArch() == llvm::Triple::arm)
+break;
+  case llvm::Triple::arm:
+  case llvm::Triple::thumb:
 CmdArgs.push_back("thumb2pe");
+break;
+  case llvm::Triple::aarch64:
+CmdArgs.push_back("arm64pe");
+break;
+  default:
+llvm_unreachable("Unsupported target architecture.");
+  }
 
   if (Args.hasArg(options::OPT_mwindows)) {
 CmdArgs.push_back("--subsystem");
Index: lib/Driver/ToolChains/CrossWindows.cpp
===
--- lib/Driver/ToolChains/CrossWindows.cpp
+++ lib/Driver/ToolChains/CrossWindows.cpp
@@ -36,6 +36,7 @@
 llvm_unreachable("unsupported architecture");
   case llvm::Triple::arm:
   case llvm::Triple::thumb:
+  case llvm::Triple::aarch64:
 break;
   case llvm::Triple::x86:
 CmdArgs.push_back("--32");
@@ -98,6 +99,9 @@
 // FIXME: this is incorrect for WinCE
 CmdArgs.push_back("thumb2pe");
 break;
+  case llvm::Triple::aarch64:
+CmdArgs.push_back("arm64pe");
+break;
   case llvm::Triple::x86:
 CmdArgs.push_back("i386pe");
 EntryPoint.append("_");
@@ -111,6 +115,7 @@
 switch (T.getArch()) {
 default:
   llvm_unreachable("unsupported architecture");
+case llvm::Triple::aarch64:
 case llvm::Triple::arm:
 case llvm::Triple::thumb:
 case llvm::Triple::x86_64:
Index: lib/Basic/Targets/AArch64.h
===
--- lib/Basic/Targets/AArch64.h
+++ lib/Basic/Targets/AArch64.h
@@ -89,24 +89,42 @@
   void setDataLayout() override;
 };
 
-class LLVM_LIBRARY_VISIBILITY MicrosoftARM64TargetInfo
+class LLVM_LIBRARY_VISIBILITY WindowsARM64TargetInfo
 : public WindowsTargetInfo {
   const llvm::Triple Triple;
 
 public:
-  MicrosoftARM64TargetInfo(const llvm::Triple &Triple,
-   const TargetOptions &Opts);
+  WindowsARM64TargetInfo(const llvm::Triple &Triple,
+ const TargetOptions &Opts);
 
   void setDataLayout() override;
 
+  BuiltinVaListKind getBuiltinVaListKind() const override;
+
+  CallingConvCheckResult checkCallingConvention(CallingConv CC) const override;
+};
+
+// Windows ARM, MS (C++) ABI
+class LLVM_LIBRARY_VISIBILITY MicrosoftARM64TargetInfo
+: public WindowsARM64TargetInfo {
+public:
+  MicrosoftARM64TargetInfo(const llvm::Triple &Triple,
+   const TargetOptions &Opts);
+
   void getVisualStudioDefines(const LangOptions &Opts,
   MacroBuilder &Builder) const;
   void getTargetDefines(const LangOptions &Opts,
 MacroBuilder &Builder) const override;
+};
 
-  BuiltinVaListKind getBuiltinVaListKind() const override;
+// ARM64 MinGW target
+class LLVM_LIBRARY_VISIBILITY MinGWARM64TargetInfo
+: public WindowsARM64TargetInfo {
+public:
+  MinGWARM64TargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts);
 
-  CallingConvCheckResult checkCallingConvention(CallingConv CC) const override;
+  void getTargetDefines(const LangOptions &Opts,
+MacroBuilder &Builder) const override;
 };
 
 class LLVM_LIBRARY_VISIBILITY AArch64beTargetInfo : public AArch64TargetInfo {
Index: lib/Basic/Targets/AArch64.cpp
===
--- lib/Basic/Targets/AArch64.cpp
+

[PATCH] D36364: [AArch64] Add support for a MinGW AArch64 target

2017-08-06 Thread Martin Storsjö via Phabricator via cfe-commits 
mstorsjo added inline comments.



Comment at: lib/Driver/ToolChains/MinGW.cpp:129
+  else if (TC.getArch() == llvm::Triple::aarch64)
+CmdArgs.push_back("arm64pe");
+  else

martell wrote:
> I believe the reason I used thumb2pe for the arm triple is because MS gave us 
> a watered down thumb environment.
> If I remember correctly there was also an armce environment in binutils 
> called thumbpe because it was thumb 1 mode.
> Anyway, I assume aarch64 on windows is a fully fledged arm64 environment that 
> doesn't use thumb mode over arm64?
> I know we don't have any real sdk for this but are you able to tell from 
> link.exe martin?
> On arm the branch for a dll call would always set the bit for thumb mode in 
> the instruction.
> Although when I think about it arm64pe is probably the most suitable name 
> anyway because we already use thumb2pe
> 
There's no thumb mode at all in 64 bit mode (yet at least), so naming it thumb* 
wouldn't make sense. Modelling the previous name after the old thumbpe makes 
sense though.


https://reviews.llvm.org/D36364



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

[PATCH] D36364: [AArch64] Add support for a MinGW AArch64 target

2017-08-06 Thread Martell Malone via Phabricator via cfe-commits 
martell added inline comments.



Comment at: lib/Driver/ToolChains/MinGW.cpp:129
+  else if (TC.getArch() == llvm::Triple::aarch64)
+CmdArgs.push_back("arm64pe");
+  else

mstorsjo wrote:
> martell wrote:
> > I believe the reason I used thumb2pe for the arm triple is because MS gave 
> > us a watered down thumb environment.
> > If I remember correctly there was also an armce environment in binutils 
> > called thumbpe because it was thumb 1 mode.
> > Anyway, I assume aarch64 on windows is a fully fledged arm64 environment 
> > that doesn't use thumb mode over arm64?
> > I know we don't have any real sdk for this but are you able to tell from 
> > link.exe martin?
> > On arm the branch for a dll call would always set the bit for thumb mode in 
> > the instruction.
> > Although when I think about it arm64pe is probably the most suitable name 
> > anyway because we already use thumb2pe
> > 
> There's no thumb mode at all in 64 bit mode (yet at least), so naming it 
> thumb* wouldn't make sense. Modelling the previous name after the old thumbpe 
> makes sense though.
Great, thanks. Just wanted to clarify because we never had a discussion about 
the naming.
LGTM


https://reviews.llvm.org/D36364



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

[PATCH] D35542: libcxxabi: Suppress LLVM_ENABLE_MODULES

2017-08-06 Thread NAKAMURA Takumi via Phabricator via cfe-commits 
chapuni added a comment.

@jroelofs Please do. libunwind emits unique module caches.

  module.cache/1JROMJZVPMD3F/std-WU7UZNPX10U5.pcm
  module.cache/1JROMJZVPMD3F/std_config-WU7UZNPX10U5.pcm
  module.cache/1JROMJZVPMD3F/_Builtin_stddef_max_align_t-1P37D07AX0QU6.pcm

They are not used outside the tree.


Repository:
  rL LLVM

https://reviews.llvm.org/D35542



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

[PATCH] D35038: [libunwind] Add a test harness

2017-08-06 Thread NAKAMURA Takumi via Phabricator via cfe-commits 
chapuni added inline comments.



Comment at: test/CMakeLists.txt:34
+  ${CMAKE_CURRENT_BINARY_DIR}
+  DEPENDS ${LIBUNWIND_TEST_DEPS}
+  )

Could you fill this, please?

  set(LIBUNWIND_TEST_DEPS
unwind
)

It makes "check-unwind" pass from clean.


https://reviews.llvm.org/D35038



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

[PATCH] D36364: [AArch64] Add support for a MinGW AArch64 target

2017-08-06 Thread Martell Malone via Phabricator via cfe-commits 
martell added inline comments.



Comment at: lib/Driver/ToolChains/MinGW.cpp:130
+  case llvm::Triple::arm:
+  case llvm::Triple::thumb:
 CmdArgs.push_back("thumb2pe");

I believe this was left incase someone wanted to do windows ce in future.
Can you add a todo like in CrossWindows.cpp in this case
`// FIXME: this is incorrect for WinCE`
or if we don't care about WinCE anymore just remove the TODO from CrossWindows?


https://reviews.llvm.org/D36364



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

[PATCH] D36378: Enable LLVM asan support for NetBSD/i386

2017-08-06 Thread Kamil Rytarowski via Phabricator via cfe-commits 
krytarowski created this revision.
krytarowski added a project: Sanitizers.

Verified to work and useful to run check-asan, as this target tests 32-bit and 
64-bit execution.

Sponsored by 


Repository:
  rL LLVM

https://reviews.llvm.org/D36378

Files:
  lib/Driver/ToolChains/NetBSD.cpp


Index: lib/Driver/ToolChains/NetBSD.cpp
===
--- lib/Driver/ToolChains/NetBSD.cpp
+++ lib/Driver/ToolChains/NetBSD.cpp
@@ -417,9 +417,10 @@
 }
 
 SanitizerMask NetBSD::getSupportedSanitizers() const {
+  const bool IsX86 = getTriple().getArch() == llvm::Triple::x86;
   const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
-  if (IsX86_64) {
+  if (IsX86 || IsX86_64) {
 Res |= SanitizerKind::Address;
   }
   return Res;


Index: lib/Driver/ToolChains/NetBSD.cpp
===
--- lib/Driver/ToolChains/NetBSD.cpp
+++ lib/Driver/ToolChains/NetBSD.cpp
@@ -417,9 +417,10 @@
 }
 
 SanitizerMask NetBSD::getSupportedSanitizers() const {
+  const bool IsX86 = getTriple().getArch() == llvm::Triple::x86;
   const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
-  if (IsX86_64) {
+  if (IsX86 || IsX86_64) {
 Res |= SanitizerKind::Address;
   }
   return Res;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36364: [AArch64] Add support for a MinGW AArch64 target

2017-08-06 Thread Martin Storsjö via Phabricator via cfe-commits 
mstorsjo added inline comments.



Comment at: lib/Driver/ToolChains/MinGW.cpp:130
+  case llvm::Triple::arm:
+  case llvm::Triple::thumb:
 CmdArgs.push_back("thumb2pe");

martell wrote:
> I believe this was left incase someone wanted to do windows ce in future.
> Can you add a todo like in CrossWindows.cpp in this case
> `// FIXME: this is incorrect for WinCE`
> or if we don't care about WinCE anymore just remove the TODO from 
> CrossWindows?
Sure, I can add a todo. I wanted to add it, since technically, the modern 
windows on arm stuff is thumb, we should handle it if the user uses the triple 
thumbv7-windows-gnu (iirc, some of the tests do).


https://reviews.llvm.org/D36364



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

[PATCH] D36353: Instantiate constexpr function when it is used

2017-08-06 Thread Serge Pavlov via Phabricator via cfe-commits 
sepavloff updated this revision to Diff 109928.
sepavloff added a comment.

Updated patch

I missed CWG issue 1581. It make patch description invalid, but the patch
itself can be repaired with small modification.

This fix originated from the attempt to solve the problem described in
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20170731/199590.html.
Compiler crashed on the code:

  template 
  constexpr void f(T) {
f(0);
  }

When parsing template body clang encounters f(0) and tries to immediately
instantiate f. It is not possible, because body of the function template
f is not available yet. Before r305903 (Function with unparsed body is a
definition) the function template f was considered as undefined and
instantiation request was silently ignored, so no error observed. With r305903
f is reported as defined but instantiation pattern is not available for it,
and the compilation crashes.

Instantiation request cannot be fulfilled during parsing of f, so
the instantiation of f must be postponed. CWG issue 1581 deals with
function calls which can be skipped for some reason. Return value of the call
in this case is ignored, so instantiation of such constexpr function makes
sense only if the body can trigger an error at instantiation, by static_assert,
throw or thing like T:error. If the above is true, constexpr functions does not
need to be instantiated in the point of use, it is sufficient to instantiate it
somewhere later, so that the diagnostics be be present.

According to investigation in https://bugs.llvm.org/show_bug.cgi?id=33561 too
early instantiation is a reason of hang if -fdelayed-template-parsing is used.
At least the reduced test case provided in that bug compiles successfully if
this patch is applied.

The fix was changed a bit so that constexpr functions are added to
PendingInstantiations, the call to isConstexpr is restored in SemaExpr.cpp.
The test from CWG issue 1581 was also added.


https://reviews.llvm.org/D36353

Files:
  include/clang/AST/ASTContext.h
  lib/AST/ASTContext.cpp
  lib/AST/ExprConstant.cpp
  lib/Sema/Sema.cpp
  lib/Sema/SemaExpr.cpp
  test/SemaTemplate/constexpr-instantiate.cpp
  test/SemaTemplate/instantiate-constexpr-function.cpp

Index: test/SemaTemplate/instantiate-constexpr-function.cpp
===
--- /dev/null
+++ test/SemaTemplate/instantiate-constexpr-function.cpp
@@ -0,0 +1,34 @@
+// RUN: %clang_cc1 -std=c++14 -verify %s
+// expected-no-diagnostics
+
+template constexpr void func_01(T) {
+  func_01(0);
+}
+
+
+template constexpr unsigned func_02a() {
+  return sizeof(T);
+}
+template constexpr T func_02b(T x) {
+  return x + func_02a();
+}
+constexpr long val_02 = func_02b(14L);
+
+
+template constexpr T func_03(T) {
+  return T::xyz;
+}
+template T func_04(T x) {
+  return x;
+}
+template<> constexpr long func_04(long x) {
+  return 66;
+}
+constexpr long var_04 = func_04(0L);
+static_assert(var_04 == 66, "error");
+
+
+template struct C_05 {
+  constexpr T func_05() { return T::xyz; }
+};
+C_05 var_05;
Index: test/SemaTemplate/constexpr-instantiate.cpp
===
--- test/SemaTemplate/constexpr-instantiate.cpp
+++ test/SemaTemplate/constexpr-instantiate.cpp
@@ -259,3 +259,9 @@
   }
   static_assert(fact(0) == 1, "");
 }
+
+namespace CWG_1581 {
+  template struct U {};
+  template constexpr int h(T) { return T::error; } // expected-error{{type 'int' cannot be used prior to '::' because it has no members}}
+  int k2 = sizeof(U<0 && h(0)>); // expected-note{{in instantiation of function template specialization 'CWG_1581::h' requested here}}
+}
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -13635,11 +13635,6 @@
   CodeSynthesisContexts.size())
 PendingLocalImplicitInstantiations.push_back(
 std::make_pair(Func, PointOfInstantiation));
-  else if (Func->isConstexpr())
-// Do not defer instantiations of constexpr functions, to avoid the
-// expression evaluator needing to call back into Sema if it sees a
-// call to such a function.
-InstantiateFunctionDefinition(PointOfInstantiation, Func);
   else {
 Func->setInstantiationIsPending(true);
 PendingInstantiations.push_back(std::make_pair(Func,
Index: lib/Sema/Sema.cpp
===
--- lib/Sema/Sema.cpp
+++ lib/Sema/Sema.cpp
@@ -113,6 +113,20 @@
 } // end namespace sema
 } // end namespace clang
 
+namespace {
+class SemaTemplateInstantiator : public ASTContext::InstantiationHelper {
+  Sema &S;
+public:
+  ~SemaTemplateInstantiator() {}
+  SemaTemplateInstantiator(Sema &S) : S(S) {}
+  bool instantiateFunctionDefinition(SourceLocation PointOfInstantiation,
+ FunctionDecl *Function) override {
+S.InstantiateFunc

[PATCH] D36353: Postpone instantiation of constexpr functions

2017-08-06 Thread Richard Smith - zygoloid via Phabricator via cfe-commits 
rsmith added inline comments.



Comment at: lib/Sema/Sema.cpp:189
+
+  Context.setInstantiator(new SemaTemplateInstantiator(*this));
 }

It's not correct/reasonable to instantiate whenever an expression happens to be 
evaluated, in numerous ways:

1) You'll get the "point of instantiation" wrong -- the standard only permits 
instantiation (as-if) immediately at the point of use or at the end of the 
translation unit
2) You risk instantiating at some points where no instantiation is permitted at 
all -- for instance, if SemaChecking decides it wants to try to evaluate some 
expression to produce a warning, and the code it tries to evaluate happens to 
be in an unevaluated operand, you are not permitted to instantiate things it 
references.
3) It risks making the set of instantiations / effective points of 
instantiation dependent on the warning flags that happen to be in effect, since 
existing code may or may not choose to evaluate an expression depending on 
warning flags.

Fundamentally, either constant expression evaluation needs to be side-effect 
free, or we need to distinguish between places where we happen to evaluate 
things and places where we evaluate things because the language requires them 
to be constant expressions. The current direction of CWG1581 is to make the 
"should we instantiate?" determination based solely on the syntactic context, 
which means that the constant expression evaluator should never trigger any 
instantiations.

In order to fix the case where a function/variable template specialization that 
is usable in a constant expression is defined after the point of use, I think 
we should check for pending instantiations of that function / variable template 
when we complete its definition, and perform those instantiations at that time.


https://reviews.llvm.org/D36353



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

Re: [PATCH] D24933: Enable configuration files in clang

2017-08-06 Thread Serge Pavlov via cfe-commits 
2017-08-06 6:43 GMT+07:00 Hal Finkel :

> On 07/24/2017 10:18 AM, Serge Pavlov wrote:
>
> I am thinking about reducing the patch further to leave only the ability
> to include config file when clang is called as `target-clang-drivermode`.
> It is still useful for cross compilation tasks because:
> - It is a convenient way to switch between supported targets,
> - SDK producer can ship compiler with a set of appropriate options or
> prepare them during installation.
> In this case if clang is called as `target-clang-drivermode`, it first
> tries to find file `target-drivermode.cfg` or `target.cfg` in a set of
> well-known directories, which in minimal case includes the directory where
> clang executable resides. If such file is found, options are  read from it,
> otherwise only option --target is added as clang does it now.
>
> This solution has obvious drawbacks:
> - User cannot specify config file in command line in the same way as he
> can choose a target: `clang --target `,
> - On Windows symlinks are implemented as file copy, the solution looks
> awkward.
> So more or less complete solution needs to allow specifying config file in
> command line.
>
>
> I'd rather not reduce the patch in this way, and you didn't describe why
> you're considering reducing the patch. Can you please elaborate?
>

The only intent was to facilitate review process.

>
> Using `@file` has some problems. Config file is merely a set of options,
> just as file included by `@file`. Different include file search is only a
> convenience and could be sacrificed. Comments and unused option warning
> suppression could be extended for all files included with `@file`. The real
> problem is the search path. To be useful, config files must be searched for
> in well-known directories, so that meaning of `clang @config_fille` does
> not depend on the current directory. So clang must have some rule to
> distinguish between config file and traditional use of `@file`. For
> instance, if file name ends with `.cfg` and there is a file with this name
> in config search directories, this is a config file and it is interpreted a
> bit differently. Of course, the file may be specified with full path, but
> this way is inconvenient.
>
>
> I see no reason why we can't unify the processing but have different
> search-path rules for @file vs. --config file.
>

Now I think we can use @file without breaking compatibility.

libiberty resolves `file` in `@file` always relative to current directory.
If such file is not found, it tries to open file with name `@file`. We must
keep this behavior for the sake of compatibility. If after these steps
`file` is not found and `file` does not contain directory separator, clang
could try to treat `file` as config file and search it using special search
path. If such solution is acceptable, we can get rid of `--config`.

Another possible solution is to extend meaning of `--target` so that it
> fully matches with the use of `target-clang-drivermode`, that is the option
> `--target=hexagon` causes clang first to look for the file `hexagon.cfg` in
> well-known directories and use it if found. In this case treatment of
> `--target` is different if the option is specified in command line or in
> the content of config file (in the latter case it is processed as target
> name only), it may be confusing. Besides, use of config files is not
> restricted to the choice of target.
>
>
> I think we should do this, so long as the implementation is reasonable,
> and the special case doesn't bother me in this regard. I don't view this as
> a replacement for '--config file', however, because, as you mention, the
> config files need not be restricted to target triples.
>

Different treatment of  `--target` in config file and in command line is
still a concern, to do or not to do this depends on which is looks more
intuitive. I would try implementing it is a separate patch.

Thanks,
--Serge



>
> Thanks again,
> Hal
>
>
> Using special option for config files does not bring risk of compatibility
> breakage and does not change meaning of existing options.
>
>
> Thanks,
> --Serge
>
> 2017-05-10 11:25 GMT+07:00 Serge Pavlov :
>
>> 2017-05-10 3:46 GMT+07:00 Richard Smith :
>>
>>> On 1 March 2017 at 02:50, Serge Pavlov via Phabricator <
>>> revi...@reviews.llvm.org> wrote:
>>>

 Format of configuration file is similar to file used in the construct
 `@file`, it is a set of options. Configuration file have advantage over
 this construct:

 - it is searched for in well-known places rather than in current
 directory,

>>>
>>> This (and suppressing unused-argument warnings) might well be sufficient
>>> to justify a different command-line syntax rather than @file...
>>>
>>
>> Construct `@file` in this implementation is used only to read parts of
>> config file inside containing file. Driver knows that it processes config
>> file and can adjust treatment of `@file`. On the other hand, driver might
>> parse config files

Re: [PATCH] D24933: Enable configuration files in clang

2017-08-06 Thread Hal Finkel via cfe-commits 


On 08/06/2017 01:15 PM, Serge Pavlov wrote:
2017-08-06 6:43 GMT+07:00 Hal Finkel >:


On 07/24/2017 10:18 AM, Serge Pavlov wrote:


I am thinking about reducing the patch further to leave only the
ability to include config file when clang is called as
`target-clang-drivermode`. It is still useful for cross
compilation tasks because:
- It is a convenient way to switch between supported targets,
- SDK producer can ship compiler with a set of appropriate
options or prepare them during installation.
In this case if clang is called as `target-clang-drivermode`, it
first tries to find file `target-drivermode.cfg` or `target.cfg`
in a set of well-known directories, which in minimal case
includes the directory where clang executable resides. If such
file is found, options are  read from it, otherwise only option
--target is added as clang does it now.

This solution has obvious drawbacks:
- User cannot specify config file in command line in the same way
as he can choose a target: `clang --target `,
- On Windows symlinks are implemented as file copy, the solution
looks awkward.
So more or less complete solution needs to allow specifying
config file in command line.


I'd rather not reduce the patch in this way, and you didn't
describe why you're considering reducing the patch. Can you please
elaborate?


The only intent was to facilitate review process.


As someone who's worked on reviewing the patches, I don't think this 
makes things any easier or harder. Once we decide on what we want to do, 
the rest of the review process should be straightforward.




Using `@file` has some problems. Config file is merely a set of
options, just as file included by `@file`. Different include file
search is only a convenience and could be sacrificed. Comments
and unused option warning suppression could be extended for all
files included with `@file`. The real problem is the search path.
To be useful, config files must be searched for in well-known
directories, so that meaning of `clang @config_fille` does not
depend on the current directory. So clang must have some rule to
distinguish between config file and traditional use of `@file`.
For instance, if file name ends with `.cfg` and there is a file
with this name in config search directories, this is a config
file and it is interpreted a bit differently. Of course, the file
may be specified with full path, but this way is inconvenient.


I see no reason why we can't unify the processing but have
different search-path rules for @file vs. --config file.


Now I think we can use @file without breaking compatibility.

libiberty resolves `file` in `@file` always relative to current 
directory. If such file is not found, it tries to open file with name 
`@file`. We must keep this behavior for the sake of compatibility. If 
after these steps `file` is not found and `file` does not contain 
directory separator, clang could try to treat `file` as config file 
and search it using special search path. If such solution is 
acceptable, we can get rid of `--config`.


I think that I'd prefer --config to this scheme. For one thing, it means 
that if I have a wrapper script that adds --config foo, this will break 
if the user happens to have a file named foo in their directory. I think 
that unifying the implementation of @foo and --config foo is a good 
idea, but combining them all into the same interface is not obviously 
optimal.


Thanks again,
Hal




Another possible solution is to extend meaning of `--target` so
that it fully matches with the use of `target-clang-drivermode`,
that is the option `--target=hexagon` causes clang first to look
for the file `hexagon.cfg` in well-known directories and use it
if found. In this case treatment of `--target` is different if
the option is specified in command line or in the content of
config file (in the latter case it is processed as target name
only), it may be confusing. Besides, use of config files is not
restricted to the choice of target.


I think we should do this, so long as the implementation is
reasonable, and the special case doesn't bother me in this regard.
I don't view this as a replacement for '--config file', however,
because, as you mention, the config files need not be restricted
to target triples.


Different treatment of  `--target` in config file and in command line 
is still a concern, to do or not to do this depends on which is looks 
more intuitive. I would try implementing it is a separate patch.


Thanks,
--Serge


Thanks again,
Hal



Using special option for config files does not bring risk of
compatibility breakage and does not change meaning of existing
options.


Thanks,
--Serge

2017-05-10 11:25 GMT+07:00 Serge Pavlov mailto:sepavl...@gmail.com>>:

Re: [PATCH] D24933: Enable configuration files in clang

2017-08-06 Thread Richard Smith via cfe-commits 
On 6 August 2017 at 11:15, Serge Pavlov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> 2017-08-06 6:43 GMT+07:00 Hal Finkel :
>
>> On 07/24/2017 10:18 AM, Serge Pavlov wrote:
>>
>> I am thinking about reducing the patch further to leave only the ability
>> to include config file when clang is called as `target-clang-drivermode`.
>> It is still useful for cross compilation tasks because:
>> - It is a convenient way to switch between supported targets,
>> - SDK producer can ship compiler with a set of appropriate options or
>> prepare them during installation.
>> In this case if clang is called as `target-clang-drivermode`, it first
>> tries to find file `target-drivermode.cfg` or `target.cfg` in a set of
>> well-known directories, which in minimal case includes the directory where
>> clang executable resides. If such file is found, options are  read from it,
>> otherwise only option --target is added as clang does it now.
>>
>> This solution has obvious drawbacks:
>> - User cannot specify config file in command line in the same way as he
>> can choose a target: `clang --target `,
>> - On Windows symlinks are implemented as file copy, the solution looks
>> awkward.
>> So more or less complete solution needs to allow specifying config file
>> in command line.
>>
>>
>> I'd rather not reduce the patch in this way, and you didn't describe why
>> you're considering reducing the patch. Can you please elaborate?
>>
>
> The only intent was to facilitate review process.
>
>>
>> Using `@file` has some problems. Config file is merely a set of options,
>> just as file included by `@file`. Different include file search is only a
>> convenience and could be sacrificed. Comments and unused option warning
>> suppression could be extended for all files included with `@file`. The real
>> problem is the search path. To be useful, config files must be searched for
>> in well-known directories, so that meaning of `clang @config_fille` does
>> not depend on the current directory. So clang must have some rule to
>> distinguish between config file and traditional use of `@file`. For
>> instance, if file name ends with `.cfg` and there is a file with this name
>> in config search directories, this is a config file and it is interpreted a
>> bit differently. Of course, the file may be specified with full path, but
>> this way is inconvenient.
>>
>>
>> I see no reason why we can't unify the processing but have different
>> search-path rules for @file vs. --config file.
>>
>
> Now I think we can use @file without breaking compatibility.
>
> libiberty resolves `file` in `@file` always relative to current directory.
> If such file is not found, it tries to open file with name `@file`. We must
> keep this behavior for the sake of compatibility.
>

Do you know of actual software that depends on the fallback working this
way? That seems very fragile to me, since a command line that uses @foo to
name the file ./@foo would change meaning if a file named foo were created.
Perhaps we should consider the fallback to be a mistake, and require files
whose name starts with @ to be named as ./@filename, just like we do for
files whose name starts with a hyphen.

If after these steps `file` is not found and `file` does not contain
> directory separator, clang could try to treat `file` as config file and
> search it using special search path. If such solution is acceptable, we can
> get rid of `--config`.
>

If we go this way, I think we should also deprecate the @file -> "open file
with name ./@file" (warn on it for now, with the intent to remove it in a
future version).

But... I think the concern about @ vs --config is principally around having
two different file formats, not about having two different command-line
syntaxes to specify a file, so this may be addressing a non-issue. And I
think the different use cases provide a decent argument for using different
search paths (compiler configs should live with the compiler, @-files are
expected to be generated by the user or the build system so should be found
relative to the current directory). Keeping the two separate but with a
unified format and internal mechanism seems like a good approach to me.

> Another possible solution is to extend meaning of `--target` so that it
>> fully matches with the use of `target-clang-drivermode`, that is the option
>> `--target=hexagon` causes clang first to look for the file `hexagon.cfg` in
>> well-known directories and use it if found. In this case treatment of
>> `--target` is different if the option is specified in command line or in
>> the content of config file (in the latter case it is processed as target
>> name only), it may be confusing. Besides, use of config files is not
>> restricted to the choice of target.
>>
>>
>> I think we should do this, so long as the implementation is reasonable,
>> and the special case doesn't bother me in this regard. I don't view this as
>> a replacement for '--config file', however, because, as you mention, the

[PATCH] D35056: GCC ABI incompatibility when passing object with trivial copy ctor, trivial dtor, and non-trivial move ctor

2017-08-06 Thread Vassil Vassilev via Phabricator via cfe-commits 
v.g.vassilev updated this revision to Diff 109932.
v.g.vassilev marked an inline comment as done.
v.g.vassilev added a comment.

We set the record's property denoting whether we can pass the decl by registers 
as a last step of `Sema::CheckCompletedCXXClass`. We cannot do it any earlier 
than that because we have not computed the triviality information.

This patch still eagerly defines too many implicit members. As discussed with 
@rsmith, he will take care of the non-trivial refactoring of 
`Sema::ShouldDeleteSpecialMember` to fix this regression.

This patch passes all tests in codegen but still fails a few which are 
sensitive to the amount of implicit members being created:

  Failing Tests (13):
  Clang :: CodeCompletion/ordinary-name-cxx11.cpp
  Clang :: Misc/ast-dump-color.cpp
  Clang :: Misc/ast-dump-decl.cpp
  Clang :: Misc/ast-dump-invalid.cpp
  Clang-Unit :: 
AST/./ASTTests/CXXMethodDecl.CXXMethodDeclWithNoExceptSpecification
  Clang-Unit :: 
ASTMatchers/./ASTMatchersTests/ConstructorDeclaration.IsImplicit
  Clang-Unit :: ASTMatchers/./ASTMatchersTests/ConstructorDeclaration.Kinds
  Clang-Unit :: ASTMatchers/./ASTMatchersTests/DeclarationMatcher.MatchNot
  Clang-Unit :: ASTMatchers/./ASTMatchersTests/DeclarationMatcher.hasMethod
  Clang-Unit :: 
ASTMatchers/./ASTMatchersTests/DeclaratorDecl.MatchesDeclaratorDecls
  Clang-Unit :: ASTMatchers/./ASTMatchersTests/Matcher.References
  Clang-Unit :: ASTMatchers/./ASTMatchersTests/TypeMatcher.MatchesClassType
  Clang-Unit :: 
ASTMatchers/Dynamic/./DynamicASTMatchersTests/RegistryTest.VariadicOp
  
Expected Passes: 10786
Expected Failures  : 17
Unsupported Tests  : 195
Unexpected Failures: 13


https://reviews.llvm.org/D35056

Files:
  include/clang/AST/DeclCXX.h
  include/clang/Sema/Sema.h
  lib/AST/ASTImporter.cpp
  lib/AST/DeclCXX.cpp
  lib/CodeGen/CGCXXABI.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/Sema/SemaDeclCXX.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriter.cpp
  test/CodeGenCXX/uncopyable-args.cpp

Index: test/CodeGenCXX/uncopyable-args.cpp
===
--- test/CodeGenCXX/uncopyable-args.cpp
+++ test/CodeGenCXX/uncopyable-args.cpp
@@ -52,12 +52,11 @@
 void bar() {
   foo({});
 }
-// FIXME: The copy ctor is implicitly deleted.
-// CHECK-DISABLED-LABEL: define void @_ZN9move_ctor3barEv()
-// CHECK-DISABLED: call void @_Z{{.*}}C1Ev(
-// CHECK-DISABLED-NOT: call
-// CHECK-DISABLED: call void @_ZN9move_ctor3fooENS_1AE(%"struct.move_ctor::A"* %{{.*}})
-// CHECK-DISABLED-LABEL: declare void @_ZN9move_ctor3fooENS_1AE(%"struct.move_ctor::A"*)
+// CHECK-LABEL: define void @_ZN9move_ctor3barEv()
+// CHECK: call void @_Z{{.*}}C1Ev(
+// CHECK-NOT: call
+// CHECK: call void @_ZN9move_ctor3fooENS_1AE(%"struct.move_ctor::A"* %{{.*}})
+// CHECK-LABEL: declare void @_ZN9move_ctor3fooENS_1AE(%"struct.move_ctor::A"*)
 
 // WIN64-LABEL: declare void @"\01?foo@move_ctor@@YAXUA@1@@Z"(%"struct.move_ctor::A"*)
 }
@@ -73,12 +72,11 @@
 void bar() {
   foo({});
 }
-// FIXME: The copy ctor is deleted.
-// CHECK-DISABLED-LABEL: define void @_ZN11all_deleted3barEv()
-// CHECK-DISABLED: call void @_Z{{.*}}C1Ev(
-// CHECK-DISABLED-NOT: call
-// CHECK-DISABLED: call void @_ZN11all_deleted3fooENS_1AE(%"struct.all_deleted::A"* %{{.*}})
-// CHECK-DISABLED-LABEL: declare void @_ZN11all_deleted3fooENS_1AE(%"struct.all_deleted::A"*)
+// CHECK-LABEL: define void @_ZN11all_deleted3barEv()
+// CHECK: call void @_Z{{.*}}C1Ev(
+// CHECK-NOT: call
+// CHECK: call void @_ZN11all_deleted3fooENS_1AE(%"struct.all_deleted::A"* %{{.*}})
+// CHECK-LABEL: declare void @_ZN11all_deleted3fooENS_1AE(%"struct.all_deleted::A"*)
 
 // WIN64-LABEL: declare void @"\01?foo@all_deleted@@YAXUA@1@@Z"(%"struct.all_deleted::A"*)
 }
@@ -93,12 +91,11 @@
 void bar() {
   foo({});
 }
-// FIXME: The copy and move ctors are implicitly deleted.
-// CHECK-DISABLED-LABEL: define void @_ZN18implicitly_deleted3barEv()
-// CHECK-DISABLED: call void @_Z{{.*}}C1Ev(
-// CHECK-DISABLED-NOT: call
-// CHECK-DISABLED: call void @_ZN18implicitly_deleted3fooENS_1AE(%"struct.implicitly_deleted::A"* %{{.*}})
-// CHECK-DISABLED-LABEL: declare void @_ZN18implicitly_deleted3fooENS_1AE(%"struct.implicitly_deleted::A"*)
+// CHECK-LABEL: define void @_ZN18implicitly_deleted3barEv()
+// CHECK: call void @_Z{{.*}}C1Ev(
+// CHECK-NOT: call
+// CHECK: call void @_ZN18implicitly_deleted3fooENS_1AE(%"struct.implicitly_deleted::A"* %{{.*}})
+// CHECK-LABEL: declare void @_ZN18implicitly_deleted3fooENS_1AE(%"struct.implicitly_deleted::A"*)
 
 // WIN64-LABEL: declare void @"\01?foo@implicitly_deleted@@YAXUA@1@@Z"(%"struct.implicitly_deleted::A"*)
 }
@@ -113,12 +110,11 @@
 void bar() {
   foo({});
 }
-// FIXME: The copy constructor is implicitly deleted.
-// CHECK-DISABLED-LABEL: define void @_ZN11one_deleted3barEv()
-// CHECK-DISABLED: call void @_Z{{.*}}C1Ev(
-// CHECK-DISABLED-NOT: call
-// CHECK

[PATCH] D36364: [AArch64] Add support for a MinGW AArch64 target

2017-08-06 Thread Martin Storsjö via Phabricator via cfe-commits 
mstorsjo updated this revision to Diff 109935.
mstorsjo added a comment.

Added a fixme comment about this being incorrect for WinCE.


https://reviews.llvm.org/D36364

Files:
  lib/Basic/Targets.cpp
  lib/Basic/Targets/AArch64.cpp
  lib/Basic/Targets/AArch64.h
  lib/Driver/ToolChains/CrossWindows.cpp
  lib/Driver/ToolChains/MinGW.cpp
  test/Preprocessor/predefined-macros.c

Index: test/Preprocessor/predefined-macros.c
===
--- test/Preprocessor/predefined-macros.c
+++ test/Preprocessor/predefined-macros.c
@@ -199,3 +199,13 @@
 // CHECK-ARM64-WIN: #define _M_ARM64 1
 // CHECK-ARM64-WIN: #define _WIN32 1
 // CHECK-ARM64-WIN: #define _WIN64 1
+
+// RUN: %clang_cc1 -triple aarch64-windows-gnu %s -E -dM -o - \
+// RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-ARM64-MINGW
+
+// CHECK-ARM64-MINGW-NOT: #define _M_ARM64 1
+// CHECK-ARM64-MINGW: #define WIN32 1
+// CHECK-ARM64-MINGW: #define WIN64 1
+// CHECK-ARM64-MINGW: #define _WIN32 1
+// CHECK-ARM64-MINGW: #define _WIN64 1
+// CHECK-ARM64-MINGW: #define __aarch64__ 1
Index: lib/Driver/ToolChains/MinGW.cpp
===
--- lib/Driver/ToolChains/MinGW.cpp
+++ lib/Driver/ToolChains/MinGW.cpp
@@ -119,12 +119,24 @@
 CmdArgs.push_back("-s");
 
   CmdArgs.push_back("-m");
-  if (TC.getArch() == llvm::Triple::x86)
+  switch (TC.getArch()) {
+  case llvm::Triple::x86:
 CmdArgs.push_back("i386pe");
-  if (TC.getArch() == llvm::Triple::x86_64)
+break;
+  case llvm::Triple::x86_64:
 CmdArgs.push_back("i386pep");
-  if (TC.getArch() == llvm::Triple::arm)
+break;
+  case llvm::Triple::arm:
+  case llvm::Triple::thumb:
+// FIXME: this is incorrect for WinCE
 CmdArgs.push_back("thumb2pe");
+break;
+  case llvm::Triple::aarch64:
+CmdArgs.push_back("arm64pe");
+break;
+  default:
+llvm_unreachable("Unsupported target architecture.");
+  }
 
   if (Args.hasArg(options::OPT_mwindows)) {
 CmdArgs.push_back("--subsystem");
Index: lib/Driver/ToolChains/CrossWindows.cpp
===
--- lib/Driver/ToolChains/CrossWindows.cpp
+++ lib/Driver/ToolChains/CrossWindows.cpp
@@ -36,6 +36,7 @@
 llvm_unreachable("unsupported architecture");
   case llvm::Triple::arm:
   case llvm::Triple::thumb:
+  case llvm::Triple::aarch64:
 break;
   case llvm::Triple::x86:
 CmdArgs.push_back("--32");
@@ -98,6 +99,9 @@
 // FIXME: this is incorrect for WinCE
 CmdArgs.push_back("thumb2pe");
 break;
+  case llvm::Triple::aarch64:
+CmdArgs.push_back("arm64pe");
+break;
   case llvm::Triple::x86:
 CmdArgs.push_back("i386pe");
 EntryPoint.append("_");
@@ -111,6 +115,7 @@
 switch (T.getArch()) {
 default:
   llvm_unreachable("unsupported architecture");
+case llvm::Triple::aarch64:
 case llvm::Triple::arm:
 case llvm::Triple::thumb:
 case llvm::Triple::x86_64:
Index: lib/Basic/Targets/AArch64.h
===
--- lib/Basic/Targets/AArch64.h
+++ lib/Basic/Targets/AArch64.h
@@ -89,24 +89,42 @@
   void setDataLayout() override;
 };
 
-class LLVM_LIBRARY_VISIBILITY MicrosoftARM64TargetInfo
+class LLVM_LIBRARY_VISIBILITY WindowsARM64TargetInfo
 : public WindowsTargetInfo {
   const llvm::Triple Triple;
 
 public:
-  MicrosoftARM64TargetInfo(const llvm::Triple &Triple,
-   const TargetOptions &Opts);
+  WindowsARM64TargetInfo(const llvm::Triple &Triple,
+ const TargetOptions &Opts);
 
   void setDataLayout() override;
 
+  BuiltinVaListKind getBuiltinVaListKind() const override;
+
+  CallingConvCheckResult checkCallingConvention(CallingConv CC) const override;
+};
+
+// Windows ARM, MS (C++) ABI
+class LLVM_LIBRARY_VISIBILITY MicrosoftARM64TargetInfo
+: public WindowsARM64TargetInfo {
+public:
+  MicrosoftARM64TargetInfo(const llvm::Triple &Triple,
+   const TargetOptions &Opts);
+
   void getVisualStudioDefines(const LangOptions &Opts,
   MacroBuilder &Builder) const;
   void getTargetDefines(const LangOptions &Opts,
 MacroBuilder &Builder) const override;
+};
 
-  BuiltinVaListKind getBuiltinVaListKind() const override;
+// ARM64 MinGW target
+class LLVM_LIBRARY_VISIBILITY MinGWARM64TargetInfo
+: public WindowsARM64TargetInfo {
+public:
+  MinGWARM64TargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts);
 
-  CallingConvCheckResult checkCallingConvention(CallingConv CC) const override;
+  void getTargetDefines(const LangOptions &Opts,
+MacroBuilder &Builder) const override;
 };
 
 class LLVM_LIBRARY_VISIBILITY AArch64beTargetInfo : public AArch64TargetInfo {
Index: lib/Basic/Targets/AArch64.cpp
===
--- lib/Basic/Targets/AArch64.cpp
+++ l

r310222 - [test] Remove an unintentional -x cl flag in an aarch64-windows test

2017-08-06 Thread Martin Storsjo via cfe-commits 
Author: mstorsjo
Date: Sun Aug  6 12:57:49 2017
New Revision: 310222

URL: http://llvm.org/viewvc/llvm-project?rev=310222&view=rev
Log:
[test] Remove an unintentional -x cl flag in an aarch64-windows test

This test was only intended to test compiling C, not OpenCL.

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

Modified:
cfe/trunk/test/Preprocessor/predefined-macros.c

Modified: cfe/trunk/test/Preprocessor/predefined-macros.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/predefined-macros.c?rev=310222&r1=310221&r2=310222&view=diff
==
--- cfe/trunk/test/Preprocessor/predefined-macros.c (original)
+++ cfe/trunk/test/Preprocessor/predefined-macros.c Sun Aug  6 12:57:49 2017
@@ -193,7 +193,7 @@
 // MSCOPE:#define __OPENCL_MEMORY_SCOPE_WORK_GROUP 1
 // MSCOPE:#define __OPENCL_MEMORY_SCOPE_WORK_ITEM 0
 
-// RUN: %clang_cc1 -triple aarch64-windows %s -E -dM -o - -x cl \
+// RUN: %clang_cc1 -triple aarch64-windows %s -E -dM -o - \
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-ARM64-WIN
 
 // CHECK-ARM64-WIN: #define _M_ARM64 1


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

[PATCH] D36363: [test] Remove an unintentional -x cl flag in an aarch64-windows test

2017-08-06 Thread Martin Storsjö via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL310222: [test] Remove an unintentional -x cl flag in an 
aarch64-windows test (authored by mstorsjo).

Changed prior to commit:
  https://reviews.llvm.org/D36363?vs=109889&id=109936#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D36363

Files:
  cfe/trunk/test/Preprocessor/predefined-macros.c


Index: cfe/trunk/test/Preprocessor/predefined-macros.c
===
--- cfe/trunk/test/Preprocessor/predefined-macros.c
+++ cfe/trunk/test/Preprocessor/predefined-macros.c
@@ -193,7 +193,7 @@
 // MSCOPE:#define __OPENCL_MEMORY_SCOPE_WORK_GROUP 1
 // MSCOPE:#define __OPENCL_MEMORY_SCOPE_WORK_ITEM 0
 
-// RUN: %clang_cc1 -triple aarch64-windows %s -E -dM -o - -x cl \
+// RUN: %clang_cc1 -triple aarch64-windows %s -E -dM -o - \
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-ARM64-WIN
 
 // CHECK-ARM64-WIN: #define _M_ARM64 1


Index: cfe/trunk/test/Preprocessor/predefined-macros.c
===
--- cfe/trunk/test/Preprocessor/predefined-macros.c
+++ cfe/trunk/test/Preprocessor/predefined-macros.c
@@ -193,7 +193,7 @@
 // MSCOPE:#define __OPENCL_MEMORY_SCOPE_WORK_GROUP 1
 // MSCOPE:#define __OPENCL_MEMORY_SCOPE_WORK_ITEM 0
 
-// RUN: %clang_cc1 -triple aarch64-windows %s -E -dM -o - -x cl \
+// RUN: %clang_cc1 -triple aarch64-windows %s -E -dM -o - \
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-ARM64-WIN
 
 // CHECK-ARM64-WIN: #define _M_ARM64 1
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxxabi] r310226 - [demangler] Fix another oss-fuzz bug

2017-08-06 Thread Erik Pilkington via cfe-commits 
Author: epilk
Date: Sun Aug  6 13:46:33 2017
New Revision: 310226

URL: http://llvm.org/viewvc/llvm-project?rev=310226&view=rev
Log:
[demangler] Fix another oss-fuzz bug

Modified:
libcxxabi/trunk/src/cxa_demangle.cpp
libcxxabi/trunk/test/test_demangle.pass.cpp

Modified: libcxxabi/trunk/src/cxa_demangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/cxa_demangle.cpp?rev=310226&r1=310225&r2=310226&view=diff
==
--- libcxxabi/trunk/src/cxa_demangle.cpp (original)
+++ libcxxabi/trunk/src/cxa_demangle.cpp Sun Aug  6 13:46:33 2017
@@ -2896,7 +2896,7 @@ parse_new_expr(const char* first, const
 return first;
 init_list = db.popTrailingNodeArray(init_list_begin);
 }
-if (*t != 'E')
+if (*t != 'E' || db.names.empty())
 return first;
 auto type = db.names.back();
 db.names.pop_back();

Modified: libcxxabi/trunk/test/test_demangle.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/test_demangle.pass.cpp?rev=310226&r1=310225&r2=310226&view=diff
==
--- libcxxabi/trunk/test/test_demangle.pass.cpp (original)
+++ libcxxabi/trunk/test/test_demangle.pass.cpp Sun Aug  6 13:46:33 2017
@@ -29677,6 +29677,7 @@ const char* invalid_cases[] =
 "FSiIJEENT_IoE ",
 "ZTVSiIZTVSiIZTVSiIZTVSiINIJEET_T_T_T_T_ ",
 
"_ZSiIJEttvvET_v",
+"Ana_T_E_T_IJEffersfrsrsffbgE",
 };
 
 const unsigned NI = sizeof(invalid_cases) / sizeof(invalid_cases[0]);


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

[PATCH] D34784: [OpenMP] Add flag for specifying the target device architecture for OpenMP device offloading

2017-08-06 Thread Gheorghe-Teodor Bercea via Phabricator via cfe-commits 
gtbercea updated this revision to Diff 109938.
gtbercea added a comment.

Address comments.


https://reviews.llvm.org/D34784

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  include/clang/Driver/Options.td
  include/clang/Driver/ToolChain.h
  lib/Driver/Compilation.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains/Cuda.cpp
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -597,3 +597,35 @@
 // RUN:   | FileCheck -check-prefix=CHK-FOPENMP-IS-DEVICE %s
 
 // CHK-FOPENMP-IS-DEVICE: clang{{.*}} "-aux-triple" "powerpc64le--linux" {{.*}}.c" "-fopenmp-is-device" "-fopenmp-host-ir-file-path"
+
+/// ###
+
+/// Check -Xopenmp-target=powerpc64le-ibm-linux-gnu -march=pwr8 is passed when compiling for the device.
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target=powerpc64le-ibm-linux-gnu -mcpu=pwr7 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-FOPENMP-EQ-TARGET %s
+
+// CHK-FOPENMP-EQ-TARGET: clang{{.*}} "-target-cpu" "pwr7"
+
+/// ###
+
+/// Check -Xopenmp-target -march=pwr8 is passed when compiling for the device.
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target -mcpu=pwr7 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-FOPENMP-TARGET %s
+
+// CHK-FOPENMP-TARGET: clang{{.*}} "-target-cpu" "pwr7"
+
+/// ###
+
+/// Check -Xopenmp-target triggers error when multiple triples are used.
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu,powerpc64le-unknown-linux-gnu -Xopenmp-target -mcpu=pwr8 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-FOPENMP-TARGET-AMBIGUOUS-ERROR %s
+
+// CHK-FOPENMP-TARGET-AMBIGUOUS-ERROR: clang{{.*}} error: cannot deduce implicit triple value for -Xopenmp-target, specify triple using -Xopenmp-target=
+
+/// ###
+
+/// Check -Xopenmp-target triggers error when an option requiring arguments is passed to it.
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target -Xopenmp-target -mcpu=pwr8 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-FOPENMP-TARGET-NESTED-ERROR %s
+
+// CHK-FOPENMP-TARGET-NESTED-ERROR: clang{{.*}} error: invalid -Xopenmp-target argument: '-Xopenmp-target -Xopenmp-target', options requiring arguments are unsupported
Index: lib/Driver/ToolChains/Cuda.cpp
===
--- lib/Driver/ToolChains/Cuda.cpp
+++ lib/Driver/ToolChains/Cuda.cpp
@@ -212,8 +212,20 @@
   static_cast(getToolChain());
   assert(TC.getTriple().isNVPTX() && "Wrong platform");
 
+  StringRef GPUArchName;
+  std::vector GPUArchNames;
+  // If this is an OpenMP action we need to extract the device architecture from
+  // the -fopenmp-target-arch option.
+  if (JA.isDeviceOffloading(Action::OFK_OpenMP)) {
+GPUArchNames = Args.getAllArgValues(options::OPT_march_EQ);
+assert(GPUArchNames.size() == 1 &&
+   "Exactly one GPU Arch required for ptxas.");
+GPUArchName = GPUArchNames[0];
+  } else
+GPUArchName = JA.getOffloadingArch();
+
   // Obtain architecture from the action.
-  CudaArch gpu_arch = StringToCudaArch(JA.getOffloadingArch());
+  CudaArch gpu_arch = StringToCudaArch(GPUArchName);
   assert(gpu_arch != CudaArch::UNKNOWN &&
  "Device action expected to have an architecture.");
 
@@ -405,7 +417,7 @@
 
   // For OpenMP device offloading, append derived arguments. Make sure
   // flags are not duplicated.
-  // TODO: Append the compute capability.
+  // Also append the compute capability.
   if (DeviceOffloadKind == Action::OFK_OpenMP) {
 for (Arg *A : Args){
   bool IsDuplicate = false;
@@ -418,6 +430,15 @@
   if (!IsDuplicate)
 DAL->append(A);
 }
+
+auto MArchList = DAL->getAllArgValues(options::OPT_march_EQ);
+assert(MArchList.size() < 2 &&
+   "Too many archs under -Xopenmp-targets");
+if (MArchList.empty())
+  // Default compute capability for CUDA toolchain is sm_20.
+  DAL->AddJoinedArg(nullptr,
+  Opts.getOption(options::OPT_march_EQ), "sm_20");
+
 return DAL;
   }
 
Index: lib/Driver/ToolChain.cpp
===
--- lib/Driver/ToolChain.cpp
+++ lib/Driver/ToolChain.cpp
@@ -775,3 +775,69 @@
 
   return VersionTuple();
 }
+
+llvm::opt::DerivedArgList *
+ToolChain::TranslateOpenMPTargetArgs(const llvm::opt::DerivedArgList &Args,
+Action::OffloadKind DeviceOffloadKind) const {
+  if (DeviceOffloadKind == Action::OFK_OpenMP) {
+DerivedArgList *DAL = new DerivedArgList(Ar

[PATCH] D34784: [OpenMP] Add flag for specifying the target device architecture for OpenMP device offloading

2017-08-06 Thread Gheorghe-Teodor Bercea via Phabricator via cfe-commits 
gtbercea added inline comments.



Comment at: lib/Driver/ToolChain.cpp:808
+  continue;
+  } else if (XOpenMPTargetNoTriple)
+// Passing device args: -Xopenmp-target -opt=val.

hfinkel wrote:
> Please include {} around this else-if  code, even though it is not necessary, 
> because the other blocks require it.
Done



Comment at: lib/Driver/ToolChain.cpp:820
+  if (!XOpenMPTargetArg || Index > Prev + 1) {
+getDriver().Diag(diag::err_drv_invalid_Xopenmp_target_with_args)
+<< A->getAsString(Args);

hfinkel wrote:
> Is this covered by a test case?
Done



Comment at: lib/Driver/ToolChain.cpp:827
+  options::OPT_fopenmp_targets_EQ).size() != 1) {
+getDriver().Diag(diag::err_drv_Xopenmp_target_missing_triple);
+continue;

hfinkel wrote:
> Is this covered by a test case?
Done



Comment at: test/Driver/openmp-offload.c:615
+
+// CHK-FOPENMP-TARGET: clang{{.*}} argument unused during compilation: 
'-Xopenmp-target -march=pwr8'

hfinkel wrote:
> Now that this is in common code, why are these arguments still unused?
Fixed.


https://reviews.llvm.org/D34784



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

[PATCH] D34784: [OpenMP] Add flag for specifying the target device architecture for OpenMP device offloading

2017-08-06 Thread Gheorghe-Teodor Bercea via Phabricator via cfe-commits 
gtbercea updated this revision to Diff 109939.
gtbercea added a comment.

Fix -march special casing.


https://reviews.llvm.org/D34784

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  include/clang/Driver/Options.td
  include/clang/Driver/ToolChain.h
  lib/Driver/Compilation.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains/Cuda.cpp
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -597,3 +597,35 @@
 // RUN:   | FileCheck -check-prefix=CHK-FOPENMP-IS-DEVICE %s
 
 // CHK-FOPENMP-IS-DEVICE: clang{{.*}} "-aux-triple" "powerpc64le--linux" {{.*}}.c" "-fopenmp-is-device" "-fopenmp-host-ir-file-path"
+
+/// ###
+
+/// Check -Xopenmp-target=powerpc64le-ibm-linux-gnu -march=pwr8 is passed when compiling for the device.
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target=powerpc64le-ibm-linux-gnu -mcpu=pwr7 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-FOPENMP-EQ-TARGET %s
+
+// CHK-FOPENMP-EQ-TARGET: clang{{.*}} "-target-cpu" "pwr7"
+
+/// ###
+
+/// Check -Xopenmp-target -march=pwr8 is passed when compiling for the device.
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target -mcpu=pwr7 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-FOPENMP-TARGET %s
+
+// CHK-FOPENMP-TARGET: clang{{.*}} "-target-cpu" "pwr7"
+
+/// ###
+
+/// Check -Xopenmp-target triggers error when multiple triples are used.
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu,powerpc64le-unknown-linux-gnu -Xopenmp-target -mcpu=pwr8 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-FOPENMP-TARGET-AMBIGUOUS-ERROR %s
+
+// CHK-FOPENMP-TARGET-AMBIGUOUS-ERROR: clang{{.*}} error: cannot deduce implicit triple value for -Xopenmp-target, specify triple using -Xopenmp-target=
+
+/// ###
+
+/// Check -Xopenmp-target triggers error when an option requiring arguments is passed to it.
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target -Xopenmp-target -mcpu=pwr8 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-FOPENMP-TARGET-NESTED-ERROR %s
+
+// CHK-FOPENMP-TARGET-NESTED-ERROR: clang{{.*}} error: invalid -Xopenmp-target argument: '-Xopenmp-target -Xopenmp-target', options requiring arguments are unsupported
Index: lib/Driver/ToolChains/Cuda.cpp
===
--- lib/Driver/ToolChains/Cuda.cpp
+++ lib/Driver/ToolChains/Cuda.cpp
@@ -212,8 +212,18 @@
   static_cast(getToolChain());
   assert(TC.getTriple().isNVPTX() && "Wrong platform");
 
+  StringRef GPUArchName;
+  // If this is an OpenMP action we need to extract the device architecture
+  // from the -march=arch option. This option may come from -Xopenmp-target
+  // flag or the default value.
+  if (JA.isDeviceOffloading(Action::OFK_OpenMP)) {
+GPUArchName = Args.getLastArgValue(options::OPT_march_EQ);
+assert(!GPUArchName.empty() && "Must have an architecture passed in.");
+  } else
+GPUArchName = JA.getOffloadingArch();
+
   // Obtain architecture from the action.
-  CudaArch gpu_arch = StringToCudaArch(JA.getOffloadingArch());
+  CudaArch gpu_arch = StringToCudaArch(GPUArchName);
   assert(gpu_arch != CudaArch::UNKNOWN &&
  "Device action expected to have an architecture.");
 
@@ -405,7 +415,7 @@
 
   // For OpenMP device offloading, append derived arguments. Make sure
   // flags are not duplicated.
-  // TODO: Append the compute capability.
+  // Also append the compute capability.
   if (DeviceOffloadKind == Action::OFK_OpenMP) {
 for (Arg *A : Args){
   bool IsDuplicate = false;
@@ -418,6 +428,13 @@
   if (!IsDuplicate)
 DAL->append(A);
 }
+
+StringRef Arch = DAL->getLastArgValue(options::OPT_march_EQ);
+if (Arch.empty())
+  // Default compute capability for CUDA toolchain is sm_20.
+  DAL->AddJoinedArg(nullptr,
+  Opts.getOption(options::OPT_march_EQ), "sm_20");
+
 return DAL;
   }
 
Index: lib/Driver/ToolChain.cpp
===
--- lib/Driver/ToolChain.cpp
+++ lib/Driver/ToolChain.cpp
@@ -775,3 +775,65 @@
 
   return VersionTuple();
 }
+
+llvm::opt::DerivedArgList *
+ToolChain::TranslateOpenMPTargetArgs(const llvm::opt::DerivedArgList &Args,
+Action::OffloadKind DeviceOffloadKind) const {
+  if (DeviceOffloadKind == Action::OFK_OpenMP) {
+DerivedArgList *DAL = new DerivedArgList(Args.getBaseArgs());
+const OptTable &Opts = getDriver().getOpts();
+
+// Handle -Xopenmp-target fla

[PATCH] D34784: [OpenMP] Add flag for specifying the target device architecture for OpenMP device offloading

2017-08-06 Thread Hal Finkel via Phabricator via cfe-commits 
hfinkel accepted this revision.
hfinkel added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks for all of your work on this!




Comment at: test/Driver/openmp-offload.c:603
+
+/// Check -Xopenmp-target=powerpc64le-ibm-linux-gnu -march=pwr8 is passed when 
compiling for the device.
+// RUN:   %clang -### -fopenmp=libomp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu 
-Xopenmp-target=powerpc64le-ibm-linux-gnu -mcpu=pwr7 %s 2>&1 \

Comment should say pwr7, not pwr8, to match the test.



Comment at: test/Driver/openmp-offload.c:611
+
+/// Check -Xopenmp-target -march=pwr8 is passed when compiling for the device.
+// RUN:   %clang -### -fopenmp=libomp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target -mcpu=pwr7 %s 2>&1 \

Comment should say pwr7, not pwr8, to match the test.


https://reviews.llvm.org/D34784



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

[PATCH] D36349: [CMake] Build sanitized C++ runtimes for Fuchsia

2017-08-06 Thread Roland McGrath via Phabricator via cfe-commits 
mcgrathr added inline comments.



Comment at: cmake/caches/Fuchsia-stage2.cmake:56
 
+foreach(target x86_64;aarch64)
+  set(RUNTIMES_${target}-fuchsia-asan_CMAKE_BUILD_WITH_INSTALL_RPATH ON CACHE 
BOOL "")

Can you do this without duplicating all the identical settings from the block 
above?
It looks like the asan cases are just all of the above plus two more.


Repository:
  rL LLVM

https://reviews.llvm.org/D36349



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

[PATCH] D36349: [CMake] Build sanitized C++ runtimes for Fuchsia

2017-08-06 Thread Petr Hosek via Phabricator via cfe-commits 
phosek added inline comments.



Comment at: cmake/caches/Fuchsia-stage2.cmake:56
 
+foreach(target x86_64;aarch64)
+  set(RUNTIMES_${target}-fuchsia-asan_CMAKE_BUILD_WITH_INSTALL_RPATH ON CACHE 
BOOL "")

mcgrathr wrote:
> Can you do this without duplicating all the identical settings from the block 
> above?
> It looks like the asan cases are just all of the above plus two more.
Yes, I'm working on this literally right now ;)


Repository:
  rL LLVM

https://reviews.llvm.org/D36349



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

[PATCH] D36347: Add new script to launch lldb and set breakpoints for diagnostics all diagnostics seen.

2017-08-06 Thread don hinton via Phabricator via cfe-commits 
hintonda updated this revision to Diff 109949.
hintonda added a comment.

- Use temp files instead of temp dir.


https://reviews.llvm.org/D36347

Files:
  CMakeLists.txt
  utils/CMakeLists.txt
  utils/run_lldb.sh.in

Index: utils/run_lldb.sh.in
===
--- /dev/null
+++ utils/run_lldb.sh.in
@@ -0,0 +1,70 @@
+#!/usr/bin/env bash
+#
+# This script runs the given command in lldb and sets breakpoints on all reported diagnostics.
+
+function usage() {
+  cat <
+EOF
+  exit 1
+}
+
+if [ $# -eq 0 ]; then
+  echo "Error: No arguments supplied"
+  usage
+fi
+
+cmd=""
+if [ "$2" == "-cc1" ]; then
+  cmd=`echo "$@" 2>&1 | sed -ne "s/\(.*\) -cc1/-f \1 -- -cc1/p"`
+else
+  cmd=`$@ -### 2>&1 | sed -ne "s/.*\"\(.*\)\" .*\-cc1\"/-f \1 -- -cc1/p"`
+fi
+
+tmpdir=/tmp/run_lldb
+test ! -d $tmpdir && mkdir $tmpdir
+
+indexfile=$(mktemp $tmpdir/diag.idx.XX)
+cd @CLANG_SOURCE_DIR@
+find lib include tools \( -name \*.cpp -or -name \*.h \) -exec grep -nHE 'diag::(err_|warn_|ext_)[a-z_]+' \{\} \; |\
+  sed -e 's/^\(.*:[0-9]*:\).*diag::\([a-z_]*\).*/\2:\1/' | \
+  sort > $indexfile
+cd - > /dev/null
+
+root=$(mktemp $tmpdir/diagXX) && rm $root
+module=$(basename $root)
+script=$root.py
+cat << EOF > $script
+import lldb
+import re
+from subprocess import check_output as qx;
+
+def setDiagBreakpoint(frame):
+  id = frame.FindVariable("DiagID").GetValue()
+  if id is None:
+return False
+
+  name = qx(["@CMAKE_RUNTIME_OUTPUT_DIRECTORY@/diagtool", "find-diagnostic-id", id]).rstrip();
+  target = frame.GetThread().GetProcess().GetTarget()
+
+  file = open("$indexfile", "r")
+  for line in file:
+if re.search(name, line):
+  i = filter(None, re.split(r'.*:.*/(\w.*):(\w.*):.*\n', line))
+  bp = target.BreakpointCreateByLocation(i[0], int(i[1]))
+  bp.SetEnabled(False)
+
+  return False
+EOF
+
+PYTHONPATH=$PYTHONPATH:$tmpdir lldb \
+  -o "breakpoint set -n DiagnosticsEngine::Report" \
+  -o "break command add -s p -o 'import $module; return $module.setDiagBreakpoint(frame)'" \
+  -o "run" \
+  -o "breakpoint delete -f 1" \
+  -o "breakpoint enable" \
+  -o "run" \
+  $cmd
+
+rm $indexfile
+rm $script
Index: utils/CMakeLists.txt
===
--- /dev/null
+++ utils/CMakeLists.txt
@@ -0,0 +1,17 @@
+
+set(FILENAME run_lldb.sh)
+# Configure to a temparary directory
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/${FILENAME}.in
+  ${CMAKE_CURRENT_BINARY_DIR}/.tmp/${FILENAME}
+  @ONLY
+  )
+# Copy temparary file to real destination and set permissions/
+file(COPY
+  ${CMAKE_CURRENT_BINARY_DIR}/.tmp/${FILENAME}
+  DESTINATION ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
+  FILE_PERMISSIONS
+OWNER_READ OWNER_WRITE OWNER_EXECUTE
+GROUP_READ GROUP_EXECUTE
+WORLD_READ WORLD_EXECUTE
+)
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -408,6 +408,8 @@
 
 add_subdirectory(utils/TableGen)
 
+add_subdirectory(utils)
+
 add_subdirectory(include)
 
 # All targets below may depend on all tablegen'd files.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D35056: GCC ABI incompatibility when passing object with trivial copy ctor, trivial dtor, and non-trivial move ctor

2017-08-06 Thread John McCall via Phabricator via cfe-commits 
rjmccall added inline comments.



Comment at: lib/Sema/SemaDeclCXX.cpp:5742
+// effect of performing a trivial copy of the type.
+bool Sema::CanPassInRegisters(CXXRecordDecl *D) {
+  if (D->isDependentType())

This should probably be called something like "computeCanPassInRegisters" to 
discourage other code from calling it directly.

It should also just be a static function in this file unless it needs to be a 
member for some access-control reason.


https://reviews.llvm.org/D35056



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

[PATCH] D36019: [clang-format] Fix bug with ENAS_DontAlign and empty lines

2017-08-06 Thread Daniel Jasper via Phabricator via cfe-commits 
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.

Thanks you.




Comment at: lib/Format/WhitespaceManager.cpp:650
+for (unsigned i = 0; i < Newlines; ++i)
+  Text.append(UseCRLF ? " \\\r\n" : " \\\n");
+return;

jtbandes wrote:
> djasper wrote:
> > Note that when you have an empty line, this would turn into:
> > 
> >   #define A \
> > int i; \
> >\<-- Note the 1-space indent here.
> > int j; \
> > int k;
> > 
> > With my alternative below, that "\" will just be put at column 0, which 
> > probably isn't better or worse.
> I suppose that can be changed back to 1 by using `std::max(1, 
> EscapedNewlineColumn - 1);` instead, right? I don't have strong feelings 
> about whether it should be 0 or 1.
I don't either. Leave as is for now.


https://reviews.llvm.org/D36019



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

[PATCH] D36386: [clang] Remove unit test which uses reverse-iterate and fix a PointerLikeTypeTrait specialization

2017-08-06 Thread Mandeep Singh Grang via Phabricator via cfe-commits 
mgrang created this revision.

This patch is in response to https://reviews.llvm.org/D35043 which removed 
-reverse-iterate flag
and the base definition for PointerLikeTypeTrait.


https://reviews.llvm.org/D36386

Files:
  include/clang/AST/ExternalASTSource.h
  test/Rewriter/objc-modern-metadata-visibility2.mm


Index: test/Rewriter/objc-modern-metadata-visibility2.mm
===
--- test/Rewriter/objc-modern-metadata-visibility2.mm
+++ /dev/null
@@ -1,45 +0,0 @@
-// REQUIRES: abi-breaking-checks
-// NOTE: This test has been split from objc-modern-metadata-visibility.mm in
-// order to test with -reverse-iterate as this flag is only present with
-// ABI_BREAKING_CHECKS.
-
-// RUN: %clang_cc1 -E %s -o %t.mm -mllvm -reverse-iterate
-// RUN: %clang_cc1 -x objective-c++ -fblocks -fms-extensions -rewrite-objc 
%t.mm -mllvm -reverse-iterate -o - | FileCheck %s
-// rdar://11144048
-
-@class NSString;
-
-@interface NSObject {
-Class isa;
-}
-@end
-
-@interface Sub : NSObject {
-int subIvar;
-NSString *nsstring;
-@private
-id PrivateIvar;
-}
-@end
-
-@implementation Sub
-- (id) MyNSString { return subIvar ? PrivateIvar : nsstring; }
-@end
-
-@interface NSString @end
-@implementation NSString @end
-
-// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C" 
__declspec(dllimport) unsigned long OBJC_IVAR_$_Sub$subIvar;
-// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C" unsigned long 
OBJC_IVAR_$_Sub$PrivateIvar;
-// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C" 
__declspec(dllimport) unsigned long OBJC_IVAR_$_Sub$nsstring;
-// CHECK: #pragma warning(disable:4273)
-// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C" 
__declspec(dllexport) unsigned long int OBJC_IVAR_$_Sub$subIvar
-// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C" 
__declspec(dllexport) unsigned long int OBJC_IVAR_$_Sub$nsstring
-// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C" unsigned long int 
OBJC_IVAR_$_Sub$PrivateIvar
-// CHECK: extern "C" __declspec(dllimport) struct _class_t 
OBJC_METACLASS_$_NSObject;
-// CHECK: extern "C" __declspec(dllexport) struct _class_t OBJC_METACLASS_$_Sub
-// CHECK: extern "C" __declspec(dllimport) struct _class_t 
OBJC_CLASS_$_NSObject;
-// CHECK: extern "C" __declspec(dllexport) struct _class_t OBJC_CLASS_$_Sub
-// CHECK: extern "C" __declspec(dllexport) struct _class_t 
OBJC_CLASS_$_NSString;
-// CHECK: extern "C" __declspec(dllexport) struct _class_t 
OBJC_METACLASS_$_NSString
-// CHECK: extern "C" __declspec(dllexport) struct _class_t 
OBJC_CLASS_$_NSString
Index: include/clang/AST/ExternalASTSource.h
===
--- include/clang/AST/ExternalASTSource.h
+++ include/clang/AST/ExternalASTSource.h
@@ -466,9 +466,10 @@
 namespace llvm {
 template
-struct PointerLikeTypeTraits<
+class PointerLikeTypeTraits<
 clang::LazyGenerationalUpdatePtr> {
   typedef clang::LazyGenerationalUpdatePtr Ptr;
+public:
   static void *getAsVoidPointer(Ptr P) { return P.getOpaqueValue(); }
   static Ptr getFromVoidPointer(void *P) { return Ptr::getFromOpaqueValue(P); }
   enum {


Index: test/Rewriter/objc-modern-metadata-visibility2.mm
===
--- test/Rewriter/objc-modern-metadata-visibility2.mm
+++ /dev/null
@@ -1,45 +0,0 @@
-// REQUIRES: abi-breaking-checks
-// NOTE: This test has been split from objc-modern-metadata-visibility.mm in
-// order to test with -reverse-iterate as this flag is only present with
-// ABI_BREAKING_CHECKS.
-
-// RUN: %clang_cc1 -E %s -o %t.mm -mllvm -reverse-iterate
-// RUN: %clang_cc1 -x objective-c++ -fblocks -fms-extensions -rewrite-objc %t.mm -mllvm -reverse-iterate -o - | FileCheck %s
-// rdar://11144048
-
-@class NSString;
-
-@interface NSObject {
-Class isa;
-}
-@end
-
-@interface Sub : NSObject {
-int subIvar;
-NSString *nsstring;
-@private
-id PrivateIvar;
-}
-@end
-
-@implementation Sub
-- (id) MyNSString { return subIvar ? PrivateIvar : nsstring; }
-@end
-
-@interface NSString @end
-@implementation NSString @end
-
-// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C" __declspec(dllimport) unsigned long OBJC_IVAR_$_Sub$subIvar;
-// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C" unsigned long OBJC_IVAR_$_Sub$PrivateIvar;
-// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C" __declspec(dllimport) unsigned long OBJC_IVAR_$_Sub$nsstring;
-// CHECK: #pragma warning(disable:4273)
-// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C" __declspec(dllexport) unsigned long int OBJC_IVAR_$_Sub$subIvar
-// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C" __declspec(dllexport) unsigned long int OBJC_IVAR_$_Sub$nsstring
-// CHECK: __declspec(allocate(".objc_ivar$B")) extern "C" unsigned long int OBJC_IVAR_$_Sub$PrivateIvar
-// CHECK: extern "C" __declspec(dllimport) struct _class_t OBJC_METACLASS_$_NSObject;
-// CHECK: extern "C" __declspec