date:20170107

[PATCH] D24688: Introduce "hosted" module flag.

2017-01-07 Thread Mehdi AMINI via Phabricator via cfe-commits

mehdi_amini added a comment.

In https://reviews.llvm.org/D24688#639158, @jyknight wrote:

> Since this requires everyone generating llvm IR to add this module attribute 
> for optimal codegen,

Not sure yet how it'll end up, I'll revamp this.
See also: http://lists.llvm.org/pipermail/cfe-dev/2017-January/052114.html

> it should be documented in release notes and the LangRef, I think.

Thanks, I'll try not to forget.

https://reviews.llvm.org/D24688

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

Re: r291123 - CodeGen: plumb header search down to the IAS

2017-01-07 Thread Sean Silva via cfe-commits

On Sat, Jan 7, 2017 at 1:27 PM, Saleem Abdulrasool via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> I agree with Eric, I don't think that serializing the structure to
> std::cout is the right way to handle this.
>
> What were you thinking of mocking?  Wouldn't you really end up mocking the
> entire backend?
>
> That is the small wrinkle with the way that we deal with inline assembly.
> It really doesn't mesh too well with LTO if you do something like
> `.include`.  What happens if you relocated the bitcode between the
> compile/link phase?  The header search path may be entirely inaccessible at
> this point.  Or they may be relocated, and the paths may need adjustment.
>

Another bad case: two different TU's that are linked into the same LTO
invocation might have conflicting paths. I.e. one says to search
/path/to/foo/ first but the other says to search /path/to/bar/ first. When
both paths could satisfy the include, who wins? I don't think we can
provide any coherent expectations for users about what will happen.

-- Sean Silva


>   But, I agree with you (Eric) here as well, I find the idea of
> serializing the header search options into the module distasteful.
>
> On Fri, Jan 6, 2017 at 6:22 PM, Eric Christopher 
> wrote:
>
>>
>>
>> On Fri, Jan 6, 2017 at 5:56 AM Hal Finkel  wrote:
>>
>>>
>>> On 01/05/2017 08:30 PM, Eric Christopher via cfe-commits wrote:
>>>
>>> Ok, thanks. I agree that it's a problem. I'm definitely open for testing
>>> ideas here. There are a few other things in the
>>> TargetOptions/MCTargetOptions area that are already problematic to test.
>>>
>>>
>>> I think that we need to add serialization for these structures, and a
>>> printing option for them, so that we can test these kinds of things. That
>>> having been said, a lot of these things need to end up in attributes so
>>> that they work correctly with LTO. Is this one of them?
>>>
>>>
>> We definitely need to figure out testing for this, but I don't know that
>> serializing them to std::out is right. Might want to come up with either a
>> gtest or gmock way?
>>
>> That said, ultimately anything that involves parsing at code generation
>> time could involve putting it into a module - that said, I really disagree
>> with all of the include paths etc being serialized into the module.
>>
>> -eric
>>
>>
>>
>>>  -Hal
>>>
>>>
>>>
>>> -eric
>>>
>>> On Thu, Jan 5, 2017 at 6:27 PM Saleem Abdulrasool 
>>> wrote:
>>>
>>> This was certainly the problem that I had.  The test really needs a way
>>> to check that the field was set.  As you state, this is a problematic
>>> area.  The backend already has a test to ensure that the paths are honored,
>>> but, I didn't see any way to actually ensure that it was getting sent to
>>> the backend otherwise.
>>>
>>> The module itself doesnt encode the search path, nor is the information
>>> in the command line.  I can see the argument that the test itself doesn't
>>> add much value especially with the backend side testing that the processing
>>> of the inclusion does occur correctly.  I'll go ahead and remove the test
>>> (which already has ended up being a pain to test).
>>>
>>> On Thu, Jan 5, 2017 at 6:11 PM, Eric Christopher 
>>> wrote:
>>>
>>> Hi Saleem,
>>>
>>> Love that you wanted to add a test for it, but I'd really prefer that
>>> you not engage the backend here in order to do it. You can verify some of
>>> it from the backend and just that the module is correct via the front end
>>> if you'd like. Ensuring the paths are correct is a bit of a sticky problem,
>>> but this is an API boundary that we just have problems with.
>>>
>>> TL;DR: Would you mind splitting this test into front end and back end
>>> tests and avoid using the backend in clang's test harness?
>>>
>>> Thanks!
>>>
>>> -eric
>>>
>>> On Thu, Jan 5, 2017 at 8:13 AM Saleem Abdulrasool via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>> Author: compnerd
>>> Date: Thu Jan  5 10:02:32 2017
>>> New Revision: 291123
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=291123=rev
>>> Log:
>>> CodeGen: plumb header search down to the IAS
>>>
>>> inline assembly may use the `.include` directive to include other
>>> content into the file.  Without the integrated assembler, the `-I` group
>>> gets passed to the assembler.  Emulate this by collecting the header
>>> search paths and passing them to the IAS.
>>>
>>> Resolves PR24811!
>>>
>>> Added:
>>> cfe/trunk/test/CodeGen/include/
>>> cfe/trunk/test/CodeGen/include/function.x
>>> cfe/trunk/test/CodeGen/include/module.x
>>> cfe/trunk/test/CodeGen/inline-asm-inclusion.c
>>> Modified:
>>> cfe/trunk/include/clang/CodeGen/BackendUtil.h
>>> cfe/trunk/lib/CodeGen/BackendUtil.cpp
>>> cfe/trunk/lib/CodeGen/CodeGenAction.cpp
>>> cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
>>>
>>> Modified: cfe/trunk/include/clang/CodeGen/BackendUtil.h
>>> URL:

r291382 - PR18402: work around bug in libstdc++4.8's detection of whether ::gets exists.

2017-01-07 Thread Richard Smith via cfe-commits

Author: rsmith
Date: Sat Jan  7 22:01:15 2017
New Revision: 291382

URL: http://llvm.org/viewvc/llvm-project?rev=291382=rev
Log:
PR18402: work around bug in libstdc++4.8's detection of whether ::gets exists.

This should allow clang to successfully compile libstdc++4.8's headers in C++14
mode.

Added:
cfe/trunk/test/SemaCXX/libstdcxx_gets_hack.cpp
Modified:
cfe/trunk/lib/Sema/SemaDeclCXX.cpp

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=291382=291381=291382=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Sat Jan  7 22:01:15 2017
@@ -9135,6 +9135,16 @@ NamedDecl *Sema::BuildUsingDeclaration(S
   // invalid).
   if (R.empty() &&
   NameInfo.getName().getNameKind() != DeclarationName::CXXConstructorName) 
{
+// HACK: Work around a bug in libstdc++'s detection of ::gets. Sometimes
+// it will believe that glibc provides a ::gets in cases where it does not,
+// and will try to pull it into namespace std with a using-declaration.
+// Just ignore the using-declaration in that case.
+auto *II = NameInfo.getName().getAsIdentifierInfo();
+if (getLangOpts().CPlusPlus14 && II && II->isStr("gets") &&
+CurContext->isStdNamespace() &&
+isa(LookupContext) &&
+getSourceManager().isInSystemHeader(UsingLoc))
+  return nullptr;
 if (TypoCorrection Corrected = CorrectTypo(
 R.getLookupNameInfo(), R.getLookupKind(), S, ,
 llvm::make_unique(

Added: cfe/trunk/test/SemaCXX/libstdcxx_gets_hack.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/libstdcxx_gets_hack.cpp?rev=291382=auto
==
--- cfe/trunk/test/SemaCXX/libstdcxx_gets_hack.cpp (added)
+++ cfe/trunk/test/SemaCXX/libstdcxx_gets_hack.cpp Sat Jan  7 22:01:15 2017
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -fsyntax-only %s -std=c++14 -verify
+
+// This is a test for an egregious hack in Clang that works around
+// an issue with libstdc++'s detection of whether glibc provides a
+// ::gets function. If there is no ::gets, ignore
+//   using ::gets;
+// in namespace std.
+//
+// See PR18402 and gcc.gnu.org/PR77795 for more details.
+
+#ifdef BE_THE_HEADER
+
+#pragma GCC system_header
+namespace std {
+  using ::gets;
+  using ::getx; // expected-error {{no member named 'getx'}}
+}
+
+#else
+
+#define BE_THE_HEADER
+#include "libstdcxx_pointer_return_false_hack.cpp"
+
+namespace foo {
+  using ::gets; // expected-error {{no member named 'gets'}}
+}
+
+#endif


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

[PATCH] D24688: Introduce "hosted" module flag.

2017-01-07 Thread James Y Knight via Phabricator via cfe-commits

jyknight added a comment.

Since this requires everyone generating llvm IR to add this module attribute 
for optimal codegen, it should be documented in release notes and the LangRef, 
I think.

I mean: it's unfortunate that it's needed at all, but at the very least it 
should be possible for people to find out about it.


https://reviews.llvm.org/D24688



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

[PATCH] D28451: [AVR] Add support for the 'interrupt' and 'naked' attributes

2017-01-07 Thread Dylan McKay via Phabricator via cfe-commits

dylanmckay updated this revision to Diff 83544.
dylanmckay added a comment.

Lower the 'signal' attribute correctly

I had forgotten to lower this attribute and so it would not have been lowered 
to IR at all.

Now it works fine.


https://reviews.llvm.org/D28451

Files:
  include/clang/Basic/Attr.td
  lib/CodeGen/TargetInfo.cpp
  lib/Sema/SemaDeclAttr.cpp
  test/CodeGen/avr/attributes/interrupt.c
  test/CodeGen/avr/attributes/naked.c
  test/CodeGen/avr/attributes/signal.c

Index: test/CodeGen/avr/attributes/signal.c
===
--- /dev/null
+++ test/CodeGen/avr/attributes/signal.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: define void @foo() #0
+__attribute__((signal)) void foo(void) { }
+
+// CHECK: attributes #0 = {{{.*signal.*}}}
Index: test/CodeGen/avr/attributes/naked.c
===
--- /dev/null
+++ test/CodeGen/avr/attributes/naked.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: define void @foo() #0
+__attribute__((naked)) void foo(void) { }
+
+// CHECK: attributes #0 = {{{.*naked.*}}}
Index: test/CodeGen/avr/attributes/interrupt.c
===
--- /dev/null
+++ test/CodeGen/avr/attributes/interrupt.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: define void @foo() #0
+__attribute__((interrupt)) void foo(void) { }
+
+// CHECK: attributes #0 = {{{.*interrupt.*}}}
Index: lib/Sema/SemaDeclAttr.cpp
===
--- lib/Sema/SemaDeclAttr.cpp
+++ lib/Sema/SemaDeclAttr.cpp
@@ -5042,6 +5042,20 @@
   D->addAttr(UsedAttr::CreateImplicit(S.Context));
 }
 
+static void handleAVRInterruptAttr(Sema , Decl *D,
+   const AttributeList ) {
+  D->addAttr(::new (S.Context)
+ AVRInterruptAttr(Attr.getLoc(), S.Context,
+  Attr.getAttributeSpellingListIndex()));
+}
+
+static void handleAVRSignalAttr(Sema , Decl *D,
+const AttributeList ) {
+  D->addAttr(::new (S.Context)
+ AVRSignalAttr(Attr.getLoc(), S.Context,
+   Attr.getAttributeSpellingListIndex()));
+}
+
 static void handleInterruptAttr(Sema , Decl *D, const AttributeList ) {
   // Dispatch the interrupt attribute based on the current target.
   switch (S.Context.getTargetInfo().getTriple().getArch()) {
@@ -5056,6 +5070,9 @@
   case llvm::Triple::x86_64:
 handleAnyX86InterruptAttr(S, D, Attr);
 break;
+  case llvm::Triple::avr:
+handleAVRInterruptAttr(S, D, Attr);
+break;
   default:
 handleARMInterruptAttr(S, D, Attr);
 break;
@@ -5616,6 +5633,9 @@
   case AttributeList::AT_AMDGPUNumVGPR:
 handleAMDGPUNumVGPRAttr(S, D, Attr);
 break;
+  case AttributeList::AT_AVRSignal:
+handleAVRSignalAttr(S, D, Attr);
+break;
   case AttributeList::AT_IBAction:
 handleSimpleAttribute(S, D, Attr);
 break;
Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -6884,6 +6884,31 @@
 }
 
 //===--===//
+// AVR ABI Implementation.
+//===--===//
+
+namespace {
+class AVRTargetCodeGenInfo : public TargetCodeGenInfo {
+public:
+  AVRTargetCodeGenInfo(CodeGenTypes )
+: TargetCodeGenInfo(new DefaultABIInfo(CGT)) { }
+
+  void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
+   CodeGen::CodeGenModule ) const override {
+const FunctionDecl *FD = dyn_cast_or_null(D);
+if (!FD) return;
+llvm::Function *Fn = cast(GV);
+
+if (FD->getAttr())
+  Fn->addFnAttr("interrupt");
+
+if (FD->getAttr())
+  Fn->addFnAttr("signal");
+  }
+};
+}
+
+//===--===//
 // TCE ABI Implementation (see http://tce.cs.tut.fi). Uses mostly the defaults.
 // Currently subclassed only to implement custom OpenCL C function attribute
 // handling.
@@ -8386,6 +8411,9 @@
   case llvm::Triple::mips64el:
 return SetCGInfo(new MIPSTargetCodeGenInfo(Types, false));
 
+  case llvm::Triple::avr:
+return SetCGInfo(new AVRTargetCodeGenInfo(Types));
+
   case llvm::Triple::aarch64:
   case llvm::Triple::aarch64_be: {
 AArch64ABIInfo::ABIKind Kind = AArch64ABIInfo::AAPCS;
Index: include/clang/Basic/Attr.td
===
--- include/clang/Basic/Attr.td
+++ include/clang/Basic/Attr.td
@@ -255,6 +255,7 @@
   list CXXABIs;
 }
 def TargetARM : TargetArch<["arm", "thumb", "armeb", "thumbeb"]>;
+def

[PATCH] D28451: [AVR] Add support for the 'interrupt' and 'naked' attributes

2017-01-07 Thread Dylan McKay via Phabricator via cfe-commits

dylanmckay created this revision.
dylanmckay added a reviewer: aaron.ballman.
dylanmckay added a subscriber: cfe-commits.

This teaches clang how to parse and lower the 'interrupt' and 'naked'
attributes.

This allows interrupt signal handlers to be written.


https://reviews.llvm.org/D28451

Files:
  include/clang/Basic/Attr.td
  lib/CodeGen/TargetInfo.cpp
  lib/Sema/SemaDeclAttr.cpp
  test/CodeGen/avr/attributes/interrupt.c
  test/CodeGen/avr/attributes/naked.c

Index: test/CodeGen/avr/attributes/naked.c
===
--- /dev/null
+++ test/CodeGen/avr/attributes/naked.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: define void @foo() #0
+__attribute__((naked)) void foo(void) { }
+
+// CHECK: attributes #0 = {{{.*naked.*}}}
Index: test/CodeGen/avr/attributes/interrupt.c
===
--- /dev/null
+++ test/CodeGen/avr/attributes/interrupt.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: define void @foo() #0
+__attribute__((interrupt)) void foo(void) { }
+
+// CHECK: attributes #0 = {{{.*interrupt.*}}}
Index: lib/Sema/SemaDeclAttr.cpp
===
--- lib/Sema/SemaDeclAttr.cpp
+++ lib/Sema/SemaDeclAttr.cpp
@@ -5042,6 +5042,20 @@
   D->addAttr(UsedAttr::CreateImplicit(S.Context));
 }
 
+static void handleAVRInterruptAttr(Sema , Decl *D,
+   const AttributeList ) {
+  D->addAttr(::new (S.Context)
+ AVRInterruptAttr(Attr.getLoc(), S.Context,
+  Attr.getAttributeSpellingListIndex()));
+}
+
+static void handleAVRSignalAttr(Sema , Decl *D,
+const AttributeList ) {
+  D->addAttr(::new (S.Context)
+ AVRSignalAttr(Attr.getLoc(), S.Context,
+   Attr.getAttributeSpellingListIndex()));
+}
+
 static void handleInterruptAttr(Sema , Decl *D, const AttributeList ) {
   // Dispatch the interrupt attribute based on the current target.
   switch (S.Context.getTargetInfo().getTriple().getArch()) {
@@ -5056,6 +5070,9 @@
   case llvm::Triple::x86_64:
 handleAnyX86InterruptAttr(S, D, Attr);
 break;
+  case llvm::Triple::avr:
+handleAVRInterruptAttr(S, D, Attr);
+break;
   default:
 handleARMInterruptAttr(S, D, Attr);
 break;
@@ -5616,6 +5633,9 @@
   case AttributeList::AT_AMDGPUNumVGPR:
 handleAMDGPUNumVGPRAttr(S, D, Attr);
 break;
+  case AttributeList::AT_AVRSignal:
+handleAVRSignalAttr(S, D, Attr);
+break;
   case AttributeList::AT_IBAction:
 handleSimpleAttribute(S, D, Attr);
 break;
Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -6884,6 +6884,29 @@
 }
 
 //===--===//
+// AVR ABI Implementation.
+//===--===//
+
+namespace {
+class AVRTargetCodeGenInfo : public TargetCodeGenInfo {
+public:
+  AVRTargetCodeGenInfo(CodeGenTypes )
+: TargetCodeGenInfo(new DefaultABIInfo(CGT)) { }
+
+  void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
+   CodeGen::CodeGenModule ) const override {
+const FunctionDecl *FD = dyn_cast_or_null(D);
+if (!FD) return;
+llvm::Function *Fn = cast(GV);
+
+if (FD->getAttr()) {
+  Fn->addFnAttr("interrupt");
+}
+  }
+};
+}
+
+//===--===//
 // TCE ABI Implementation (see http://tce.cs.tut.fi). Uses mostly the defaults.
 // Currently subclassed only to implement custom OpenCL C function attribute
 // handling.
@@ -8386,6 +8409,9 @@
   case llvm::Triple::mips64el:
 return SetCGInfo(new MIPSTargetCodeGenInfo(Types, false));
 
+  case llvm::Triple::avr:
+return SetCGInfo(new AVRTargetCodeGenInfo(Types));
+
   case llvm::Triple::aarch64:
   case llvm::Triple::aarch64_be: {
 AArch64ABIInfo::ABIKind Kind = AArch64ABIInfo::AAPCS;
Index: include/clang/Basic/Attr.td
===
--- include/clang/Basic/Attr.td
+++ include/clang/Basic/Attr.td
@@ -255,6 +255,7 @@
   list CXXABIs;
 }
 def TargetARM : TargetArch<["arm", "thumb", "armeb", "thumbeb"]>;
+def TargetAVR : TargetArch<["avr"]>;
 def TargetMips : TargetArch<["mips", "mipsel"]>;
 def TargetMSP430 : TargetArch<["msp430"]>;
 def TargetX86 : TargetArch<["x86"]>;
@@ -477,6 +478,18 @@
   let Documentation = [ARMInterruptDocs];
 }
 
+def AVRInterrupt : InheritableAttr, TargetSpecificAttr {
+  let Spellings = [GNU<"interrupt">];
+  let Subjects = SubjectList<[Function]>;
+  let ParseKind = "Interrupt";
+  let Documentation = [Undocumented];
+}
+
+def

[PATCH] D28450: [libcxxabi] By default, enable test targets when building in standalone.

2017-01-07 Thread bryant via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291378: [libcxxabi] Enable tests by default in standalone. 
(authored by bryant).

Changed prior to commit:
  https://reviews.llvm.org/D28450?vs=83541=83542#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28450

Files:
  libcxxabi/trunk/CMakeLists.txt


Index: libcxxabi/trunk/CMakeLists.txt
===
--- libcxxabi/trunk/CMakeLists.txt
+++ libcxxabi/trunk/CMakeLists.txt
@@ -70,6 +70,10 @@
   set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
   set(PACKAGE_BUGREPORT "llvm-b...@lists.llvm.org")
 
+  if (NOT DEFINED LLVM_INCLUDE_TESTS)
+set(LLVM_INCLUDE_TESTS ON)
+  endif()
+
   if(EXISTS ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py)
 set(LLVM_LIT ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py)
   else()


Index: libcxxabi/trunk/CMakeLists.txt
===
--- libcxxabi/trunk/CMakeLists.txt
+++ libcxxabi/trunk/CMakeLists.txt
@@ -70,6 +70,10 @@
   set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
   set(PACKAGE_BUGREPORT "llvm-b...@lists.llvm.org")
 
+  if (NOT DEFINED LLVM_INCLUDE_TESTS)
+set(LLVM_INCLUDE_TESTS ON)
+  endif()
+
   if(EXISTS ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py)
 set(LLVM_LIT ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py)
   else()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28450: [libcxxabi] By default, enable test targets when building in standalone.

2017-01-07 Thread bryant via Phabricator via cfe-commits

bryant created this revision.
bryant added reviewers: compnerd, jroelofs, EricWF.
bryant added subscribers: cfe-commits, llvm-commits.
Herald added a subscriber: mgorny.

This fixes the current buildbot failure: 
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-msan/builds/212


https://reviews.llvm.org/D28450

Files:
  CMakeLists.txt


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -70,6 +70,10 @@
   set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
   set(PACKAGE_BUGREPORT "llvm-b...@lists.llvm.org")
 
+  if (NOT DEFINED LLVM_INCLUDE_TESTS)
+set(LLVM_INCLUDE_TESTS ON)
+  endif()
+
   if(EXISTS ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py)
 set(LLVM_LIT ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py)
   else()


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -70,6 +70,10 @@
   set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
   set(PACKAGE_BUGREPORT "llvm-b...@lists.llvm.org")
 
+  if (NOT DEFINED LLVM_INCLUDE_TESTS)
+set(LLVM_INCLUDE_TESTS ON)
+  endif()
+
   if(EXISTS ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py)
 set(LLVM_LIT ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py)
   else()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28238: [Driver] Add openSuse AArch64 Triple

2017-01-07 Thread Kostya Kortchinsky via Phabricator via cfe-commits

cryptoad added inline comments.



Comment at: test/Driver/linux-ld.c:623
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=arm64-unknown-linux-gnu \
+// RUN: --gcc-toolchain="" \

rengolin wrote:
> cryptoad wrote:
> > rengolin wrote:
> > > shouldn't you have used your triple?
> > The similar Fedora and Ubuntu tests appear to be using an unknown target as 
> > well, I based myself on that.
> This is odd... Just be sure the test doesn't pass without your patch.
Confirming that without the patch the test fails, with the following (slightly 
sanitized) output:
```
Command Output (stderr):
--
[...]/llvm/tools/clang/test/Driver/linux-ld.c:633:33: error: expected string 
not found in input
// CHECK-OPENSUSE-42-2-AARCH64: 
"{{.*}}/usr/lib64/gcc/aarch64-suse-linux/4.8/../../../../lib64{{/|}}crt1.o"
^
:6:127: note: scanning from here
 "/usr/bin/ld" 
"--sysroot=[...]/llvm/tools/clang/test/Driver/Inputs/opensuse_42.2_aarch64_tree"
 "
-z" "relro" "--hash-style=gnu" "--eh-frame-hdr" "-m" "aarch64linux" 
"-dynamic-linker" "/lib/ld-linux-aarch64.so.1" "-o" 
"[...]/llvm-build/clang/tools/clang/test/Driver/Output/linux-ld.c.tmp.o" 
"crt1.o" "crti.o" "crtbegin.o" "/tmp
/lit_tmp_V096EA/linux-ld-7a7333.o" "-lgcc" "--as-needed" "-lgcc_s" 
"--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no
-as-needed" "crtend.o" "crtn.o"
```
Tests pass with the patch.



https://reviews.llvm.org/D28238



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

[PATCH] D27424: Add the diagnose_if attribute to clang.

2017-01-07 Thread Eric Fiselier via Phabricator via cfe-commits

EricWF added a comment.

Awesome! I'm so excited for this!


https://reviews.llvm.org/D27424



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

[libcxxabi] r291367 - [libcxxabi] Add flag to conditionally enable tests

2017-01-07 Thread Bryant Wong via cfe-commits

Author: bryant
Date: Sat Jan  7 16:14:04 2017
New Revision: 291367

URL: http://llvm.org/viewvc/llvm-project?rev=291367=rev
Log:
[libcxxabi] Add flag to conditionally enable tests

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

Modified:
libcxxabi/trunk/CMakeLists.txt

Modified: libcxxabi/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/CMakeLists.txt?rev=291367=291366=291367=diff
==
--- libcxxabi/trunk/CMakeLists.txt (original)
+++ libcxxabi/trunk/CMakeLists.txt Sat Jan  7 16:14:04 2017
@@ -122,6 +122,7 @@ option(LIBCXXABI_HAS_EXTERNAL_THREAD_API
   "Build libc++abi with an externalized threading API.
   This option may only be set to ON when LIBCXXABI_ENABLE_THREADS=ON." OFF)
 option(LIBCXXABI_BUILD_32_BITS "Build 32 bit libc++abi." ${LLVM_BUILD_32_BITS})
+option(LIBCXXABI_INCLUDE_TESTS "Generate build targets for the libc++abi unit 
tests." ${LLVM_INCLUDE_TESTS})
 set(LIBCXXABI_TARGET_TRIPLE "" CACHE STRING "Target triple for cross 
compiling.")
 set(LIBCXXABI_GCC_TOOLCHAIN "" CACHE PATH "GCC toolchain for cross compiling.")
 set(LIBCXXABI_SYSROOT "" CACHE PATH "Sysroot for cross compiling.")
@@ -448,7 +449,7 @@ endif()
 # soname, etc...
 add_subdirectory(src)
 
-if (LIBCXXABI_STANDALONE_BUILD AND NOT LIBCXXABI_ENABLE_SHARED)
+if (NOT LIBCXXABI_INCLUDE_TESTS OR (LIBCXXABI_STANDALONE_BUILD AND NOT 
LIBCXXABI_ENABLE_SHARED))
   # We can't reasonably test the system C++ library with a static libc++abi.
   # We either need to be able to replace libc++abi at run time (with a shared
   # libc++abi), or we need to be able to replace the C++ runtime (with a non-


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

[PATCH] D28449: [libcxxabi] Include flag to exclude test and fuzz subdirs.

2017-01-07 Thread bryant via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291367: [libcxxabi] Add flag to conditionally enable tests 
(authored by bryant).

Changed prior to commit:
  https://reviews.llvm.org/D28449?vs=83536=83539#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28449

Files:
  libcxxabi/trunk/CMakeLists.txt


Index: libcxxabi/trunk/CMakeLists.txt
===
--- libcxxabi/trunk/CMakeLists.txt
+++ libcxxabi/trunk/CMakeLists.txt
@@ -122,6 +122,7 @@
   "Build libc++abi with an externalized threading API.
   This option may only be set to ON when LIBCXXABI_ENABLE_THREADS=ON." OFF)
 option(LIBCXXABI_BUILD_32_BITS "Build 32 bit libc++abi." ${LLVM_BUILD_32_BITS})
+option(LIBCXXABI_INCLUDE_TESTS "Generate build targets for the libc++abi unit 
tests." ${LLVM_INCLUDE_TESTS})
 set(LIBCXXABI_TARGET_TRIPLE "" CACHE STRING "Target triple for cross 
compiling.")
 set(LIBCXXABI_GCC_TOOLCHAIN "" CACHE PATH "GCC toolchain for cross compiling.")
 set(LIBCXXABI_SYSROOT "" CACHE PATH "Sysroot for cross compiling.")
@@ -448,7 +449,7 @@
 # soname, etc...
 add_subdirectory(src)
 
-if (LIBCXXABI_STANDALONE_BUILD AND NOT LIBCXXABI_ENABLE_SHARED)
+if (NOT LIBCXXABI_INCLUDE_TESTS OR (LIBCXXABI_STANDALONE_BUILD AND NOT 
LIBCXXABI_ENABLE_SHARED))
   # We can't reasonably test the system C++ library with a static libc++abi.
   # We either need to be able to replace libc++abi at run time (with a shared
   # libc++abi), or we need to be able to replace the C++ runtime (with a non-


Index: libcxxabi/trunk/CMakeLists.txt
===
--- libcxxabi/trunk/CMakeLists.txt
+++ libcxxabi/trunk/CMakeLists.txt
@@ -122,6 +122,7 @@
   "Build libc++abi with an externalized threading API.
   This option may only be set to ON when LIBCXXABI_ENABLE_THREADS=ON." OFF)
 option(LIBCXXABI_BUILD_32_BITS "Build 32 bit libc++abi." ${LLVM_BUILD_32_BITS})
+option(LIBCXXABI_INCLUDE_TESTS "Generate build targets for the libc++abi unit tests." ${LLVM_INCLUDE_TESTS})
 set(LIBCXXABI_TARGET_TRIPLE "" CACHE STRING "Target triple for cross compiling.")
 set(LIBCXXABI_GCC_TOOLCHAIN "" CACHE PATH "GCC toolchain for cross compiling.")
 set(LIBCXXABI_SYSROOT "" CACHE PATH "Sysroot for cross compiling.")
@@ -448,7 +449,7 @@
 # soname, etc...
 add_subdirectory(src)
 
-if (LIBCXXABI_STANDALONE_BUILD AND NOT LIBCXXABI_ENABLE_SHARED)
+if (NOT LIBCXXABI_INCLUDE_TESTS OR (LIBCXXABI_STANDALONE_BUILD AND NOT LIBCXXABI_ENABLE_SHARED))
   # We can't reasonably test the system C++ library with a static libc++abi.
   # We either need to be able to replace libc++abi at run time (with a shared
   # libc++abi), or we need to be able to replace the C++ runtime (with a non-
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r291345 - Replace identifiers called `__out` because Windows.h #defines it.

2017-01-07 Thread Saleem Abdulrasool via cfe-commits

Just a correction on the commit message: its not Windows.h that is defining
`__out`.  `__out` is a SAL keyword.  Unfortunately, I don't know of a way
to disable SAL.

On Sat, Jan 7, 2017 at 3:27 AM, Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ericwf
> Date: Sat Jan  7 05:27:06 2017
> New Revision: 291345
>
> URL: http://llvm.org/viewvc/llvm-project?rev=291345=rev
> Log:
> Replace identifiers called `__out` because Windows.h #defines it.
>
> Windows is greedy and it defines the identifier `__out` as a macro.
> This patch renames all conflicting libc++ identifiers in order
> to correctly work on Windows.
>
> Modified:
> libcxx/trunk/include/algorithm
> libcxx/trunk/include/experimental/algorithm
> libcxx/trunk/include/experimental/iterator
> libcxx/trunk/include/regex
> libcxx/trunk/test/support/nasty_macros.hpp
>
> Modified: libcxx/trunk/include/algorithm
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/
> algorithm?rev=291345=291344=291345=diff
> 
> ==
> --- libcxx/trunk/include/algorithm (original)
> +++ libcxx/trunk/include/algorithm Sat Jan  7 05:27:06 2017
> @@ -3100,28 +3100,28 @@ template class _UniformRandomNumberGenerator>
>  _LIBCPP_INLINE_VISIBILITY
>  _SampleIterator __sample(_PopulationIterator __first,
> - _PopulationIterator __last, _SampleIterator
> __out,
> + _PopulationIterator __last, _SampleIterator
> __output,
>   _Distance __n,
>   _UniformRandomNumberGenerator & __g,
>   input_iterator_tag) {
>
>_Distance __k = 0;
>for (; __first != __last && __k < __n; ++__first, (void)++__k)
> -__out[__k] = *__first;
> +__output[__k] = *__first;
>_Distance __sz = __k;
>for (; __first != __last; ++__first, (void)++__k) {
>  _Distance __r = _VSTD::uniform_int_distribution<_Distance>(0,
> __k)(__g);
>  if (__r < __sz)
> -  __out[__r] = *__first;
> +  __output[__r] = *__first;
>}
> -  return __out + _VSTD::min(__n, __k);
> +  return __output + _VSTD::min(__n, __k);
>  }
>
>  template  _Distance,
>class _UniformRandomNumberGenerator>
>  _LIBCPP_INLINE_VISIBILITY
>  _SampleIterator __sample(_PopulationIterator __first,
> - _PopulationIterator __last, _SampleIterator
> __out,
> + _PopulationIterator __last, _SampleIterator
> __output,
>   _Distance __n,
>   _UniformRandomNumberGenerator& __g,
>   forward_iterator_tag) {
> @@ -3130,18 +3130,18 @@ _SampleIterator __sample(_PopulationIter
>  _Distance __r =
>  _VSTD::uniform_int_distribution<_Distance>(0,
> --__unsampled_sz)(__g);
>  if (__r < __n) {
> -  *__out++ = *__first;
> +  *__output++ = *__first;
>--__n;
>  }
>}
> -  return __out;
> +  return __output;
>  }
>
>  template  _Distance,
>class _UniformRandomNumberGenerator>
>  _LIBCPP_INLINE_VISIBILITY
>  _SampleIterator __sample(_PopulationIterator __first,
> - _PopulationIterator __last, _SampleIterator
> __out,
> + _PopulationIterator __last, _SampleIterator
> __output,
>   _Distance __n, _UniformRandomNumberGenerator&
> __g) {
>typedef typename iterator_traits<_PopulationIterator>::iterator_
> category
>  _PopCategory;
> @@ -3153,7 +3153,7 @@ _SampleIterator __sample(_PopulationIter
>typedef typename common_type<_Distance, _Difference>::type _CommonType;
>_LIBCPP_ASSERT(__n >= 0, "N must be a positive number.");
>return _VSTD::__sample(
> -  __first, __last, __out, _CommonType(__n),
> +  __first, __last, __output, _CommonType(__n),
>__g, _PopCategory());
>  }
>
> @@ -3162,9 +3162,9 @@ template class _UniformRandomNumberGenerator>
>  inline _LIBCPP_INLINE_VISIBILITY
>  _SampleIterator sample(_PopulationIterator __first,
> -   _PopulationIterator __last, _SampleIterator __out,
> +   _PopulationIterator __last, _SampleIterator
> __output,
> _Distance __n, _UniformRandomNumberGenerator&&
> __g) {
> -return _VSTD::__sample(__first, __last, __out, __n, __g);
> +return _VSTD::__sample(__first, __last, __output, __n, __g);
>  }
>  #endif // _LIBCPP_STD_VER > 14
>
>
> Modified: libcxx/trunk/include/experimental/algorithm
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/
> experimental/algorithm?rev=291345=291344=291345=diff
> 
> ==
> --- libcxx/trunk/include/experimental/algorithm (original)
> +++ libcxx/trunk/include/experimental/algorithm Sat Jan  7 05:27:06 2017
> @@ -60,9 +60,9 @@ template class

[PATCH] D28212: typeinfo: provide a partial implementation for Win32

2017-01-07 Thread Saleem Abdulrasool via Phabricator via cfe-commits

compnerd added inline comments.



Comment at: include/typeinfo:109
 protected:
+#if defined(_LIBCPP_HAS_MS_ABI_TYPEINFO)
+#else

EricWF wrote:
> Don't we need a constructor here?
No, we do not need a constructor since the emitted object is already a well 
formed object instance.


Repository:
  rL LLVM

https://reviews.llvm.org/D28212



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

[PATCH] D28383: build: add a heuristic to determine the C++ ABI

2017-01-07 Thread Saleem Abdulrasool via Phabricator via cfe-commits

compnerd abandoned this revision.
compnerd added a comment.

We have a temporary workaround while a proper macro is considered by SD-6.


Repository:
  rL LLVM

https://reviews.llvm.org/D28383



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

Re: [libcxx] r291331 - thread: implement sleep_for on Windows

2017-01-07 Thread Asiri Rathnayake via cfe-commits

Yup, that sounds better.

I'll put up a patch soon.

Cheers,

/ Asiri

On 7 Jan 2017 9:18 p.m., "Saleem Abdulrasool"  wrote:

> I would really rather not introduce a `__libcpp_thread_nanosleep`.
> Different systems may have different granularities for their sleep.  A
> `__libcpp_sleep_for(std::chrono::duration)` sounds reasonable however.
>
> On Fri, Jan 6, 2017 at 11:53 PM, Asiri Rathnayake <
> asiri.rathnay...@gmail.com> wrote:
>
>> Wouldn't it be better to introduce a __libcpp_thread_nanosleep() API call
>> here?
>>
>> I bumped into a similar issue with a custom thread implementation and
>> have a downstream patch like that.
>>
>> Cheers,
>>
>> / Asiri
>>
>>
>> On 7 Jan 2017 2:59 a.m., "Saleem Abdulrasool via cfe-commits" <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> Author: compnerd
>> Date: Fri Jan  6 20:48:30 2017
>> New Revision: 291331
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=291331=rev
>> Log:
>> thread: implement sleep_for on Windows
>>
>> Windows does not provide an implementation of `nanosleep`.  Round up the
>> time duration to the nearest ms and use `Sleep`.  Although this may
>> over-sleep, there is no hard real-time guarantee on the wake, so
>> sleeping a bit more is better than under-sleeping as it within the
>> specification.
>>
>> Modified:
>> libcxx/trunk/src/thread.cpp
>>
>> Modified: libcxx/trunk/src/thread.cpp
>> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/thread.
>> cpp?rev=291331=291330=291331=diff
>> 
>> ==
>> --- libcxx/trunk/src/thread.cpp (original)
>> +++ libcxx/trunk/src/thread.cpp Fri Jan  6 20:48:30 2017
>> @@ -117,6 +117,12 @@ sleep_for(const chrono::nanoseconds& ns)
>>  using namespace chrono;
>>  if (ns > nanoseconds::zero())
>>  {
>> +#if defined(_LIBCPP_WIN32API)
>> +milliseconds ms = duration_cast(ns);
>> +if (ns > duration_cast(ms))
>> +  ++ms;
>> +Sleep(ms.count());
>> +#else
>>  seconds s = duration_cast(ns);
>>  timespec ts;
>>  typedef decltype(ts.tv_sec) ts_sec;
>> @@ -134,6 +140,7 @@ sleep_for(const chrono::nanoseconds& ns)
>>
>>  while (nanosleep(, ) == -1 && errno == EINTR)
>>  ;
>> +#endif
>>  }
>>  }
>>
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>>
>>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r291123 - CodeGen: plumb header search down to the IAS

2017-01-07 Thread Saleem Abdulrasool via cfe-commits

I agree with Eric, I don't think that serializing the structure to
std::cout is the right way to handle this.

What were you thinking of mocking?  Wouldn't you really end up mocking the
entire backend?

That is the small wrinkle with the way that we deal with inline assembly.
It really doesn't mesh too well with LTO if you do something like
`.include`.  What happens if you relocated the bitcode between the
compile/link phase?  The header search path may be entirely inaccessible at
this point.  Or they may be relocated, and the paths may need adjustment.
But, I agree with you (Eric) here as well, I find the idea of serializing
the header search options into the module distasteful.

On Fri, Jan 6, 2017 at 6:22 PM, Eric Christopher  wrote:

>
>
> On Fri, Jan 6, 2017 at 5:56 AM Hal Finkel  wrote:
>
>>
>> On 01/05/2017 08:30 PM, Eric Christopher via cfe-commits wrote:
>>
>> Ok, thanks. I agree that it's a problem. I'm definitely open for testing
>> ideas here. There are a few other things in the
>> TargetOptions/MCTargetOptions area that are already problematic to test.
>>
>>
>> I think that we need to add serialization for these structures, and a
>> printing option for them, so that we can test these kinds of things. That
>> having been said, a lot of these things need to end up in attributes so
>> that they work correctly with LTO. Is this one of them?
>>
>>
> We definitely need to figure out testing for this, but I don't know that
> serializing them to std::out is right. Might want to come up with either a
> gtest or gmock way?
>
> That said, ultimately anything that involves parsing at code generation
> time could involve putting it into a module - that said, I really disagree
> with all of the include paths etc being serialized into the module.
>
> -eric
>
>
>
>>  -Hal
>>
>>
>>
>> -eric
>>
>> On Thu, Jan 5, 2017 at 6:27 PM Saleem Abdulrasool 
>> wrote:
>>
>> This was certainly the problem that I had.  The test really needs a way
>> to check that the field was set.  As you state, this is a problematic
>> area.  The backend already has a test to ensure that the paths are honored,
>> but, I didn't see any way to actually ensure that it was getting sent to
>> the backend otherwise.
>>
>> The module itself doesnt encode the search path, nor is the information
>> in the command line.  I can see the argument that the test itself doesn't
>> add much value especially with the backend side testing that the processing
>> of the inclusion does occur correctly.  I'll go ahead and remove the test
>> (which already has ended up being a pain to test).
>>
>> On Thu, Jan 5, 2017 at 6:11 PM, Eric Christopher 
>> wrote:
>>
>> Hi Saleem,
>>
>> Love that you wanted to add a test for it, but I'd really prefer that you
>> not engage the backend here in order to do it. You can verify some of it
>> from the backend and just that the module is correct via the front end if
>> you'd like. Ensuring the paths are correct is a bit of a sticky problem,
>> but this is an API boundary that we just have problems with.
>>
>> TL;DR: Would you mind splitting this test into front end and back end
>> tests and avoid using the backend in clang's test harness?
>>
>> Thanks!
>>
>> -eric
>>
>> On Thu, Jan 5, 2017 at 8:13 AM Saleem Abdulrasool via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> Author: compnerd
>> Date: Thu Jan  5 10:02:32 2017
>> New Revision: 291123
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=291123=rev
>> Log:
>> CodeGen: plumb header search down to the IAS
>>
>> inline assembly may use the `.include` directive to include other
>> content into the file.  Without the integrated assembler, the `-I` group
>> gets passed to the assembler.  Emulate this by collecting the header
>> search paths and passing them to the IAS.
>>
>> Resolves PR24811!
>>
>> Added:
>> cfe/trunk/test/CodeGen/include/
>> cfe/trunk/test/CodeGen/include/function.x
>> cfe/trunk/test/CodeGen/include/module.x
>> cfe/trunk/test/CodeGen/inline-asm-inclusion.c
>> Modified:
>> cfe/trunk/include/clang/CodeGen/BackendUtil.h
>> cfe/trunk/lib/CodeGen/BackendUtil.cpp
>> cfe/trunk/lib/CodeGen/CodeGenAction.cpp
>> cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
>>
>> Modified: cfe/trunk/include/clang/CodeGen/BackendUtil.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
>> clang/CodeGen/BackendUtil.h?rev=291123=291122=291123=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/CodeGen/BackendUtil.h (original)
>> +++ cfe/trunk/include/clang/CodeGen/BackendUtil.h Thu Jan  5 10:02:32
>> 2017
>> @@ -21,6 +21,7 @@ namespace llvm {
>>
>>  namespace clang {
>>class DiagnosticsEngine;
>> +  class HeaderSearchOptions;
>>class CodeGenOptions;
>>class TargetOptions;
>>class LangOptions;
>> @@ -34,7 +35,8 @@ namespace clang {
>>  Backend_EmitObj

Re: [libcxx] r291331 - thread: implement sleep_for on Windows

2017-01-07 Thread Saleem Abdulrasool via cfe-commits

I would really rather not introduce a `__libcpp_thread_nanosleep`.
Different systems may have different granularities for their sleep.  A
`__libcpp_sleep_for(std::chrono::duration)` sounds reasonable however.

On Fri, Jan 6, 2017 at 11:53 PM, Asiri Rathnayake <
asiri.rathnay...@gmail.com> wrote:

> Wouldn't it be better to introduce a __libcpp_thread_nanosleep() API call
> here?
>
> I bumped into a similar issue with a custom thread implementation and have
> a downstream patch like that.
>
> Cheers,
>
> / Asiri
>
>
> On 7 Jan 2017 2:59 a.m., "Saleem Abdulrasool via cfe-commits" <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: compnerd
> Date: Fri Jan  6 20:48:30 2017
> New Revision: 291331
>
> URL: http://llvm.org/viewvc/llvm-project?rev=291331=rev
> Log:
> thread: implement sleep_for on Windows
>
> Windows does not provide an implementation of `nanosleep`.  Round up the
> time duration to the nearest ms and use `Sleep`.  Although this may
> over-sleep, there is no hard real-time guarantee on the wake, so
> sleeping a bit more is better than under-sleeping as it within the
> specification.
>
> Modified:
> libcxx/trunk/src/thread.cpp
>
> Modified: libcxx/trunk/src/thread.cpp
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/thread.
> cpp?rev=291331=291330=291331=diff
> 
> ==
> --- libcxx/trunk/src/thread.cpp (original)
> +++ libcxx/trunk/src/thread.cpp Fri Jan  6 20:48:30 2017
> @@ -117,6 +117,12 @@ sleep_for(const chrono::nanoseconds& ns)
>  using namespace chrono;
>  if (ns > nanoseconds::zero())
>  {
> +#if defined(_LIBCPP_WIN32API)
> +milliseconds ms = duration_cast(ns);
> +if (ns > duration_cast(ms))
> +  ++ms;
> +Sleep(ms.count());
> +#else
>  seconds s = duration_cast(ns);
>  timespec ts;
>  typedef decltype(ts.tv_sec) ts_sec;
> @@ -134,6 +140,7 @@ sleep_for(const chrono::nanoseconds& ns)
>
>  while (nanosleep(, ) == -1 && errno == EINTR)
>  ;
> +#endif
>  }
>  }
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28449: [libcxxabi] Include flag to exclude test and fuzz subdirs.

2017-01-07 Thread bryant via Phabricator via cfe-commits

bryant updated this revision to Diff 83536.
bryant added a comment.

set default val to LLVM_INCLUDE_TESTS, like the others.


https://reviews.llvm.org/D28449

Files:
  CMakeLists.txt


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -122,6 +122,7 @@
   "Build libc++abi with an externalized threading API.
   This option may only be set to ON when LIBCXXABI_ENABLE_THREADS=ON." OFF)
 option(LIBCXXABI_BUILD_32_BITS "Build 32 bit libc++abi." ${LLVM_BUILD_32_BITS})
+option(LIBCXXABI_INCLUDE_TESTS "Generate build targets for the libc++abi unit 
tests." ${LLVM_INCLUDE_TESTS})
 set(LIBCXXABI_TARGET_TRIPLE "" CACHE STRING "Target triple for cross 
compiling.")
 set(LIBCXXABI_GCC_TOOLCHAIN "" CACHE PATH "GCC toolchain for cross compiling.")
 set(LIBCXXABI_SYSROOT "" CACHE PATH "Sysroot for cross compiling.")
@@ -448,7 +449,7 @@
 # soname, etc...
 add_subdirectory(src)
 
-if (LIBCXXABI_STANDALONE_BUILD AND NOT LIBCXXABI_ENABLE_SHARED)
+if (NOT LIBCXXABI_INCLUDE_TESTS OR (LIBCXXABI_STANDALONE_BUILD AND NOT 
LIBCXXABI_ENABLE_SHARED))
   # We can't reasonably test the system C++ library with a static libc++abi.
   # We either need to be able to replace libc++abi at run time (with a shared
   # libc++abi), or we need to be able to replace the C++ runtime (with a non-


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -122,6 +122,7 @@
   "Build libc++abi with an externalized threading API.
   This option may only be set to ON when LIBCXXABI_ENABLE_THREADS=ON." OFF)
 option(LIBCXXABI_BUILD_32_BITS "Build 32 bit libc++abi." ${LLVM_BUILD_32_BITS})
+option(LIBCXXABI_INCLUDE_TESTS "Generate build targets for the libc++abi unit tests." ${LLVM_INCLUDE_TESTS})
 set(LIBCXXABI_TARGET_TRIPLE "" CACHE STRING "Target triple for cross compiling.")
 set(LIBCXXABI_GCC_TOOLCHAIN "" CACHE PATH "GCC toolchain for cross compiling.")
 set(LIBCXXABI_SYSROOT "" CACHE PATH "Sysroot for cross compiling.")
@@ -448,7 +449,7 @@
 # soname, etc...
 add_subdirectory(src)
 
-if (LIBCXXABI_STANDALONE_BUILD AND NOT LIBCXXABI_ENABLE_SHARED)
+if (NOT LIBCXXABI_INCLUDE_TESTS OR (LIBCXXABI_STANDALONE_BUILD AND NOT LIBCXXABI_ENABLE_SHARED))
   # We can't reasonably test the system C++ library with a static libc++abi.
   # We either need to be able to replace libc++abi at run time (with a shared
   # libc++abi), or we need to be able to replace the C++ runtime (with a non-
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28449: [libcxxabi] Include flag to exclude test and fuzz subdirs.

2017-01-07 Thread bryant via Phabricator via cfe-commits

bryant created this revision.
bryant added reviewers: compnerd, EricWF, jroelofs.
bryant added subscribers: cfe-commits, llvm-commits.
Herald added a subscriber: mgorny.

LLVM_INCLUDE_TESTS
CLANG_INCLUDE_TESTS
LIBCXX_INCLUDE_TESTS

...and now this.


https://reviews.llvm.org/D28449

Files:
  CMakeLists.txt


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -122,6 +122,7 @@
   "Build libc++abi with an externalized threading API.
   This option may only be set to ON when LIBCXXABI_ENABLE_THREADS=ON." OFF)
 option(LIBCXXABI_BUILD_32_BITS "Build 32 bit libc++abi." ${LLVM_BUILD_32_BITS})
+option(LIBCXXABI_INCLUDE_TESTS "Generate build targets for the libc++abi unit 
tests." ON)
 set(LIBCXXABI_TARGET_TRIPLE "" CACHE STRING "Target triple for cross 
compiling.")
 set(LIBCXXABI_GCC_TOOLCHAIN "" CACHE PATH "GCC toolchain for cross compiling.")
 set(LIBCXXABI_SYSROOT "" CACHE PATH "Sysroot for cross compiling.")
@@ -448,7 +449,7 @@
 # soname, etc...
 add_subdirectory(src)
 
-if (LIBCXXABI_STANDALONE_BUILD AND NOT LIBCXXABI_ENABLE_SHARED)
+if (NOT LIBCXXABI_INCLUDE_TESTS OR (LIBCXXABI_STANDALONE_BUILD AND NOT 
LIBCXXABI_ENABLE_SHARED))
   # We can't reasonably test the system C++ library with a static libc++abi.
   # We either need to be able to replace libc++abi at run time (with a shared
   # libc++abi), or we need to be able to replace the C++ runtime (with a non-


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -122,6 +122,7 @@
   "Build libc++abi with an externalized threading API.
   This option may only be set to ON when LIBCXXABI_ENABLE_THREADS=ON." OFF)
 option(LIBCXXABI_BUILD_32_BITS "Build 32 bit libc++abi." ${LLVM_BUILD_32_BITS})
+option(LIBCXXABI_INCLUDE_TESTS "Generate build targets for the libc++abi unit tests." ON)
 set(LIBCXXABI_TARGET_TRIPLE "" CACHE STRING "Target triple for cross compiling.")
 set(LIBCXXABI_GCC_TOOLCHAIN "" CACHE PATH "GCC toolchain for cross compiling.")
 set(LIBCXXABI_SYSROOT "" CACHE PATH "Sysroot for cross compiling.")
@@ -448,7 +449,7 @@
 # soname, etc...
 add_subdirectory(src)
 
-if (LIBCXXABI_STANDALONE_BUILD AND NOT LIBCXXABI_ENABLE_SHARED)
+if (NOT LIBCXXABI_INCLUDE_TESTS OR (LIBCXXABI_STANDALONE_BUILD AND NOT LIBCXXABI_ENABLE_SHARED))
   # We can't reasonably test the system C++ library with a static libc++abi.
   # We either need to be able to replace libc++abi at run time (with a shared
   # libc++abi), or we need to be able to replace the C++ runtime (with a non-
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r291360 - Fix buildbots.

2017-01-07 Thread Richard Smith via cfe-commits

Author: rsmith
Date: Sat Jan  7 13:58:39 2017
New Revision: 291360

URL: http://llvm.org/viewvc/llvm-project?rev=291360=rev
Log:
Fix buildbots.

Modified:
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp

Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp?rev=291360=291359=291360=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp Sat Jan  7 13:58:39 2017
@@ -173,7 +173,7 @@ static void instantiateDependentEnableIf
 const EnableIfAttr *A, const Decl *Tmpl, Decl *New) {
   Expr *Cond = nullptr;
   {
-ContextRAII SwitchContext(*this, cast(New));
+Sema::ContextRAII SwitchContext(S, cast(New));
 EnterExpressionEvaluationContext Unevaluated(S, Sema::ConstantEvaluated);
 ExprResult Result = S.SubstExpr(A->getCond(), TemplateArgs);
 if (Result.isInvalid())


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

r291358 - Consistently use a ConstantEvaluated context for expressions in attributes,

2017-01-07 Thread Richard Smith via cfe-commits

Author: rsmith
Date: Sat Jan  7 13:42:26 2017
New Revision: 291358

URL: http://llvm.org/viewvc/llvm-project?rev=291358=rev
Log:
Consistently use a ConstantEvaluated context for expressions in attributes,
except for those with the "attributes are unevaluated contexts" flag.

Modified:
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
cfe/trunk/test/SemaCXX/enable_if.cpp

Modified: cfe/trunk/lib/Parse/ParseDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseDecl.cpp?rev=291358=291357=291358=diff
==
--- cfe/trunk/lib/Parse/ParseDecl.cpp (original)
+++ cfe/trunk/lib/Parse/ParseDecl.cpp Sat Jan  7 13:42:26 2017
@@ -306,10 +306,11 @@ unsigned Parser::ParseAttributeArgsCommo
 
 // Parse the non-empty comma-separated list of expressions.
 do {
-  bool ShouldEnter = attributeParsedArgsUnevaluated(*AttrName);
+  bool Uneval = attributeParsedArgsUnevaluated(*AttrName);
   EnterExpressionEvaluationContext Unevaluated(
-  Actions, Sema::Unevaluated, /*LambdaContextDecl=*/nullptr,
-  /*IsDecltype=*/false, ShouldEnter);
+  Actions, Uneval ? Sema::Unevaluated : Sema::ConstantEvaluated,
+  /*LambdaContextDecl=*/nullptr,
+  /*IsDecltype=*/false);
 
   ExprResult ArgExpr(
   Actions.CorrectDelayedTyposInExpr(ParseAssignmentExpression()));

Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp?rev=291358=291357=291358=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp Sat Jan  7 13:42:26 2017
@@ -173,7 +173,8 @@ static void instantiateDependentEnableIf
 const EnableIfAttr *A, const Decl *Tmpl, Decl *New) {
   Expr *Cond = nullptr;
   {
-EnterExpressionEvaluationContext Unevaluated(S, Sema::Unevaluated);
+ContextRAII SwitchContext(*this, cast(New));
+EnterExpressionEvaluationContext Unevaluated(S, Sema::ConstantEvaluated);
 ExprResult Result = S.SubstExpr(A->getCond(), TemplateArgs);
 if (Result.isInvalid())
   return;

Modified: cfe/trunk/test/SemaCXX/enable_if.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/enable_if.cpp?rev=291358=291357=291358=diff
==
--- cfe/trunk/test/SemaCXX/enable_if.cpp (original)
+++ cfe/trunk/test/SemaCXX/enable_if.cpp Sat Jan  7 13:42:26 2017
@@ -464,3 +464,11 @@ void runFoo() {
   Foo().bar(1);
 }
 }
+
+namespace instantiate_constexpr_in_enable_if {
+  template struct X {
+static constexpr bool ok() { return true; }
+void f() __attribute__((enable_if(ok(), "")));
+  };
+  void g() { X().f(); }
+}


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

[PATCH] D28238: [Driver] Add openSuse AArch64 Triple

2017-01-07 Thread Renato Golin via Phabricator via cfe-commits

rengolin added inline comments.



Comment at: test/Driver/linux-ld.c:623
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=arm64-unknown-linux-gnu \
+// RUN: --gcc-toolchain="" \

cryptoad wrote:
> rengolin wrote:
> > shouldn't you have used your triple?
> The similar Fedora and Ubuntu tests appear to be using an unknown target as 
> well, I based myself on that.
This is odd... Just be sure the test doesn't pass without your patch.


https://reviews.llvm.org/D28238



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

[PATCH] D27424: Add the diagnose_if attribute to clang.

2017-01-07 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM, but please point this out in the release notes as well.


https://reviews.llvm.org/D27424



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

[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

2017-01-07 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

In https://reviews.llvm.org/D20693#639030, @hintonda wrote:

> Matthias, I think you make a good point.  While noexcept(expr) is valuable, 
> noexcept(false) adds no value.  Therefore, I think we should do as you 
> suggest, i.e.:
>
>   s/throw()/noexcept/
>   s/throw(something)//
>   
>
> Aaron, does this work for you?

I think it makes a reasonable option, but I think it should be off by default. 
Again, I think that's hostile towards users to remove an explicit exception 
specification entirely when there was an explicit dynamic exception 
specification written on the function signature. `noexcept(false)` is a 
stronger signal to anyone reading the signature than no exception specification 
whatsoever.

Be careful, though, not to break code by removing the exception specification. 
These two are *not* equivalent, for instance:

  struct S {
~S() noexcept(false);
void operator delete(void *ptr) noexcept(false); 
  };

  struct T {
~T(); // Is actually noexcept(true) by default!
void operator delete(void *ptr); // Is actually noexcept(true) by default!
  };

https://reviews.llvm.org/D20693

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

[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

2017-01-07 Thread don hinton via Phabricator via cfe-commits

hintonda added a comment.

Matthias, I think you make a good point.  While noexcept(expr) is valuable, 
noexcept(false) adds no value.  Therefore, I think we should do as you suggest, 
i.e.:

  s/throw()/noexcept/
  s/throw(something)//

Aaron, does this work for you?


https://reviews.llvm.org/D20693



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

[PATCH] D28441: [libc++] [CMake] Link with /nodefaultlibs on Windows

2017-01-07 Thread Shoaib Meenai via Phabricator via cfe-commits

smeenai added a comment.

One potential issue with always forcing the non-debug msvcrt is that any apps 
that link against libc++ would also then need to use the non-debug CRT 
libraries, otherwise you'd get all sorts of fun runtime errors (e.g. 
cross-domain frees). I think the default Visual Studio settings are to link 
against `msvcrtd`, `ucrtd`, etc. for debug builds and `msvcrt`, `ucrt`, etc. 
for release builds, so having libc++ unconditionally use the non-debug versions 
is probably bad for interoperability.

I think the right thing to do would be to either always compile two versions of 
libc++, one linked against the debug libraries and the other against the 
non-debug libraries, or make the Debug configuration use the debug libraries 
and the Release configuration use the release libraries (and have `config.py` 
deal with this as well).




Comment at: CMakeLists.txt:43
+if (WIN32 AND NOT MINGW)
+  set(LIBCXX_TARGETING_WINDOWS ON)
+else()

EricWF wrote:
> EricWF wrote:
> > smeenai wrote:
> > > Not the biggest fan of this name, since it's not obvious why MinGW 
> > > shouldn't count as targeting Windows. I thought of 
> > > `LIBCXX_TARGETING_NATIVE_WINDOWS` or `LIBCXX_TARGETING_MSVCRT` instead, 
> > > but MinGW is also native Windows and targets MSVCRT, so those names 
> > > aren't any better from that perspective either. I can't think of anything 
> > > else at the moment, but I'm sure there's a better name.
> > Thanks for the feedback. I'm not exactly sure how this macro should be 
> > defined either.
> > 
> > I thought that `MinGW` provided its own C library runtime wrappers that 
> > forward to `MSVCRT`. 
> > 
> > The difference I was imagining between Native Windows builds and `MinGW` is 
> > that it's possible to use
> > `pthread` with `MinGW` but not with native Windows targets. 
> Another distinction I would like this macro to embody is whether on not the 
> compiler defines `_MSC_VER`.  `clang-cl`, `clang++`  on Windows, and MSVC 
> `cl` all define this macro.
If I recall correctly, MinGW uses `mscvrt.dll` but not `msvcrt.lib` (see my 
other comment for the distinction). I'm fine with this name for now then; we 
can always bikeshed later.

Btw it's also possible to use pthread with native Windows targets, via 
[pthreads-win32](http://www.sourceware.org/pthreads-win32/) or other libraries.



Comment at: CMakeLists.txt:388
+# non-debug DLLs
+remove_flags("/D_DEBUG" "/MTd" "/MDd" "/MT" "/Md" "/RTC1")
+

EricWF wrote:
> smeenai wrote:
> > cl (and presumably clang-cl) also accepts all these flags with a leading 
> > dash instead of a leading slash, and cmake at least has a tendency to do 
> > `-D` instead of `/D`, so you might need to take those into account as well. 
> > Also, what about the other potential `/RTC` options?
> My goal here is only to remove flags which CMake adds by default as part of 
> `CMAKE_CXX_FLAGS__INIT`.
Fair enough, works for me.



Comment at: lib/CMakeLists.txt:108-109
+if (LIBCXX_TARGETING_WINDOWS)
+  add_compile_flags(/Zl)
+  add_link_flags(/nodefaultlib)
+  add_library_flags(ucrt) # Universal C runtime

EricWF wrote:
> smeenai wrote:
> > halyavin wrote:
> > > smeenai wrote:
> > > > These should be guarded under a check for a cl or cl-like frontend 
> > > > rather than `LIBCXX_TARGETING_WINDOWS` (since in theory we could be 
> > > > using the regular clang frontend to compile for Windows as well).
> > > Regular clang supports both gcc-like and cl-like options (there are 2 
> > > compilers: clang.exe and clang-cl.exe). I think it is not worth it to 
> > > support both considering they differ only in command line options 
> > > handling.
> > I'm aware of the separate drivers, but I still think it's worthwhile 
> > specifying appropriate conditionals when it's easy enough to do. (In this 
> > case, the inverse check of 
> > https://reviews.llvm.org/diffusion/L/browse/libcxx/trunk/CMakeLists.txt;291339$394
> >  should do the trick.)
> Is it alright if libc++'s CMakeLists.txt only supports targeting `clang-cl` 
> for the time being? I would love to also support `clang++` but that seems 
> like a ways off.
> 
> For now my only concern is getting `clang-cl` working. Expanding to include 
> supporting `clang++` seems like it's a ways away. @smeenai Would this be a 
> regression for you?
It would. It's easy enough to work around locally, so I don't care too much, 
but it's also easy enough to not regress in the first place :p Would using 
`add_flags_if_supported` and `add_link_flags_if_supported` instead of the 
unconditional versions here work?



Comment at: lib/CMakeLists.txt:111
+  add_library_flags(ucrt) # Universal C runtime
+  add_library_flags(vcruntime) # C++ runtime
+  add_library_flags(msvcrt) # C runtime startup files

EricWF wrote:
> smeenai wrote:
> > halyavin wrote:
> > > smeenai wrote:
> > > > Idk if there's anything specific to

[PATCH] D27872: [APFloat] Switch from (PPCDoubleDoubleImpl, IEEEdouble) layout to (IEEEdouble, IEEEdouble)

2017-01-07 Thread Hal Finkel via Phabricator via cfe-commits

hfinkel added a comment.

> (IEEEdouble, IEEEdouble) -> (uint64_t, uint64_t) -> PPCDoubleDoubleImpl, then 
> run the old algorithm.

We need to document in the code what is going on here and why it works. Just 
looking at a bunch of code like this:

  if (Semantics == ) {
APFloat Tmp(semPPCDoubleDoubleImpl, bitcastToAPInt());
auto Ret = Tmp.next(nextDown);
*this = DoubleAPFloat(semPPCDoubleDouble, Tmp.bitcastToAPInt());
return Ret;
  }

it is not at all obvious what is going on (i.e. why are we casting to 
integers?). Maybe semPPCDoubleDoubleImpl needs a better name now? It seems 
confusing to have semPPCDoubleDoubleImpl and semPPCDoubleDouble where one is 
not really an "implementation" class of the other.




Comment at: llvm/include/llvm/ADT/APFloat.h:791
   void makeNaN(bool SNaN, bool Neg, const APInt *fill) {
-getIEEE().makeNaN(SNaN, Neg, fill);
+if (usesLayout(getSemantics()))
+  return U.IEEE.makeNaN(SNaN, Neg, fill);

I realize that some of this existed before, but is there any way to refactor 
this so that we don't have so much boiler plate? Even using a utility macro is 
probably better than this.


https://reviews.llvm.org/D27872



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

[PATCH] D28238: [Driver] Add openSuse AArch64 Triple

2017-01-07 Thread Kostya Kortchinsky via Phabricator via cfe-commits

cryptoad added inline comments.



Comment at: test/Driver/linux-ld.c:623
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=arm64-unknown-linux-gnu \
+// RUN: --gcc-toolchain="" \

rengolin wrote:
> shouldn't you have used your triple?
The similar Fedora and Ubuntu tests appear to be using an unknown target as 
well, I based myself on that.


https://reviews.llvm.org/D28238



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

[PATCH] D26900: [cmake] Obtain LLVM_CMAKE_PATH from llvm-config if available

2017-01-07 Thread Michał Górny via Phabricator via cfe-commits

mgorny retitled this revision from "[cmake] Obtain LLVM_CMAKE_PATH from 
llvm-config" to "[cmake] Obtain LLVM_CMAKE_PATH from llvm-config if available".
mgorny updated the summary for this revision.
mgorny updated this revision to Diff 83527.
mgorny added a comment.

Updated to support fallback to hardcoded path.


https://reviews.llvm.org/D26900

Files:
  CMakeLists.txt


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -58,7 +58,18 @@
   find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
 NO_DEFAULT_PATH)
 
-  set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+  # --cmakedir is supported since llvm r291218 (4.0 release)
+  execute_process(
+COMMAND ${LLVM_CONFIG} --cmakedir
+RESULT_VARIABLE HAD_ERROR
+OUTPUT_VARIABLE CONFIG_OUTPUT)
+  if(NOT HAD_ERROR)
+string(STRIP "${CONFIG_OUTPUT}" LLVM_CMAKE_PATH)
+  else()
+set(LLVM_CMAKE_PATH
+"${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+  endif()
+
   set(LLVMCONFIG_FILE "${LLVM_CMAKE_PATH}/LLVMConfig.cmake")
   if(EXISTS ${LLVMCONFIG_FILE})
 list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_PATH}")


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -58,7 +58,18 @@
   find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
 NO_DEFAULT_PATH)
 
-  set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+  # --cmakedir is supported since llvm r291218 (4.0 release)
+  execute_process(
+COMMAND ${LLVM_CONFIG} --cmakedir
+RESULT_VARIABLE HAD_ERROR
+OUTPUT_VARIABLE CONFIG_OUTPUT)
+  if(NOT HAD_ERROR)
+string(STRIP "${CONFIG_OUTPUT}" LLVM_CMAKE_PATH)
+  else()
+set(LLVM_CMAKE_PATH
+"${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+  endif()
+
   set(LLVMCONFIG_FILE "${LLVM_CMAKE_PATH}/LLVMConfig.cmake")
   if(EXISTS ${LLVMCONFIG_FILE})
 list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_PATH}")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28441: [libc++] [CMake] Link with /nodefaultlibs on Windows

2017-01-07 Thread Andrey Khalyavin via Phabricator via cfe-commits

halyavin added inline comments.



Comment at: lib/CMakeLists.txt:113
+  add_library_flags(msvcrt) # C runtime startup files
+  add_library_flags(iso_stdio_wide_specifiers)
+endif()

EricWF wrote:
> halyavin wrote:
> > EricWF wrote:
> > > smeenai wrote:
> > > > Maybe add a comment explaining the purpose of this one as well?
> > > Not sure what the comment should read. I originally implemented this 
> > > patch without this library, but during testing it generated a undefined 
> > > reference to `___PLEASE_LINK_WITH_iso_stdio_wide_specifiers.lib`.  So 
> > > should the comment read "MSVC told me to link this"?
> > From very few hits Google gave me, it looks like this library implements 
> > proper behavior for %s and %c in printfw/scanfw-like functions. 
> That would make sense since the undefined symbols were in `locale.cpp`.  I 
> guess I'll update the comment to say "# required for wide character 
> formatting (e.g. `printfw`/`scanfw`)"
It is required for **correct** wide character formatting functions. Hence the 
ISO in the name. They were previously implemented incorrectly and this library 
fixes this (probably just flips a switch between legacy and correct behavior).


https://reviews.llvm.org/D28441



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

[PATCH] D28441: [libc++] [CMake] Link with /nodefaultlibs on Windows

2017-01-07 Thread Eric Fiselier via Phabricator via cfe-commits

EricWF updated this revision to Diff 83526.
EricWF added a comment.

- Add comment explaining need for `iso_stdio_wide_specifiers.lib`.


https://reviews.llvm.org/D28441

Files:
  CMakeLists.txt
  cmake/Modules/HandleLibcxxFlags.cmake
  lib/CMakeLists.txt
  test/libcxx/test/config.py


Index: test/libcxx/test/config.py
===
--- test/libcxx/test/config.py
+++ test/libcxx/test/config.py
@@ -667,7 +667,7 @@
 self.cxx.link_flags += ['-lcxxrt']
 elif cxx_abi == 'none' or cxx_abi == 'default':
 if self.is_windows:
-self.cxx.link_flags += ['-lmsvcrtd']
+self.cxx.link_flags += ['-lmsvcrt']
 else:
 self.lit_config.fatal(
 'C++ ABI setting %s unsupported for tests' % cxx_abi)
Index: lib/CMakeLists.txt
===
--- lib/CMakeLists.txt
+++ lib/CMakeLists.txt
@@ -104,6 +104,16 @@
 endif()
 add_link_flags_if_supported(-nodefaultlibs)
 
+if (LIBCXX_TARGETING_WINDOWS)
+  add_compile_flags(/Zl)
+  add_link_flags(/nodefaultlib)
+  add_library_flags(ucrt) # Universal C runtime
+  add_library_flags(vcruntime) # C++ runtime
+  add_library_flags(msvcrt) # C runtime startup files
+  # Required for wide character formatting functions (e.g. `printfw`/`scanfw`)
+  add_library_flags(iso_stdio_wide_specifiers)
+endif()
+
 if (LIBCXX_OSX_REEXPORT_SYSTEM_ABI_LIBRARY)
   if (NOT DEFINED LIBCXX_LIBCPPABI_VERSION)
 set(LIBCXX_LIBCPPABI_VERSION "2") # Default value
Index: cmake/Modules/HandleLibcxxFlags.cmake
===
--- cmake/Modules/HandleLibcxxFlags.cmake
+++ cmake/Modules/HandleLibcxxFlags.cmake
@@ -26,6 +26,10 @@
 # or added in other parts of LLVM's cmake configuration.
 macro(remove_flags)
   foreach(var ${ARGN})
+string(REPLACE "${var}" "" CMAKE_CXX_FLAGS_DEBUG 
"${CMAKE_CXX_FLAGS_DEBUG}")
+string(REPLACE "${var}" "" CMAKE_CXX_FLAGS_MINSIZEREL 
"${CMAKE_CXX_FLAGS_DEBUG}")
+string(REPLACE "${var}" "" CMAKE_CXX_FLAGS_RELEASE 
"${CMAKE_CXX_FLAGS_DEBUG}")
+string(REPLACE "${var}" "" CMAKE_CXX_FLAGS_RELWITHDEBINFO 
"${CMAKE_CXX_FLAGS_DEBUG}")
 string(REPLACE "${var}" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
 string(REPLACE "${var}" "" CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
 string(REPLACE "${var}" "" CMAKE_EXE_LINKER_FLAGS 
"${CMAKE_EXE_LINKER_FLAGS}")
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -39,6 +39,12 @@
  build directory and run 'cmake /path/to/${PROJECT_NAME} [options]' there."
  )
 
+if (WIN32 AND NOT MINGW)
+  set(LIBCXX_TARGETING_WINDOWS ON)
+else()
+  set(LIBCXX_TARGETING_WINDOWS OFF)
+endif()
+
 
#===
 # Setup CMake Options
 
#===
@@ -376,6 +382,11 @@
 endif()
 remove_flags(-stdlib=libc++ -stdlib=libstdc++)
 
+# FIXME: Remove all debug flags and flags that change which Windows
+# default libraries are linked. Currently we only support linking the
+# non-debug DLLs
+remove_flags("/D_DEBUG" "/MTd" "/MDd" "/MT" "/Md" "/RTC1")
+
 # FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
 # Remove the -pedantic flag and -Wno-pedantic and -pedantic-errors
 # so they don't get transformed into -Wno and -errors respectivly.
@@ -473,7 +484,7 @@
 # Assertion flags =
 define_if(LIBCXX_ENABLE_ASSERTIONS -UNDEBUG)
 define_if_not(LIBCXX_ENABLE_ASSERTIONS -DNDEBUG)
-if (LIBCXX_ENABLE_ASSERTIONS)
+if (LIBCXX_ENABLE_ASSERTIONS AND NOT LIBCXX_TARGETING_WINDOWS)
   # MSVC doesn't like _DEBUG on release builds. See PR 4379.
   define_if_not(MSVC -D_DEBUG)
 endif()


Index: test/libcxx/test/config.py
===
--- test/libcxx/test/config.py
+++ test/libcxx/test/config.py
@@ -667,7 +667,7 @@
 self.cxx.link_flags += ['-lcxxrt']
 elif cxx_abi == 'none' or cxx_abi == 'default':
 if self.is_windows:
-self.cxx.link_flags += ['-lmsvcrtd']
+self.cxx.link_flags += ['-lmsvcrt']
 else:
 self.lit_config.fatal(
 'C++ ABI setting %s unsupported for tests' % cxx_abi)
Index: lib/CMakeLists.txt
===
--- lib/CMakeLists.txt
+++ lib/CMakeLists.txt
@@ -104,6 +104,16 @@
 endif()
 add_link_flags_if_supported(-nodefaultlibs)
 
+if (LIBCXX_TARGETING_WINDOWS)
+  add_compile_flags(/Zl)
+  add_link_flags(/nodefaultlib)
+  add_library_flags(ucrt) # Universal C runtime
+  add_library_flags(vcruntime) # C++ runtime
+  add_library_flags(msvcrt) # C runtime startup files
+  # Required for wide character formatting functions (e.g. `printfw`/`scanfw`)
+

[PATCH] D28441: [libc++] [CMake] Link with /nodefaultlibs on Windows

2017-01-07 Thread Eric Fiselier via Phabricator via cfe-commits

EricWF added inline comments.



Comment at: lib/CMakeLists.txt:113
+  add_library_flags(msvcrt) # C runtime startup files
+  add_library_flags(iso_stdio_wide_specifiers)
+endif()

halyavin wrote:
> EricWF wrote:
> > smeenai wrote:
> > > Maybe add a comment explaining the purpose of this one as well?
> > Not sure what the comment should read. I originally implemented this patch 
> > without this library, but during testing it generated a undefined reference 
> > to `___PLEASE_LINK_WITH_iso_stdio_wide_specifiers.lib`.  So should the 
> > comment read "MSVC told me to link this"?
> From very few hits Google gave me, it looks like this library implements 
> proper behavior for %s and %c in printfw/scanfw-like functions. 
That would make sense since the undefined symbols were in `locale.cpp`.  I 
guess I'll update the comment to say "# required for wide character formatting 
(e.g. `printfw`/`scanfw`)"


https://reviews.llvm.org/D28441



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

[PATCH] D28441: [libc++] [CMake] Link with /nodefaultlibs on Windows

2017-01-07 Thread Andrey Khalyavin via Phabricator via cfe-commits

halyavin added inline comments.



Comment at: lib/CMakeLists.txt:113
+  add_library_flags(msvcrt) # C runtime startup files
+  add_library_flags(iso_stdio_wide_specifiers)
+endif()

EricWF wrote:
> smeenai wrote:
> > Maybe add a comment explaining the purpose of this one as well?
> Not sure what the comment should read. I originally implemented this patch 
> without this library, but during testing it generated a undefined reference 
> to `___PLEASE_LINK_WITH_iso_stdio_wide_specifiers.lib`.  So should the 
> comment read "MSVC told me to link this"?
From very few hits Google gave me, it looks like this library implements proper 
behavior for %s and %c in printfw/scanfw-like functions. 


https://reviews.llvm.org/D28441



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

[PATCH] D28295: [libunwind] [cmake] Support overriding LLVM_CMAKE_PATH

2017-01-07 Thread Michał Górny via Phabricator via cfe-commits

mgorny requested a review of this revision.
mgorny added a comment.

@EricWF suggests that it'd be better to wait a while before depending on newer 
llvm-config, so it'd probably be preferable to do this one instead first.


https://reviews.llvm.org/D28295



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

[PATCH] D28441: [libc++] [CMake] Link with /nodefaultlibs on Windows

2017-01-07 Thread Eric Fiselier via Phabricator via cfe-commits

EricWF added inline comments.



Comment at: CMakeLists.txt:43
+if (WIN32 AND NOT MINGW)
+  set(LIBCXX_TARGETING_WINDOWS ON)
+else()

EricWF wrote:
> smeenai wrote:
> > Not the biggest fan of this name, since it's not obvious why MinGW 
> > shouldn't count as targeting Windows. I thought of 
> > `LIBCXX_TARGETING_NATIVE_WINDOWS` or `LIBCXX_TARGETING_MSVCRT` instead, but 
> > MinGW is also native Windows and targets MSVCRT, so those names aren't any 
> > better from that perspective either. I can't think of anything else at the 
> > moment, but I'm sure there's a better name.
> Thanks for the feedback. I'm not exactly sure how this macro should be 
> defined either.
> 
> I thought that `MinGW` provided its own C library runtime wrappers that 
> forward to `MSVCRT`. 
> 
> The difference I was imagining between Native Windows builds and `MinGW` is 
> that it's possible to use
> `pthread` with `MinGW` but not with native Windows targets. 
Another distinction I would like this macro to embody is whether on not the 
compiler defines `_MSC_VER`.  `clang-cl`, `clang++`  on Windows, and MSVC `cl` 
all define this macro.



Comment at: lib/CMakeLists.txt:112
+  add_library_flags(vcruntime) # C++ runtime
+  add_library_flags(msvcrt) # C runtime startup files
+  add_library_flags(iso_stdio_wide_specifiers)

halyavin wrote:
> halyavin wrote:
> > As far as I know, applications shouldn't use msvcrt.dll ([[ 
> > https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 | Windows 
> > is not a Microsoft Visual C/C++ Run-Time delivery channel ]]) Can we 
> > survive on ucrt only?
> Oh, it is static library that doesn't correspond to a dll.
I don't think that link suggests that applications shouldn't link `msvcrt.dll`. 

Instead all of the doc I see suggests that `msvcrt.dll` is linked implicitly by 
`/MD`. However since libc++ removes `/MD` and adds `/nodefaultlibs` we need to 
manually re-create the `/MD` link without the MSVC STL. That involves manually 
linking `msvcrt.dll`.


https://reviews.llvm.org/D28441



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

[PATCH] D28441: [libc++] [CMake] Link with /nodefaultlibs on Windows

2017-01-07 Thread Andrey Khalyavin via Phabricator via cfe-commits

halyavin added inline comments.



Comment at: lib/CMakeLists.txt:112
+  add_library_flags(vcruntime) # C++ runtime
+  add_library_flags(msvcrt) # C runtime startup files
+  add_library_flags(iso_stdio_wide_specifiers)

halyavin wrote:
> As far as I know, applications shouldn't use msvcrt.dll ([[ 
> https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 | Windows is 
> not a Microsoft Visual C/C++ Run-Time delivery channel ]]) Can we survive on 
> ucrt only?
Oh, it is static library that doesn't correspond to a dll.


https://reviews.llvm.org/D28441



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

[PATCH] D28441: [libc++] [CMake] Link with /nodefaultlibs on Windows

2017-01-07 Thread Andrey Khalyavin via Phabricator via cfe-commits

halyavin added inline comments.



Comment at: lib/CMakeLists.txt:112
+  add_library_flags(vcruntime) # C++ runtime
+  add_library_flags(msvcrt) # C runtime startup files
+  add_library_flags(iso_stdio_wide_specifiers)

As far as I know, applications shouldn't use msvcrt.dll ([[ 
https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 | Windows is 
not a Microsoft Visual C/C++ Run-Time delivery channel ]]) Can we survive on 
ucrt only?


https://reviews.llvm.org/D28441



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

[libcxx] r291345 - Replace identifiers called `__out` because Windows.h #defines it.

2017-01-07 Thread Eric Fiselier via cfe-commits

Author: ericwf
Date: Sat Jan  7 05:27:06 2017
New Revision: 291345

URL: http://llvm.org/viewvc/llvm-project?rev=291345=rev
Log:
Replace identifiers called `__out` because Windows.h #defines it.

Windows is greedy and it defines the identifier `__out` as a macro.
This patch renames all conflicting libc++ identifiers in order
to correctly work on Windows.

Modified:
libcxx/trunk/include/algorithm
libcxx/trunk/include/experimental/algorithm
libcxx/trunk/include/experimental/iterator
libcxx/trunk/include/regex
libcxx/trunk/test/support/nasty_macros.hpp

Modified: libcxx/trunk/include/algorithm
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/algorithm?rev=291345=291344=291345=diff
==
--- libcxx/trunk/include/algorithm (original)
+++ libcxx/trunk/include/algorithm Sat Jan  7 05:27:06 2017
@@ -3100,28 +3100,28 @@ template 
 _LIBCPP_INLINE_VISIBILITY
 _SampleIterator __sample(_PopulationIterator __first,
- _PopulationIterator __last, _SampleIterator __out,
+ _PopulationIterator __last, _SampleIterator __output,
  _Distance __n,
  _UniformRandomNumberGenerator & __g,
  input_iterator_tag) {
 
   _Distance __k = 0;
   for (; __first != __last && __k < __n; ++__first, (void)++__k)
-__out[__k] = *__first;
+__output[__k] = *__first;
   _Distance __sz = __k;
   for (; __first != __last; ++__first, (void)++__k) {
 _Distance __r = _VSTD::uniform_int_distribution<_Distance>(0, __k)(__g);
 if (__r < __sz)
-  __out[__r] = *__first;
+  __output[__r] = *__first;
   }
-  return __out + _VSTD::min(__n, __k);
+  return __output + _VSTD::min(__n, __k);
 }
 
 template 
 _LIBCPP_INLINE_VISIBILITY
 _SampleIterator __sample(_PopulationIterator __first,
- _PopulationIterator __last, _SampleIterator __out,
+ _PopulationIterator __last, _SampleIterator __output,
  _Distance __n,
  _UniformRandomNumberGenerator& __g,
  forward_iterator_tag) {
@@ -3130,18 +3130,18 @@ _SampleIterator __sample(_PopulationIter
 _Distance __r =
 _VSTD::uniform_int_distribution<_Distance>(0, --__unsampled_sz)(__g);
 if (__r < __n) {
-  *__out++ = *__first;
+  *__output++ = *__first;
   --__n;
 }
   }
-  return __out;
+  return __output;
 }
 
 template 
 _LIBCPP_INLINE_VISIBILITY
 _SampleIterator __sample(_PopulationIterator __first,
- _PopulationIterator __last, _SampleIterator __out,
+ _PopulationIterator __last, _SampleIterator __output,
  _Distance __n, _UniformRandomNumberGenerator& __g) {
   typedef typename iterator_traits<_PopulationIterator>::iterator_category
 _PopCategory;
@@ -3153,7 +3153,7 @@ _SampleIterator __sample(_PopulationIter
   typedef typename common_type<_Distance, _Difference>::type _CommonType;
   _LIBCPP_ASSERT(__n >= 0, "N must be a positive number.");
   return _VSTD::__sample(
-  __first, __last, __out, _CommonType(__n),
+  __first, __last, __output, _CommonType(__n),
   __g, _PopCategory());
 }
 
@@ -3162,9 +3162,9 @@ template 
 inline _LIBCPP_INLINE_VISIBILITY
 _SampleIterator sample(_PopulationIterator __first,
-   _PopulationIterator __last, _SampleIterator __out,
+   _PopulationIterator __last, _SampleIterator __output,
_Distance __n, _UniformRandomNumberGenerator&& __g) {
-return _VSTD::__sample(__first, __last, __out, __n, __g);
+return _VSTD::__sample(__first, __last, __output, __n, __g);
 }
 #endif // _LIBCPP_STD_VER > 14
 

Modified: libcxx/trunk/include/experimental/algorithm
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/experimental/algorithm?rev=291345=291344=291345=diff
==
--- libcxx/trunk/include/experimental/algorithm (original)
+++ libcxx/trunk/include/experimental/algorithm Sat Jan  7 05:27:06 2017
@@ -60,9 +60,9 @@ template 
 inline _LIBCPP_INLINE_VISIBILITY
 _SampleIterator sample(_PopulationIterator __first, _PopulationIterator __last,
-   _SampleIterator __out, _Distance __n,
+   _SampleIterator __output, _Distance __n,
_UniformRandomNumberGenerator &&__g) {
-  return _VSTD::__sample(__first, __last, __out, __n, __g);
+  return _VSTD::__sample(__first, __last, __output, __n, __g);
 }
 
 _LIBCPP_END_NAMESPACE_LFTS

Modified: libcxx/trunk/include/experimental/iterator
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/experimental/iterator?rev=291345=291344=291345=diff
==
---

[libcxx] r291344 - Added "Michael Park" to `CREDITS.TXT`.

2017-01-07 Thread Michael Park via cfe-commits

Author: mpark
Date: Sat Jan  7 04:19:24 2017
New Revision: 291344

URL: http://llvm.org/viewvc/llvm-project?rev=291344=rev
Log:
Added "Michael Park" to `CREDITS.TXT`.

Summary: Test commit + give myself credit.

Reviewers: EricWF

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

Modified:
libcxx/trunk/CREDITS.TXT

Modified: libcxx/trunk/CREDITS.TXT
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CREDITS.TXT?rev=291344=291343=291344=diff
==
--- libcxx/trunk/CREDITS.TXT (original)
+++ libcxx/trunk/CREDITS.TXT Sat Jan  7 04:19:24 2017
@@ -80,6 +80,10 @@ N: Andrew Morrow
 E: andrew.c.mor...@gmail.com
 D: Minor patches and Linux fixes.
 
+N: Michael Park
+E: mp...@apache.org
+D: Implementation of .
+
 N: Arvid Picciani
 E: aep at exys dot org
 D: Minor patches and musl port.


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

[PATCH] D28441: [libc++] [CMake] Link with /nodefaultlibs on Windows

2017-01-07 Thread Eric Fiselier via Phabricator via cfe-commits

EricWF added inline comments.



Comment at: CMakeLists.txt:388
+# non-debug DLLs
+remove_flags("/D_DEBUG" "/MTd" "/MDd" "/MT" "/Md" "/RTC1")
+

smeenai wrote:
> cl (and presumably clang-cl) also accepts all these flags with a leading dash 
> instead of a leading slash, and cmake at least has a tendency to do `-D` 
> instead of `/D`, so you might need to take those into account as well. Also, 
> what about the other potential `/RTC` options?
My goal here is only to remove flags which CMake adds by default as part of 
`CMAKE_CXX_FLAGS__INIT`.



Comment at: lib/CMakeLists.txt:108-109
+if (LIBCXX_TARGETING_WINDOWS)
+  add_compile_flags(/Zl)
+  add_link_flags(/nodefaultlib)
+  add_library_flags(ucrt) # Universal C runtime

smeenai wrote:
> halyavin wrote:
> > smeenai wrote:
> > > These should be guarded under a check for a cl or cl-like frontend rather 
> > > than `LIBCXX_TARGETING_WINDOWS` (since in theory we could be using the 
> > > regular clang frontend to compile for Windows as well).
> > Regular clang supports both gcc-like and cl-like options (there are 2 
> > compilers: clang.exe and clang-cl.exe). I think it is not worth it to 
> > support both considering they differ only in command line options handling.
> I'm aware of the separate drivers, but I still think it's worthwhile 
> specifying appropriate conditionals when it's easy enough to do. (In this 
> case, the inverse check of 
> https://reviews.llvm.org/diffusion/L/browse/libcxx/trunk/CMakeLists.txt;291339$394
>  should do the trick.)
Is it alright if libc++'s CMakeLists.txt only supports targeting `clang-cl` for 
the time being? I would love to also support `clang++` but that seems like a 
ways off.

For now my only concern is getting `clang-cl` working. Expanding to include 
supporting `clang++` seems like it's a ways away. @smeenai Would this be a 
regression for you?



Comment at: lib/CMakeLists.txt:111
+  add_library_flags(ucrt) # Universal C runtime
+  add_library_flags(vcruntime) # C++ runtime
+  add_library_flags(msvcrt) # C runtime startup files

smeenai wrote:
> halyavin wrote:
> > smeenai wrote:
> > > Idk if there's anything specific to C++ in vcruntime; it's more compiler 
> > > runtime functions as far as I know.
> > It contains exception handling stuff.
> You're right, but it also contains `longjmp`, `memcpy`, `memmove`, `memset`, 
> etc, which is why I found the comment slightly weird initially. I guess it's 
> fairly accurate as far as the usage of vcruntime in libc++ goes though.
FYI here is the documentation I was reading when deciding what libraries to 
link: https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx



Comment at: lib/CMakeLists.txt:113
+  add_library_flags(msvcrt) # C runtime startup files
+  add_library_flags(iso_stdio_wide_specifiers)
+endif()

smeenai wrote:
> Maybe add a comment explaining the purpose of this one as well?
Not sure what the comment should read. I originally implemented this patch 
without this library, but during testing it generated a undefined reference to 
`___PLEASE_LINK_WITH_iso_stdio_wide_specifiers.lib`.  So should the comment 
read "MSVC told me to link this"?


https://reviews.llvm.org/D28441



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

[libcxx] r291343 - [libc++] Implement terminate(), unexpected() and uncaught_exceptions() on Windows

2017-01-07 Thread Eric Fiselier via cfe-commits

Author: ericwf
Date: Sat Jan  7 04:04:40 2017
New Revision: 291343

URL: http://llvm.org/viewvc/llvm-project?rev=291343=rev
Log:
[libc++] Implement terminate(), unexpected() and uncaught_exceptions() on 
Windows

Summary:
This patch implements the following functions on Windows by forwarding to the 
MSVCRT:

* `get_terminate()`
* `set_terminate()`
* `terminate()`
* `set_unexpected()`
* `get_unexpected()`
* `unexpected()`
* `uncaught_exception()`

* `uncaught_exceptions()`

Reviewers: compnerd, rnk, majnemer, smeenai

Subscribers: cfe-commits

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

Modified:
libcxx/trunk/src/exception.cpp

Modified: libcxx/trunk/src/exception.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/exception.cpp?rev=291343=291342=291343=diff
==
--- libcxx/trunk/src/exception.cpp (original)
+++ libcxx/trunk/src/exception.cpp Sat Jan  7 04:04:40 2017
@@ -12,7 +12,10 @@
 #include "exception"
 #include "new"
 
-#if defined(__APPLE__) && !defined(LIBCXXRT) && \
+#if defined(_LIBCPP_ABI_MICROSOFT)
+#include 
+#include 
+#elif defined(__APPLE__) && !defined(LIBCXXRT) && \
 !defined(_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY)
   #include 
 
@@ -46,13 +49,21 @@ namespace std
 unexpected_handler
 set_unexpected(unexpected_handler func) _NOEXCEPT
 {
-return __sync_lock_test_and_set(&__unexpected_handler, func);
+#if defined(_LIBCPP_ABI_MICROSOFT)
+  return ::set_unexpected(func);
+#else
+  return __sync_lock_test_and_set(&__unexpected_handler, func);
+#endif
 }
 
 unexpected_handler
 get_unexpected() _NOEXCEPT
 {
-return __sync_fetch_and_add(&__unexpected_handler, (unexpected_handler)0);
+#if defined(_LIBCPP_ABI_MICROSOFT)
+  return ::_get_unexpected();
+#else
+  return __sync_fetch_and_add(&__unexpected_handler, (unexpected_handler)0);
+#endif
 }
 
 _LIBCPP_NORETURN
@@ -67,13 +78,21 @@ unexpected()
 terminate_handler
 set_terminate(terminate_handler func) _NOEXCEPT
 {
-return __sync_lock_test_and_set(&__terminate_handler, func);
+#if defined(_LIBCPP_ABI_MICROSOFT)
+  return ::set_terminate(func);
+#else
+  return __sync_lock_test_and_set(&__terminate_handler, func);
+#endif
 }
 
 terminate_handler
 get_terminate() _NOEXCEPT
 {
-return __sync_fetch_and_add(&__terminate_handler, (terminate_handler)0);
+#if defined(_LIBCPP_ABI_MICROSOFT)
+  return ::_get_terminate();
+#else
+  return __sync_fetch_and_add(&__terminate_handler, (terminate_handler)0);
+#endif
 }
 
 #ifndef __EMSCRIPTEN__ // We provide this in JS
@@ -103,6 +122,7 @@ terminate() _NOEXCEPT
 #endif // !defined(LIBCXXRT) && !defined(_LIBCPPABI_VERSION)
 
 #if !defined(LIBCXXRT) && !defined(__GLIBCXX__) && !defined(__EMSCRIPTEN__)
+
 bool uncaught_exception() _NOEXCEPT { return uncaught_exceptions() > 0; }
 
 int uncaught_exceptions() _NOEXCEPT
@@ -115,7 +135,9 @@ int uncaught_exceptions() _NOEXCEPT
 # else
 return __cxa_uncaught_exception() ? 1 : 0;
 # endif
-#else  // __APPLE__
+#elif defined(_LIBCPP_ABI_MICROSOFT)
+return __uncaught_exceptions();
+#else
 #   if defined(_MSC_VER) && ! defined(__clang__)
 _LIBCPP_WARNING("uncaught_exceptions not yet implemented")
 #   else


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

[PATCH] D28442: [libc++] Implement terminate(), unexpected() and uncaught_exceptions() on Windows

2017-01-07 Thread Eric Fiselier via Phabricator via cfe-commits

EricWF marked an inline comment as done.
EricWF added a comment.

In https://reviews.llvm.org/D28442#638862, @smeenai wrote:

> Hooray for Microsoft for putting all these in msvcrt (their **C** runtime 
> library) instead of msvcprt (their C++ runtime library), I guess :p


Although Boo to `eh.h` for being in the same directory as the MSVC STL headers. 
If possible I would like to be able to compile libc++ without
adding that directory to the include paths.




Comment at: src/exception.cpp:53
+#if defined(_LIBCPP_ABI_MICROSOFT)
+  return ::set_unexpected(func);
+#else

smeenai wrote:
> MSDN says "unexpected is not used in the current C++ exception-handling 
> implementation", which is maybe not the most desirable thing in the world, 
> but I guess this is going away in C++17 anyway :D
Actually `unexpected()` has gone away in C++17 since C++17 removes "dynamic 
exception specifications" (ie `void foo() throw(int, ...)`). Therefore I 
suspect the doc is referring to that.

However I suspect are still used when `clang-cl` targets C++14 or newer.



Comment at: src/exception.cpp:139
+#elif defined(_LIBCPP_ABI_MICROSOFT)
+return __uncaught_exceptions();
+#else

smeenai wrote:
> Yay undocumented APIs (at least as far as I can see).
Undocumented API for sure. Unfortunately libc++ is going to have to rely on a 
number of undocumented API's because Microsoft doesn't provide documentation 
for porting an STL to Windows.


https://reviews.llvm.org/D28442



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

[PATCH] D28427: Allow constexpr construction of subobjects unconditionally, not just in C++14.

2017-01-07 Thread Richard Smith via Phabricator via cfe-commits

rsmith added a comment.

Can you add a test please?


https://reviews.llvm.org/D28427



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

Re: [libcxx] r291329 - Add _LIBCPP_ABI_[ITANIUM|MICROSOFT] macros.

2017-01-07 Thread Eric Fiselier via cfe-commits

On Sat, Jan 7, 2017 at 1:29 AM, Shoaib Meenai  wrote:

> Do you think it's worth also checking for the presence of cxxabi.h and
> assuming the Itanium ABI if it's found, since the MS ABI shouldn't be using
> any ABI library?
>

No I don't think we should check for `cxxabi.h`.It's entirely possible to
want to compile
for the Microsoft ABI when `cxxabi.h` is in your path.

That being said I don't think the current configuration is correct either.
I'm just using it
until we change Clang to provide the needed macros.


>
> (_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY would have been ideal were it
> available
> persistently rather than only during the build of libc++ itself. It could
> still work if this macro isn't used in any headers though.)
>
> Also, is there ever a case where _MSC_VER would be defined and _WIN32
> wouldn't? The current check seems slightly redundant.
>
> On 1/6/17, 6:43 PM, "cfe-commits on behalf of Eric Fiselier via
> cfe-commits"  cfe-commits@lists.llvm.org> wrote:
>
> Author: ericwf
> Date: Fri Jan  6 20:43:58 2017
> New Revision: 291329
>
> URL: https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.
> org_viewvc_llvm-2Dproject-3Frev-3D291329-26view-3Drev=DgIGaQ=
> 5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=vt8N_ZR6syyL2-CBgE_
> SBSS0YTQdKIMfcLf4r8leu2c=fVFRdDSSgXSZHuGlbfQI1SHyPLDGvuVdhQdxOsU30hI=
> Log:
> Add _LIBCPP_ABI_[ITANIUM|MICROSOFT] macros.
>
> This patch adds a libc++ configuration macro for the ABI we
> are targeting, either Itanium or Microsoft. For now we configure
> for the Microsoft ABI when on Windows with a compiler that defines
> _MSC_VER. However this is only temporary until Clang implements
> builtin macros we can use.
>
> Modified:
> libcxx/trunk/include/__config
>
> Modified: libcxx/trunk/include/__config
> URL: https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.
> org_viewvc_llvm-2Dproject_libcxx_trunk_include_-5F-
> 5Fconfig-3Frev-3D291329-26r1-3D291328-26r2-3D291329-26view-
> 3Ddiff=DgIGaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=vt8N_
> ZR6syyL2-CBgE_SBSS0YTQdKIMfcLf4r8leu2c=46ge62wLL0LHhhQmWVsvb0uPoh8oV4
> 4DG0fsq0nEPs8=
> 
> ==
> --- libcxx/trunk/include/__config (original)
> +++ libcxx/trunk/include/__config Fri Jan  6 20:43:58 2017
> @@ -111,6 +111,15 @@
>  #define _LIBCPP_COMPILER_IBM
>  #endif
>
> +// FIXME: ABI detection should be done via compiler builtin macros.
> This
> +// is just a placeholder until Clang implements such macros. For now
> assume
> +// that Windows compilers pretending to be MSVC++ target the
> microsoft ABI.
> +#if defined(_WIN32) && defined(_MSC_VER)
> +# define _LIBCPP_ABI_MICROSOFT
> +#else
> +# define _LIBCPP_ABI_ITANIUM
> +#endif
> +
>  // Need to detect which libc we're using if we're on Linux.
>  #if defined(__linux__)
>  #include 
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.
> llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits=DgIGaQ=
> 5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=vt8N_ZR6syyL2-CBgE_
> SBSS0YTQdKIMfcLf4r8leu2c=rzONjyM9TBpTpA9aQpIA9LFsaiofSZIYff34ZiNb5cA=
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r291342 - Ensure Sleep(...) isn't passed the value 0 on Windows

2017-01-07 Thread Eric Fiselier via cfe-commits

Author: ericwf
Date: Sat Jan  7 03:53:28 2017
New Revision: 291342

URL: http://llvm.org/viewvc/llvm-project?rev=291342=rev
Log:
Ensure Sleep(...) isn't passed the value 0 on Windows

Modified:
libcxx/trunk/src/thread.cpp

Modified: libcxx/trunk/src/thread.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/thread.cpp?rev=291342=291341=291342=diff
==
--- libcxx/trunk/src/thread.cpp (original)
+++ libcxx/trunk/src/thread.cpp Sat Jan  7 03:53:28 2017
@@ -119,7 +119,7 @@ sleep_for(const chrono::nanoseconds& ns)
 {
 #if defined(_LIBCPP_WIN32API)
 milliseconds ms = duration_cast(ns);
-if (ns > duration_cast(ms))
+if (ms.count() == 0 || ns > duration_cast(ms))
   ++ms;
 Sleep(ms.count());
 #else


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

[PATCH] D28445: [Analyzer] Extend taint propagation and checking

2017-01-07 Thread Vlad Tsyrklevich via Phabricator via cfe-commits

vlad.tsyrklevich created this revision.
vlad.tsyrklevich added reviewers: zaks.anna, cfe-commits.

While extending the GenericTaintChecker for my purposes I'm hitting a case 
where taint is not propagated where I believe it should be. Currently, the 
following example will propagate taint correctly:

  char buf[16];
  taint_source(buf);
  taint_sink(buf);

However, the following fails:

  char buf[16];
  taint_source();
  taint_sink(buf);

In the first example, buf has it's symbol correctly extracted (via 
`GenericTaintChecker::getPointedToSymbol()`) as a  
`SymbolDerived{conj_$N{char}, element{buf,0 S64b,char}}`, it's marked as 
tainted and then the taint check correctly finds it using 
`ProgramState::isTainted()`.

In the second example, the SVal obtained in 
`GenericTaintChecker::getPointedToSymbol()` is a LazyCompoundVal so 
`SVal::getAsSymbol()` returns a NULL SymbolRef, meaning the symbol is not 
tainted.

This change extends GenericTaintChecker to obtain a SymbolRegionValue from the 
LCV MemRegion in `getPointedToSymbol()`, and then extends 
`ProgramState::isTainted()` to correctly match a `SymbolRegionValue{buf}` 
against a `SymbolDerived{conj_$N{char}, element{buf,0 S64b,char}}`.

I'm not familiar enough with analyzer internals to be confident in whether this 
is the right approach to fix this bug, so feedback is welcome.


https://reviews.llvm.org/D28445

Files:
  lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp
  lib/StaticAnalyzer/Core/ProgramState.cpp
  test/Analysis/taint-generic.c


Index: test/Analysis/taint-generic.c
===
--- test/Analysis/taint-generic.c
+++ test/Analysis/taint-generic.c
@@ -169,6 +169,11 @@
   sock = socket(AF_LOCAL, SOCK_STREAM, 0);
   read(sock, buffer, 100);
   execl(buffer, "filename", 0); // no-warning
+
+  sock = socket(AF_INET, SOCK_STREAM, 0);
+  // References to both buffer and  as an argument should taint the 
argument
+  read(sock, , 100);
+  execl(buffer, "filename", 0); // expected-warning {{Untrusted data is passed 
to a system call}}
 }
 
 int testDivByZero() {
Index: lib/StaticAnalyzer/Core/ProgramState.cpp
===
--- lib/StaticAnalyzer/Core/ProgramState.cpp
+++ lib/StaticAnalyzer/Core/ProgramState.cpp
@@ -690,6 +690,15 @@
   if (!Reg)
 return false;
 
+  if (const TypedValueRegion *TVR = dyn_cast(Reg)) {
+SymbolRef Sym = getSymbolManager().getRegionValueSymbol(TVR);
+
+// We don't call isTainted(Sym, K) here because it could lead to infinite 
recursion.
+const TaintTagType *Tag = get(Sym);
+if (Tag && *Tag == K)
+  return true;
+  }
+
   // Element region (array element) is tainted if either the base or the offset
   // are tainted.
   if (const ElementRegion *ER = dyn_cast(Reg))
@@ -720,7 +729,8 @@
 
 // If this is a SymbolDerived with a tainted parent, it's also tainted.
 if (const SymbolDerived *SD = dyn_cast(*SI))
-  Tainted = Tainted || isTainted(SD->getParentSymbol(), Kind);
+  Tainted = Tainted || isTainted(SD->getParentSymbol(), Kind)
+|| isTainted(SD->getOriginRegion(), Kind);
 
 // If memory region is tainted, data is also tainted.
 if (const SymbolRegionValue *SRV = dyn_cast(*SI))
Index: lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp
+++ lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp
@@ -438,6 +438,10 @@
 dyn_cast(Arg->getType().getCanonicalType().getTypePtr());
   SVal Val = State->getSVal(*AddrLoc,
 ArgTy ? ArgTy->getPointeeType(): QualType());
+
+  if (auto LCV = Val.getAs())
+return C.getSymbolManager().getRegionValueSymbol(LCV->getRegion());
+
   return Val.getAsSymbol();
 }
 


Index: test/Analysis/taint-generic.c
===
--- test/Analysis/taint-generic.c
+++ test/Analysis/taint-generic.c
@@ -169,6 +169,11 @@
   sock = socket(AF_LOCAL, SOCK_STREAM, 0);
   read(sock, buffer, 100);
   execl(buffer, "filename", 0); // no-warning
+
+  sock = socket(AF_INET, SOCK_STREAM, 0);
+  // References to both buffer and  as an argument should taint the argument
+  read(sock, , 100);
+  execl(buffer, "filename", 0); // expected-warning {{Untrusted data is passed to a system call}}
 }
 
 int testDivByZero() {
Index: lib/StaticAnalyzer/Core/ProgramState.cpp
===
--- lib/StaticAnalyzer/Core/ProgramState.cpp
+++ lib/StaticAnalyzer/Core/ProgramState.cpp
@@ -690,6 +690,15 @@
   if (!Reg)
 return false;
 
+  if (const TypedValueRegion *TVR = dyn_cast(Reg)) {
+SymbolRef Sym = getSymbolManager().getRegionValueSymbol(TVR);
+
+// We don't call isTainted(Sym, K) here because it could lead to infinite recursion.
+const TaintTagType *Tag = get(Sym);
+if (Tag &&

Re: [libcxx] r291329 - Add _LIBCPP_ABI_[ITANIUM|MICROSOFT] macros.

2017-01-07 Thread Shoaib Meenai via cfe-commits

Do you think it's worth also checking for the presence of cxxabi.h and
assuming the Itanium ABI if it's found, since the MS ABI shouldn't be using
any ABI library?

(_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY would have been ideal were it available
persistently rather than only during the build of libc++ itself. It could
still work if this macro isn't used in any headers though.)

Also, is there ever a case where _MSC_VER would be defined and _WIN32
wouldn't? The current check seems slightly redundant.

On 1/6/17, 6:43 PM, "cfe-commits on behalf of Eric Fiselier via cfe-commits" 
 
wrote:

Author: ericwf
Date: Fri Jan  6 20:43:58 2017
New Revision: 291329

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D291329-26view-3Drev=DgIGaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=vt8N_ZR6syyL2-CBgE_SBSS0YTQdKIMfcLf4r8leu2c=fVFRdDSSgXSZHuGlbfQI1SHyPLDGvuVdhQdxOsU30hI=
 
Log:
Add _LIBCPP_ABI_[ITANIUM|MICROSOFT] macros.

This patch adds a libc++ configuration macro for the ABI we
are targeting, either Itanium or Microsoft. For now we configure
for the Microsoft ABI when on Windows with a compiler that defines
_MSC_VER. However this is only temporary until Clang implements
builtin macros we can use.

Modified:
libcxx/trunk/include/__config

Modified: libcxx/trunk/include/__config
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_libcxx_trunk_include_-5F-5Fconfig-3Frev-3D291329-26r1-3D291328-26r2-3D291329-26view-3Ddiff=DgIGaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=vt8N_ZR6syyL2-CBgE_SBSS0YTQdKIMfcLf4r8leu2c=46ge62wLL0LHhhQmWVsvb0uPoh8oV44DG0fsq0nEPs8=
 

==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Fri Jan  6 20:43:58 2017
@@ -111,6 +111,15 @@
 #define _LIBCPP_COMPILER_IBM
 #endif
 
+// FIXME: ABI detection should be done via compiler builtin macros. This
+// is just a placeholder until Clang implements such macros. For now assume
+// that Windows compilers pretending to be MSVC++ target the microsoft ABI.
+#if defined(_WIN32) && defined(_MSC_VER)
+# define _LIBCPP_ABI_MICROSOFT
+#else
+# define _LIBCPP_ABI_ITANIUM
+#endif
+
 // Need to detect which libc we're using if we're on Linux.
 #if defined(__linux__)
 #include 


___
cfe-commits mailing list
cfe-commits@lists.llvm.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits=DgIGaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=vt8N_ZR6syyL2-CBgE_SBSS0YTQdKIMfcLf4r8leu2c=rzONjyM9TBpTpA9aQpIA9LFsaiofSZIYff34ZiNb5cA=
 


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

[PATCH] D28441: [libc++] [CMake] Link with /nodefaultlibs on Windows

2017-01-07 Thread Shoaib Meenai via Phabricator via cfe-commits

smeenai added inline comments.



Comment at: lib/CMakeLists.txt:108-109
+if (LIBCXX_TARGETING_WINDOWS)
+  add_compile_flags(/Zl)
+  add_link_flags(/nodefaultlib)
+  add_library_flags(ucrt) # Universal C runtime

halyavin wrote:
> smeenai wrote:
> > These should be guarded under a check for a cl or cl-like frontend rather 
> > than `LIBCXX_TARGETING_WINDOWS` (since in theory we could be using the 
> > regular clang frontend to compile for Windows as well).
> Regular clang supports both gcc-like and cl-like options (there are 2 
> compilers: clang.exe and clang-cl.exe). I think it is not worth it to support 
> both considering they differ only in command line options handling.
I'm aware of the separate drivers, but I still think it's worthwhile specifying 
appropriate conditionals when it's easy enough to do. (In this case, the 
inverse check of 
https://reviews.llvm.org/diffusion/L/browse/libcxx/trunk/CMakeLists.txt;291339$394
 should do the trick.)



Comment at: lib/CMakeLists.txt:111
+  add_library_flags(ucrt) # Universal C runtime
+  add_library_flags(vcruntime) # C++ runtime
+  add_library_flags(msvcrt) # C runtime startup files

halyavin wrote:
> smeenai wrote:
> > Idk if there's anything specific to C++ in vcruntime; it's more compiler 
> > runtime functions as far as I know.
> It contains exception handling stuff.
You're right, but it also contains `longjmp`, `memcpy`, `memmove`, `memset`, 
etc, which is why I found the comment slightly weird initially. I guess it's 
fairly accurate as far as the usage of vcruntime in libc++ goes though.


https://reviews.llvm.org/D28441



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

49 matches

Mail list logo