[PATCH] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

[Pekka Jääskeläinen via Phabricator via cfe-commits]

pekka.jaaskelainen added a comment.

In https://reviews.llvm.org/D28080#653493, @Anastasia wrote:

> > Also, for me the command without -emit-llvm doesn't output anything.
>
> What targets do you use?


In this case I used only SPIR. I suppose this is fine as the concept of linking 
is unclear in case of Clang's OpenCL
support.

> I think the problem is that it's not clear what the default output of the 
> standalone compiler should be for the most of the OpenCL targets, since it 
> does't produce a valid binary. If let's say we emit an x86 binary, would it 
> be valid to run it for POCL directly?  Perhaps, we could try to emit the 
> bitcode by default then.

An x86 OpenCL binary from Clang is not executable as is (especially in case of 
multi-WI WGs), but needs a transformation to convert the multi-WI
to parallel loops, fibers, straight to vector instructions, or similar.  
However, I try to keep the Clang's OpenCL output of any target valid for pocl 
without
a special triplet code for now. This way it should be possible to get OpenCL 
support for most, if not all, targets supported by LLVM out of the box.

One problem I've found are the host callable kernel functions. We don't want 
the target-specific CC/ABI used for them as they have clSetKernelArg()
mappable arguments and other interfacing considerations, especially with 
heterogeneous setups. Recently I discovered that there might be a way to fix 
this
nicely via the SPIR target. If we use SPIR ABI by default for OpenCL kernel 
functions, the rest of it might just work with the target's default settings.

Just a heads up, I will propose this patch to upstream after some testing: 
https://raw.githubusercontent.com/pocl/pocl/c9ae29f2268d3b92462d6ca97d1d596dae0d15a1/tools/patches/clang-3.9-always-spir-cc-for-kernels.patch


https://reviews.llvm.org/D28080



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

[PATCH] D29065: Split isUsingLTO() outside of embedBitcodeInObject() and embedBitcodeMarkerOnly().

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D29065#654336, @steven_wu wrote:

> I think you should add a new API for embedBitcodeMarkerEnabled() or revert 
> the name the APIs to before https://reviews.llvm.org/rL287084.


I'm missing where https://reviews.llvm.org/rL287084 changed the name? It 
introduced a new API but didn't rename anything AFAICT, here is what it was 
before:

  bool embedBitcodeEnabled() const { return BitcodeEmbed == EmbedBitcode; }
  bool embedBitcodeEnabled() const { return BitcodeEmbed != EmbedNone; }


https://reviews.llvm.org/D29065



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

[PATCH] D29066: Forward -bitcode_process_mode to ld64 in marker-only mode

[Steven Wu via Phabricator via cfe-commits]

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

LGTM


https://reviews.llvm.org/D29066



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

[PATCH] D29066: Forward -bitcode_process_mode to ld64 in marker-only mode

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini updated this revision to Diff 85530.
mehdi_amini added a comment.

Add a test


https://reviews.llvm.org/D29066

Files:
  clang/lib/Driver/Tools.cpp
  clang/test/Driver/embed-bitcode.c


Index: clang/test/Driver/embed-bitcode.c
===
--- clang/test/Driver/embed-bitcode.c
+++ clang/test/Driver/embed-bitcode.c
@@ -34,6 +34,13 @@
 // CHECK-LTO-NOT: warning: argument unused during compilation: 
'-fembed-bitcode'
 // CHECK-LTO-NOT: -cc1
 // CHECK-LTO-NOT: -fembed-bitcode=all
+// RUN: touch %t.o
+// RUN: %clang  %t.o -fembed-bitcode  -fembed-bitcode-marker 
-mlinker-version=277  2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LTO-MARKER-277
+// RUN: %clang  %t.o -fembed-bitcode  -fembed-bitcode-marker 
-mlinker-version=278  2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LTO-MARKER-278
+// CHECK-LTO-MARKER-277-NOT: bitcode_process_mode
+// CHECK-LTO-MARKER-278: bitcode_process_mode
+
+
 
 // RUN: %clang -c %s -fembed-bitcode-marker -fintegrated-as 2>&1 -### | 
FileCheck %s -check-prefix=CHECK-MARKER
 // CHECK-MARKER: -cc1
Index: clang/lib/Driver/Tools.cpp
===
--- clang/lib/Driver/Tools.cpp
+++ clang/lib/Driver/Tools.cpp
@@ -8435,9 +8435,13 @@
   // for embed-bitcode, use -bitcode_bundle in linker command
   if (C.getDriver().embedBitcodeEnabled()) {
 // Check if the toolchain supports bitcode build flow.
-if (MachOTC.SupportsEmbeddedBitcode())
+if (MachOTC.SupportsEmbeddedBitcode()) {
   CmdArgs.push_back("-bitcode_bundle");
-else
+  if (C.getDriver().embedBitcodeMarkerOnly() && Version[0] >= 278) {
+CmdArgs.push_back("-bitcode_process_mode");
+CmdArgs.push_back("marker");
+  }
+} else
   D.Diag(diag::err_drv_bitcode_unsupported_on_toolchain);
   }
 


Index: clang/test/Driver/embed-bitcode.c
===
--- clang/test/Driver/embed-bitcode.c
+++ clang/test/Driver/embed-bitcode.c
@@ -34,6 +34,13 @@
 // CHECK-LTO-NOT: warning: argument unused during compilation: '-fembed-bitcode'
 // CHECK-LTO-NOT: -cc1
 // CHECK-LTO-NOT: -fembed-bitcode=all
+// RUN: touch %t.o
+// RUN: %clang  %t.o -fembed-bitcode  -fembed-bitcode-marker -mlinker-version=277  2>&1 -### | FileCheck %s -check-prefix=CHECK-LTO-MARKER-277
+// RUN: %clang  %t.o -fembed-bitcode  -fembed-bitcode-marker -mlinker-version=278  2>&1 -### | FileCheck %s -check-prefix=CHECK-LTO-MARKER-278
+// CHECK-LTO-MARKER-277-NOT: bitcode_process_mode
+// CHECK-LTO-MARKER-278: bitcode_process_mode
+
+
 
 // RUN: %clang -c %s -fembed-bitcode-marker -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-MARKER
 // CHECK-MARKER: -cc1
Index: clang/lib/Driver/Tools.cpp
===
--- clang/lib/Driver/Tools.cpp
+++ clang/lib/Driver/Tools.cpp
@@ -8435,9 +8435,13 @@
   // for embed-bitcode, use -bitcode_bundle in linker command
   if (C.getDriver().embedBitcodeEnabled()) {
 // Check if the toolchain supports bitcode build flow.
-if (MachOTC.SupportsEmbeddedBitcode())
+if (MachOTC.SupportsEmbeddedBitcode()) {
   CmdArgs.push_back("-bitcode_bundle");
-else
+  if (C.getDriver().embedBitcodeMarkerOnly() && Version[0] >= 278) {
+CmdArgs.push_back("-bitcode_process_mode");
+CmdArgs.push_back("marker");
+  }
+} else
   D.Diag(diag::err_drv_bitcode_unsupported_on_toolchain);
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28981: Use GNU-style attributes for several __throw_XXX() functions

[Eric Fiselier via Phabricator via cfe-commits]

EricWF resigned from this revision.
EricWF added a comment.

I think we've agreed that this change shouldn't proceed. Resigning as reviewer.


https://reviews.llvm.org/D28981



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

[libcxx] r292883 - [libcxx] Never use within libc++

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Mon Jan 23 22:57:33 2017
New Revision: 292883

URL: http://llvm.org/viewvc/llvm-project?rev=292883&view=rev
Log:
[libcxx] Never use  within libc++

Summary:
It is my opinion that libc++ should never use ``, including in the 
`dylib`. This patch remove all uses of `assert` from within libc++ and replaces 
most of them with `_LIBCPP_ASSERT` instead.

Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS`  off by default, 
because the standard library should not be aborting user programs unless 
explicitly asked to.

Reviewers: mclow.lists, compnerd, smeenai

Reviewed By: mclow.lists

Subscribers: mgorny, cfe-commits

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

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/include/__config
libcxx/trunk/include/__threading_support
libcxx/trunk/src/condition_variable.cpp
libcxx/trunk/src/experimental/filesystem/path.cpp
libcxx/trunk/src/mutex.cpp
libcxx/trunk/src/system_error.cpp

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=292883&r1=292882&r2=292883&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Mon Jan 23 22:57:33 2017
@@ -60,7 +60,7 @@ endif()
 include(CMakeDependentOption)
 
 # Basic options ---
-option(LIBCXX_ENABLE_ASSERTIONS "Enable assertions independent of build mode." 
ON)
+option(LIBCXX_ENABLE_ASSERTIONS "Enable assertions independent of build mode." 
OFF)
 option(LIBCXX_ENABLE_SHARED "Build libc++ as a shared library." ON)
 option(LIBCXX_ENABLE_STATIC "Build libc++ as a static library." ON)
 option(LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY "Build libc++experimental.a" ON)
@@ -501,6 +501,7 @@ endif()
 # Assertion flags =
 define_if(LIBCXX_ENABLE_ASSERTIONS -UNDEBUG)
 define_if_not(LIBCXX_ENABLE_ASSERTIONS -DNDEBUG)
+define_if(LIBCXX_ENABLE_ASSERTIONS -D_LIBCPP_DEBUG=0)
 define_if(LIBCXX_DEBUG_BUILD -D_DEBUG)
 if (LIBCXX_ENABLE_ASSERTIONS AND NOT LIBCXX_DEBUG_BUILD)
   # MSVC doesn't like _DEBUG on release builds. See PR 4379.

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=292883&r1=292882&r2=292883&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Mon Jan 23 22:57:33 2017
@@ -824,7 +824,9 @@ template  struct __static_asse
 #   else
 #   error Supported values for _LIBCPP_DEBUG are 0 and 1
 #   endif
+# if !defined(_LIBCPP_BUILDING_LIBRARY)
 #   define _LIBCPP_EXTERN_TEMPLATE(...)
+# endif
 #endif
 
 #ifndef _LIBCPP_EXTERN_TEMPLATE

Modified: libcxx/trunk/include/__threading_support
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__threading_support?rev=292883&r1=292882&r2=292883&view=diff
==
--- libcxx/trunk/include/__threading_support (original)
+++ libcxx/trunk/include/__threading_support Mon Jan 23 22:57:33 2017
@@ -25,7 +25,6 @@
 # include 
 # include 
 #elif defined(_LIBCPP_HAS_THREAD_API_WIN32)
-#include 
 #include 
 #include 
 #include 

Modified: libcxx/trunk/src/condition_variable.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/condition_variable.cpp?rev=292883&r1=292882&r2=292883&view=diff
==
--- libcxx/trunk/src/condition_variable.cpp (original)
+++ libcxx/trunk/src/condition_variable.cpp Mon Jan 23 22:57:33 2017
@@ -14,7 +14,6 @@
 #include "condition_variable"
 #include "thread"
 #include "system_error"
-#include "cassert"
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 

Modified: libcxx/trunk/src/experimental/filesystem/path.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/experimental/filesystem/path.cpp?rev=292883&r1=292882&r2=292883&view=diff
==
--- libcxx/trunk/src/experimental/filesystem/path.cpp (original)
+++ libcxx/trunk/src/experimental/filesystem/path.cpp Mon Jan 23 22:57:33 2017
@@ -6,11 +6,9 @@
 // Source Licenses. See LICENSE.TXT for details.
 //
 
//===--===//
-#undef NDEBUG
 #include "experimental/filesystem"
 #include "string_view"
 #include "utility"
-#include "cassert"
 
 namespace { namespace parser
 {
@@ -113,7 +111,6 @@ public:
   void decrement() noexcept {
 const PosPtr REnd = &Path.front() - 1;
 const PosPtr RStart = getCurrentTokenStartPos() - 1;
-assert(RStart != REnd);
 
 switch (State) {
 case PS_AtEnd: {
@@ -322,7 +319,6 @@ string_view_t path::__root_path_raw() co
   auto NextCh = PP.peek();
   if (NextCh && *NextCh == '/') {
   

[PATCH] D29063: [libcxx] Never use within libc++

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added inline comments.



Comment at: include/__config:827
 #   endif
+# if !defined(_LIBCPP_BUILDING_LIBRARY)
 #   define _LIBCPP_EXTERN_TEMPLATE(...)

mclow.lists wrote:
> Does this belong here?
> 
Yeah, so `-DLIBCXX_ENABLE_ASSERTIONS=ON` now define `-D_LIBCPP_DEBUG=0` during 
the build. This suppresses `std::strings` extern template declarations and 
changes the export lists of `libc++.dylib`. This change ensures that enabling 
debug mode during the build doesn't do that.


https://reviews.llvm.org/D29063



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

Re: [PATCH] D28933: Revert the return type for `emplace_(back|front)` to `void` in C++14 and before

[Marshall Clow via cfe-commits]

On Mon, Jan 23, 2017 at 4:33 PM, Hans Wennborg via Phabricator <
revi...@reviews.llvm.org> wrote:

> hans added a comment.
>
> This sounds like something we'll want to merge to the release branch when
> it lands?
>
>
> https://reviews.llvm.org/D28933
>

Yes.  I'll land it tomorrow afternoon.

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

[PATCH] D29063: [libcxx] Never use within libc++

[Marshall Clow via Phabricator via cfe-commits]

mclow.lists accepted this revision.
mclow.lists added a comment.
This revision is now accepted and ready to land.

this LGTM.   assert is not something we should have in the dylib.




Comment at: include/__config:827
 #   endif
+# if !defined(_LIBCPP_BUILDING_LIBRARY)
 #   define _LIBCPP_EXTERN_TEMPLATE(...)

Does this belong here?



https://reviews.llvm.org/D29063



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

[PATCH] D29067: IRGen: When loading the main module in the distributed ThinLTO backend, look for the module containing the summary.

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added inline comments.



Comment at: clang/include/clang/CodeGen/BackendUtil.h:51
+  llvm::Expected
+  FindThinLTOModule(llvm::MemoryBufferRef MBRef);
 }

Indentation seems strange?



Comment at: clang/lib/CodeGen/CodeGenAction.cpp:841
 
+std::unique_ptr CodeGenAction::loadModule(MemoryBufferRef MBRef) 
{
+  CompilerInstance &CI = getCompilerInstance();

Can you extract this function in a separate patch? I feel the diff could be a 
lot more contained here.



https://reviews.llvm.org/D29067



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

[PATCH] D29065: Split isUsingLTO() outside of embedBitcodeInObject() and embedBitcodeMarkerOnly().

[Steven Wu via Phabricator via cfe-commits]

steven_wu added a comment.

I think you should add a new API for embedBitcodeMarkerEnabled() or revert the 
name the APIs to before https://reviews.llvm.org/rL287084.


https://reviews.llvm.org/D29065



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

[PATCH] D29067: IRGen: When loading the main module in the distributed ThinLTO backend, look for the module containing the summary.

[Peter Collingbourne via Phabricator via cfe-commits]

pcc created this revision.
Herald added a subscriber: mgorny.

https://reviews.llvm.org/D29067

Files:
  clang/include/clang/CodeGen/BackendUtil.h
  clang/include/clang/CodeGen/CodeGenAction.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/test/CMakeLists.txt
  clang/test/CodeGen/thinlto_backend.ll

Index: clang/test/CodeGen/thinlto_backend.ll
===
--- clang/test/CodeGen/thinlto_backend.ll
+++ clang/test/CodeGen/thinlto_backend.ll
@@ -2,6 +2,7 @@
 
 ; RUN: opt -module-summary -o %t1.o %s
 ; RUN: opt -module-summary -o %t2.o %S/Inputs/thinlto_backend.ll
+; RUN: opt -o %t2merge.o %S/Inputs/thinlto_backend.ll
 ; RUN: llvm-lto -thinlto -o %t %t1.o %t2.o
 
 ; Ensure clang -cc1 give expected error for incorrect input type
@@ -14,12 +15,17 @@
 
 ; Ensure we ignore empty index file under -ignore-empty-index-file, and run
 ; non-ThinLTO compilation which would not import f2
-; RUN: touch %t4.thinlto.bc
-; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t4.o -x ir %t1.o -c -fthinlto-index=%t4.thinlto.bc -mllvm -ignore-empty-index-file
+; RUN: touch %t.empty.thinlto.bc
+; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t4.o -x ir %t1.o -c -fthinlto-index=%t.empty.thinlto.bc -mllvm -ignore-empty-index-file
 ; RUN: llvm-nm %t4.o | FileCheck --check-prefix=CHECK-OBJ-IGNORE-EMPTY %s
 ; CHECK-OBJ-IGNORE-EMPTY: T f1
 ; CHECK-OBJ-IGNORE-EMPTY: U f2
 
+; Ensure we load the correct module from a multi-module bitcode file
+; RUN: llvm-cat -b -o %t5.o %t1.o %t2merge.o
+; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t6.o -x ir %t5.o -c -fthinlto-index=%t.empty.thinlto.bc -mllvm -ignore-empty-index-file
+; RUN: llvm-nm %t5.o | FileCheck --check-prefix=CHECK-OBJ-IGNORE-EMPTY %s
+
 ; Ensure f2 was imported
 ; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t3.o -x ir %t1.o -c -fthinlto-index=%t.thinlto.bc
 ; RUN: llvm-nm %t3.o | FileCheck --check-prefix=CHECK-OBJ %s
Index: clang/test/CMakeLists.txt
===
--- clang/test/CMakeLists.txt
+++ clang/test/CMakeLists.txt
@@ -79,6 +79,7 @@
 FileCheck count not
 llc
 llvm-bcanalyzer
+llvm-cat
 llvm-dis
 llvm-modextract
 llvm-nm
Index: clang/lib/CodeGen/CodeGenAction.cpp
===
--- clang/lib/CodeGen/CodeGenAction.cpp
+++ clang/lib/CodeGen/CodeGenAction.cpp
@@ -838,6 +838,62 @@
   Diags->Report(DiagID).AddString("cannot compile inline asm");
 }
 
+std::unique_ptr CodeGenAction::loadModule(MemoryBufferRef MBRef) {
+  CompilerInstance &CI = getCompilerInstance();
+  SourceManager &SM = CI.getSourceManager();
+
+  // For ThinLTO backend invocations, ensure that the context
+  // merges types based on ODR identifiers. We also need to read
+  // the correct module out of a multi-module bitcode file.
+  if (!CI.getCodeGenOpts().ThinLTOIndexFile.empty()) {
+VMContext->enableDebugTypeODRUniquing();
+
+auto DiagErrors = [&](Error E) -> std::unique_ptr {
+  unsigned DiagID =
+  CI.getDiagnostics().getCustomDiagID(DiagnosticsEngine::Error, "%0");
+  handleAllErrors(std::move(E), [&](ErrorInfoBase &EIB) {
+CI.getDiagnostics().Report(DiagID) << EIB.message();
+  });
+  return {};
+};
+
+Expected BMOrErr = FindThinLTOModule(MBRef);
+if (!BMOrErr)
+  return DiagErrors(BMOrErr.takeError());
+
+Expected> MOrErr =
+BMOrErr->parseModule(*VMContext);
+if (!MOrErr)
+  return DiagErrors(MOrErr.takeError());
+return std::move(*MOrErr);
+  }
+
+  llvm::SMDiagnostic Err;
+  if (std::unique_ptr M = parseIR(MBRef, Err, *VMContext))
+return M;
+
+  // Translate from the diagnostic info to the SourceManager location if
+  // available.
+  // TODO: Unify this with ConvertBackendLocation()
+  SourceLocation Loc;
+  if (Err.getLineNo() > 0) {
+assert(Err.getColumnNo() >= 0);
+Loc = SM.translateFileLineCol(SM.getFileEntryForID(SM.getMainFileID()),
+  Err.getLineNo(), Err.getColumnNo() + 1);
+  }
+
+  // Strip off a leading diagnostic code if there is one.
+  StringRef Msg = Err.getMessage();
+  if (Msg.startswith("error: "))
+Msg = Msg.substr(7);
+
+  unsigned DiagID =
+  CI.getDiagnostics().getCustomDiagID(DiagnosticsEngine::Error, "%0");
+
+  CI.getDiagnostics().Report(Loc, DiagID) << Msg;
+  return {};
+}
+
 void CodeGenAction::ExecuteAction() {
   // If this is an IR file, we have to treat it specially.
   if (getCurrentFileKind() == IK_LLVM_IR) {
@@ -855,35 +911,10 @@
 if (Invalid)
   return;
 
-// For ThinLTO backend invocations, ensure that the context
-// merges types based on ODR identifiers.
-if (!CI.getCodeGenOpts().ThinLTOIndexFile.empty())
-  VMContext->enableDebugTypeODRUniquing();
-
-llvm::SMDiagnostic Err;
-TheModule = parseIR(MainFile->getMemBufferRef(), Err, *VMContext);
-if (

[PATCH] D29066: Forward -bitcode_process_mode to ld64 in marker-only mode

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini created this revision.

https://reviews.llvm.org/D29066

Files:
  clang/lib/Driver/Tools.cpp


Index: clang/lib/Driver/Tools.cpp
===
--- clang/lib/Driver/Tools.cpp
+++ clang/lib/Driver/Tools.cpp
@@ -8435,9 +8435,13 @@
   // for embed-bitcode, use -bitcode_bundle in linker command
   if (C.getDriver().embedBitcodeEnabled()) {
 // Check if the toolchain supports bitcode build flow.
-if (MachOTC.SupportsEmbeddedBitcode())
+if (MachOTC.SupportsEmbeddedBitcode()) {
   CmdArgs.push_back("-bitcode_bundle");
-else
+  if (C.getDriver().embedBitcodeMarkerOnly() && Version[0] >= 278) {
+CmdArgs.push_back("-bitcode_process_mode");
+CmdArgs.push_back("marker");
+  }
+} else
   D.Diag(diag::err_drv_bitcode_unsupported_on_toolchain);
   }
 


Index: clang/lib/Driver/Tools.cpp
===
--- clang/lib/Driver/Tools.cpp
+++ clang/lib/Driver/Tools.cpp
@@ -8435,9 +8435,13 @@
   // for embed-bitcode, use -bitcode_bundle in linker command
   if (C.getDriver().embedBitcodeEnabled()) {
 // Check if the toolchain supports bitcode build flow.
-if (MachOTC.SupportsEmbeddedBitcode())
+if (MachOTC.SupportsEmbeddedBitcode()) {
   CmdArgs.push_back("-bitcode_bundle");
-else
+  if (C.getDriver().embedBitcodeMarkerOnly() && Version[0] >= 278) {
+CmdArgs.push_back("-bitcode_process_mode");
+CmdArgs.push_back("marker");
+  }
+} else
   D.Diag(diag::err_drv_bitcode_unsupported_on_toolchain);
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29065: Split isUsingLTO() outside of embedBitcodeInObject() and embedBitcodeMarkerOnly().

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini created this revision.

These accessors maps directly to the command line option.


https://reviews.llvm.org/D29065

Files:
  clang/include/clang/Driver/Driver.h
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/Tools.cpp


Index: clang/lib/Driver/Tools.cpp
===
--- clang/lib/Driver/Tools.cpp
+++ clang/lib/Driver/Tools.cpp
@@ -4258,14 +4258,14 @@
   }
 
   // Embed-bitcode option.
-  if (C.getDriver().embedBitcodeInObject() &&
+  if (C.getDriver().embedBitcodeInObject() && !C.getDriver().isUsingLTO() &&
   (isa(JA) || isa(JA))) {
 // Add flags implied by -fembed-bitcode.
 Args.AddLastArg(CmdArgs, options::OPT_fembed_bitcode_EQ);
 // Disable all llvm IR level optimizations.
 CmdArgs.push_back("-disable-llvm-passes");
   }
-  if (C.getDriver().embedBitcodeMarkerOnly())
+  if (C.getDriver().embedBitcodeMarkerOnly() && !C.getDriver().isUsingLTO())
 CmdArgs.push_back("-fembed-bitcode=marker");
 
   // We normally speed up the clang process a bit by skipping destructors at
@@ -6461,7 +6461,8 @@
   // pristine IR generated by the frontend. Ideally, a new compile action 
should
   // be added so both IR can be captured.
   if (C.getDriver().isSaveTempsEnabled() &&
-  !C.getDriver().embedBitcodeInObject() && isa(JA))
+  !C.getDriver().embedBitcodeInObject() && !C.getDriver().isUsingLTO() &&
+  isa(JA))
 CmdArgs.push_back("-disable-llvm-passes");
 
   if (Output.getType() == types::TY_Dependencies) {
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -3180,7 +3180,8 @@
   const JobAction *JA = cast(A);
   ActionList CollapsedOffloadActions;
 
-  ToolSelector TS(JA, *TC, C, isSaveTempsEnabled(), embedBitcodeInObject());
+  ToolSelector TS(JA, *TC, C, isSaveTempsEnabled(),
+  embedBitcodeInObject() && !isUsingLTO());
   const Tool *T = TS.getTool(Inputs, CollapsedOffloadActions);
 
   if (!T)
Index: clang/include/clang/Driver/Driver.h
===
--- clang/include/clang/Driver/Driver.h
+++ clang/include/clang/Driver/Driver.h
@@ -304,13 +304,8 @@
   bool isSaveTempsObj() const { return SaveTemps == SaveTempsObj; }
 
   bool embedBitcodeEnabled() const { return BitcodeEmbed != EmbedNone; }
-  bool embedBitcodeInObject() const {
-// LTO has no object file output so ignore embed bitcode option in LTO.
-return (BitcodeEmbed == EmbedBitcode) && !isUsingLTO();
-  }
-  bool embedBitcodeMarkerOnly() const {
-return (BitcodeEmbed == EmbedMarker) && !isUsingLTO();
-  }
+  bool embedBitcodeInObject() const { return (BitcodeEmbed == EmbedBitcode); }
+  bool embedBitcodeMarkerOnly() const { return (BitcodeEmbed == EmbedMarker); }
 
   /// Compute the desired OpenMP runtime from the flags provided.
   OpenMPRuntimeKind getOpenMPRuntime(const llvm::opt::ArgList &Args) const;


Index: clang/lib/Driver/Tools.cpp
===
--- clang/lib/Driver/Tools.cpp
+++ clang/lib/Driver/Tools.cpp
@@ -4258,14 +4258,14 @@
   }
 
   // Embed-bitcode option.
-  if (C.getDriver().embedBitcodeInObject() &&
+  if (C.getDriver().embedBitcodeInObject() && !C.getDriver().isUsingLTO() &&
   (isa(JA) || isa(JA))) {
 // Add flags implied by -fembed-bitcode.
 Args.AddLastArg(CmdArgs, options::OPT_fembed_bitcode_EQ);
 // Disable all llvm IR level optimizations.
 CmdArgs.push_back("-disable-llvm-passes");
   }
-  if (C.getDriver().embedBitcodeMarkerOnly())
+  if (C.getDriver().embedBitcodeMarkerOnly() && !C.getDriver().isUsingLTO())
 CmdArgs.push_back("-fembed-bitcode=marker");
 
   // We normally speed up the clang process a bit by skipping destructors at
@@ -6461,7 +6461,8 @@
   // pristine IR generated by the frontend. Ideally, a new compile action should
   // be added so both IR can be captured.
   if (C.getDriver().isSaveTempsEnabled() &&
-  !C.getDriver().embedBitcodeInObject() && isa(JA))
+  !C.getDriver().embedBitcodeInObject() && !C.getDriver().isUsingLTO() &&
+  isa(JA))
 CmdArgs.push_back("-disable-llvm-passes");
 
   if (Output.getType() == types::TY_Dependencies) {
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -3180,7 +3180,8 @@
   const JobAction *JA = cast(A);
   ActionList CollapsedOffloadActions;
 
-  ToolSelector TS(JA, *TC, C, isSaveTempsEnabled(), embedBitcodeInObject());
+  ToolSelector TS(JA, *TC, C, isSaveTempsEnabled(),
+  embedBitcodeInObject() && !isUsingLTO());
   const Tool *T = TS.getTool(Inputs, CollapsedOffloadActions);
 
   if (!T)
Index: clang/include/clang/Driver/Driver.h
===
--- clang/include/clang/Driver/Driver.h
+++ clan

Re: r292800 - [analyzer] Fix memory space of static locals seen from nested blocks.

[Devin Coughlin via cfe-commits]

FYI, I reverted r292800 from trunk in r292874. It was causing our internal 
validation bots to have false positives whenever a static local was 
dereferenced/passed to a nonnull function in a block evaluated at the top level.

Devin


> On Jan 23, 2017, at 4:19 PM, Hans Wennborg  wrote:
> 
> Merged in r292858.
> 
> Thanks,
> Hans
> 
> On Mon, Jan 23, 2017 at 4:15 PM, Anna Zaks  wrote:
>> Yes, ok to merge!
>> Thank you.
>> 
>> Sent from my iPhone
>> 
>>> On Jan 23, 2017, at 1:50 PM, Hans Wennborg  wrote:
>>> 
>>> Sounds good to me.
>>> 
>>> Anna, you're the code owner here. Ok to merge this?
>>> 
>>> Thanks,
>>> Hans
>>> 
 On Mon, Jan 23, 2017 at 10:37 AM, Artem Dergachev  
 wrote:
 Hans,
 
 Could we merge this one into the 4.0.0 release branch? It's a recent bugfix
 for the analyzer.
 
 Thanks,
 Artem.
 
 
 
> On 1/23/17 7:57 PM, Artem Dergachev via cfe-commits wrote:
> 
> Author: dergachev
> Date: Mon Jan 23 10:57:11 2017
> New Revision: 292800
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=292800&view=rev
> Log:
> [analyzer] Fix memory space of static locals seen from nested blocks.
> 
> When a block within a function accesses a function's static local
> variable,
> this local is captured by reference rather than copied to the heap.
> 
> Therefore this variable's memory space is known: StaticGlobalSpaceRegion.
> Used to be UnknownSpaceRegion, same as for stack locals.
> 
> Fixes a false positive in MacOSXAPIChecker.
> 
> rdar://problem/30105546
> Differential revision: https://reviews.llvm.org/D28946
> 
> Modified:
>cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
>cfe/trunk/test/Analysis/dispatch-once.m
> 
> Modified: cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp?rev=292800&r1=292799&r2=292800&view=diff
> 
> ==
> --- cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp (original)
> +++ cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp Mon Jan 23 10:57:11
> 2017
> @@ -776,6 +776,22 @@ getStackOrCaptureRegionForDeclContext(co
>   return (const StackFrameContext *)nullptr;
> }
> +static CanQualType getBlockPointerType(const BlockDecl *BD, ASTContext
> &C) {
> +  // FIXME: The fallback type here is totally bogus -- though it should
> +  // never be queried, it will prevent uniquing with the real
> +  // BlockCodeRegion. Ideally we'd fix the AST so that we always had a
> +  // signature.
> +  QualType T;
> +  if (const TypeSourceInfo *TSI = BD->getSignatureAsWritten())
> +T = TSI->getType();
> +  if (T.isNull())
> +T = C.VoidTy;
> +  if (!T->getAs())
> +T = C.getFunctionNoProtoType(T);
> +  T = C.getBlockPointerType(T);
> +  return C.getCanonicalType(T);
> +}
> +
> const VarRegion* MemRegionManager::getVarRegion(const VarDecl *D,
> const LocationContext
> *LC) {
>   const MemRegion *sReg = nullptr;
> @@ -803,7 +819,7 @@ const VarRegion* MemRegionManager::getVa
> sReg = getGlobalsRegion();
> }
> -  // Finally handle static locals.
> +  // Finally handle locals.
>   } else {
> // FIXME: Once we implement scope handling, we will need to properly
> lookup
> // 'D' to the proper LocationContext.
> @@ -816,9 +832,22 @@ const VarRegion* MemRegionManager::getVa
>   const StackFrameContext *STC = V.get();
> -if (!STC)
> -  sReg = getUnknownRegion();
> -else {
> +if (!STC) {
> +  if (D->isStaticLocal()) {
> +const CodeTextRegion *fReg = nullptr;
> +if (const auto *ND = dyn_cast(DC))
> +  fReg = getFunctionCodeRegion(ND);
> +else if (const auto *BD = dyn_cast(DC))
> +  fReg = getBlockCodeRegion(BD, getBlockPointerType(BD,
> getContext()),
> +LC->getAnalysisDeclContext());
> +assert(fReg && "Unable to determine code region for a static
> local!");
> +sReg = getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,
> fReg);
> +  } else {
> +// We're looking at a block-captured local variable, which may be
> either
> +// still local, or already moved to the heap. So we're not sure.
> +sReg = getUnknownRegion();
> +  }
> +} else {
>   if (D->hasLocalStorage()) {
> sReg = isa(D) || isa(D)
>? static_cast MemRegion*>(getStackArgumentsRegion(STC))
> @@ -831,22 +860,9 @@ const VarRegion* MemRegionManager::getVa
>   sReg =
> getGlobalsRegion(MemRegion::StaticGl

r292874 - Revert "[analyzer] Fix memory space of static locals seen from nested blocks."

[Devin Coughlin via cfe-commits]

Author: dcoughlin
Date: Mon Jan 23 20:10:59 2017
New Revision: 292874

URL: http://llvm.org/viewvc/llvm-project?rev=292874&view=rev
Log:
Revert "[analyzer] Fix memory space of static locals seen from nested blocks."

This reverts commit r292800.

It is causing null pointer dereference false positives when a block that
captures a static local is evaluated at the top level.

Modified:
cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
cfe/trunk/test/Analysis/dispatch-once.m

Modified: cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp?rev=292874&r1=292873&r2=292874&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp Mon Jan 23 20:10:59 2017
@@ -776,22 +776,6 @@ getStackOrCaptureRegionForDeclContext(co
   return (const StackFrameContext *)nullptr;
 }
 
-static CanQualType getBlockPointerType(const BlockDecl *BD, ASTContext &C) {
-  // FIXME: The fallback type here is totally bogus -- though it should
-  // never be queried, it will prevent uniquing with the real
-  // BlockCodeRegion. Ideally we'd fix the AST so that we always had a
-  // signature.
-  QualType T;
-  if (const TypeSourceInfo *TSI = BD->getSignatureAsWritten())
-T = TSI->getType();
-  if (T.isNull())
-T = C.VoidTy;
-  if (!T->getAs())
-T = C.getFunctionNoProtoType(T);
-  T = C.getBlockPointerType(T);
-  return C.getCanonicalType(T);
-}
-
 const VarRegion* MemRegionManager::getVarRegion(const VarDecl *D,
 const LocationContext *LC) {
   const MemRegion *sReg = nullptr;
@@ -819,7 +803,7 @@ const VarRegion* MemRegionManager::getVa
 sReg = getGlobalsRegion();
 }
 
-  // Finally handle locals.
+  // Finally handle static locals.
   } else {
 // FIXME: Once we implement scope handling, we will need to properly lookup
 // 'D' to the proper LocationContext.
@@ -832,22 +816,9 @@ const VarRegion* MemRegionManager::getVa
 
 const StackFrameContext *STC = V.get();
 
-if (!STC) {
-  if (D->isStaticLocal()) {
-const CodeTextRegion *fReg = nullptr;
-if (const auto *ND = dyn_cast(DC))
-  fReg = getFunctionCodeRegion(ND);
-else if (const auto *BD = dyn_cast(DC))
-  fReg = getBlockCodeRegion(BD, getBlockPointerType(BD, getContext()),
-LC->getAnalysisDeclContext());
-assert(fReg && "Unable to determine code region for a static local!");
-sReg = getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind, fReg);
-  } else {
-// We're looking at a block-captured local variable, which may be 
either
-// still local, or already moved to the heap. So we're not sure.
-sReg = getUnknownRegion();
-  }
-} else {
+if (!STC)
+  sReg = getUnknownRegion();
+else {
   if (D->hasLocalStorage()) {
 sReg = isa(D) || isa(D)
? static_cast(getStackArgumentsRegion(STC))
@@ -860,9 +831,22 @@ const VarRegion* MemRegionManager::getVa
   sReg = getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,
   
getFunctionCodeRegion(cast(STCD)));
 else if (const BlockDecl *BD = dyn_cast(STCD)) {
+  // FIXME: The fallback type here is totally bogus -- though it should
+  // never be queried, it will prevent uniquing with the real
+  // BlockCodeRegion. Ideally we'd fix the AST so that we always had a
+  // signature.
+  QualType T;
+  if (const TypeSourceInfo *TSI = BD->getSignatureAsWritten())
+T = TSI->getType();
+  if (T.isNull())
+T = getContext().VoidTy;
+  if (!T->getAs())
+T = getContext().getFunctionNoProtoType(T);
+  T = getContext().getBlockPointerType(T);
+
   const BlockCodeRegion *BTR =
-  getBlockCodeRegion(BD, getBlockPointerType(BD, getContext()),
- STC->getAnalysisDeclContext());
+getBlockCodeRegion(BD, C.getCanonicalType(T),
+   STC->getAnalysisDeclContext());
   sReg = getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,
   BTR);
 }

Modified: cfe/trunk/test/Analysis/dispatch-once.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/dispatch-once.m?rev=292874&r1=292873&r2=292874&view=diff
==
--- cfe/trunk/test/Analysis/dispatch-once.m (original)
+++ cfe/trunk/test/Analysis/dispatch-once.m Mon Jan 23 20:10:59 2017
@@ -107,10 +107,3 @@ void test_block_var_from_outside_block()
   };
   dispatch_once(&once, ^{}); // expected-warning{{Call to 'dispatch_once' uses 
the block variable 'once' for the predicate

[PATCH] D29063: [libcxx] Never use within libc++

[Eric Fiselier via Phabricator via cfe-commits]

EricWF created this revision.
Herald added a subscriber: mgorny.

It is my opinion that libc++ should never use ``, including in the 
`dylib`. This patch remove all uses of `assert` from within libc++ and replaces 
most of them with `_LIBCPP_ASSERT` instead.

Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS`  off by default, 
because the standard library should not be aborting user programs unless 
explicitly asked to.


https://reviews.llvm.org/D29063

Files:
  CMakeLists.txt
  include/__config
  include/__threading_support
  src/condition_variable.cpp
  src/experimental/filesystem/path.cpp
  src/mutex.cpp
  src/system_error.cpp

Index: src/system_error.cpp
===
--- src/system_error.cpp
+++ src/system_error.cpp
@@ -17,9 +17,9 @@
 #include "cstring"
 #include "cstdio"
 #include "cstdlib"
-#include "cassert"
 #include "string"
 #include "string.h"
+#include "__debug"
 
 #if defined(__ANDROID__)
 #include 
@@ -96,7 +96,7 @@
 std::snprintf(buffer, strerror_buff_size, "Unknown error %d", ev);
 return string(buffer);
 } else {
-assert(new_errno == ERANGE);
+_LIBCPP_ASSERT(new_errno == ERANGE, "unexpected error from ::strerr_r");
 // FIXME maybe? 'strerror_buff_size' is likely to exceed the
 // maximum error size so ERANGE shouldn't be returned.
 std::abort();
Index: src/mutex.cpp
===
--- src/mutex.cpp
+++ src/mutex.cpp
@@ -11,7 +11,6 @@
 #include "mutex"
 #include "limits"
 #include "system_error"
-#include "cassert"
 #include "include/atomic_support.h"
 
 _LIBCPP_BEGIN_NAMESPACE_STD
@@ -45,7 +44,7 @@
 {
 int ec = __libcpp_mutex_unlock(&__m_);
 (void)ec;
-assert(ec == 0);
+_LIBCPP_ASSERT(ec == 0, "call to mutex::unlock failed");
 }
 
 // recursive_mutex
@@ -61,7 +60,7 @@
 {
 int e = __libcpp_recursive_mutex_destroy(&__m_);
 (void)e;
-assert(e == 0);
+_LIBCPP_ASSERT(e == 0, "call to ~recursive_mutex() failed");
 }
 
 void
@@ -77,7 +76,7 @@
 {
 int e = __libcpp_recursive_mutex_unlock(&__m_);
 (void)e;
-assert(e == 0);
+_LIBCPP_ASSERT(e == 0, "call to recursive_mutex::unlock() failed");
 }
 
 bool
Index: src/experimental/filesystem/path.cpp
===
--- src/experimental/filesystem/path.cpp
+++ src/experimental/filesystem/path.cpp
@@ -6,11 +6,9 @@
 // Source Licenses. See LICENSE.TXT for details.
 //
 //===--===//
-#undef NDEBUG
 #include "experimental/filesystem"
 #include "string_view"
 #include "utility"
-#include "cassert"
 
 namespace { namespace parser
 {
@@ -113,7 +111,6 @@
   void decrement() noexcept {
 const PosPtr REnd = &Path.front() - 1;
 const PosPtr RStart = getCurrentTokenStartPos() - 1;
-assert(RStart != REnd);
 
 switch (State) {
 case PS_AtEnd: {
@@ -322,7 +319,6 @@
   auto NextCh = PP.peek();
   if (NextCh && *NextCh == '/') {
 ++PP;
-assert(PP.State == PathParser::PS_InRootDir);
 return createView(__pn_.data(), &PP.RawEntry.back());
   }
   return PP.RawEntry;
Index: src/condition_variable.cpp
===
--- src/condition_variable.cpp
+++ src/condition_variable.cpp
@@ -14,7 +14,6 @@
 #include "condition_variable"
 #include "thread"
 #include "system_error"
-#include "cassert"
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
Index: include/__threading_support
===
--- include/__threading_support
+++ include/__threading_support
@@ -25,7 +25,6 @@
 # include 
 # include 
 #elif defined(_LIBCPP_HAS_THREAD_API_WIN32)
-#include 
 #include 
 #include 
 #include 
Index: include/__config
===
--- include/__config
+++ include/__config
@@ -824,7 +824,9 @@
 #   else
 #   error Supported values for _LIBCPP_DEBUG are 0 and 1
 #   endif
+# if !defined(_LIBCPP_BUILDING_LIBRARY)
 #   define _LIBCPP_EXTERN_TEMPLATE(...)
+# endif
 #endif
 
 #ifndef _LIBCPP_EXTERN_TEMPLATE
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -60,7 +60,7 @@
 include(CMakeDependentOption)
 
 # Basic options ---
-option(LIBCXX_ENABLE_ASSERTIONS "Enable assertions independent of build mode." ON)
+option(LIBCXX_ENABLE_ASSERTIONS "Enable assertions independent of build mode." OFF)
 option(LIBCXX_ENABLE_SHARED "Build libc++ as a shared library." ON)
 option(LIBCXX_ENABLE_STATIC "Build libc++ as a static library." ON)
 option(LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY "Build libc++experimental.a" ON)
@@ -501,6 +501,7 @@
 # Assertion flags ===

Re: [libcxx] r292822 - Fixed a typo in __config that prevented the aligned new/delete tests from passing on Mac OS.

[Eric Fiselier via cfe-commits]

r292869.

On Mon, Jan 23, 2017 at 3:00 PM, Hans Wennborg  wrote:

> Ok, go ahead.
>
> On Mon, Jan 23, 2017 at 1:54 PM, Eric Fiselier  wrote:
> > This patch needs to get merged into 4.0 since the offending commit with
> the
> > misspelling is in the 4.0 branch.
> >
> > /Eric
> >
> >
> > On Mon, Jan 23, 2017 at 12:51 PM, Marshall Clow via cfe-commits
> >  wrote:
> >>
> >> Author: marshall
> >> Date: Mon Jan 23 13:51:54 2017
> >> New Revision: 292822
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=292822&view=rev
> >> Log:
> >> Fixed a typo in __config that prevented the aligned new/delete tests
> from
> >> passing on Mac OS.
> >>
> >> Modified:
> >> libcxx/trunk/include/__config
> >>
> >> Modified: libcxx/trunk/include/__config
> >> URL:
> >> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/_
> _config?rev=292822&r1=292821&r2=292822&view=diff
> >>
> >> 
> ==
> >> --- libcxx/trunk/include/__config (original)
> >> +++ libcxx/trunk/include/__config Mon Jan 23 13:51:54 2017
> >> @@ -851,7 +851,7 @@ template  struct __static_asse
> >>  #if defined(__APPLE__)
> >>  # if !defined(__MAC_OS_X_VERSION_MIN_REQUIRED) && \
> >>   defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__)
> >> -#   define __MAC_OS_X_VERSION_MIN_REQUIRED
> >> __ENVIROMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
> >> +#   define __MAC_OS_X_VERSION_MIN_REQUIRED
> >> __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
> >>  # endif
> >>  # if defined(__MAC_OS_X_VERSION_MIN_REQUIRED)
> >>  #   if __MAC_OS_X_VERSION_MIN_REQUIRED < 1060
> >>
> >>
> >> ___
> >> cfe-commits mailing list
> >> cfe-commits@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >
> >
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r292869 - Merge r292822 - Fixed a typo in __config that prevented the aligned new/delete tests from passing on Mac OS.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Mon Jan 23 19:05:56 2017
New Revision: 292869

URL: http://llvm.org/viewvc/llvm-project?rev=292869&view=rev
Log:
Merge r292822 - Fixed a typo in __config that prevented the aligned new/delete 
tests from passing on Mac OS.

Modified:
libcxx/branches/release_40/include/__config

Modified: libcxx/branches/release_40/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/branches/release_40/include/__config?rev=292869&r1=292868&r2=292869&view=diff
==
--- libcxx/branches/release_40/include/__config (original)
+++ libcxx/branches/release_40/include/__config Mon Jan 23 19:05:56 2017
@@ -845,7 +845,7 @@ template  struct __static_asse
 #if defined(__APPLE__)
 # if !defined(__MAC_OS_X_VERSION_MIN_REQUIRED) && \
  defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__)
-#   define __MAC_OS_X_VERSION_MIN_REQUIRED 
__ENVIROMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
+#   define __MAC_OS_X_VERSION_MIN_REQUIRED 
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
 # endif
 # if defined(__MAC_OS_X_VERSION_MIN_REQUIRED)
 #   if __MAC_OS_X_VERSION_MIN_REQUIRED < 1060


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

r292868 - Switch TableGen to emit calls to ASTRecordReader for AttrPCHRead.

[David L. Jones via cfe-commits]

Author: dlj
Date: Mon Jan 23 19:04:30 2017
New Revision: 292868

URL: http://llvm.org/viewvc/llvm-project?rev=292868&view=rev
Log:
Switch TableGen to emit calls to ASTRecordReader for AttrPCHRead.

Summary:
This patch changes TableGen-generated code in AttrPCHRead to call functions on
ASTRecordReader, instead of passing separate parameters to ASTReader. This is a
follow-up to r290217.

Reviewers: rsmith

Subscribers: cfe-commits

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

Modified:
cfe/trunk/include/clang/Serialization/ASTReader.h
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp

Modified: cfe/trunk/include/clang/Serialization/ASTReader.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Serialization/ASTReader.h?rev=292868&r1=292867&r2=292868&view=diff
==
--- cfe/trunk/include/clang/Serialization/ASTReader.h (original)
+++ cfe/trunk/include/clang/Serialization/ASTReader.h Mon Jan 23 19:04:30 2017
@@ -2098,8 +2098,7 @@ public:
  unsigned &Idx);
 
   /// \brief Reads attributes from the current stream position.
-  void ReadAttributes(ModuleFile &F, AttrVec &Attrs,
-  const RecordData &Record, unsigned &Idx);
+  void ReadAttributes(ASTRecordReader &Record, AttrVec &Attrs);
 
   /// \brief Reads a statement.
   Stmt *ReadStmt(ModuleFile &F);
@@ -2284,6 +2283,14 @@ public:
   /// \brief Reads a sub-expression operand during statement reading.
   Expr *readSubExpr() { return Reader->ReadSubExpr(); }
 
+  /// \brief Reads a declaration with the given local ID in the given module.
+  ///
+  /// \returns The requested declaration, casted to the given return type.
+  template
+  T *GetLocalDeclAs(uint32_t LocalID) {
+return cast_or_null(Reader->GetLocalDecl(*F, LocalID));
+  }
+
   /// \brief Reads a TemplateArgumentLocInfo appropriate for the
   /// given TemplateArgument kind, advancing Idx.
   TemplateArgumentLocInfo
@@ -2455,7 +2462,7 @@ public:
 
   /// \brief Reads attributes from the current stream position, advancing Idx.
   void readAttributes(AttrVec &Attrs) {
-return Reader->ReadAttributes(*F, Attrs, Record, Idx);
+return Reader->ReadAttributes(*this, Attrs);
   }
 
   /// \brief Reads a token out of a record, advancing Idx.

Modified: cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReaderDecl.cpp?rev=292868&r1=292867&r2=292868&view=diff
==
--- cfe/trunk/lib/Serialization/ASTReaderDecl.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReaderDecl.cpp Mon Jan 23 19:04:30 2017
@@ -1831,7 +1831,7 @@ void ASTDeclReader::VisitImportDecl(Impo
   SourceLocation *StoredLocs = D->getTrailingObjects();
   for (unsigned I = 0, N = Record.back(); I != N; ++I)
 StoredLocs[I] = ReadSourceLocation();
-  (void)Record.readInt(); // The number of stored source locations.
+  Record.skipInts(1); // The number of stored source locations.
 }
 
 void ASTDeclReader::VisitAccessSpecDecl(AccessSpecDecl *D) {
@@ -2471,12 +2471,11 @@ void ASTDeclReader::VisitOMPCapturedExpr
 
//===--===//
 
 /// \brief Reads attributes from the current stream position.
-void ASTReader::ReadAttributes(ModuleFile &F, AttrVec &Attrs,
-   const RecordData &Record, unsigned &Idx) {
-  for (unsigned i = 0, e = Record[Idx++]; i != e; ++i) {
+void ASTReader::ReadAttributes(ASTRecordReader &Record, AttrVec &Attrs) {
+  for (unsigned i = 0, e = Record.readInt(); i != e; ++i) {
 Attr *New = nullptr;
-attr::Kind Kind = (attr::Kind)Record[Idx++];
-SourceRange Range = ReadSourceRange(F, Record, Idx);
+attr::Kind Kind = (attr::Kind)Record.readInt();
+SourceRange Range = Record.readSourceRange();
 
 #include "clang/Serialization/AttrPCHRead.inc"
 

Modified: cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp?rev=292868&r1=292867&r2=292868&view=diff
==
--- cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp (original)
+++ cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp Mon Jan 23 19:04:30 2017
@@ -90,13 +90,13 @@ GetFlattenedSpellings(const Record &Attr
 
 static std::string ReadPCHRecord(StringRef type) {
   return StringSwitch(type)
-.EndsWith("Decl *", "GetLocalDeclAs<" 
-  + std::string(type, 0, type.size()-1) + ">(F, Record[Idx++])")
-.Case("TypeSourceInfo *", "GetTypeSourceInfo(F, Record, Idx)")
-.Case("Expr *", "ReadExpr(F)")
-.Case("IdentifierInfo *", "GetIdentifierInfo(F, Record, Idx)")
-.Case("StringRef", "ReadString(Record, Idx)")
-.Default("Record[Idx++]");
+.EndsWith("Decl *", "Record

[PATCH] D28007: Switch TableGen to emit calls to ASTRecordReader for AttrPCHRead.

[David L. Jones via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL292868: Switch TableGen to emit calls to ASTRecordReader for 
AttrPCHRead. (authored by dlj).

Changed prior to commit:
  https://reviews.llvm.org/D28007?vs=85493&id=85498#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28007

Files:
  cfe/trunk/include/clang/Serialization/ASTReader.h
  cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
  cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp

Index: cfe/trunk/include/clang/Serialization/ASTReader.h
===
--- cfe/trunk/include/clang/Serialization/ASTReader.h
+++ cfe/trunk/include/clang/Serialization/ASTReader.h
@@ -2098,8 +2098,7 @@
  unsigned &Idx);
 
   /// \brief Reads attributes from the current stream position.
-  void ReadAttributes(ModuleFile &F, AttrVec &Attrs,
-  const RecordData &Record, unsigned &Idx);
+  void ReadAttributes(ASTRecordReader &Record, AttrVec &Attrs);
 
   /// \brief Reads a statement.
   Stmt *ReadStmt(ModuleFile &F);
@@ -2284,6 +2283,14 @@
   /// \brief Reads a sub-expression operand during statement reading.
   Expr *readSubExpr() { return Reader->ReadSubExpr(); }
 
+  /// \brief Reads a declaration with the given local ID in the given module.
+  ///
+  /// \returns The requested declaration, casted to the given return type.
+  template
+  T *GetLocalDeclAs(uint32_t LocalID) {
+return cast_or_null(Reader->GetLocalDecl(*F, LocalID));
+  }
+
   /// \brief Reads a TemplateArgumentLocInfo appropriate for the
   /// given TemplateArgument kind, advancing Idx.
   TemplateArgumentLocInfo
@@ -2455,7 +2462,7 @@
 
   /// \brief Reads attributes from the current stream position, advancing Idx.
   void readAttributes(AttrVec &Attrs) {
-return Reader->ReadAttributes(*F, Attrs, Record, Idx);
+return Reader->ReadAttributes(*this, Attrs);
   }
 
   /// \brief Reads a token out of a record, advancing Idx.
Index: cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
===
--- cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
+++ cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
@@ -1831,7 +1831,7 @@
   SourceLocation *StoredLocs = D->getTrailingObjects();
   for (unsigned I = 0, N = Record.back(); I != N; ++I)
 StoredLocs[I] = ReadSourceLocation();
-  (void)Record.readInt(); // The number of stored source locations.
+  Record.skipInts(1); // The number of stored source locations.
 }
 
 void ASTDeclReader::VisitAccessSpecDecl(AccessSpecDecl *D) {
@@ -2471,12 +2471,11 @@
 //===--===//
 
 /// \brief Reads attributes from the current stream position.
-void ASTReader::ReadAttributes(ModuleFile &F, AttrVec &Attrs,
-   const RecordData &Record, unsigned &Idx) {
-  for (unsigned i = 0, e = Record[Idx++]; i != e; ++i) {
+void ASTReader::ReadAttributes(ASTRecordReader &Record, AttrVec &Attrs) {
+  for (unsigned i = 0, e = Record.readInt(); i != e; ++i) {
 Attr *New = nullptr;
-attr::Kind Kind = (attr::Kind)Record[Idx++];
-SourceRange Range = ReadSourceRange(F, Record, Idx);
+attr::Kind Kind = (attr::Kind)Record.readInt();
+SourceRange Range = Record.readSourceRange();
 
 #include "clang/Serialization/AttrPCHRead.inc"
 
Index: cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
===
--- cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
+++ cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
@@ -90,13 +90,13 @@
 
 static std::string ReadPCHRecord(StringRef type) {
   return StringSwitch(type)
-.EndsWith("Decl *", "GetLocalDeclAs<" 
-  + std::string(type, 0, type.size()-1) + ">(F, Record[Idx++])")
-.Case("TypeSourceInfo *", "GetTypeSourceInfo(F, Record, Idx)")
-.Case("Expr *", "ReadExpr(F)")
-.Case("IdentifierInfo *", "GetIdentifierInfo(F, Record, Idx)")
-.Case("StringRef", "ReadString(Record, Idx)")
-.Default("Record[Idx++]");
+.EndsWith("Decl *", "Record.GetLocalDeclAs<" 
+  + std::string(type, 0, type.size()-1) + ">(Record.readInt())")
+.Case("TypeSourceInfo *", "Record.getTypeSourceInfo()")
+.Case("Expr *", "Record.readExpr()")
+.Case("IdentifierInfo *", "Record.getIdentifierInfo()")
+.Case("StringRef", "Record.readString()")
+.Default("Record.readInt()");
 }
 
 // Get a type that is suitable for storing an object of the specified type.
@@ -413,7 +413,7 @@
 
 void writePCHReadDecls(raw_ostream &OS) const override {
   OS << "std::string " << getLowerName()
- << "= ReadString(Record, Idx);\n";
+ << "= Record.readString();\n";
 }
 
 void writePCHReadArgs(raw_ostream &OS) const override {
@@ -539,13 +539,13 @@
 }
 
 void writePCHReadDecls(raw_ostream &OS) const override {
-  OS << "bool is" << getLowerName() << "Expr = 

Re: [libcxx] r292830 - Fix GCC C++03 build by hiding default template argument in C++03

[Eric Fiselier via cfe-commits]

r292867.

On Mon, Jan 23, 2017 at 2:52 PM, Hans Wennborg  wrote:

> We merged the first one, so I suppose we better fix it :-)
>
> Sounds good to me.
>
> On Mon, Jan 23, 2017 at 1:37 PM, Eric Fiselier  wrote:
> > This patch should be merge into the 4.0 branch.
> >
> > It fixes a bug introduced to the 4.0 branch in r292354
> > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216054).
> >
> > /Eric
> >
> > On Mon, Jan 23, 2017 at 2:24 PM, Eric Fiselier via cfe-commits
> >  wrote:
> >>
> >> Author: ericwf
> >> Date: Mon Jan 23 15:24:58 2017
> >> New Revision: 292830
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=292830&view=rev
> >> Log:
> >> Fix GCC C++03 build by hiding default template argument in C++03
> >>
> >> Modified:
> >> libcxx/trunk/include/string
> >>
> >> Modified: libcxx/trunk/include/string
> >> URL:
> >> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/
> string?rev=292830&r1=292829&r2=292830&view=diff
> >>
> >> 
> ==
> >> --- libcxx/trunk/include/string (original)
> >> +++ libcxx/trunk/include/string Mon Jan 23 15:24:58 2017
> >> @@ -818,7 +818,10 @@ public:
> >>  operator __self_view() const _NOEXCEPT { return __self_view(data(),
> >> size()); }
> >>
> >>  basic_string& operator=(const basic_string& __str);
> >> +
> >> +#ifndef _LIBCPP_CXX03_LANG
> >>  template 
> >> +#endif
> >>  _LIBCPP_INLINE_VISIBILITY
> >>  basic_string& operator=(__self_view __sv)  {return assign(__sv);}
> >>  #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
> >>
> >>
> >> ___
> >> cfe-commits mailing list
> >> cfe-commits@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >
> >
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r292867 - Merge r292830 - Fix GCC C++03 build by hiding default template argument in C++03

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Mon Jan 23 19:03:36 2017
New Revision: 292867

URL: http://llvm.org/viewvc/llvm-project?rev=292867&view=rev
Log:
Merge r292830 - Fix GCC C++03 build by hiding default template argument in C++03

Modified:
libcxx/branches/release_40/include/string

Modified: libcxx/branches/release_40/include/string
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/branches/release_40/include/string?rev=292867&r1=292866&r2=292867&view=diff
==
--- libcxx/branches/release_40/include/string (original)
+++ libcxx/branches/release_40/include/string Mon Jan 23 19:03:36 2017
@@ -818,7 +818,10 @@ public:
 operator __self_view() const _NOEXCEPT { return __self_view(data(), 
size()); }
 
 basic_string& operator=(const basic_string& __str);
+
+#ifndef _LIBCPP_CXX03_LANG
 template 
+#endif
 _LIBCPP_INLINE_VISIBILITY
 basic_string& operator=(__self_view __sv)  {return assign(__sv);}
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES


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

Re: [libcxx] r292833 - Manually force the use of __decltype in C++03 with Clang 3.4.

[Eric Fiselier via cfe-commits]

r292866.

On Mon, Jan 23, 2017 at 5:22 PM, Hans Wennborg  wrote:

> Sounds good to me.
>
> On Mon, Jan 23, 2017 at 1:56 PM, Eric Fiselier  wrote:
> > This patch should be merge into 4.0 since it is needed to fix compile
> time
> > regressions in  when using Clang 3.4 and C++03.
> >
> > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216054 for more
> info.
> >
> > /Eric
> >
> > On Mon, Jan 23, 2017 at 2:41 PM, Eric Fiselier via cfe-commits
> >  wrote:
> >>
> >> Author: ericwf
> >> Date: Mon Jan 23 15:41:13 2017
> >> New Revision: 292833
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=292833&view=rev
> >> Log:
> >> Manually force the use of __decltype in C++03 with Clang 3.4.
> >>
> >>  uses `decltype` in a way incompatible with `__typeof__`.
> >> This is problematic when compiling  with Clang 3.4 because
> >> even though it provides `__decltype` libc++ still used `__typeof__`
> >> because clang 3.4 doesn't provide __is_identifier which libc++
> >> uses to detect __decltype.
> >>
> >> This patch manually detects Clang 3.4 and properly configures
> >> for it.
> >>
> >> Modified:
> >> libcxx/trunk/include/__config
> >>
> >> Modified: libcxx/trunk/include/__config
> >> URL:
> >> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/_
> _config?rev=292833&r1=292832&r2=292833&view=diff
> >>
> >> 
> ==
> >> --- libcxx/trunk/include/__config (original)
> >> +++ libcxx/trunk/include/__config Mon Jan 23 15:41:13 2017
> >> @@ -109,6 +109,9 @@
> >>
> >>  #if defined(__clang__)
> >>  #define _LIBCPP_COMPILER_CLANG
> >> +# ifndef __apple_build_version__
> >> +#   define _LIBCPP_CLANG_VER (__clang_major__ * 100 + __clang_minor__)
> >> +# endif
> >>  #elif defined(__GNUC__)
> >>  #define _LIBCPP_COMPILER_GCC
> >>  #elif defined(_MSC_VER)
> >> @@ -117,6 +120,10 @@
> >>  #define _LIBCPP_COMPILER_IBM
> >>  #endif
> >>
> >> +#ifndef _LIBCPP_CLANG_VER
> >> +#define _LIBCPP_CLANG_VER 0
> >> +#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.
> >> @@ -754,7 +761,7 @@ template  struct __static_asse
> >>
> >>  #ifdef _LIBCPP_HAS_NO_DECLTYPE
> >>  // GCC 4.6 provides __decltype in all standard modes.
> >> -#if __has_keyword(__decltype) || _GNUC_VER >= 406
> >> +#if __has_keyword(__decltype) || _LIBCPP_CLANG_VER >= 304 || _GNUC_VER
> >=
> >> 406
> >>  #  define decltype(__x) __decltype(__x)
> >>  #else
> >>  #  define decltype(__x) __typeof__(__x)
> >>
> >>
> >> ___
> >> cfe-commits mailing list
> >> cfe-commits@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >
> >
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r292866 - Merge r292833 - Manually force the use of __decltype in C++03 with Clang 3.4.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Mon Jan 23 19:01:55 2017
New Revision: 292866

URL: http://llvm.org/viewvc/llvm-project?rev=292866&view=rev
Log:
Merge r292833 - Manually force the use of __decltype in C++03 with Clang 3.4.

This merges a version of r292833 since it didn't apply cleanly due to other
upstream changes. Original commit message below:

 uses `decltype` in a way incompatible with `__typeof__`.
This is problematic when compiling  with Clang 3.4 because
even though it provides `__decltype` libc++ still used `__typeof__`
because clang 3.4 doesn't provide __is_identifier which libc++
uses to detect __decltype.

Modified:
libcxx/branches/release_40/include/__config

Modified: libcxx/branches/release_40/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/branches/release_40/include/__config?rev=292866&r1=292865&r2=292866&view=diff
==
--- libcxx/branches/release_40/include/__config (original)
+++ libcxx/branches/release_40/include/__config Mon Jan 23 19:01:55 2017
@@ -103,6 +103,9 @@
 
 #if defined(__clang__)
 #define _LIBCPP_COMPILER_CLANG
+# ifndef __apple_build_version__
+#   define _LIBCPP_CLANG_VER (__clang_major__ * 100 + __clang_minor__)
+# endif
 #elif defined(__GNUC__)
 #define _LIBCPP_COMPILER_GCC
 #elif defined(_MSC_VER)
@@ -111,6 +114,10 @@
 #define _LIBCPP_COMPILER_IBM
 #endif
 
+#ifndef _LIBCPP_CLANG_VER
+# define _LIBCPP_CLANG_VER 0
+#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.
@@ -741,7 +748,7 @@ template  struct __static_asse
 
 #ifdef _LIBCPP_HAS_NO_DECLTYPE
 // GCC 4.6 provides __decltype in all standard modes.
-#if !__is_identifier(__decltype) || _GNUC_VER >= 406
+#if !__is_identifier(__decltype) || _LIBCPP_CLANG_VER >= 304 || _GNUC_VER >= 
406
 #  define decltype(__x) __decltype(__x)
 #else
 #  define decltype(__x) __typeof__(__x)


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

r292862 - [sanitizer-coverage] emit __sanitizer_cov_trace_pc_guard w/o a preceding 'if' by default. Update the docs, also add deprecation notes around other parts of sanitizer coverage

[Kostya Serebryany via cfe-commits]

Author: kcc
Date: Mon Jan 23 18:57:31 2017
New Revision: 292862

URL: http://llvm.org/viewvc/llvm-project?rev=292862&view=rev
Log:
[sanitizer-coverage] emit __sanitizer_cov_trace_pc_guard w/o a preceding 'if' 
by default. Update the docs, also add deprecation notes around other parts of 
sanitizer coverage

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=292862&r1=292861&r2=292862&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Mon Jan 23 18:57:31 2017
@@ -227,7 +227,8 @@ easily used for bitset-based corpus dist
 Caller-callee coverage
 ==
 
-(Experimental!)
+**Deprecated, don't use**
+
 Every indirect function call is instrumented with a run-time function call that
 captures caller and callee.  At the shutdown time the process dumps a separate
 file called ``caller-callee.PID.sancov`` which contains caller/callee pairs as
@@ -253,6 +254,8 @@ Current limitations:
 Coverage counters
 =
 
+**Deprecated, don't use**
+
 This experimental feature is inspired by
 `AFL `__'s coverage
 instrumentation. With additional compile-time and run-time flags you can get
@@ -296,6 +299,9 @@ These counters may also be used for in-p
 
 Tracing basic blocks
 
+
+**Deprecated, don't use**
+
 Experimental support for basic block (or edge) tracing.
 With ``-fsanitize-coverage=trace-bb`` the compiler will insert
 ``__sanitizer_cov_trace_basic_block(s32 *id)`` before every function, basic 
block, or edge
@@ -319,6 +325,9 @@ Basic block tracing is currently support
 
 Tracing PCs
 ===
+
+**Deprecated, don't use**
+
 *Experimental* feature similar to tracing basic blocks, but with a different 
API.
 With ``-fsanitize-coverage=trace-pc`` the compiler will insert
 ``__sanitizer_cov_trace_pc()`` on every edge.
@@ -331,16 +340,13 @@ and can be used with `AFL 

[PATCH] D28007: Switch TableGen to emit calls to ASTRecordReader for AttrPCHRead.

[David L. Jones via Phabricator via cfe-commits]

dlj updated this revision to Diff 85493.
dlj added a comment.

- Pull, merge, etc.


https://reviews.llvm.org/D28007

Files:
  include/clang/Serialization/ASTReader.h
  lib/Serialization/ASTReaderDecl.cpp
  utils/TableGen/ClangAttrEmitter.cpp

Index: utils/TableGen/ClangAttrEmitter.cpp
===
--- utils/TableGen/ClangAttrEmitter.cpp
+++ utils/TableGen/ClangAttrEmitter.cpp
@@ -90,13 +90,13 @@
 
 static std::string ReadPCHRecord(StringRef type) {
   return StringSwitch(type)
-.EndsWith("Decl *", "GetLocalDeclAs<" 
-  + std::string(type, 0, type.size()-1) + ">(F, Record[Idx++])")
-.Case("TypeSourceInfo *", "GetTypeSourceInfo(F, Record, Idx)")
-.Case("Expr *", "ReadExpr(F)")
-.Case("IdentifierInfo *", "GetIdentifierInfo(F, Record, Idx)")
-.Case("StringRef", "ReadString(Record, Idx)")
-.Default("Record[Idx++]");
+.EndsWith("Decl *", "Record.GetLocalDeclAs<" 
+  + std::string(type, 0, type.size()-1) + ">(Record.readInt())")
+.Case("TypeSourceInfo *", "Record.getTypeSourceInfo()")
+.Case("Expr *", "Record.readExpr()")
+.Case("IdentifierInfo *", "Record.getIdentifierInfo()")
+.Case("StringRef", "Record.readString()")
+.Default("Record.readInt()");
 }
 
 // Get a type that is suitable for storing an object of the specified type.
@@ -413,7 +413,7 @@
 
 void writePCHReadDecls(raw_ostream &OS) const override {
   OS << "std::string " << getLowerName()
- << "= ReadString(Record, Idx);\n";
+ << "= Record.readString();\n";
 }
 
 void writePCHReadArgs(raw_ostream &OS) const override {
@@ -539,13 +539,13 @@
 }
 
 void writePCHReadDecls(raw_ostream &OS) const override {
-  OS << "bool is" << getLowerName() << "Expr = Record[Idx++];\n";
+  OS << "bool is" << getLowerName() << "Expr = Record.readInt();\n";
   OS << "void *" << getLowerName() << "Ptr;\n";
   OS << "if (is" << getLowerName() << "Expr)\n";
-  OS << "  " << getLowerName() << "Ptr = ReadExpr(F);\n";
+  OS << "  " << getLowerName() << "Ptr = Record.readExpr();\n";
   OS << "else\n";
   OS << "  " << getLowerName()
- << "Ptr = GetTypeSourceInfo(F, Record, Idx);\n";
+ << "Ptr = Record.getTypeSourceInfo();\n";
 }
 
 void writePCHWrite(raw_ostream &OS) const override {
@@ -658,7 +658,7 @@
 }
 
 void writePCHReadDecls(raw_ostream &OS) const override {
-  OS << "unsigned " << getLowerName() << "Size = Record[Idx++];\n";
+  OS << "unsigned " << getLowerName() << "Size = Record.readInt();\n";
   OS << "SmallVector<" << getType() << ", 4> "
  << getLowerName() << ";\n";
   OS << "" << getLowerName() << ".reserve(" << getLowerName()
@@ -783,7 +783,7 @@
 void writePCHReadDecls(raw_ostream &OS) const override {
   OS << "" << getAttrName() << "Attr::" << type << " " << getLowerName()
  << "(static_cast<" << getAttrName() << "Attr::" << type
- << ">(Record[Idx++]));\n";
+ << ">(Record.readInt()));\n";
 }
 
 void writePCHReadArgs(raw_ostream &OS) const override {
@@ -906,14 +906,14 @@
 }
 
 void writePCHReadDecls(raw_ostream &OS) const override {
-  OS << "unsigned " << getLowerName() << "Size = Record[Idx++];\n";
+  OS << "unsigned " << getLowerName() << "Size = Record.readInt();\n";
   OS << "SmallVector<" << QualifiedTypeName << ", 4> " << getLowerName()
  << ";\n";
   OS << "" << getLowerName() << ".reserve(" << getLowerName()
  << "Size);\n";
   OS << "for (unsigned i = " << getLowerName() << "Size; i; --i)\n";
   OS << "  " << getLowerName() << ".push_back(" << "static_cast<"
- << QualifiedTypeName << ">(Record[Idx++]));\n";
+ << QualifiedTypeName << ">(Record.readInt()));\n";
 }
 
 void writePCHWrite(raw_ostream &OS) const override {
@@ -996,7 +996,7 @@
 
 void writePCHReadDecls(raw_ostream &OS) const override {
   OS << "VersionTuple " << getLowerName()
- << "= ReadVersionTuple(Record, Idx);\n";
+ << "= Record.readVersionTuple();\n";
 }
 
 void writePCHReadArgs(raw_ostream &OS) const override {
@@ -2126,9 +2126,9 @@
 
 OS << "  case attr::" << R.getName() << ": {\n";
 if (R.isSubClassOf(InhClass))
-  OS << "bool isInherited = Record[Idx++];\n";
-OS << "bool isImplicit = Record[Idx++];\n";
-OS << "unsigned Spelling = Record[Idx++];\n";
+  OS << "bool isInherited = Record.readInt();\n";
+OS << "bool isImplicit = Record.readInt();\n";
+OS << "unsigned Spelling = Record.readInt();\n";
 ArgRecords = R.getValueAsListOfDefs("Args");
 Args.clear();
 for (const auto *Arg : ArgRecords) {
Index: lib/Serialization/ASTReaderDecl.cpp
===
--- lib/Serialization/ASTReaderDecl

[PATCH] D28835: [coroutines] NFC: Refactor Sema::CoroutineBodyStmt construction.

[Gor Nishanov via Phabricator via cfe-commits]

GorNishanov marked 2 inline comments as done.
GorNishanov added a comment.

Looks even better now!


https://reviews.llvm.org/D28835



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

[PATCH] D28835: [coroutines] NFC: Refactor Sema::CoroutineBodyStmt construction.

[Gor Nishanov via Phabricator via cfe-commits]

GorNishanov updated this revision to Diff 85490.
GorNishanov added a comment.

Feedback implemented!


https://reviews.llvm.org/D28835

Files:
  include/clang/AST/StmtCXX.h
  include/clang/Sema/ScopeInfo.h
  lib/AST/StmtCXX.cpp
  lib/Sema/SemaCoroutine.cpp
  test/SemaCXX/coroutines.cpp

Index: test/SemaCXX/coroutines.cpp
===
--- test/SemaCXX/coroutines.cpp
+++ test/SemaCXX/coroutines.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++14 -fcoroutines-ts -verify %s
+// RUN: %clang_cc1 -std=c++14 -fcoroutines-ts -verify %s -fcxx-exceptions
 
 void no_coroutine_traits_bad_arg_await() {
   co_await a; // expected-error {{include }}
Index: lib/Sema/SemaCoroutine.cpp
===
--- lib/Sema/SemaCoroutine.cpp
+++ lib/Sema/SemaCoroutine.cpp
@@ -487,7 +487,7 @@
 static bool buildAllocationAndDeallocation(Sema &S, SourceLocation Loc,
FunctionScopeInfo *Fn,
Expr *&Allocation,
-   Stmt *&Deallocation) {
+   Expr *&Deallocation) {
   TypeSourceInfo *TInfo = Fn->CoroutinePromise->getTypeSourceInfo();
   QualType PromiseType = TInfo->getType();
   if (PromiseType->isDependentType())
@@ -564,6 +564,48 @@
   return true;
 }
 
+namespace {
+class SubStmtBuilder : public CoroutineBodyStmt::CtorArgs {
+  Sema &S;
+  FunctionDecl &FD;
+  FunctionScopeInfo &Fn;
+  bool IsValid;
+  SourceLocation Loc;
+  QualType RetType;
+  SmallVector ParamMovesVector;
+  const bool IsPromiseDependentType;
+  CXXRecordDecl *PromiseRecordDecl;
+
+public:
+  SubStmtBuilder(Sema &S, FunctionDecl &FD, FunctionScopeInfo &Fn, Stmt *Body)
+  : S(S), FD(FD), Fn(Fn), Loc(FD.getLocation()),
+IsPromiseDependentType(
+!Fn.CoroutinePromise ||
+Fn.CoroutinePromise->getType()->isDependentType()) {
+this->Body = Body;
+if (!IsPromiseDependentType) {
+  PromiseRecordDecl = Fn.CoroutinePromise->getType()->getAsCXXRecordDecl();
+  assert(PromiseRecordDecl && "Type should have already been checked");
+}
+this->IsValid = makePromiseStmt() && makeInitialSuspend() &&
+makeFinalSuspend() && makeOnException() &&
+makeOnFallthrough() && makeNewAndDeleteExpr() &&
+makeReturnObject() && makeParamMoves();
+  }
+
+  bool isInvalid() const { return !this->IsValid; }
+
+  bool makePromiseStmt();
+  bool makeInitialSuspend();
+  bool makeFinalSuspend();
+  bool makeNewAndDeleteExpr();
+  bool makeOnFallthrough();
+  bool makeOnException();
+  bool makeReturnObject();
+  bool makeParamMoves();
+};
+}
+
 void Sema::CheckCompletedCoroutineBody(FunctionDecl *FD, Stmt *&Body) {
   FunctionScopeInfo *Fn = getCurFunction();
   assert(Fn && !Fn->CoroutineStmts.empty() && "not a coroutine");
@@ -577,120 +619,159 @@
 << (isa(First) ? 0 :
 isa(First) ? 1 : 2);
   }
+  SubStmtBuilder Builder(*this, *FD, *Fn, Body);
+  if (Builder.isInvalid())
+return FD->setInvalidDecl();
 
-  SourceLocation Loc = FD->getLocation();
+  // Build body for the coroutine wrapper statement.
+  Body = CoroutineBodyStmt::Create(Context, Builder);
+}
 
+bool SubStmtBuilder::makePromiseStmt() {
   // Form a declaration statement for the promise declaration, so that AST
   // visitors can more easily find it.
   StmtResult PromiseStmt =
-  ActOnDeclStmt(ConvertDeclToDeclGroup(Fn->CoroutinePromise), Loc, Loc);
+  S.ActOnDeclStmt(S.ConvertDeclToDeclGroup(Fn.CoroutinePromise), Loc, Loc);
   if (PromiseStmt.isInvalid())
-return FD->setInvalidDecl();
+return false;
+
+  this->Promise = PromiseStmt.get();
+  return true;
+}
 
+bool SubStmtBuilder::makeInitialSuspend() {
   // Form and check implicit 'co_await p.initial_suspend();' statement.
   ExprResult InitialSuspend =
-  buildPromiseCall(*this, Fn, Loc, "initial_suspend", None);
+  buildPromiseCall(S, &Fn, Loc, "initial_suspend", None);
   // FIXME: Support operator co_await here.
   if (!InitialSuspend.isInvalid())
-InitialSuspend = BuildCoawaitExpr(Loc, InitialSuspend.get());
-  InitialSuspend = ActOnFinishFullExpr(InitialSuspend.get());
+InitialSuspend = S.BuildCoawaitExpr(Loc, InitialSuspend.get());
+  InitialSuspend = S.ActOnFinishFullExpr(InitialSuspend.get());
   if (InitialSuspend.isInvalid())
-return FD->setInvalidDecl();
+return false;
+
+  this->InitialSuspend = InitialSuspend.get();
+  return true;
+}
 
+bool SubStmtBuilder::makeFinalSuspend() {
   // Form and check implicit 'co_await p.final_suspend();' statement.
   ExprResult FinalSuspend =
-  buildPromiseCall(*this, Fn, Loc, "final_suspend", None);
+  buildPromiseCall(S, &Fn, Loc, "final_suspend", None);
   // FIXME: Support operator co_await here.
   if (!FinalSuspend.isInvalid())
-FinalSuspend = BuildCoawaitExpr(Loc, FinalSusp

[PATCH] D28835: [coroutines] NFC: Refactor Sema::CoroutineBodyStmt construction.

[Gor Nishanov via Phabricator via cfe-commits]

GorNishanov updated this revision to Diff 85489.
GorNishanov added a comment.

No changes. Merge with top of the tree (to simplify comparing with the updated 
version that is coming up in a second).


https://reviews.llvm.org/D28835

Files:
  include/clang/AST/StmtCXX.h
  include/clang/Sema/ScopeInfo.h
  lib/AST/StmtCXX.cpp
  lib/Sema/SemaCoroutine.cpp
  test/SemaCXX/coroutines.cpp

Index: test/SemaCXX/coroutines.cpp
===
--- test/SemaCXX/coroutines.cpp
+++ test/SemaCXX/coroutines.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++14 -fcoroutines-ts -verify %s
+// RUN: %clang_cc1 -std=c++14 -fcoroutines-ts -verify %s -fcxx-exceptions
 
 void no_coroutine_traits_bad_arg_await() {
   co_await a; // expected-error {{include }}
Index: lib/Sema/SemaCoroutine.cpp
===
--- lib/Sema/SemaCoroutine.cpp
+++ lib/Sema/SemaCoroutine.cpp
@@ -487,7 +487,7 @@
 static bool buildAllocationAndDeallocation(Sema &S, SourceLocation Loc,
FunctionScopeInfo *Fn,
Expr *&Allocation,
-   Stmt *&Deallocation) {
+   Expr *&Deallocation) {
   TypeSourceInfo *TInfo = Fn->CoroutinePromise->getTypeSourceInfo();
   QualType PromiseType = TInfo->getType();
   if (PromiseType->isDependentType())
@@ -564,6 +564,48 @@
   return true;
 }
 
+namespace {
+class SubStmtBuilder : public CoroutineBodyStmt::CtorArgs {
+  Sema &S;
+  FunctionDecl &FD;
+  FunctionScopeInfo &Fn;
+  bool IsValid;
+  SourceLocation Loc;
+  QualType RetType;
+  SmallVector ParamMovesVector;
+  const bool IsPromiseDependentType;
+  CXXRecordDecl *PromiseRecordDecl;
+
+public:
+  SubStmtBuilder(Sema &S, FunctionDecl &FD, FunctionScopeInfo &Fn, Stmt *Body)
+  : S(S), FD(FD), Fn(Fn), Loc(FD.getLocation()),
+IsPromiseDependentType(
+!Fn.CoroutinePromise ||
+Fn.CoroutinePromise->getType()->isDependentType()) {
+this->Body = Body;
+if (!IsPromiseDependentType) {
+  PromiseRecordDecl = Fn.CoroutinePromise->getType()->getAsCXXRecordDecl();
+  assert(PromiseRecordDecl && "Type should have already been checked");
+}
+this->IsValid = makePromiseStmt() && makeInitialSuspend() &&
+makeFinalSuspend() && makeOnException() &&
+makeOnFallthrough() && makeNewAndDeleteExpr() &&
+makeReturnObject() && makeParamMoves();
+  }
+
+  bool isInvalid() const { return !this->IsValid; }  
+
+  bool makePromiseStmt();
+  bool makeInitialSuspend();
+  bool makeFinalSuspend();
+  bool makeNewAndDeleteExpr();
+  bool makeOnFallthrough();
+  bool makeOnException();
+  bool makeReturnObject();
+  bool makeParamMoves();
+};
+}
+
 void Sema::CheckCompletedCoroutineBody(FunctionDecl *FD, Stmt *&Body) {
   FunctionScopeInfo *Fn = getCurFunction();
   assert(Fn && !Fn->CoroutineStmts.empty() && "not a coroutine");
@@ -577,120 +619,159 @@
 << (isa(First) ? 0 :
 isa(First) ? 1 : 2);
   }
+  SubStmtBuilder Builder(*this, *FD, *Fn, Body);
+  if (Builder.isInvalid())
+return FD->setInvalidDecl();
 
-  SourceLocation Loc = FD->getLocation();
+  // Build body for the coroutine wrapper statement.
+  Body = CoroutineBodyStmt::Create(Context, Builder);
+}
 
+bool SubStmtBuilder::makePromiseStmt() {
   // Form a declaration statement for the promise declaration, so that AST
   // visitors can more easily find it.
   StmtResult PromiseStmt =
-  ActOnDeclStmt(ConvertDeclToDeclGroup(Fn->CoroutinePromise), Loc, Loc);
+  S.ActOnDeclStmt(S.ConvertDeclToDeclGroup(Fn.CoroutinePromise), Loc, Loc);
   if (PromiseStmt.isInvalid())
-return FD->setInvalidDecl();
+return false;
+
+  this->Promise = PromiseStmt.get();
+  return true;
+}
 
+bool SubStmtBuilder::makeInitialSuspend() {
   // Form and check implicit 'co_await p.initial_suspend();' statement.
   ExprResult InitialSuspend =
-  buildPromiseCall(*this, Fn, Loc, "initial_suspend", None);
+  buildPromiseCall(S, &Fn, Loc, "initial_suspend", None);
   // FIXME: Support operator co_await here.
   if (!InitialSuspend.isInvalid())
-InitialSuspend = BuildCoawaitExpr(Loc, InitialSuspend.get());
-  InitialSuspend = ActOnFinishFullExpr(InitialSuspend.get());
+InitialSuspend = S.BuildCoawaitExpr(Loc, InitialSuspend.get());
+  InitialSuspend = S.ActOnFinishFullExpr(InitialSuspend.get());
   if (InitialSuspend.isInvalid())
-return FD->setInvalidDecl();
+return false;
+
+  this->InitialSuspend = InitialSuspend.get();
+  return true;
+}
 
+bool SubStmtBuilder::makeFinalSuspend() {
   // Form and check implicit 'co_await p.final_suspend();' statement.
   ExprResult FinalSuspend =
-  buildPromiseCall(*this, Fn, Loc, "final_suspend", None);
+  buildPromiseCall(S, &Fn, Loc, "final_suspend", None);
   // FIXME: Support operator 

Re: [PATCH] D28889: Change where we handle arg-dependent diagnose_if attributes

[George Burgess IV via cfe-commits]

> Also, I plan to submit this (once it's LGTM'ed) to the 4.0 branch. Is
that OK with you, Richard?

(To be clear, I'll check with Hans before I submit this there, as well.
Just trying to save a round-trip. :) )

On Mon, Jan 23, 2017 at 4:39 PM, George Burgess IV via Phabricator <
revi...@reviews.llvm.org> wrote:

> george.burgess.iv updated this revision to Diff 85486.
> george.burgess.iv marked 2 inline comments as done.
> george.burgess.iv added a comment.
>
> Addressed all feedback.
>
> Richard noted that, because we're now doing these checks after overload
> resolution has occurred, we no longer need to convert arguments for
> arg-dependent diagnose_if checks. As a result, we get to make lots of
> things `const`. Yay!
>
> Also, I plan to submit this (once it's LGTM'ed) to the 4.0 branch. Is that
> OK with you, Richard?
>
>
> https://reviews.llvm.org/D28889
>
> Files:
>   include/clang/Sema/Overload.h
>   include/clang/Sema/Sema.h
>   lib/Sema/SemaChecking.cpp
>   lib/Sema/SemaExpr.cpp
>   lib/Sema/SemaExprCXX.cpp
>   lib/Sema/SemaLookup.cpp
>   lib/Sema/SemaOverload.cpp
>   test/Sema/diagnose_if.c
>   test/SemaCXX/diagnose_if.cpp
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28889: Change where we handle arg-dependent diagnose_if attributes

[George Burgess IV via Phabricator via cfe-commits]

george.burgess.iv updated this revision to Diff 85486.
george.burgess.iv marked 2 inline comments as done.
george.burgess.iv added a comment.

Addressed all feedback.

Richard noted that, because we're now doing these checks after overload 
resolution has occurred, we no longer need to convert arguments for 
arg-dependent diagnose_if checks. As a result, we get to make lots of things 
`const`. Yay!

Also, I plan to submit this (once it's LGTM'ed) to the 4.0 branch. Is that OK 
with you, Richard?


https://reviews.llvm.org/D28889

Files:
  include/clang/Sema/Overload.h
  include/clang/Sema/Sema.h
  lib/Sema/SemaChecking.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaExprCXX.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOverload.cpp
  test/Sema/diagnose_if.c
  test/SemaCXX/diagnose_if.cpp

Index: test/SemaCXX/diagnose_if.cpp
===
--- test/SemaCXX/diagnose_if.cpp
+++ test/SemaCXX/diagnose_if.cpp
@@ -2,6 +2,8 @@
 
 #define _diagnose_if(...) __attribute__((diagnose_if(__VA_ARGS__)))
 
+using size_t = unsigned long;
+
 namespace type_dependent {
 template 
 void neverok() _diagnose_if(!T(), "oh no", "error") {} // expected-note 4{{from 'diagnose_if'}}
@@ -51,14 +53,14 @@
 }
 
 template 
-void errorIf(T a) _diagnose_if(T() != a, "oh no", "error") {} // expected-note {{candidate disabled: oh no}}
+void errorIf(T a) _diagnose_if(T() != a, "oh no", "error") {} // expected-note{{from 'diagnose_if'}}
 
 template 
-void warnIf(T a) _diagnose_if(T() != a, "oh no", "warning") {} // expected-note {{from 'diagnose_if'}}
+void warnIf(T a) _diagnose_if(T() != a, "oh no", "warning") {} // expected-note{{from 'diagnose_if'}}
 
 void runIf() {
   errorIf(0);
-  errorIf(1); // expected-error{{call to unavailable function}}
+  errorIf(1); // expected-error{{oh no}}
 
   warnIf(0);
   warnIf(1); // expected-warning{{oh no}}
@@ -114,14 +116,14 @@
 }
 
 template 
-void errorIf(int a) _diagnose_if(N != a, "oh no", "error") {} // expected-note {{candidate disabled: oh no}}
+void errorIf(int a) _diagnose_if(N != a, "oh no", "error") {} // expected-note{{from 'diagnose_if'}}
 
 template 
-void warnIf(int a) _diagnose_if(N != a, "oh no", "warning") {} // expected-note {{from 'diagnose_if'}}
+void warnIf(int a) _diagnose_if(N != a, "oh no", "warning") {} // expected-note{{from 'diagnose_if'}}
 
 void runIf() {
   errorIf<0>(0);
-  errorIf<0>(1); // expected-error{{call to unavailable function}}
+  errorIf<0>(1); // expected-error{{oh no}}
 
   warnIf<0>(0);
   warnIf<0>(1); // expected-warning{{oh no}}
@@ -135,17 +137,17 @@
 void bar(int);
 void bar(short) _diagnose_if(1, "oh no", "error");
 
-void fooArg(int a) _diagnose_if(a, "oh no", "error"); // expected-note{{candidate disabled: oh no}}
-void fooArg(short); // expected-note{{candidate function}}
+void fooArg(int a) _diagnose_if(a, "oh no", "error"); // expected-note{{from 'diagnose_if'}}
+void fooArg(short);
 
 void barArg(int);
 void barArg(short a) _diagnose_if(a, "oh no", "error");
 
 void runAll() {
   foo(1); // expected-error{{oh no}}
   bar(1);
 
-  fooArg(1); // expected-error{{call to unavailable function}}
+  fooArg(1); // expected-error{{oh no}}
   barArg(1);
 
   auto p = foo; // expected-error{{incompatible initializer of type ''}}
@@ -188,11 +190,11 @@
   void foo(int i) _diagnose_if(i, "bad i", "error"); // expected-note{{from 'diagnose_if'}}
   void bar(int i) _diagnose_if(i != T(), "bad i", "error"); // expected-note{{from 'diagnose_if'}}
 
-  void fooOvl(int i) _diagnose_if(i, "int bad i", "error"); // expected-note 2{{int bad i}}
-  void fooOvl(short i) _diagnose_if(i, "short bad i", "error"); // expected-note 2{{short bad i}}
+  void fooOvl(int i) _diagnose_if(i, "int bad i", "error"); // expected-note{{from 'diagnose_if'}}
+  void fooOvl(short i) _diagnose_if(i, "short bad i", "error"); // expected-note{{from 'diagnose_if'}}
 
-  void barOvl(int i) _diagnose_if(i != T(), "int bad i", "error"); // expected-note 2{{int bad i}}
-  void barOvl(short i) _diagnose_if(i != T(), "short bad i", "error"); // expected-note 2{{short bad i}}
+  void barOvl(int i) _diagnose_if(i != T(), "int bad i", "error"); // expected-note{{from 'diagnose_if'}}
+  void barOvl(short i) _diagnose_if(i != T(), "short bad i", "error"); // expected-note{{from 'diagnose_if'}}
 };
 
 void runErrors() {
@@ -203,14 +205,14 @@
   Errors().bar(1); // expected-error{{bad i}}
 
   Errors().fooOvl(0);
-  Errors().fooOvl(1); // expected-error{{call to unavailable}}
+  Errors().fooOvl(1); // expected-error{{int bad i}}
   Errors().fooOvl(short(0));
-  Errors().fooOvl(short(1)); // expected-error{{call to unavailable}}
+  Errors().fooOvl(short(1)); // expected-error{{short bad i}}
 
   Errors().barOvl(0);
-  Errors().barOvl(1); // expected-error{{call to unavailable}}
+  Errors().barOvl(1); // expected-error{{int bad i}}
   Errors().barOvl(short(0));
-  Errors().barOvl(short(1)); // expected-error{{call to unavailable}}
+  Errors().barOvl(short(1)); 

[PATCH] D28933: Revert the return type for `emplace_(back|front)` to `void` in C++14 and before

[Hans Wennborg via Phabricator via cfe-commits]

hans added a comment.

This sounds like something we'll want to merge to the release branch when it 
lands?


https://reviews.llvm.org/D28933



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

[PATCH] D28952: [analyzer] Add new Z3 constraint manager backend

[Devin Coughlin via Phabricator via cfe-commits]

dcoughlin added a comment.

This is super-exciting work!

Some high-level notes:

- The running-time numbers you report are very high. At a ~20x slowdown, the 
benefits from improved solver reasoning will have to be very, very large to 
justify the performance cost. It is worth thinking about ways to limit the 
number of solver calls. Ultimately, I suspect @zaks.anna's suggestion of using 
z3 for refutation is the right way to go -- this would invoke the expensive 
solver only after the cheaper solver has found a potentially buggy path and try 
to show that it is infeasible.

- That said, I think there are still significant optimization opportunities. It 
looks like when performing a query you create a new solver for each set of 
constraints. My understanding (and perhaps @nlopes can correct me here) is that 
these days Z3 is quite good at incremental solves so you may be leaving a lot 
of performance on the table. For example, in `getSymVal()` you create one 
solver to query for a satisfying assignment and then later create a completely 
new one to determine whether it is the only satisfying assignment. Since those 
two queries share all of their conjuncts but one it might be faster to reuse 
the first solver and add the new assertion for the second. Similarly, since 
analyzer exploration is a DFS, you could imagine building up the path condition 
incrementally. Z3 has solver APIs for pushing and popping assertions. (Again, 
@nlopes may have a better idea of whether this would pay off in practice.)

- It would be good to measure the increased peak memory usage with the Z3 
constraint solver. The analyzer is often used as part of an IDE and so it needs 
to be able to run in memory constrained environments (such as laptops). 
Further, since multiple invocations of clang are often run simultaneously, 
memory is often a more precious resource than CPU time.

- As @a.sidorin noted, there is a significant test and maintenance cost to 
keeping two constraint managers around. Since the testing matrix would double, 
anything we can do to limit the need to modify/duplicate tests would be a huge 
savings. Is it possible to use lit substitution to call the analyzer twice for 
each run line: once with the range constraint manager and once with z3 (for 
builds where z3 is requested)? This, combined with automatically adding the 
#defines that @NoQ suggested would provide a mechanism to share most tests 
between the constraint managers.

- I don't think it is reasonable to ask all analyzer users or even all clang 
bots to install Z3, so we'll have to make sure the tests degrade gracefully 
when Z3 is not available. That said, we could set up dedicated Z3 bots to make 
sure that there is continuous integration for the feature.

- Right now the CMake uses find_package and builds with Z3 if it is found to be 
installed on the building system. I think this is too aggressive. It would be 
better to have the build explicitly opt in to using Z3. Without this, a user 
could accidentally build a clang that dynamically links to their local Z3 but 
then fails to launch with a load error when distributed. Similarly, it would be 
good to be able to explicitly set the the location of the Z3 to be used at 
build time for systems with multiple Z3s installed.


https://reviews.llvm.org/D28952



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

Re: r291963 - [clang] Emit `diagnose_if` warnings from system headers

[Hans Wennborg via cfe-commits]

Ping?

On Tue, Jan 17, 2017 at 4:16 PM, Hans Wennborg  wrote:
> Richard, what do you think?
>
> On Fri, Jan 13, 2017 at 3:16 PM, Eric Fiselier  wrote:
>> I would love to see this merged. It would make it easier to write libc++
>> tests if the tests didn't have to worry about the old 4.0 behavior.
>>
>> CC'ing Richard: Would merging this be OK?
>>
>> On Fri, Jan 13, 2017 at 3:46 PM, George Burgess IV
>>  wrote:
>>>
>>> Do we want to consider merging this into the release branch? Seems like
>>> more of a bugfix than a feature to me.
>>>
>>> On Fri, Jan 13, 2017 at 2:11 PM, Eric Fiselier via cfe-commits
>>>  wrote:

 Author: ericwf
 Date: Fri Jan 13 16:11:40 2017
 New Revision: 291963

 URL: http://llvm.org/viewvc/llvm-project?rev=291963&view=rev
 Log:
 [clang] Emit `diagnose_if` warnings from system headers

 Summary: In order for libc++ to meaningfully use `diagnose_if` warnings
 they need to be emitted from system headers by default. This patch changes
 the `diagnose_if` warning diagnostic to be shown in system headers.

 Reviewers: george.burgess.iv, rsmith, aaron.ballman

 Subscribers: cfe-commits

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

 Added:
 cfe/trunk/test/Sema/Inputs/diagnose-if-warn-system-header.h
 Modified:
 cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
 cfe/trunk/test/Sema/diagnose_if.c

 Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=291963&r1=291962&r2=291963&view=diff

 ==
 --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
 +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Jan 13
 16:11:40 2017
 @@ -3380,7 +3380,8 @@ def note_ovl_candidate_has_pass_object_s
  "candidate address cannot be taken because parameter %0 has "
  "pass_object_size attribute">;
  def err_diagnose_if_succeeded : Error<"%0">;
 -def warn_diagnose_if_succeeded : Warning<"%0">,
 InGroup;
 +def warn_diagnose_if_succeeded : Warning<"%0">,
 InGroup,
 +ShowInSystemHeader;
  def note_ovl_candidate_disabled_by_function_cond_attr : Note<
  "candidate disabled: %0">;
  def note_ovl_candidate_disabled_by_extension : Note<

 Added: cfe/trunk/test/Sema/Inputs/diagnose-if-warn-system-header.h
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/Inputs/diagnose-if-warn-system-header.h?rev=291963&view=auto

 ==
 --- cfe/trunk/test/Sema/Inputs/diagnose-if-warn-system-header.h (added)
 +++ cfe/trunk/test/Sema/Inputs/diagnose-if-warn-system-header.h Fri Jan
 13 16:11:40 2017
 @@ -0,0 +1,11 @@
 +#pragma GCC system_header
 +
 +inline int system_header_func(int x)
 +  __attribute__((diagnose_if(x == x, "system header warning",
 "warning"))) // expected-note {{from 'diagnose_if' attribute}}
 +{
 +  return 0;
 +}
 +
 +void test_system_header() {
 +  system_header_func(0); // expected-warning {{system header warning}}
 +}

 Modified: cfe/trunk/test/Sema/diagnose_if.c
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/diagnose_if.c?rev=291963&r1=291962&r2=291963&view=diff

 ==
 --- cfe/trunk/test/Sema/diagnose_if.c (original)
 +++ cfe/trunk/test/Sema/diagnose_if.c Fri Jan 13 16:11:40 2017
 @@ -150,3 +150,6 @@ void alwaysWarnWithArg(int a) _diagnose_
  void runAlwaysWarnWithArg(int a) {
alwaysWarnWithArg(a); // expected-warning{{alwaysWarn}}
  }
 +
 +// Test that diagnose_if warnings generated in system headers are not
 ignored.
 +#include "Inputs/diagnose-if-warn-system-header.h"


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

Re: r292847 - PR31692: Don't mark a declaration as invalid if we haven't necessarily emitted a (user-visible) error.

[Hans Wennborg via cfe-commits]

Thanks! r292859.

On Mon, Jan 23, 2017 at 3:26 PM, Richard Smith  wrote:
> Hans, this should go into Clang 4.
>
> On 23 January 2017 at 15:14, Richard Smith via cfe-commits
>  wrote:
>>
>> Author: rsmith
>> Date: Mon Jan 23 17:14:23 2017
>> New Revision: 292847
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=292847&view=rev
>> Log:
>> PR31692: Don't mark a declaration as invalid if we haven't necessarily
>> emitted a (user-visible) error.
>>
>> Added:
>> cfe/trunk/test/SemaCXX/cxx11-default-member-initializers.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=292847&r1=292846&r2=292847&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Mon Jan 23 17:14:23 2017
>> @@ -12383,9 +12383,9 @@ ExprResult Sema::BuildCXXDefaultInitExpr
>>Diag(Loc, diag::err_in_class_initializer_not_yet_parsed)
>><< OutermostClass << Field;
>>Diag(Field->getLocEnd(),
>> diag::note_in_class_initializer_not_yet_parsed);
>> -
>> -  // Don't diagnose this again.
>> -  Field->setInvalidDecl();
>> +  // Recover by marking the field invalid, unless we're in a SFINAE
>> context.
>> +  if (!isSFINAEContext())
>> +Field->setInvalidDecl();
>>return ExprError();
>>  }
>>
>>
>> Added: cfe/trunk/test/SemaCXX/cxx11-default-member-initializers.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/cxx11-default-member-initializers.cpp?rev=292847&view=auto
>>
>> ==
>> --- cfe/trunk/test/SemaCXX/cxx11-default-member-initializers.cpp (added)
>> +++ cfe/trunk/test/SemaCXX/cxx11-default-member-initializers.cpp Mon Jan
>> 23 17:14:23 2017
>> @@ -0,0 +1,14 @@
>> +// RUN: %clang_cc1 -std=c++11 -verify %s -pedantic
>> +
>> +namespace PR31692 {
>> +  struct A {
>> +struct X { int n = 0; } x;
>> +// Trigger construction of X() from a SFINAE context. This must not
>> mark
>> +// any part of X as invalid.
>> +static_assert(!__is_constructible(X), "");
>> +// Check that X::n is not marked invalid.
>> +double &r = x.n; // expected-error {{non-const lvalue reference to
>> type 'double' cannot bind to a value of unrelated type 'int'}}
>> +  };
>> +  // A::X can now be default-constructed.
>> +  static_assert(__is_constructible(A::X), "");
>> +}
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r292833 - Manually force the use of __decltype in C++03 with Clang 3.4.

[Hans Wennborg via cfe-commits]

Sounds good to me.

On Mon, Jan 23, 2017 at 1:56 PM, Eric Fiselier  wrote:
> This patch should be merge into 4.0 since it is needed to fix compile time
> regressions in  when using Clang 3.4 and C++03.
>
> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216054 for more info.
>
> /Eric
>
> On Mon, Jan 23, 2017 at 2:41 PM, Eric Fiselier via cfe-commits
>  wrote:
>>
>> Author: ericwf
>> Date: Mon Jan 23 15:41:13 2017
>> New Revision: 292833
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=292833&view=rev
>> Log:
>> Manually force the use of __decltype in C++03 with Clang 3.4.
>>
>>  uses `decltype` in a way incompatible with `__typeof__`.
>> This is problematic when compiling  with Clang 3.4 because
>> even though it provides `__decltype` libc++ still used `__typeof__`
>> because clang 3.4 doesn't provide __is_identifier which libc++
>> uses to detect __decltype.
>>
>> This patch manually detects Clang 3.4 and properly configures
>> for it.
>>
>> Modified:
>> libcxx/trunk/include/__config
>>
>> Modified: libcxx/trunk/include/__config
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=292833&r1=292832&r2=292833&view=diff
>>
>> ==
>> --- libcxx/trunk/include/__config (original)
>> +++ libcxx/trunk/include/__config Mon Jan 23 15:41:13 2017
>> @@ -109,6 +109,9 @@
>>
>>  #if defined(__clang__)
>>  #define _LIBCPP_COMPILER_CLANG
>> +# ifndef __apple_build_version__
>> +#   define _LIBCPP_CLANG_VER (__clang_major__ * 100 + __clang_minor__)
>> +# endif
>>  #elif defined(__GNUC__)
>>  #define _LIBCPP_COMPILER_GCC
>>  #elif defined(_MSC_VER)
>> @@ -117,6 +120,10 @@
>>  #define _LIBCPP_COMPILER_IBM
>>  #endif
>>
>> +#ifndef _LIBCPP_CLANG_VER
>> +#define _LIBCPP_CLANG_VER 0
>> +#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.
>> @@ -754,7 +761,7 @@ template  struct __static_asse
>>
>>  #ifdef _LIBCPP_HAS_NO_DECLTYPE
>>  // GCC 4.6 provides __decltype in all standard modes.
>> -#if __has_keyword(__decltype) || _GNUC_VER >= 406
>> +#if __has_keyword(__decltype) || _LIBCPP_CLANG_VER >= 304 || _GNUC_VER >=
>> 406
>>  #  define decltype(__x) __decltype(__x)
>>  #else
>>  #  define decltype(__x) __typeof__(__x)
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r292800 - [analyzer] Fix memory space of static locals seen from nested blocks.

[Hans Wennborg via cfe-commits]

Merged in r292858.

Thanks,
Hans

On Mon, Jan 23, 2017 at 4:15 PM, Anna Zaks  wrote:
> Yes, ok to merge!
> Thank you.
>
> Sent from my iPhone
>
>> On Jan 23, 2017, at 1:50 PM, Hans Wennborg  wrote:
>>
>> Sounds good to me.
>>
>> Anna, you're the code owner here. Ok to merge this?
>>
>> Thanks,
>> Hans
>>
>>> On Mon, Jan 23, 2017 at 10:37 AM, Artem Dergachev  
>>> wrote:
>>> Hans,
>>>
>>> Could we merge this one into the 4.0.0 release branch? It's a recent bugfix
>>> for the analyzer.
>>>
>>> Thanks,
>>> Artem.
>>>
>>>
>>>
 On 1/23/17 7:57 PM, Artem Dergachev via cfe-commits wrote:

 Author: dergachev
 Date: Mon Jan 23 10:57:11 2017
 New Revision: 292800

 URL: http://llvm.org/viewvc/llvm-project?rev=292800&view=rev
 Log:
 [analyzer] Fix memory space of static locals seen from nested blocks.

 When a block within a function accesses a function's static local
 variable,
 this local is captured by reference rather than copied to the heap.

 Therefore this variable's memory space is known: StaticGlobalSpaceRegion.
 Used to be UnknownSpaceRegion, same as for stack locals.

 Fixes a false positive in MacOSXAPIChecker.

 rdar://problem/30105546
 Differential revision: https://reviews.llvm.org/D28946

 Modified:
 cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
 cfe/trunk/test/Analysis/dispatch-once.m

 Modified: cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp?rev=292800&r1=292799&r2=292800&view=diff

 ==
 --- cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp (original)
 +++ cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp Mon Jan 23 10:57:11
 2017
 @@ -776,6 +776,22 @@ getStackOrCaptureRegionForDeclContext(co
return (const StackFrameContext *)nullptr;
  }
  +static CanQualType getBlockPointerType(const BlockDecl *BD, ASTContext
 &C) {
 +  // FIXME: The fallback type here is totally bogus -- though it should
 +  // never be queried, it will prevent uniquing with the real
 +  // BlockCodeRegion. Ideally we'd fix the AST so that we always had a
 +  // signature.
 +  QualType T;
 +  if (const TypeSourceInfo *TSI = BD->getSignatureAsWritten())
 +T = TSI->getType();
 +  if (T.isNull())
 +T = C.VoidTy;
 +  if (!T->getAs())
 +T = C.getFunctionNoProtoType(T);
 +  T = C.getBlockPointerType(T);
 +  return C.getCanonicalType(T);
 +}
 +
  const VarRegion* MemRegionManager::getVarRegion(const VarDecl *D,
  const LocationContext
 *LC) {
const MemRegion *sReg = nullptr;
 @@ -803,7 +819,7 @@ const VarRegion* MemRegionManager::getVa
  sReg = getGlobalsRegion();
  }
  -  // Finally handle static locals.
 +  // Finally handle locals.
} else {
  // FIXME: Once we implement scope handling, we will need to properly
 lookup
  // 'D' to the proper LocationContext.
 @@ -816,9 +832,22 @@ const VarRegion* MemRegionManager::getVa
const StackFrameContext *STC = V.get();
  -if (!STC)
 -  sReg = getUnknownRegion();
 -else {
 +if (!STC) {
 +  if (D->isStaticLocal()) {
 +const CodeTextRegion *fReg = nullptr;
 +if (const auto *ND = dyn_cast(DC))
 +  fReg = getFunctionCodeRegion(ND);
 +else if (const auto *BD = dyn_cast(DC))
 +  fReg = getBlockCodeRegion(BD, getBlockPointerType(BD,
 getContext()),
 +LC->getAnalysisDeclContext());
 +assert(fReg && "Unable to determine code region for a static
 local!");
 +sReg = getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,
 fReg);
 +  } else {
 +// We're looking at a block-captured local variable, which may be
 either
 +// still local, or already moved to the heap. So we're not sure.
 +sReg = getUnknownRegion();
 +  }
 +} else {
if (D->hasLocalStorage()) {
  sReg = isa(D) || isa(D)
 ? static_cast>>> MemRegion*>(getStackArgumentsRegion(STC))
 @@ -831,22 +860,9 @@ const VarRegion* MemRegionManager::getVa
sReg =
 getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,

 getFunctionCodeRegion(cast(STCD)));
  else if (const BlockDecl *BD = dyn_cast(STCD)) {
 -  // FIXME: The fallback type here is totally bogus -- though it
 should
 -  // never be queried, it will prevent uniquing with the real
 -  // BlockCodeRegion. Ideally we'd fix the AST so that we always
 had a
 -  // signature.
 - 

[PATCH] D28845: Prototype of modules codegen

[David Blaikie via Phabricator via cfe-commits]

dblaikie updated this revision to Diff 85484.
dblaikie added a comment.

Add bit to the Module record for when modular codegen decls are included in the 
MODULAR_CODEGEN_DECLS bitcode record


https://reviews.llvm.org/D28845

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/ExternalASTSource.h
  include/clang/Basic/LangOptions.def
  include/clang/Basic/Module.h
  include/clang/Serialization/ASTBitCodes.h
  include/clang/Serialization/ASTReader.h
  include/clang/Serialization/ASTWriter.h
  lib/AST/ASTContext.cpp
  lib/AST/ExternalASTSource.cpp
  lib/Basic/Module.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/Lex/ModuleMap.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  lib/Serialization/ASTWriterDecl.cpp

Index: lib/Serialization/ASTWriterDecl.cpp
===
--- lib/Serialization/ASTWriterDecl.cpp
+++ lib/Serialization/ASTWriterDecl.cpp
@@ -2152,7 +2152,7 @@
 /// relatively painless since they would presumably only do it for top-level
 /// decls.
 static bool isRequiredDecl(const Decl *D, ASTContext &Context,
-   bool WritingModule) {
+   bool WritingModule, bool ModularCode) {
   // An ObjCMethodDecl is never considered as "required" because its
   // implementation container always is.
 
@@ -2168,7 +2168,7 @@
 return false;
   }
 
-  return Context.DeclMustBeEmitted(D);
+  return Context.DeclMustBeEmitted(D, ModularCode);
 }
 
 void ASTWriter::WriteDecl(ASTContext &Context, Decl *D) {
@@ -2212,8 +2212,11 @@
 
   // Note declarations that should be deserialized eagerly so that we can add
   // them to a record in the AST file later.
-  if (isRequiredDecl(D, Context, WritingModule))
+  if (isRequiredDecl(D, Context, WritingModule, false))
 EagerlyDeserializedDecls.push_back(ID);
+  else if (Context.getLangOpts().ModularCodegen && WritingModule &&
+   isRequiredDecl(D, Context, true, true))
+ModularCodegenDecls.push_back(ID);
 }
 
 void ASTRecordWriter::AddFunctionDefinition(const FunctionDecl *FD) {
Index: lib/Serialization/ASTWriter.cpp
===
--- lib/Serialization/ASTWriter.cpp
+++ lib/Serialization/ASTWriter.cpp
@@ -1030,6 +1030,7 @@
   RECORD(IDENTIFIER_OFFSET);
   RECORD(IDENTIFIER_TABLE);
   RECORD(EAGERLY_DESERIALIZED_DECLS);
+  RECORD(MODULAR_CODEGEN_DECLS);
   RECORD(SPECIAL_TYPES);
   RECORD(STATISTICS);
   RECORD(TENTATIVE_DEFINITIONS);
@@ -2575,6 +2576,7 @@
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // InferExplicit...
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // InferExportWild...
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // ConfigMacrosExh...
+  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 2)); // WithCodegen
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Blob)); // Name
   unsigned DefinitionAbbrev = Stream.EmitAbbrev(std::move(Abbrev));
 
@@ -2667,7 +2669,7 @@
   SUBMODULE_DEFINITION, ID, ParentID, Mod->IsFramework, Mod->IsExplicit,
   Mod->IsSystem, Mod->IsExternC, Mod->InferSubmodules,
   Mod->InferExplicitSubmodules, Mod->InferExportWildcard,
-  Mod->ConfigMacrosExhaustive};
+  Mod->ConfigMacrosExhaustive, Mod->WithCodegen};
   Stream.EmitRecordWithBlob(DefinitionAbbrev, Record, Mod->Name);
 }
 
@@ -4675,6 +4677,9 @@
   if (!EagerlyDeserializedDecls.empty())
 Stream.EmitRecord(EAGERLY_DESERIALIZED_DECLS, EagerlyDeserializedDecls);
 
+  if (Context.getLangOpts().ModularCodegen)
+Stream.EmitRecord(MODULAR_CODEGEN_DECLS, ModularCodegenDecls);
+
   // Write the record containing tentative definitions.
   if (!TentativeDefinitions.empty())
 Stream.EmitRecord(TENTATIVE_DEFINITIONS, TentativeDefinitions);
Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -2607,7 +2607,8 @@
 break;
 
   case SUBMODULE_BLOCK_ID:
-if (ASTReadResult Result = ReadSubmoduleBlock(F, ClientLoadCapabilities))
+if (ASTReadResult Result =
+ReadSubmoduleBlock(F, ClientLoadCapabilities))
   return Result;
 break;
 
@@ -2772,6 +2773,14 @@
 EagerlyDeserializedDecls.push_back(getGlobalDeclID(F, Record[I]));
   break;
 
+case MODULAR_CODEGEN_DECLS:
+  // FIXME: Skip reading this record if our ASTConsumer doesn't care about
+  // them (ie: if we're not codegenerating this module).
+  if (F.Kind == MK_MainFile)
+for (unsigned I = 0, N = Record.size(); I != N; ++I)
+  EagerlyDeserializedDecls.push_back(getGlobalDeclID(F, Record[I]));
+  break;
+
 case SPECIAL_TYPES:
   if (SpecialTypes.empty()) {
 for (unsigned I = 0, N = Record.size(); I != N; ++I)
@@ -4630,15 +4639,17 @@
   bool InferExplicitSubmodules = Record[Idx++];
   bool InferExport

Re: r292800 - [analyzer] Fix memory space of static locals seen from nested blocks.

[Anna Zaks via cfe-commits]

Yes, ok to merge!
Thank you.

Sent from my iPhone

> On Jan 23, 2017, at 1:50 PM, Hans Wennborg  wrote:
> 
> Sounds good to me.
> 
> Anna, you're the code owner here. Ok to merge this?
> 
> Thanks,
> Hans
> 
>> On Mon, Jan 23, 2017 at 10:37 AM, Artem Dergachev  
>> wrote:
>> Hans,
>> 
>> Could we merge this one into the 4.0.0 release branch? It's a recent bugfix
>> for the analyzer.
>> 
>> Thanks,
>> Artem.
>> 
>> 
>> 
>>> On 1/23/17 7:57 PM, Artem Dergachev via cfe-commits wrote:
>>> 
>>> Author: dergachev
>>> Date: Mon Jan 23 10:57:11 2017
>>> New Revision: 292800
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=292800&view=rev
>>> Log:
>>> [analyzer] Fix memory space of static locals seen from nested blocks.
>>> 
>>> When a block within a function accesses a function's static local
>>> variable,
>>> this local is captured by reference rather than copied to the heap.
>>> 
>>> Therefore this variable's memory space is known: StaticGlobalSpaceRegion.
>>> Used to be UnknownSpaceRegion, same as for stack locals.
>>> 
>>> Fixes a false positive in MacOSXAPIChecker.
>>> 
>>> rdar://problem/30105546
>>> Differential revision: https://reviews.llvm.org/D28946
>>> 
>>> Modified:
>>> cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
>>> cfe/trunk/test/Analysis/dispatch-once.m
>>> 
>>> Modified: cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp?rev=292800&r1=292799&r2=292800&view=diff
>>> 
>>> ==
>>> --- cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp (original)
>>> +++ cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp Mon Jan 23 10:57:11
>>> 2017
>>> @@ -776,6 +776,22 @@ getStackOrCaptureRegionForDeclContext(co
>>>return (const StackFrameContext *)nullptr;
>>>  }
>>>  +static CanQualType getBlockPointerType(const BlockDecl *BD, ASTContext
>>> &C) {
>>> +  // FIXME: The fallback type here is totally bogus -- though it should
>>> +  // never be queried, it will prevent uniquing with the real
>>> +  // BlockCodeRegion. Ideally we'd fix the AST so that we always had a
>>> +  // signature.
>>> +  QualType T;
>>> +  if (const TypeSourceInfo *TSI = BD->getSignatureAsWritten())
>>> +T = TSI->getType();
>>> +  if (T.isNull())
>>> +T = C.VoidTy;
>>> +  if (!T->getAs())
>>> +T = C.getFunctionNoProtoType(T);
>>> +  T = C.getBlockPointerType(T);
>>> +  return C.getCanonicalType(T);
>>> +}
>>> +
>>>  const VarRegion* MemRegionManager::getVarRegion(const VarDecl *D,
>>>  const LocationContext
>>> *LC) {
>>>const MemRegion *sReg = nullptr;
>>> @@ -803,7 +819,7 @@ const VarRegion* MemRegionManager::getVa
>>>  sReg = getGlobalsRegion();
>>>  }
>>>  -  // Finally handle static locals.
>>> +  // Finally handle locals.
>>>} else {
>>>  // FIXME: Once we implement scope handling, we will need to properly
>>> lookup
>>>  // 'D' to the proper LocationContext.
>>> @@ -816,9 +832,22 @@ const VarRegion* MemRegionManager::getVa
>>>const StackFrameContext *STC = V.get();
>>>  -if (!STC)
>>> -  sReg = getUnknownRegion();
>>> -else {
>>> +if (!STC) {
>>> +  if (D->isStaticLocal()) {
>>> +const CodeTextRegion *fReg = nullptr;
>>> +if (const auto *ND = dyn_cast(DC))
>>> +  fReg = getFunctionCodeRegion(ND);
>>> +else if (const auto *BD = dyn_cast(DC))
>>> +  fReg = getBlockCodeRegion(BD, getBlockPointerType(BD,
>>> getContext()),
>>> +LC->getAnalysisDeclContext());
>>> +assert(fReg && "Unable to determine code region for a static
>>> local!");
>>> +sReg = getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,
>>> fReg);
>>> +  } else {
>>> +// We're looking at a block-captured local variable, which may be
>>> either
>>> +// still local, or already moved to the heap. So we're not sure.
>>> +sReg = getUnknownRegion();
>>> +  }
>>> +} else {
>>>if (D->hasLocalStorage()) {
>>>  sReg = isa(D) || isa(D)
>>> ? static_cast>> MemRegion*>(getStackArgumentsRegion(STC))
>>> @@ -831,22 +860,9 @@ const VarRegion* MemRegionManager::getVa
>>>sReg =
>>> getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,
>>> 
>>> getFunctionCodeRegion(cast(STCD)));
>>>  else if (const BlockDecl *BD = dyn_cast(STCD)) {
>>> -  // FIXME: The fallback type here is totally bogus -- though it
>>> should
>>> -  // never be queried, it will prevent uniquing with the real
>>> -  // BlockCodeRegion. Ideally we'd fix the AST so that we always
>>> had a
>>> -  // signature.
>>> -  QualType T;
>>> -  if (const TypeSourceInfo *TSI = BD->getSignatureAsWritten())
>>> -T = TSI->getType();
>>> -  if (T.isNull())
>>> -T = getContext().VoidTy;
>

Re: r292522 - Don't inline dllimport functions referencing non-imported methods

[Hans Wennborg via cfe-commits]

Thanks for reverting! This was indeed broken.

I've re-committed it with a fix in r292856.

On Fri, Jan 20, 2017 at 12:56 PM, Reid Kleckner via cfe-commits
 wrote:
> The first Chrome DLL build with this change is crashing during compilation:
> https://build.chromium.org/p/chromium.fyi/builders/ClangToTWin64%28dll%29/builds/8380/
>
> The previous build fails with a link error, so the revision range for the
> new crash is 292501 - 292526.
>
> Only the DLL builders are affected, so I think it's very likely that this is
> the culprit. I speculatively reverted it in r292643.
>
> On Thu, Jan 19, 2017 at 1:33 PM, Hans Wennborg via cfe-commits
>  wrote:
>>
>> Author: hans
>> Date: Thu Jan 19 15:33:13 2017
>> New Revision: 292522
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=292522&view=rev
>> Log:
>> Don't inline dllimport functions referencing non-imported methods
>>
>> This is another follow-up to r246338. I had assumed methods were already
>> handled by the AST visitor, but turns out they weren't.
>>
>> Modified:
>> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>> cfe/trunk/test/CodeGenCXX/dllimport.cpp
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r292856 - Re-commit "Don't inline dllimport functions referencing non-imported methods"

[Hans Wennborg via cfe-commits]

Author: hans
Date: Mon Jan 23 17:57:50 2017
New Revision: 292856

URL: http://llvm.org/viewvc/llvm-project?rev=292856&view=rev
Log:
Re-commit "Don't inline dllimport functions referencing non-imported methods"

This re-commits r292522 with the addition that it also handles calls
through pointer to member functions without crashing.

Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/test/CodeGenCXX/dllimport.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=292856&r1=292855&r2=292856&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Jan 23 17:57:50 2017
@@ -1751,6 +1751,16 @@ namespace {
   SafeToInline = E->getConstructor()->hasAttr();
   return SafeToInline;
 }
+bool VisitCXXMemberCallExpr(CXXMemberCallExpr *E) {
+  CXXMethodDecl *M = E->getMethodDecl();
+  if (!M) {
+// Call through a pointer to member function. This is safe to inline.
+SafeToInline = true;
+  } else {
+SafeToInline = M->hasAttr();
+  }
+  return SafeToInline;
+}
 bool VisitCXXDeleteExpr(CXXDeleteExpr *E) {
   SafeToInline = E->getOperatorDelete()->hasAttr();
   return SafeToInline;

Modified: cfe/trunk/test/CodeGenCXX/dllimport.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/dllimport.cpp?rev=292856&r1=292855&r2=292856&view=diff
==
--- cfe/trunk/test/CodeGenCXX/dllimport.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/dllimport.cpp Mon Jan 23 17:57:50 2017
@@ -26,6 +26,7 @@ struct ExplicitSpec_NotImported {};
 #define USEVARTYPE(type, var) type UNIQ(use)() { return var; }
 #define USEVAR(var) USEVARTYPE(int, var)
 #define USE(func) void UNIQ(use)() { func(); }
+#define USE1(func) void UNIQ(use)() { func(nullptr); }
 #define USEMEMFUNC(class, func) void (class::*UNIQ(use)())() { return 
&class::func; }
 #define USESTATICMEMFUNC(class, func) void (*UNIQ(use)())() { return 
&class::func; }
 #define USECLASS(class) void UNIQ(USE)() { class x; }
@@ -316,10 +317,13 @@ namespace ns { __declspec(dllimport) voi
 USE(ns::externalFunc)
 
 // A dllimport function referencing non-imported vars or functions must not be 
available_externally.
+
 __declspec(dllimport) int ImportedVar;
 int NonImportedVar;
 __declspec(dllimport) int ImportedFunc();
 int NonImportedFunc();
+struct ClassWithNonImportedMethod { int f(); };
+
 __declspec(dllimport) inline int ReferencingImportedVar() { return 
ImportedVar; }
 // MO1-DAG: define available_externally dllimport i32 
@"\01?ReferencingImportedVar@@YAHXZ"
 __declspec(dllimport) inline int ReferencingNonImportedVar() { return 
NonImportedVar; }
@@ -328,10 +332,16 @@ __declspec(dllimport) inline int Referen
 // MO1-DAG: define available_externally dllimport i32 
@"\01?ReferencingImportedFunc@@YAHXZ"
 __declspec(dllimport) inline int ReferencingNonImportedFunc() { return 
NonImportedFunc(); }
 // MO1-DAG: declare dllimport i32 @"\01?ReferencingNonImportedFunc@@YAHXZ"()
+__declspec(dllimport) inline int 
ReferencingNonImportedMethod(ClassWithNonImportedMethod *x) { return x->f(); }
+// MO1-DAG: declare dllimport i32 @"\01?ReferencingNonImportedMethod
+__declspec(dllimport) inline int ReferencingClassMemberPtr(int 
(ClassWithNonImportedMethod::*p)(), ClassWithNonImportedMethod *x) { return 
(x->*p)(); }
+// MO1-DAG: define available_externally dllimport i32 
@"\01?ReferencingClassMemberPtr@@YAHP8ClassWithNonImportedMethod@@AEHXZPAU1@@Z"
 USE(ReferencingImportedVar)
 USE(ReferencingNonImportedVar)
 USE(ReferencingImportedFunc)
 USE(ReferencingNonImportedFunc)
+USE1(ReferencingNonImportedMethod)
+void UNIQ(use)() { ReferencingClassMemberPtr(&ClassWithNonImportedMethod::f, 
nullptr); }
 // References to operator new and delete count too, despite not being 
DeclRefExprs.
 __declspec(dllimport) inline int *ReferencingNonImportedNew() { return new 
int[2]; }
 // MO1-DAG: declare dllimport i32* @"\01?ReferencingNonImportedNew@@YAPAHXZ"


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

Re: [libcxx] r291961 - Add _LIBCPP_DIAGNOSE_WARNING and _LIBCPP_DIAGNOSE_ERROR macros.

[George Burgess via cfe-commits]

> However I do want a little special behavior for libc++ [...]

I have no problem with this: I just wanted to be sure that we could
reasonably use this feature for things that aren't libcxx. :)

> Libc++ defines some symbols within the global namespace, and we'll need a
way to group those as part of libc++ as well.

Good point. It also seems that implicitly namespacing things would be
problematic for things like specializing std::hash (and might get fun when
mixed with inline namespaces?) so I'm liking the wildcard +
please-just-add-a-prefix-to-your-IDs strategy more now.

On Mon, Jan 23, 2017 at 3:35 PM, Eric Fiselier  wrote:

> > I like the idea of tagging diagnose_ifs with tags, though I wonder how
> this could be made applicable to code outside of libcxx. Specifically, if I
> import some big library that uses diagnose_if, then I'd still need to use
> `-Wno-user-defined-warnings` if said lib had a single diagnose_if that I
> didn't want to fix immediately.
>
> Yeah, we absolutely want this code to be applicable outside of libc++,
> other libraries and their users will have the same need to
> tag/enable/disable warnings separately.
> However I do want a little special behavior for libc++. Specifically I
> dislike that libc++ warnings are part of -Wuser-defined-warnings, since it
> should be considered part
> of the C++ implementation, and not part of "user-code". Instead I would
> greatly appreciate if libc++ had its own top-level warning group
>  -Wstandard-library-warnings, since
> many of the diagnostics it generates will be about violations of the C++
> standard. Also when other libraries start using diagnose_if I don't want
> the libc++ warnings
> getting suppressed when a user adds -Wno-user-defined-warnings to disable
> diagnostics produced elsewhere.
>
> I'm not sure what the best way to achieve this, but that's my rational for
> wanting it.
>
> > If not this, then I'd like to at least consider some kind of
> wildcarding thing in the warning flag, since libraries will likely roll
> their own tag-namespaces anyway to avoid things like:
>
> Libc++ defines some symbols within the global namespace, and we'll need a
> way to group those as part of libc++ as well.
>
> /Eric
>
>
>
>
> On Mon, Jan 23, 2017 at 4:06 PM, George Burgess  wrote:
>
>> I like the idea of tagging diagnose_ifs with tags, though I wonder how
>> this could be made applicable to code outside of libcxx. Specifically, if I
>> import some big library that uses diagnose_if, then I'd still need to use
>> `-Wno-user-defined-warnings` if said lib had a single diagnose_if that I
>> didn't want to fix immediately.
>>
>> My thought is that we may be able to tag these IDs with namespaces, and
>> we can match against those in the -Wno-user-defined-warnings=whatever.
>>
>> For example:
>>
>> namespace std {
>>   void foo(int i) __attribute__((diagnose_if(i, "oh no", "warning",
>> "foo_tag")));
>>   void bar(int i) __attribute__((diagnose_if(i, "oh no", "warning",
>> "bar_tag")));
>> }
>>
>> -Wno-user-defined-warnings='std::' // all diagnose_ifs in std:: are
>> disabled
>> -Wno-user-defined-warnings='std::foo_tag' // std::bar can warn
>> -Wno-user-defined-warnings='std::foo_tag,std::bar_tag' // neither
>> std::foo nor std::bar warn
>>
>> If not this, then I'd like to at least consider some kind of wildcarding
>> thing in the warning flag, since libraries will likely roll their own
>> tag-namespaces anyway to avoid things like:
>>
>> namespace boost {
>>   void foo(int i) __attribute__((diagnose_if(i, "oh no", "warning",
>> "foo")));
>> }
>> namespace internal_lib {
>>   void foo(int i) __attribute__((diagnose_if(i, "oh no", "warning",
>> "foo")));
>> }
>>
>> -Wno-user-defined-warnings='foo' // disables boost::foo and
>> internal_lib::foo's warnings.
>>
>> To be clear, I'm imagining the wildcards would look something like
>>
>> #define _LIBCXX_TAG "libcxx_warning_"
>> namespace std {
>>   void foo(int i) __attribute__((diagnose_if(i, "oh no", "warning",
>> _LIBCXX_TAG "foo_tag")));
>>   void bar(int i) __attribute__((diagnose_if(i, "oh no", "warning",
>> _LIBCXX_TAG "bar_tag")));
>> }
>>
>> -Wno-user-defined-warnings='libcxx_warning*' // std::foo and std::bar
>> warnings are disabled
>> -Wno-user-defined-warnings='libcxx_warning_foo_tag' // std::bar can warn
>> -Wno-user-defined-warnings='libcxx_warning_foo_tag,libcxx_warning_bar_tag'
>> // neither std::foo nor std::bar warn
>>
>> ...Personally, I'm leaning toward the implicit namespacing, since it's
>> impossible to forget (e.g. a library that doesn't use tags can be disabled
>> with 'lib_namespace::', instead of having to disable all user-defined
>> warnings), but I'd be content with either.
>>
>> On Mon, Jan 23, 2017 at 2:11 PM, Eric Fiselier via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> My dream, and something I would like to work towards is supporting
>>> something like this:
>>>
>>>
>> On Mon, Jan 23, 2017 at 2:11 PM, Eric Fiselier  wrote:
>>
>>> My dream, and something I wo

[PATCH] D28772: [Preprocessor] Fix incorrect token caching that occurs when lexing _Pragma in macro argument pre-expansion mode when skipping a function body

[Richard Smith via Phabricator via cfe-commits]

rsmith added a comment.

Can we instead address this locally in `_Pragma` handling, by getting it to 
clear out the junk it inserted into the token stream when it's done (if 
backtracking is enabled)?


Repository:
  rL LLVM

https://reviews.llvm.org/D28772



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

Re: [libcxx] r291961 - Add _LIBCPP_DIAGNOSE_WARNING and _LIBCPP_DIAGNOSE_ERROR macros.

[Eric Fiselier via cfe-commits]

> I like the idea of tagging diagnose_ifs with tags, though I wonder how
this could be made applicable to code outside of libcxx. Specifically, if I
import some big library that uses diagnose_if, then I'd still need to use
`-Wno-user-defined-warnings` if said lib had a single diagnose_if that I
didn't want to fix immediately.

Yeah, we absolutely want this code to be applicable outside of libc++,
other libraries and their users will have the same need to
tag/enable/disable warnings separately.
However I do want a little special behavior for libc++. Specifically I
dislike that libc++ warnings are part of -Wuser-defined-warnings, since it
should be considered part
of the C++ implementation, and not part of "user-code". Instead I would
greatly appreciate if libc++ had its own top-level warning group
 -Wstandard-library-warnings, since
many of the diagnostics it generates will be about violations of the C++
standard. Also when other libraries start using diagnose_if I don't want
the libc++ warnings
getting suppressed when a user adds -Wno-user-defined-warnings to disable
diagnostics produced elsewhere.

I'm not sure what the best way to achieve this, but that's my rational for
wanting it.

> If not this, then I'd like to at least consider some kind of wildcarding
thing in the warning flag, since libraries will likely roll their own
tag-namespaces anyway to avoid things like:

Libc++ defines some symbols within the global namespace, and we'll need a
way to group those as part of libc++ as well.

/Eric




On Mon, Jan 23, 2017 at 4:06 PM, George Burgess  wrote:

> I like the idea of tagging diagnose_ifs with tags, though I wonder how
> this could be made applicable to code outside of libcxx. Specifically, if I
> import some big library that uses diagnose_if, then I'd still need to use
> `-Wno-user-defined-warnings` if said lib had a single diagnose_if that I
> didn't want to fix immediately.
>
> My thought is that we may be able to tag these IDs with namespaces, and we
> can match against those in the -Wno-user-defined-warnings=whatever.
>
> For example:
>
> namespace std {
>   void foo(int i) __attribute__((diagnose_if(i, "oh no", "warning",
> "foo_tag")));
>   void bar(int i) __attribute__((diagnose_if(i, "oh no", "warning",
> "bar_tag")));
> }
>
> -Wno-user-defined-warnings='std::' // all diagnose_ifs in std:: are
> disabled
> -Wno-user-defined-warnings='std::foo_tag' // std::bar can warn
> -Wno-user-defined-warnings='std::foo_tag,std::bar_tag' // neither
> std::foo nor std::bar warn
>
> If not this, then I'd like to at least consider some kind of wildcarding
> thing in the warning flag, since libraries will likely roll their own
> tag-namespaces anyway to avoid things like:
>
> namespace boost {
>   void foo(int i) __attribute__((diagnose_if(i, "oh no", "warning",
> "foo")));
> }
> namespace internal_lib {
>   void foo(int i) __attribute__((diagnose_if(i, "oh no", "warning",
> "foo")));
> }
>
> -Wno-user-defined-warnings='foo' // disables boost::foo and
> internal_lib::foo's warnings.
>
> To be clear, I'm imagining the wildcards would look something like
>
> #define _LIBCXX_TAG "libcxx_warning_"
> namespace std {
>   void foo(int i) __attribute__((diagnose_if(i, "oh no", "warning",
> _LIBCXX_TAG "foo_tag")));
>   void bar(int i) __attribute__((diagnose_if(i, "oh no", "warning",
> _LIBCXX_TAG "bar_tag")));
> }
>
> -Wno-user-defined-warnings='libcxx_warning*' // std::foo and std::bar
> warnings are disabled
> -Wno-user-defined-warnings='libcxx_warning_foo_tag' // std::bar can warn
> -Wno-user-defined-warnings='libcxx_warning_foo_tag,libcxx_warning_bar_tag'
> // neither std::foo nor std::bar warn
>
> ...Personally, I'm leaning toward the implicit namespacing, since it's
> impossible to forget (e.g. a library that doesn't use tags can be disabled
> with 'lib_namespace::', instead of having to disable all user-defined
> warnings), but I'd be content with either.
>
> On Mon, Jan 23, 2017 at 2:11 PM, Eric Fiselier via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> My dream, and something I would like to work towards is supporting
>> something like this:
>>
>>
> On Mon, Jan 23, 2017 at 2:11 PM, Eric Fiselier  wrote:
>
>> My dream, and something I would like to work towards is supporting
>> something like this:
>>
>> > [[clang::libcxx_diagnose_if(cond, "message", "warning", /*
>> warning-id*/ "non-const-functor")]]
>> >
>> > -Wno-libcxx-warnings=non-const-functor
>>
>> This way libc++ warnings get treated differently from all other users of
>> diagnose_if, and can be enabled
>> and disabled separately.
>>
>> @George does this sound like a reasonable goal? If so I'm happy to start
>> working on this.
>>
>> /Eric
>>
>>
>> On Mon, Jan 23, 2017 at 11:46 AM, George Burgess  wrote:
>>
>>> The only plan that we have at the moment is basically for a
>>> -Wno-user-defined-warnings-in-system-headers type of flag. I agree that
>>> it would be nice if we could be more granular than this, so I'll think
>>> about what we 

[PATCH] D28981: Use GNU-style attributes for several __throw_XXX() functions

[Jonathan Wakely via Phabricator via cfe-commits]

jwakely added a comment.

The __throw_xxx functions are not part of the public libstdc++ API and whatever 
Firefox is trying to do with them is not supported by libstdc++ and is 
undefined behaviour. Make it stop.


https://reviews.llvm.org/D28981



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

[PATCH] D28477: Add LF_ prefix to LibFunc enums in TargetLibraryInfo.

[David L. Jones via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL292849: Add LF_ prefix to LibFunc enums in 
TargetLibraryInfo. (authored by dlj).

Changed prior to commit:
  https://reviews.llvm.org/D28477?vs=83674&id=85473#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28477

Files:
  cfe/trunk/lib/CodeGen/BackendUtil.cpp


Index: cfe/trunk/lib/CodeGen/BackendUtil.cpp
===
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp
@@ -262,7 +262,7 @@
 TLII->disableAllFunctions();
   else {
 // Disable individual libc/libm calls in TargetLibraryInfo.
-LibFunc::Func F;
+LibFunc F;
 for (auto &FuncName : CodeGenOpts.getNoBuiltinFuncs())
   if (TLII->getLibFunc(FuncName, F))
 TLII->setUnavailable(F);


Index: cfe/trunk/lib/CodeGen/BackendUtil.cpp
===
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp
@@ -262,7 +262,7 @@
 TLII->disableAllFunctions();
   else {
 // Disable individual libc/libm calls in TargetLibraryInfo.
-LibFunc::Func F;
+LibFunc F;
 for (auto &FuncName : CodeGenOpts.getNoBuiltinFuncs())
   if (TLII->getLibFunc(FuncName, F))
 TLII->setUnavailable(F);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r292849 - Add LF_ prefix to LibFunc enums in TargetLibraryInfo.

[David L. Jones via cfe-commits]

Author: dlj
Date: Mon Jan 23 17:16:58 2017
New Revision: 292849

URL: http://llvm.org/viewvc/llvm-project?rev=292849&view=rev
Log:
Add LF_ prefix to LibFunc enums in TargetLibraryInfo.

Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).

Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via ). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.

The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LF_". (Unfortunately, a scoped enum is not sufficient to override macros.)

These changes are for clang. See https://reviews.llvm.org/D28476 for LLVM.

Reviewers: rsmith

Subscribers: cfe-commits

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

Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=292849&r1=292848&r2=292849&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon Jan 23 17:16:58 2017
@@ -262,7 +262,7 @@ static TargetLibraryInfoImpl *createTLII
 TLII->disableAllFunctions();
   else {
 // Disable individual libc/libm calls in TargetLibraryInfo.
-LibFunc::Func F;
+LibFunc F;
 for (auto &FuncName : CodeGenOpts.getNoBuiltinFuncs())
   if (TLII->getLibFunc(FuncName, F))
 TLII->setUnavailable(F);


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

Re: r292847 - PR31692: Don't mark a declaration as invalid if we haven't necessarily emitted a (user-visible) error.

[Richard Smith via cfe-commits]

Hans, this should go into Clang 4.

On 23 January 2017 at 15:14, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Mon Jan 23 17:14:23 2017
> New Revision: 292847
>
> URL: http://llvm.org/viewvc/llvm-project?rev=292847&view=rev
> Log:
> PR31692: Don't mark a declaration as invalid if we haven't necessarily
> emitted a (user-visible) error.
>
> Added:
> cfe/trunk/test/SemaCXX/cxx11-default-member-initializers.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=292847&r1=292846&r2=292847&view=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Mon Jan 23 17:14:23 2017
> @@ -12383,9 +12383,9 @@ ExprResult Sema::BuildCXXDefaultInitExpr
>Diag(Loc, diag::err_in_class_initializer_not_yet_parsed)
><< OutermostClass << Field;
>Diag(Field->getLocEnd(), diag::note_in_class_
> initializer_not_yet_parsed);
> -
> -  // Don't diagnose this again.
> -  Field->setInvalidDecl();
> +  // Recover by marking the field invalid, unless we're in a SFINAE
> context.
> +  if (!isSFINAEContext())
> +Field->setInvalidDecl();
>return ExprError();
>  }
>
>
> Added: cfe/trunk/test/SemaCXX/cxx11-default-member-initializers.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> SemaCXX/cxx11-default-member-initializers.cpp?rev=292847&view=auto
> 
> ==
> --- cfe/trunk/test/SemaCXX/cxx11-default-member-initializers.cpp (added)
> +++ cfe/trunk/test/SemaCXX/cxx11-default-member-initializers.cpp Mon Jan
> 23 17:14:23 2017
> @@ -0,0 +1,14 @@
> +// RUN: %clang_cc1 -std=c++11 -verify %s -pedantic
> +
> +namespace PR31692 {
> +  struct A {
> +struct X { int n = 0; } x;
> +// Trigger construction of X() from a SFINAE context. This must not
> mark
> +// any part of X as invalid.
> +static_assert(!__is_constructible(X), "");
> +// Check that X::n is not marked invalid.
> +double &r = x.n; // expected-error {{non-const lvalue reference to
> type 'double' cannot bind to a value of unrelated type 'int'}}
> +  };
> +  // A::X can now be default-constructed.
> +  static_assert(__is_constructible(A::X), "");
> +}
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r292847 - PR31692: Don't mark a declaration as invalid if we haven't necessarily emitted a (user-visible) error.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Jan 23 17:14:23 2017
New Revision: 292847

URL: http://llvm.org/viewvc/llvm-project?rev=292847&view=rev
Log:
PR31692: Don't mark a declaration as invalid if we haven't necessarily emitted 
a (user-visible) error.

Added:
cfe/trunk/test/SemaCXX/cxx11-default-member-initializers.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=292847&r1=292846&r2=292847&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Mon Jan 23 17:14:23 2017
@@ -12383,9 +12383,9 @@ ExprResult Sema::BuildCXXDefaultInitExpr
   Diag(Loc, diag::err_in_class_initializer_not_yet_parsed)
   << OutermostClass << Field;
   Diag(Field->getLocEnd(), diag::note_in_class_initializer_not_yet_parsed);
-
-  // Don't diagnose this again.
-  Field->setInvalidDecl();
+  // Recover by marking the field invalid, unless we're in a SFINAE context.
+  if (!isSFINAEContext())
+Field->setInvalidDecl();
   return ExprError();
 }
 

Added: cfe/trunk/test/SemaCXX/cxx11-default-member-initializers.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/cxx11-default-member-initializers.cpp?rev=292847&view=auto
==
--- cfe/trunk/test/SemaCXX/cxx11-default-member-initializers.cpp (added)
+++ cfe/trunk/test/SemaCXX/cxx11-default-member-initializers.cpp Mon Jan 23 
17:14:23 2017
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -std=c++11 -verify %s -pedantic
+
+namespace PR31692 {
+  struct A {
+struct X { int n = 0; } x;
+// Trigger construction of X() from a SFINAE context. This must not mark
+// any part of X as invalid.
+static_assert(!__is_constructible(X), "");
+// Check that X::n is not marked invalid.
+double &r = x.n; // expected-error {{non-const lvalue reference to type 
'double' cannot bind to a value of unrelated type 'int'}}
+  };
+  // A::X can now be default-constructed.
+  static_assert(__is_constructible(A::X), "");
+}


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

[PATCH] D29032: [mips] Define macros related to -mabicalls in the preprocessor

[Joerg Sonnenberger via Phabricator via cfe-commits]

joerg added a comment.

I'm not terribly attached to using __ABICALLS__ for NetBSD, but let me check 
back with some of the MIPS folks. I would prefer __mips_abicalls to be always 
defined though, independent of the historic behavior.


https://reviews.llvm.org/D29032



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

[PATCH] D28981: Use GNU-style attributes for several __throw_XXX() functions

[Marshall Clow via Phabricator via cfe-commits]

mclow.lists added a comment.

> It would be nice to have some way of making them semi-compatible.

I'm afraid I disagree.  If we make them something that people can "count on", 
then we have to support them.
The whole point of names that start with `__` (or `_[A-Z]` are that they are 
internal, implementation details and are NOT part of the published API.


https://reviews.llvm.org/D28981



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

[PATCH] D29039: Proposal for clang-format -r option

[Daniel Jasper via Phabricator via cfe-commits]

djasper added a comment.

I am happy to let other people in the community weigh in, but I would not move 
forward with this patch. Listing directories is not a task that clang-format 
should do. It does not seem useful to me to add this functionality to basically 
every single tool that you might want to pipe files through. That would mean 
that you'd have to repeat the same code many times. Also, I would not call this 
"bash magic", these are more like "bash basics". I don't know how much harder 
this is on windows, but still solving that doesn't sound like something 
clang-format should fix.

The other point I'd like to make is that it rarely makes sense to format an 
entire directory structure with clang-format. It is actually much more useful 
if integrated into editors (plugins available) or the version control system 
(e.g. through git-clang-format). That's also why you see many diffs here, we 
don't reformat all of clang-format on every commit, just the changed lines. The 
rest might go sightly out of sync with clang-format's formatting, but that's 
ok, no harm done. Often this is preferable over lots of spurious diffs as 
present here.


Repository:
  rL LLVM

https://reviews.llvm.org/D29039



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

Re: [libcxx] r291961 - Add _LIBCPP_DIAGNOSE_WARNING and _LIBCPP_DIAGNOSE_ERROR macros.

[George Burgess via cfe-commits]

I like the idea of tagging diagnose_ifs with tags, though I wonder how this
could be made applicable to code outside of libcxx. Specifically, if I
import some big library that uses diagnose_if, then I'd still need to use
`-Wno-user-defined-warnings` if said lib had a single diagnose_if that I
didn't want to fix immediately.

My thought is that we may be able to tag these IDs with namespaces, and we
can match against those in the -Wno-user-defined-warnings=whatever.

For example:

namespace std {
  void foo(int i) __attribute__((diagnose_if(i, "oh no", "warning",
"foo_tag")));
  void bar(int i) __attribute__((diagnose_if(i, "oh no", "warning",
"bar_tag")));
}

-Wno-user-defined-warnings='std::' // all diagnose_ifs in std:: are disabled
-Wno-user-defined-warnings='std::foo_tag' // std::bar can warn
-Wno-user-defined-warnings='std::foo_tag,std::bar_tag' // neither std::foo
nor std::bar warn

If not this, then I'd like to at least consider some kind of wildcarding
thing in the warning flag, since libraries will likely roll their own
tag-namespaces anyway to avoid things like:

namespace boost {
  void foo(int i) __attribute__((diagnose_if(i, "oh no", "warning",
"foo")));
}
namespace internal_lib {
  void foo(int i) __attribute__((diagnose_if(i, "oh no", "warning",
"foo")));
}

-Wno-user-defined-warnings='foo' // disables boost::foo and
internal_lib::foo's warnings.

To be clear, I'm imagining the wildcards would look something like

#define _LIBCXX_TAG "libcxx_warning_"
namespace std {
  void foo(int i) __attribute__((diagnose_if(i, "oh no", "warning",
_LIBCXX_TAG "foo_tag")));
  void bar(int i) __attribute__((diagnose_if(i, "oh no", "warning",
_LIBCXX_TAG "bar_tag")));
}

-Wno-user-defined-warnings='libcxx_warning*' // std::foo and std::bar
warnings are disabled
-Wno-user-defined-warnings='libcxx_warning_foo_tag' // std::bar can warn
-Wno-user-defined-warnings='libcxx_warning_foo_tag,libcxx_warning_bar_tag'
// neither std::foo nor std::bar warn

...Personally, I'm leaning toward the implicit namespacing, since it's
impossible to forget (e.g. a library that doesn't use tags can be disabled
with 'lib_namespace::', instead of having to disable all user-defined
warnings), but I'd be content with either.

On Mon, Jan 23, 2017 at 2:11 PM, Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> My dream, and something I would like to work towards is supporting
> something like this:
>
>
On Mon, Jan 23, 2017 at 2:11 PM, Eric Fiselier  wrote:

> My dream, and something I would like to work towards is supporting
> something like this:
>
> > [[clang::libcxx_diagnose_if(cond, "message", "warning", /* warning-id*/
> "non-const-functor")]]
> >
> > -Wno-libcxx-warnings=non-const-functor
>
> This way libc++ warnings get treated differently from all other users of
> diagnose_if, and can be enabled
> and disabled separately.
>
> @George does this sound like a reasonable goal? If so I'm happy to start
> working on this.
>
> /Eric
>
>
> On Mon, Jan 23, 2017 at 11:46 AM, George Burgess  wrote:
>
>> The only plan that we have at the moment is basically for a
>> -Wno-user-defined-warnings-in-system-headers type of flag. I agree that
>> it would be nice if we could be more granular than this, so I'll think
>> about what we can do.
>>
>> On Mon, Jan 23, 2017 at 8:36 AM, Nico Weber  wrote:
>>
>>> This happens to fire in practice in protobuf. It's probably a true
>>> positive and it's cool that this warning found it, but it means we have to
>>> disable Wuser-defined-warnings for a bit -- which then disables all of
>>> these user-defined warnings. Right now there aren't any others, but it
>>> feels like we'd want to have the ability to turn individual user-defined
>>> warnings on or off instead of just having a single toggle for all of them.
>>> Are there plans for something like that?
>>>
>>> On Fri, Jan 13, 2017 at 5:02 PM, Eric Fiselier via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: ericwf
 Date: Fri Jan 13 16:02:08 2017
 New Revision: 291961

 URL: http://llvm.org/viewvc/llvm-project?rev=291961&view=rev
 Log:
 Add _LIBCPP_DIAGNOSE_WARNING and _LIBCPP_DIAGNOSE_ERROR macros.

 Clang recently added a `diagnose_if(cond, msg, type)` attribute
 which can be used to generate diagnostics when `cond` is a constant
 expression that evaluates to true. Otherwise no attribute has no
 effect.

 This patch adds _LIBCPP_DIAGNOSE_ERROR/WARNING macros which
 use this new attribute. Additionally this patch implements
 a diagnostic message when a non-const-callable comparator is
 given to a container.

 Note: For now the warning version of the diagnostic is useless
 within libc++ since warning diagnostics are suppressed by the
 system header pragma. I'm going to work on fixing this.

 Added:
 libcxx/trunk/test/libcxx/containers/associative/non_const_co
 mparator.fail.cpp
 Modified:
 libcxx/trunk/docs/U

Re: r291905 - [Sema] Add warning for unused lambda captures

[Nico Weber via cfe-commits]

On Mon, Jan 23, 2017 at 5:29 PM, Aaron Ballman 
wrote:

> On Mon, Jan 23, 2017 at 5:00 PM, Nico Weber via cfe-commits
>  wrote:
> > On Sun, Jan 22, 2017 at 6:17 AM, Malcolm Parsons <
> malcolm.pars...@gmail.com>
> > wrote:
> >>
> >> On 20 January 2017 at 21:32, Nico Weber  wrote:
> >> > This warns about code like
> >> >
> >> >   constexpr int foo = 4;
> >> >   [&foo]() { use(foo); }
> >> >
> >> > That's correct, but removing &foo then makes MSVC complain about this
> >> > code
> >> > like "error C3493: 'foo' cannot be implicitly captured because no
> >> > default
> >> > capture mode has been specified". A workaround is to make foo static
> >> > const
> >> > instead of constexpr.
> >> >
> >> > This seems like an MSVC bug, but it's still a bit annoying that clang
> >> > now
> >> > suggests doing things that won't build in other compilers. Any ideas
> >> > what to
> >> > do about this?
> >>
> >> Should Clang care about the behaviour of other compilers that don't
> >> follow the standard?
> >
> >
> > clang should be a compiler that people like to use. Multi-platform
> > development isn't super uncommon, so trying to give a good experience in
> > that case seems like a good thing to me -- and we've tried to do that in
> the
> > past pretty hard. It's possible that "do nothing" is the right thing, but
> > "well that other compiler is buggy" seems like a somewhat oversimplified
> > reply.
>
> We generally don't try to be bug-for-bug compatible with other
> compilers unless the bug is sufficiently important (like it is relied
> upon in system headers, for instance). In this case, I think the bug
> in MSVC is annoying, but not the end of the world because it's trivial
> to workaround in a compiler-agnostic way


It's easy, but you need to know about it. Say you're working on some
project that uses clang on macOS, gcc on Linux, MSVC on Windows, and you're
developing on Linux. You write some patch, and things work fine on your
machine. You submit your thing, it gets reverted because it triggers this
new warning on mac. Hey, fair enough, looks like a good warning, so you
remove the thing from the capture list and reland. Now you get reverted
_again_ because MSVC does need that thing that clang just told you to
revert. After three such interactions you'll be pretty unhappy, I gather :-)


> without disabling the
> diagnostic everywhere in Clang. You can leave the capture in place to
> appease MSVC and cast the use to void to appease Clang, if you so
> desire. Not an awesome solution, but my intuition is that this is an
> uncommon situation in the first place.
>
> >
> >>
> >> You could:
> >> Disable the warning on the command line.
> >> Disable the warning with a pragma.
> >
> >
> > It's an error, not a warning.
>
> I took the original statement to mean "for a Clang build", not "for an
> MSVC build".
>

Ah, that makes more sense.


>
> >
> >>
> >> Cast foo to void inside the lambda.
> >
> >
> > That's equivalent to disabling the clang warning in those cases (which
> would
> > be a shame, since the warning is super useful, and it doesn't introduce
> > problems in most cases -- only with local constexprs). Maybe the warning
> > could be split in two, so that it can be toggled separately for
> constexpr?
>
> While functional, that seems like a lot of work for this case.
>

It's like 4 lines, no?

As I said, I'm not sure it's worth it either. As-is, I think larger cross
platform teams must enable this warning for the reason mentioned above.
Requiring this is a bit of a shame since I think it's a great warning, so I
was hoping we could come up with a way so we could use the warning as well.


> However, the downside to the cast to void is that when MSVC does fix
> the bug, the diagnostic remains silenced in the user's source base.
>
> >
> >>
> >> Only capture foo when building with MSVC.
> >>
> >> Stop building with MSVC.
> >
> >
> > This reply like this make me believe you think it was silly to even
> report
> > this problem. I don't think it's silly, and there's ample precedent in
> clang
> > to make it work well in the actual world instead of in a world we wished
> we
> > lived in.
>
> Definitely not silly to report the problem, but at the same time, that
> precedent is usually reserved for things that affect a significant
> portion of users when the issue boils down to a compiler bug in
> another compiler. How common of a problem is this use case? Does it
> crop up in important header files?
>

It's not super common. Ivan, I think you ran into this twice in all of
Chromium?


>
> ~Aaron
>
> >
> >>
> >> Complain to Microsoft.
> >
> >
> > Already done. The reality is that their shipping compiler produces this
> > diagnostic, and the current 2017 build does too.
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >
>
___
cfe-commits mailing list
cfe-comm

r292839 - [APFloat] Switch from (PPCDoubleDoubleImpl, IEEEdouble) layout to (IEEEdouble, IEEEdouble)

[Tim Shen via cfe-commits]

Author: timshen
Date: Mon Jan 23 16:39:35 2017
New Revision: 292839

URL: http://llvm.org/viewvc/llvm-project?rev=292839&view=rev
Log:
[APFloat] Switch from (PPCDoubleDoubleImpl, IEEEdouble) layout to (IEEEdouble, 
IEEEdouble)

Summary:
This patch changes the layout of DoubleAPFloat, and adjust all
operations to do either:
1) (IEEEdouble, IEEEdouble) -> (uint64_t, uint64_t) -> PPCDoubleDoubleImpl,
   then run the old algorithm.
2) Do the right thing directly.

1) includes multiply, divide, remainder, mod, fusedMultiplyAdd, roundToIntegral,
   convertFromString, next, convertToInteger, convertFromAPInt,
   convertFromSignExtendedInteger, convertFromZeroExtendedInteger,
   convertToHexString, toString, getExactInverse.
2) includes makeZero, makeLargest, makeSmallest, makeSmallestNormalized,
   compare, bitwiseIsEqual, bitcastToAPInt, isDenormal, isSmallest,
   isLargest, isInteger, ilogb, scalbn, frexp, hash_value, Profile.

I could split this into two patches, e.g. use
1) for all operatoins first, then incrementally change some of them to
2). I didn't do that, because 1) involves code that converts data between
PPCDoubleDoubleImpl and (IEEEdouble, IEEEdouble) back and forth, and may
pessimize the compiler. Instead, I find easy functions and use
approach 2) for them directly.

Next step is to implement move multiply and divide from 1) to 2). I don't
have plans for other functions in 1).

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

Modified:
cfe/trunk/test/CodeGen/ppc64-complex-parms.c

Modified: cfe/trunk/test/CodeGen/ppc64-complex-parms.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/ppc64-complex-parms.c?rev=292839&r1=292838&r2=292839&view=diff
==
--- cfe/trunk/test/CodeGen/ppc64-complex-parms.c (original)
+++ cfe/trunk/test/CodeGen/ppc64-complex-parms.c Mon Jan 23 16:39:35 2017
@@ -93,7 +93,7 @@ void bar_long_double(void) {
 // CHECK: %[[VAR22:[A-Za-z0-9.]+]] = getelementptr inbounds { ppc_fp128, 
ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %[[VAR21]], i32 0, i32 0
 // CHECK: %[[VAR23:[A-Za-z0-9.]+]] = getelementptr inbounds { ppc_fp128, 
ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %[[VAR21]], i32 0, i32 1
 // CHECK: store ppc_fp128 0xM4000, ppc_fp128* 
%[[VAR22]]
-// CHECK: store ppc_fp128 0xMC004, ppc_fp128* 
%[[VAR23]]
+// CHECK: store ppc_fp128 0xMC0048000, ppc_fp128* 
%[[VAR23]]
 // CHECK: %[[VAR24:[A-Za-z0-9.]+]] = getelementptr inbounds { ppc_fp128, 
ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %[[VAR21]], i32 0, i32 0
 // CHECK: %[[VAR25:[A-Za-z0-9.]+]] = load ppc_fp128, ppc_fp128* %[[VAR24]], 
align 16
 // CHECK: %[[VAR26:[A-Za-z0-9.]+]] = getelementptr inbounds { ppc_fp128, 
ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %[[VAR21]], i32 0, i32 1


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

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

[Tim Shen via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL292839: [APFloat] Switch from (PPCDoubleDoubleImpl, 
IEEEdouble) layout to (IEEEdouble… (authored by timshen).

Changed prior to commit:
  https://reviews.llvm.org/D27872?vs=85217&id=85457#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D27872

Files:
  cfe/trunk/test/CodeGen/ppc64-complex-parms.c
  llvm/trunk/include/llvm/ADT/APFloat.h
  llvm/trunk/lib/Support/APFloat.cpp
  llvm/trunk/test/CodeGen/PowerPC/fp128-bitcast-after-operation.ll
  llvm/trunk/unittests/ADT/APFloatTest.cpp

Index: cfe/trunk/test/CodeGen/ppc64-complex-parms.c
===
--- cfe/trunk/test/CodeGen/ppc64-complex-parms.c
+++ cfe/trunk/test/CodeGen/ppc64-complex-parms.c
@@ -93,7 +93,7 @@
 // CHECK: %[[VAR22:[A-Za-z0-9.]+]] = getelementptr inbounds { ppc_fp128, ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %[[VAR21]], i32 0, i32 0
 // CHECK: %[[VAR23:[A-Za-z0-9.]+]] = getelementptr inbounds { ppc_fp128, ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %[[VAR21]], i32 0, i32 1
 // CHECK: store ppc_fp128 0xM4000, ppc_fp128* %[[VAR22]]
-// CHECK: store ppc_fp128 0xMC004, ppc_fp128* %[[VAR23]]
+// CHECK: store ppc_fp128 0xMC0048000, ppc_fp128* %[[VAR23]]
 // CHECK: %[[VAR24:[A-Za-z0-9.]+]] = getelementptr inbounds { ppc_fp128, ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %[[VAR21]], i32 0, i32 0
 // CHECK: %[[VAR25:[A-Za-z0-9.]+]] = load ppc_fp128, ppc_fp128* %[[VAR24]], align 16
 // CHECK: %[[VAR26:[A-Za-z0-9.]+]] = getelementptr inbounds { ppc_fp128, ppc_fp128 }, { ppc_fp128, ppc_fp128 }* %[[VAR21]], i32 0, i32 1
Index: llvm/trunk/lib/Support/APFloat.cpp
===
--- llvm/trunk/lib/Support/APFloat.cpp
+++ llvm/trunk/lib/Support/APFloat.cpp
@@ -83,16 +83,26 @@
  and we heavily rely on them having distinct addresses. */
   static const fltSemantics semPPCDoubleDouble = {-1, 0, 0, 0};
 
-  /* There are temporary semantics for the real PPCDoubleDouble implementation.
- Currently, APFloat of PPCDoubleDouble holds one PPCDoubleDoubleImpl as the
- high part of double double, and one IEEEdouble as the low part, so that
- the old operations operate on PPCDoubleDoubleImpl, while the newly added
- operations also populate the IEEEdouble.
-
- TODO: Once all functions support DoubleAPFloat mode, we'll change all
- PPCDoubleDoubleImpl to IEEEdouble and remove PPCDoubleDoubleImpl.  */
-  static const fltSemantics semPPCDoubleDoubleImpl = {1023, -1022 + 53, 53 + 53,
-  128};
+  /* These are legacy semantics for the fallback, inaccrurate implementation of
+ IBM double-double, if the accurate semPPCDoubleDouble doesn't handle the
+ case. It's equivalent to have an IEEE number with consecutive 106 bits of
+ mantissa, and 11 bits of exponent. It's not accurate, becuase the two
+ 53-bit mantissa parts don't actually have to be consecutive,
+ e.g. 1 + epsilon.
+
+ Currently, these semantics are used in the following way:
+
+   (IEEEdouble, IEEEdouble) -> (64-bit APInt, 64-bit APInt) ->
+   (128-bit APInt) -> semPPCDoubleDoubleLegacy -> IEEE operations
+
+ We use bitcastToAPInt() to get the bit representation (in APInt) of the
+ underlying IEEEdouble, then use the APInt constructor to construct the
+ legacy IEEE float.
+
+ TODO: Implement all operations in semPPCDoubleDouble, and delete these
+ semantics.  */
+  static const fltSemantics semPPCDoubleDoubleLegacy = {1023, -1022 + 53,
+53 + 53, 128};
 
   const fltSemantics &APFloatBase::IEEEhalf() {
 return semIEEEhalf;
@@ -862,11 +872,6 @@
 
 IEEEFloat::~IEEEFloat() { freeSignificand(); }
 
-// Profile - This method 'profiles' an APFloat for use with FoldingSet.
-void IEEEFloat::Profile(FoldingSetNodeID &ID) const {
-  ID.Add(bitcastToAPInt());
-}
-
 unsigned int IEEEFloat::partCount() const {
   return partCountForBits(semantics->precision + 1);
 }
@@ -1611,16 +1616,6 @@
   sign = !sign;
 }
 
-void IEEEFloat::clearSign() {
-  /* So is this one. */
-  sign = 0;
-}
-
-void IEEEFloat::copySign(const IEEEFloat &rhs) {
-  /* And this one. */
-  sign = rhs.sign;
-}
-
 /* Normalized addition or subtraction.  */
 IEEEFloat::opStatus IEEEFloat::addOrSubtract(const IEEEFloat &rhs,
  roundingMode rounding_mode,
@@ -1840,7 +1835,7 @@
   IEEEFloat MagicConstant(*semantics);
   fs = MagicConstant.convertFromAPInt(IntegerConstant, false,
   rmNearestTiesToEven);
-  MagicConstant.copySign(*this);
+  MagicConstant.sign = sign;
 
   if (fs != opOK)
 return fs;
@@ -2185,22 +2180,6 @@
   return fs;
 }
 
-/* Same as convertToInteger(integerPart*, ...), except the result is returned i

r292838 - AMDGPU: Update for changed subtarget feature name

[Matt Arsenault via cfe-commits]

Author: arsenm
Date: Mon Jan 23 16:31:14 2017
New Revision: 292838

URL: http://llvm.org/viewvc/llvm-project?rev=292838&view=rev
Log:
AMDGPU: Update for changed subtarget feature name

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/test/CodeGenOpenCL/denorms-are-zero.cl

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=292838&r1=292837&r2=292838&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Mon Jan 23 16:31:14 2017
@@ -2113,15 +2113,15 @@ public:
 for (auto &I : TargetOpts.FeaturesAsWritten) {
   if (I == "+fp32-denormals" || I == "-fp32-denormals")
 hasFP32Denormals = true;
-  if (I == "+fp64-denormals" || I == "-fp64-denormals")
+  if (I == "+fp64-fp16-denormals" || I == "-fp64-fp16-denormals")
 hasFP64Denormals = true;
 }
 if (!hasFP32Denormals)
   TargetOpts.Features.push_back((Twine(hasFullSpeedFP32Denorms &&
   !CGOpts.FlushDenorm ? '+' : '-') + Twine("fp32-denormals")).str());
-// Always do not flush fp64 denorms.
+// Always do not flush fp64 or fp16 denorms.
 if (!hasFP64Denormals && hasFP64)
-  TargetOpts.Features.push_back("+fp64-denormals");
+  TargetOpts.Features.push_back("+fp64-fp16-denormals");
   }
 
   ArrayRef getTargetBuiltins() const override {

Modified: cfe/trunk/test/CodeGenOpenCL/denorms-are-zero.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/denorms-are-zero.cl?rev=292838&r1=292837&r2=292838&view=diff
==
--- cfe/trunk/test/CodeGenOpenCL/denorms-are-zero.cl (original)
+++ cfe/trunk/test/CodeGenOpenCL/denorms-are-zero.cl Mon Jan 23 16:31:14 2017
@@ -1,19 +1,19 @@
 // RUN: %clang_cc1 -S -cl-denorms-are-zero -o - %s 2>&1
 // RUN: %clang_cc1 -emit-llvm -cl-denorms-are-zero -o - -triple amdgcn--amdhsa 
-target-cpu fiji %s | FileCheck %s
 // RUN: %clang_cc1 -emit-llvm -o - -triple amdgcn--amdhsa -target-cpu fiji %s 
| FileCheck %s --check-prefix=CHECK-DENORM
-// RUN: %clang_cc1 -emit-llvm -target-feature +fp32-denormals -target-feature 
-fp64-denormals -cl-denorms-are-zero -o - -triple amdgcn--amdhsa -target-cpu 
fiji %s | FileCheck --check-prefix=CHECK-FEATURE %s
+// RUN: %clang_cc1 -emit-llvm -target-feature +fp32-denormals -target-feature 
-fp64-fp16-denormals -cl-denorms-are-zero -o - -triple amdgcn--amdhsa 
-target-cpu fiji %s | FileCheck --check-prefix=CHECK-FEATURE %s
 
 // For non-amdgcn targets, this test just checks that the -cl-denorms-are-zero 
argument is accepted
 // by clang.  This option is currently a no-op, which is allowed by the
 // OpenCL specification.
 
 // For amdgcn target cpu fiji, fp32 should be flushed since fiji does not 
support fp32 denormals, unless +fp32-denormals is
-// explicitly set. amdgcn target always do not flush fp64 denormals.
+// explicitly set. amdgcn target always do not flush fp64 denormals. The 
control for fp64 and fp16 denormals is the same.
 
 // CHECK-DENORM-LABEL: define void @f()
-// CHECK-DENORM: attributes #{{[0-9]*}} = {{{[^}]*}} 
"target-features"="{{[^"]*}}+fp64-denormals,{{[^"]*}}-fp32-denormals{{[^"]*}}"
+// CHECK-DENORM: attributes #{{[0-9]*}} = {{{[^}]*}} 
"target-features"="{{[^"]*}}+fp64-fp16-denormals,{{[^"]*}}-fp32-denormals{{[^"]*}}"
 // CHECK-LABEL: define void @f()
-// CHECK: attributes #{{[0-9]*}} = {{{[^}]*}} 
"target-features"="{{[^"]*}}+fp64-denormals,{{[^"]*}}-fp32-denormals{{[^"]*}}"
+// CHECK: attributes #{{[0-9]*}} = {{{[^}]*}} 
"target-features"="{{[^"]*}}+fp64-fp16-denormals,{{[^"]*}}-fp32-denormals{{[^"]*}}"
 // CHECK-FEATURE-LABEL: define void @f()
-// CHECK-FEATURE: attributes #{{[0-9]*}} = {{{[^}]*}} 
"target-features"="{{[^"]*}}+fp32-denormals,{{[^"]*}}-fp64-denormals{{[^"]*}}"
+// CHECK-FEATURE: attributes #{{[0-9]*}} = {{{[^}]*}} 
"target-features"="{{[^"]*}}+fp32-denormals,{{[^"]*}}-fp64-fp16-denormals{{[^"]*}}"
 void f() {}


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

[PATCH] D28981: Use GNU-style attributes for several __throw_XXX() functions

[Dimitry Andric via Phabricator via cfe-commits]

dim added a comment.

In https://reviews.llvm.org/D28981#653908, @mclow.lists wrote:

> > In https://reviews.llvm.org/rL279744, __throw_XXX() functions were 
> > introduced, partially for compatibility with software compiled against 
> > libstdc++.
>
> You're working from a false premise.  These functions were not added for 
> compatibility with libstdc++, but rather to encapsulate the mechanism for 
> throwing an exception - to localize the changes needed to support 
> `-fno-exceptions`


Ok, I was mistaken about the premise, but by accident (or by their 
self-evidentness) the names are still shared with the GNU names.  It would be 
nice to have some way of making them semi-compatible.  Alternatively, we could 
rename them, but that would be more churn, I guess.


https://reviews.llvm.org/D28981



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

Re: r291905 - [Sema] Add warning for unused lambda captures

[Aaron Ballman via cfe-commits]

On Mon, Jan 23, 2017 at 5:00 PM, Nico Weber via cfe-commits
 wrote:
> On Sun, Jan 22, 2017 at 6:17 AM, Malcolm Parsons 
> wrote:
>>
>> On 20 January 2017 at 21:32, Nico Weber  wrote:
>> > This warns about code like
>> >
>> >   constexpr int foo = 4;
>> >   [&foo]() { use(foo); }
>> >
>> > That's correct, but removing &foo then makes MSVC complain about this
>> > code
>> > like "error C3493: 'foo' cannot be implicitly captured because no
>> > default
>> > capture mode has been specified". A workaround is to make foo static
>> > const
>> > instead of constexpr.
>> >
>> > This seems like an MSVC bug, but it's still a bit annoying that clang
>> > now
>> > suggests doing things that won't build in other compilers. Any ideas
>> > what to
>> > do about this?
>>
>> Should Clang care about the behaviour of other compilers that don't
>> follow the standard?
>
>
> clang should be a compiler that people like to use. Multi-platform
> development isn't super uncommon, so trying to give a good experience in
> that case seems like a good thing to me -- and we've tried to do that in the
> past pretty hard. It's possible that "do nothing" is the right thing, but
> "well that other compiler is buggy" seems like a somewhat oversimplified
> reply.

We generally don't try to be bug-for-bug compatible with other
compilers unless the bug is sufficiently important (like it is relied
upon in system headers, for instance). In this case, I think the bug
in MSVC is annoying, but not the end of the world because it's trivial
to workaround in a compiler-agnostic way without disabling the
diagnostic everywhere in Clang. You can leave the capture in place to
appease MSVC and cast the use to void to appease Clang, if you so
desire. Not an awesome solution, but my intuition is that this is an
uncommon situation in the first place.

>
>>
>> You could:
>> Disable the warning on the command line.
>> Disable the warning with a pragma.
>
>
> It's an error, not a warning.

I took the original statement to mean "for a Clang build", not "for an
MSVC build".

>
>>
>> Cast foo to void inside the lambda.
>
>
> That's equivalent to disabling the clang warning in those cases (which would
> be a shame, since the warning is super useful, and it doesn't introduce
> problems in most cases -- only with local constexprs). Maybe the warning
> could be split in two, so that it can be toggled separately for constexpr?

While functional, that seems like a lot of work for this case.
However, the downside to the cast to void is that when MSVC does fix
the bug, the diagnostic remains silenced in the user's source base.

>
>>
>> Only capture foo when building with MSVC.
>>
>> Stop building with MSVC.
>
>
> This reply like this make me believe you think it was silly to even report
> this problem. I don't think it's silly, and there's ample precedent in clang
> to make it work well in the actual world instead of in a world we wished we
> lived in.

Definitely not silly to report the problem, but at the same time, that
precedent is usually reserved for things that affect a significant
portion of users when the issue boils down to a compiler bug in
another compiler. How common of a problem is this use case? Does it
crop up in important header files?

~Aaron

>
>>
>> Complain to Microsoft.
>
>
> Already done. The reality is that their shipping compiler produces this
> diagnostic, and the current 2017 build does too.
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Eric Christopher via Phabricator via cfe-commits]

echristo added a comment.

Hal has given an ack (offline) as well. Go ahead Tim.


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] D22057: Prevent devirtualization of calls to un-instantiated functions.

[Sunil Srivastava via Phabricator via cfe-commits]

Sunil_Srivastava added a comment.

Ping


https://reviews.llvm.org/D22057



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

Re: [clang-tools-extra] r291892 - Fix the build of the include-fixer plugin for some shared cmake builds and MSVC.

[Hans Wennborg via cfe-commits]

I've merged this to the release branch in r292834.

Thanks,
Hans

On Fri, Jan 13, 2017 at 2:14 AM, Benjamin Kramer via cfe-commits
 wrote:
> Author: d0k
> Date: Fri Jan 13 04:14:07 2017
> New Revision: 291892
>
> URL: http://llvm.org/viewvc/llvm-project?rev=291892&view=rev
> Log:
> Fix the build of the include-fixer plugin for some shared cmake builds and 
> MSVC.
>
> - The include fixer plugin does not directly depend on pthread, but can
> pick up pthread references transitively through inlining. Just add
> pthreads to the linked libs unconditionally.
> - MSVC emits bogus warnings when including  and building without
> exceptions. Blacklist the warnings explicitly.
>
> Modified:
> clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
> clang-tools-extra/trunk/include-fixer/plugin/CMakeLists.txt
>
> Modified: clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h?rev=291892&r1=291891&r2=291892&view=diff
> ==
> --- clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h (original)
> +++ clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h Fri Jan 13 
> 04:14:07 2017
> @@ -13,8 +13,19 @@
>  #include "SymbolIndex.h"
>  #include "find-all-symbols/SymbolInfo.h"
>  #include "llvm/ADT/StringRef.h"
> +
> +#ifdef _MSC_VER
> +// Disable warnings from ppltasks.h transitively included by .
> +#pragma warning(push)
> +#pragma warning(disable:4530)
> +#endif
> +
>  #include 
>
> +#ifdef _MSC_VER
> +#pragma warning(pop)
> +#endif
> +
>  namespace clang {
>  namespace include_fixer {
>
>
> Modified: clang-tools-extra/trunk/include-fixer/plugin/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/plugin/CMakeLists.txt?rev=291892&r1=291891&r2=291892&view=diff
> ==
> --- clang-tools-extra/trunk/include-fixer/plugin/CMakeLists.txt (original)
> +++ clang-tools-extra/trunk/include-fixer/plugin/CMakeLists.txt Fri Jan 13 
> 04:14:07 2017
> @@ -9,4 +9,5 @@ add_clang_library(clangIncludeFixerPlugi
>clangParse
>clangSema
>clangTooling
> +  ${PTHREAD_LIB}
>)
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28981: Use GNU-style attributes for several __throw_XXX() functions

[Marshall Clow via Phabricator via cfe-commits]

mclow.lists added a comment.

> In https://reviews.llvm.org/rL279744, __throw_XXX() functions were 
> introduced, partially for compatibility with software compiled against 
> libstdc++.

You're working from a false premise.  These functions were not added for 
compatibility with libstdc++, but rather to encapsulate the mechanism for 
throwing an exception - to localize the changes needed to support 
`-fno-exceptions`


https://reviews.llvm.org/D28981



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

Re: [libcxx] r291961 - Add _LIBCPP_DIAGNOSE_WARNING and _LIBCPP_DIAGNOSE_ERROR macros.

[Eric Fiselier via cfe-commits]

My dream, and something I would like to work towards is supporting
something like this:

> [[clang::libcxx_diagnose_if(cond, "message", "warning", /* warning-id*/
"non-const-functor")]]
>
> -Wno-libcxx-warnings=non-const-functor

This way libc++ warnings get treated differently from all other users of
diagnose_if, and can be enabled
and disabled separately.

@George does this sound like a reasonable goal? If so I'm happy to start
working on this.

/Eric


On Mon, Jan 23, 2017 at 11:46 AM, George Burgess  wrote:

> The only plan that we have at the moment is basically for a
> -Wno-user-defined-warnings-in-system-headers type of flag. I agree that
> it would be nice if we could be more granular than this, so I'll think
> about what we can do.
>
> On Mon, Jan 23, 2017 at 8:36 AM, Nico Weber  wrote:
>
>> This happens to fire in practice in protobuf. It's probably a true
>> positive and it's cool that this warning found it, but it means we have to
>> disable Wuser-defined-warnings for a bit -- which then disables all of
>> these user-defined warnings. Right now there aren't any others, but it
>> feels like we'd want to have the ability to turn individual user-defined
>> warnings on or off instead of just having a single toggle for all of them.
>> Are there plans for something like that?
>>
>> On Fri, Jan 13, 2017 at 5:02 PM, Eric Fiselier via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: ericwf
>>> Date: Fri Jan 13 16:02:08 2017
>>> New Revision: 291961
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=291961&view=rev
>>> Log:
>>> Add _LIBCPP_DIAGNOSE_WARNING and _LIBCPP_DIAGNOSE_ERROR macros.
>>>
>>> Clang recently added a `diagnose_if(cond, msg, type)` attribute
>>> which can be used to generate diagnostics when `cond` is a constant
>>> expression that evaluates to true. Otherwise no attribute has no
>>> effect.
>>>
>>> This patch adds _LIBCPP_DIAGNOSE_ERROR/WARNING macros which
>>> use this new attribute. Additionally this patch implements
>>> a diagnostic message when a non-const-callable comparator is
>>> given to a container.
>>>
>>> Note: For now the warning version of the diagnostic is useless
>>> within libc++ since warning diagnostics are suppressed by the
>>> system header pragma. I'm going to work on fixing this.
>>>
>>> Added:
>>> libcxx/trunk/test/libcxx/containers/associative/non_const_co
>>> mparator.fail.cpp
>>> Modified:
>>> libcxx/trunk/docs/UsingLibcxx.rst
>>> libcxx/trunk/include/__config
>>> libcxx/trunk/include/__tree
>>> libcxx/trunk/include/map
>>> libcxx/trunk/include/type_traits
>>> libcxx/trunk/test/libcxx/compiler.py
>>> libcxx/trunk/test/libcxx/test/config.py
>>> libcxx/trunk/test/libcxx/test/format.py
>>> libcxx/trunk/test/libcxx/utilities/tuple/tuple.tuple/diagnos
>>> e_reference_binding.fail.cpp
>>>
>>> Modified: libcxx/trunk/docs/UsingLibcxx.rst
>>> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/UsingL
>>> ibcxx.rst?rev=291961&r1=291960&r2=291961&view=diff
>>> 
>>> ==
>>> --- libcxx/trunk/docs/UsingLibcxx.rst (original)
>>> +++ libcxx/trunk/docs/UsingLibcxx.rst Fri Jan 13 16:02:08 2017
>>> @@ -173,3 +173,10 @@ thread safety annotations.
>>>return Tup{"hello world", 42}; // explicit constructor called. OK.
>>>  }
>>>
>>> +**_LIBCPP_DISABLE_ADDITIONAL_DIAGNOSTICS**:
>>> +  This macro disables the additional diagnostics generated by libc++
>>> using the
>>> +  `diagnose_if` attribute. These additional diagnostics include checks
>>> for:
>>> +
>>> +* Giving `set`, `map`, `multiset`, `multimap` a comparator which is
>>> not
>>> +  const callable.
>>> +
>>>
>>> Modified: libcxx/trunk/include/__config
>>> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__c
>>> onfig?rev=291961&r1=291960&r2=291961&view=diff
>>> 
>>> ==
>>> --- libcxx/trunk/include/__config (original)
>>> +++ libcxx/trunk/include/__config Fri Jan 13 16:02:08 2017
>>> @@ -1006,6 +1006,16 @@ _LIBCPP_FUNC_VIS extern "C" void __sanit
>>>  #endif
>>>  #endif
>>>
>>> +#if __has_attribute(diagnose_if) && !defined(_LIBCPP_DISABLE_ADDIT
>>> IONAL_DIAGNOSTICS)
>>> +# define _LIBCPP_DIAGNOSE_WARNING(...) \
>>> +__attribute__((__diagnose_if__(__VA_ARGS__, "warning")))
>>> +# define _LIBCPP_DIAGNOSE_ERROR(...) \
>>> +__attribute__((__diagnose_if__(__VA_ARGS__, "error")))
>>> +#else
>>> +# define _LIBCPP_DIAGNOSE_WARNING(...)
>>> +# define _LIBCPP_DIAGNOSE_ERROR(...)
>>> +#endif
>>> +
>>>  #endif // __cplusplus
>>>
>>>  #endif // _LIBCPP_CONFIG
>>>
>>> Modified: libcxx/trunk/include/__tree
>>> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__t
>>> ree?rev=291961&r1=291960&r2=291961&view=diff
>>> 
>>> ==
>>> --- libcxx/trunk/include/__tree (original)
>>> +++ libcxx/trunk/include/_

Re: [libcxx] r292822 - Fixed a typo in __config that prevented the aligned new/delete tests from passing on Mac OS.

[Hans Wennborg via cfe-commits]

Ok, go ahead.

On Mon, Jan 23, 2017 at 1:54 PM, Eric Fiselier  wrote:
> This patch needs to get merged into 4.0 since the offending commit with the
> misspelling is in the 4.0 branch.
>
> /Eric
>
>
> On Mon, Jan 23, 2017 at 12:51 PM, Marshall Clow via cfe-commits
>  wrote:
>>
>> Author: marshall
>> Date: Mon Jan 23 13:51:54 2017
>> New Revision: 292822
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=292822&view=rev
>> Log:
>> Fixed a typo in __config that prevented the aligned new/delete tests from
>> passing on Mac OS.
>>
>> Modified:
>> libcxx/trunk/include/__config
>>
>> Modified: libcxx/trunk/include/__config
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=292822&r1=292821&r2=292822&view=diff
>>
>> ==
>> --- libcxx/trunk/include/__config (original)
>> +++ libcxx/trunk/include/__config Mon Jan 23 13:51:54 2017
>> @@ -851,7 +851,7 @@ template  struct __static_asse
>>  #if defined(__APPLE__)
>>  # if !defined(__MAC_OS_X_VERSION_MIN_REQUIRED) && \
>>   defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__)
>> -#   define __MAC_OS_X_VERSION_MIN_REQUIRED
>> __ENVIROMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
>> +#   define __MAC_OS_X_VERSION_MIN_REQUIRED
>> __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
>>  # endif
>>  # if defined(__MAC_OS_X_VERSION_MIN_REQUIRED)
>>  #   if __MAC_OS_X_VERSION_MIN_REQUIRED < 1060
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added a comment.

@dim I would really rather just suppress these warnings if we want them merged 
into 4.0.


https://reviews.llvm.org/D28520



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

Re: r291905 - [Sema] Add warning for unused lambda captures

[Nico Weber via cfe-commits]

On Sun, Jan 22, 2017 at 6:17 AM, Malcolm Parsons 
wrote:

> On 20 January 2017 at 21:32, Nico Weber  wrote:
> > This warns about code like
> >
> >   constexpr int foo = 4;
> >   [&foo]() { use(foo); }
> >
> > That's correct, but removing &foo then makes MSVC complain about this
> code
> > like "error C3493: 'foo' cannot be implicitly captured because no default
> > capture mode has been specified". A workaround is to make foo static
> const
> > instead of constexpr.
> >
> > This seems like an MSVC bug, but it's still a bit annoying that clang now
> > suggests doing things that won't build in other compilers. Any ideas
> what to
> > do about this?
>
> Should Clang care about the behaviour of other compilers that don't
> follow the standard?
>

clang should be a compiler that people like to use. Multi-platform
development isn't super uncommon, so trying to give a good experience in
that case seems like a good thing to me -- and we've tried to do that in
the past pretty hard. It's possible that "do nothing" is the right thing,
but "well that other compiler is buggy" seems like a somewhat
oversimplified reply.


> You could:
> Disable the warning on the command line.
> Disable the warning with a pragma.
>

It's an error, not a warning.


> Cast foo to void inside the lambda.
>

That's equivalent to disabling the clang warning in those cases (which
would be a shame, since the warning is super useful, and it doesn't
introduce problems in most cases -- only with local constexprs). Maybe the
warning could be split in two, so that it can be toggled separately for
constexpr?


> Only capture foo when building with MSVC.

Stop building with MSVC.
>

This reply like this make me believe you think it was silly to even report
this problem. I don't think it's silly, and there's ample precedent in
clang to make it work well in the actual world instead of in a world we
wished we lived in.


> Complain to Microsoft.
>

Already done. The reality is that their shipping compiler produces this
diagnostic, and the current 2017 build does too.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r292833 - Manually force the use of __decltype in C++03 with Clang 3.4.

[Eric Fiselier via cfe-commits]

This patch should be merge into 4.0 since it is needed to fix compile time
regressions in  when using Clang 3.4 and C++03.

See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216054 for more info.

/Eric

On Mon, Jan 23, 2017 at 2:41 PM, Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ericwf
> Date: Mon Jan 23 15:41:13 2017
> New Revision: 292833
>
> URL: http://llvm.org/viewvc/llvm-project?rev=292833&view=rev
> Log:
> Manually force the use of __decltype in C++03 with Clang 3.4.
>
>  uses `decltype` in a way incompatible with `__typeof__`.
> This is problematic when compiling  with Clang 3.4 because
> even though it provides `__decltype` libc++ still used `__typeof__`
> because clang 3.4 doesn't provide __is_identifier which libc++
> uses to detect __decltype.
>
> This patch manually detects Clang 3.4 and properly configures
> for it.
>
> Modified:
> libcxx/trunk/include/__config
>
> Modified: libcxx/trunk/include/__config
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/_
> _config?rev=292833&r1=292832&r2=292833&view=diff
> 
> ==
> --- libcxx/trunk/include/__config (original)
> +++ libcxx/trunk/include/__config Mon Jan 23 15:41:13 2017
> @@ -109,6 +109,9 @@
>
>  #if defined(__clang__)
>  #define _LIBCPP_COMPILER_CLANG
> +# ifndef __apple_build_version__
> +#   define _LIBCPP_CLANG_VER (__clang_major__ * 100 + __clang_minor__)
> +# endif
>  #elif defined(__GNUC__)
>  #define _LIBCPP_COMPILER_GCC
>  #elif defined(_MSC_VER)
> @@ -117,6 +120,10 @@
>  #define _LIBCPP_COMPILER_IBM
>  #endif
>
> +#ifndef _LIBCPP_CLANG_VER
> +#define _LIBCPP_CLANG_VER 0
> +#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.
> @@ -754,7 +761,7 @@ template  struct __static_asse
>
>  #ifdef _LIBCPP_HAS_NO_DECLTYPE
>  // GCC 4.6 provides __decltype in all standard modes.
> -#if __has_keyword(__decltype) || _GNUC_VER >= 406
> +#if __has_keyword(__decltype) || _LIBCPP_CLANG_VER >= 304 || _GNUC_VER >=
> 406
>  #  define decltype(__x) __decltype(__x)
>  #else
>  #  define decltype(__x) __typeof__(__x)
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r292822 - Fixed a typo in __config that prevented the aligned new/delete tests from passing on Mac OS.

[Eric Fiselier via cfe-commits]

This patch needs to get merged into 4.0 since the offending commit with the
misspelling is in the 4.0 branch.

/Eric

On Mon, Jan 23, 2017 at 12:51 PM, Marshall Clow via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: marshall
> Date: Mon Jan 23 13:51:54 2017
> New Revision: 292822
>
> URL: http://llvm.org/viewvc/llvm-project?rev=292822&view=rev
> Log:
> Fixed a typo in __config that prevented the aligned new/delete tests from
> passing on Mac OS.
>
> Modified:
> libcxx/trunk/include/__config
>
> Modified: libcxx/trunk/include/__config
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__
> config?rev=292822&r1=292821&r2=292822&view=diff
> 
> ==
> --- libcxx/trunk/include/__config (original)
> +++ libcxx/trunk/include/__config Mon Jan 23 13:51:54 2017
> @@ -851,7 +851,7 @@ template  struct __static_asse
>  #if defined(__APPLE__)
>  # if !defined(__MAC_OS_X_VERSION_MIN_REQUIRED) && \
>   defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__)
> -#   define __MAC_OS_X_VERSION_MIN_REQUIRED __ENVIROMENT_MAC_OS_X_VERSION_
> MIN_REQUIRED__
> +#   define __MAC_OS_X_VERSION_MIN_REQUIRED __ENVIRONMENT_MAC_OS_X_VERSION
> _MIN_REQUIRED__
>  # endif
>  # if defined(__MAC_OS_X_VERSION_MIN_REQUIRED)
>  #   if __MAC_OS_X_VERSION_MIN_REQUIRED < 1060
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r292830 - Fix GCC C++03 build by hiding default template argument in C++03

[Hans Wennborg via cfe-commits]

We merged the first one, so I suppose we better fix it :-)

Sounds good to me.

On Mon, Jan 23, 2017 at 1:37 PM, Eric Fiselier  wrote:
> This patch should be merge into the 4.0 branch.
>
> It fixes a bug introduced to the 4.0 branch in r292354
> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216054).
>
> /Eric
>
> On Mon, Jan 23, 2017 at 2:24 PM, Eric Fiselier via cfe-commits
>  wrote:
>>
>> Author: ericwf
>> Date: Mon Jan 23 15:24:58 2017
>> New Revision: 292830
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=292830&view=rev
>> Log:
>> Fix GCC C++03 build by hiding default template argument in C++03
>>
>> Modified:
>> libcxx/trunk/include/string
>>
>> Modified: libcxx/trunk/include/string
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/string?rev=292830&r1=292829&r2=292830&view=diff
>>
>> ==
>> --- libcxx/trunk/include/string (original)
>> +++ libcxx/trunk/include/string Mon Jan 23 15:24:58 2017
>> @@ -818,7 +818,10 @@ public:
>>  operator __self_view() const _NOEXCEPT { return __self_view(data(),
>> size()); }
>>
>>  basic_string& operator=(const basic_string& __str);
>> +
>> +#ifndef _LIBCPP_CXX03_LANG
>>  template 
>> +#endif
>>  _LIBCPP_INLINE_VISIBILITY
>>  basic_string& operator=(__self_view __sv)  {return assign(__sv);}
>>  #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r292833 - Manually force the use of __decltype in C++03 with Clang 3.4.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Mon Jan 23 15:41:13 2017
New Revision: 292833

URL: http://llvm.org/viewvc/llvm-project?rev=292833&view=rev
Log:
Manually force the use of __decltype in C++03 with Clang 3.4.

 uses `decltype` in a way incompatible with `__typeof__`.
This is problematic when compiling  with Clang 3.4 because
even though it provides `__decltype` libc++ still used `__typeof__`
because clang 3.4 doesn't provide __is_identifier which libc++
uses to detect __decltype.

This patch manually detects Clang 3.4 and properly configures
for it.

Modified:
libcxx/trunk/include/__config

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=292833&r1=292832&r2=292833&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Mon Jan 23 15:41:13 2017
@@ -109,6 +109,9 @@
 
 #if defined(__clang__)
 #define _LIBCPP_COMPILER_CLANG
+# ifndef __apple_build_version__
+#   define _LIBCPP_CLANG_VER (__clang_major__ * 100 + __clang_minor__)
+# endif
 #elif defined(__GNUC__)
 #define _LIBCPP_COMPILER_GCC
 #elif defined(_MSC_VER)
@@ -117,6 +120,10 @@
 #define _LIBCPP_COMPILER_IBM
 #endif
 
+#ifndef _LIBCPP_CLANG_VER
+#define _LIBCPP_CLANG_VER 0
+#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.
@@ -754,7 +761,7 @@ template  struct __static_asse
 
 #ifdef _LIBCPP_HAS_NO_DECLTYPE
 // GCC 4.6 provides __decltype in all standard modes.
-#if __has_keyword(__decltype) || _GNUC_VER >= 406
+#if __has_keyword(__decltype) || _LIBCPP_CLANG_VER >= 304 || _GNUC_VER >= 406
 #  define decltype(__x) __decltype(__x)
 #else
 #  define decltype(__x) __typeof__(__x)


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

Re: r292800 - [analyzer] Fix memory space of static locals seen from nested blocks.

[Hans Wennborg via cfe-commits]

Sounds good to me.

Anna, you're the code owner here. Ok to merge this?

Thanks,
Hans

On Mon, Jan 23, 2017 at 10:37 AM, Artem Dergachev  wrote:
> Hans,
>
> Could we merge this one into the 4.0.0 release branch? It's a recent bugfix
> for the analyzer.
>
> Thanks,
> Artem.
>
>
>
> On 1/23/17 7:57 PM, Artem Dergachev via cfe-commits wrote:
>>
>> Author: dergachev
>> Date: Mon Jan 23 10:57:11 2017
>> New Revision: 292800
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=292800&view=rev
>> Log:
>> [analyzer] Fix memory space of static locals seen from nested blocks.
>>
>> When a block within a function accesses a function's static local
>> variable,
>> this local is captured by reference rather than copied to the heap.
>>
>> Therefore this variable's memory space is known: StaticGlobalSpaceRegion.
>> Used to be UnknownSpaceRegion, same as for stack locals.
>>
>> Fixes a false positive in MacOSXAPIChecker.
>>
>> rdar://problem/30105546
>> Differential revision: https://reviews.llvm.org/D28946
>>
>> Modified:
>>  cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
>>  cfe/trunk/test/Analysis/dispatch-once.m
>>
>> Modified: cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp?rev=292800&r1=292799&r2=292800&view=diff
>>
>> ==
>> --- cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp (original)
>> +++ cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp Mon Jan 23 10:57:11
>> 2017
>> @@ -776,6 +776,22 @@ getStackOrCaptureRegionForDeclContext(co
>> return (const StackFrameContext *)nullptr;
>>   }
>>   +static CanQualType getBlockPointerType(const BlockDecl *BD, ASTContext
>> &C) {
>> +  // FIXME: The fallback type here is totally bogus -- though it should
>> +  // never be queried, it will prevent uniquing with the real
>> +  // BlockCodeRegion. Ideally we'd fix the AST so that we always had a
>> +  // signature.
>> +  QualType T;
>> +  if (const TypeSourceInfo *TSI = BD->getSignatureAsWritten())
>> +T = TSI->getType();
>> +  if (T.isNull())
>> +T = C.VoidTy;
>> +  if (!T->getAs())
>> +T = C.getFunctionNoProtoType(T);
>> +  T = C.getBlockPointerType(T);
>> +  return C.getCanonicalType(T);
>> +}
>> +
>>   const VarRegion* MemRegionManager::getVarRegion(const VarDecl *D,
>>   const LocationContext
>> *LC) {
>> const MemRegion *sReg = nullptr;
>> @@ -803,7 +819,7 @@ const VarRegion* MemRegionManager::getVa
>>   sReg = getGlobalsRegion();
>>   }
>>   -  // Finally handle static locals.
>> +  // Finally handle locals.
>> } else {
>>   // FIXME: Once we implement scope handling, we will need to properly
>> lookup
>>   // 'D' to the proper LocationContext.
>> @@ -816,9 +832,22 @@ const VarRegion* MemRegionManager::getVa
>> const StackFrameContext *STC = V.get();
>>   -if (!STC)
>> -  sReg = getUnknownRegion();
>> -else {
>> +if (!STC) {
>> +  if (D->isStaticLocal()) {
>> +const CodeTextRegion *fReg = nullptr;
>> +if (const auto *ND = dyn_cast(DC))
>> +  fReg = getFunctionCodeRegion(ND);
>> +else if (const auto *BD = dyn_cast(DC))
>> +  fReg = getBlockCodeRegion(BD, getBlockPointerType(BD,
>> getContext()),
>> +LC->getAnalysisDeclContext());
>> +assert(fReg && "Unable to determine code region for a static
>> local!");
>> +sReg = getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,
>> fReg);
>> +  } else {
>> +// We're looking at a block-captured local variable, which may be
>> either
>> +// still local, or already moved to the heap. So we're not sure.
>> +sReg = getUnknownRegion();
>> +  }
>> +} else {
>> if (D->hasLocalStorage()) {
>>   sReg = isa(D) || isa(D)
>>  ? static_cast> MemRegion*>(getStackArgumentsRegion(STC))
>> @@ -831,22 +860,9 @@ const VarRegion* MemRegionManager::getVa
>> sReg =
>> getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,
>>
>> getFunctionCodeRegion(cast(STCD)));
>>   else if (const BlockDecl *BD = dyn_cast(STCD)) {
>> -  // FIXME: The fallback type here is totally bogus -- though it
>> should
>> -  // never be queried, it will prevent uniquing with the real
>> -  // BlockCodeRegion. Ideally we'd fix the AST so that we always
>> had a
>> -  // signature.
>> -  QualType T;
>> -  if (const TypeSourceInfo *TSI = BD->getSignatureAsWritten())
>> -T = TSI->getType();
>> -  if (T.isNull())
>> -T = getContext().VoidTy;
>> -  if (!T->getAs())
>> -T = getContext().getFunctionNoProtoType(T);
>> -  T = getContext().getBlockPointerType(T);
>> -
>> const BlockCodeRegion *BTR =
>> -getBlockCodeRegion(BD, C.getCanonica

Re: [libcxx] r292830 - Fix GCC C++03 build by hiding default template argument in C++03

[Eric Fiselier via cfe-commits]

This patch should be merge into the 4.0 branch.

It fixes a bug introduced to the 4.0 branch in r292354 (
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216054).

/Eric

On Mon, Jan 23, 2017 at 2:24 PM, Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ericwf
> Date: Mon Jan 23 15:24:58 2017
> New Revision: 292830
>
> URL: http://llvm.org/viewvc/llvm-project?rev=292830&view=rev
> Log:
> Fix GCC C++03 build by hiding default template argument in C++03
>
> Modified:
> libcxx/trunk/include/string
>
> Modified: libcxx/trunk/include/string
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/
> string?rev=292830&r1=292829&r2=292830&view=diff
> 
> ==
> --- libcxx/trunk/include/string (original)
> +++ libcxx/trunk/include/string Mon Jan 23 15:24:58 2017
> @@ -818,7 +818,10 @@ public:
>  operator __self_view() const _NOEXCEPT { return __self_view(data(),
> size()); }
>
>  basic_string& operator=(const basic_string& __str);
> +
> +#ifndef _LIBCPP_CXX03_LANG
>  template 
> +#endif
>  _LIBCPP_INLINE_VISIBILITY
>  basic_string& operator=(__self_view __sv)  {return assign(__sv);}
>  #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r292830 - Fix GCC C++03 build by hiding default template argument in C++03

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Mon Jan 23 15:24:58 2017
New Revision: 292830

URL: http://llvm.org/viewvc/llvm-project?rev=292830&view=rev
Log:
Fix GCC C++03 build by hiding default template argument in C++03

Modified:
libcxx/trunk/include/string

Modified: libcxx/trunk/include/string
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/string?rev=292830&r1=292829&r2=292830&view=diff
==
--- libcxx/trunk/include/string (original)
+++ libcxx/trunk/include/string Mon Jan 23 15:24:58 2017
@@ -818,7 +818,10 @@ public:
 operator __self_view() const _NOEXCEPT { return __self_view(data(), 
size()); }
 
 basic_string& operator=(const basic_string& __str);
+
+#ifndef _LIBCPP_CXX03_LANG
 template 
+#endif
 _LIBCPP_INLINE_VISIBILITY
 basic_string& operator=(__self_view __sv)  {return assign(__sv);}
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES


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

[PATCH] D27800: Add overload of TransformToPotentiallyEvaluated for TypeSourceInfo

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: lib/Sema/SemaExpr.cpp:4031
   // C99 6.5.3.4p4: the type (an unsigned integer type) is size_t.
+  if (isUnevaluatedContext() && ExprKind == UETT_SizeOf &&
+  TInfo->getType()->isVariablyModifiedType())

Is the isUnevaluatedContext() check here necessary?



Comment at: test/SemaCXX/pr31042.cpp:1
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -emit-obj 
-disable-free %s
+

-emit-obj ?



Comment at: test/SemaCXX/pr31042.cpp:3
+
+extern void abort (void);
+

Is this declaration necessary somehow?


https://reviews.llvm.org/D27800



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

[PATCH] D26110: Add a check for GCC to the _LIBCPP_EXPLICIT define

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added a comment.

I think I may have committed these changes as part of another change set.


https://reviews.llvm.org/D26110



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

[PATCH] D28526: [ARM] Add diagnostics when initialization global variables with ropi/rwpi

[Weiming Zhao via Phabricator via cfe-commits]

weimingz updated this revision to Diff 85446.
weimingz edited the summary of this revision.
weimingz added a comment.

As Eli sugguested, it's better to check it in Sema. In order to access 
RelocationModel in Sema, we moved it from CodeGenOpts to LangOpts


https://reviews.llvm.org/D28526

Files:
  include/clang/Basic/LangOptions.def
  include/clang/Basic/LangOptions.h
  include/clang/Frontend/CodeGenOptions.h
  lib/AST/ExprConstant.cpp
  lib/CodeGen/BackendUtil.cpp
  lib/Frontend/CodeGenOptions.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGen/arm-ropi-rwpi.c
  test/Sema/ropi-rwpi.c

Index: test/Sema/ropi-rwpi.c
===
--- /dev/null
+++ test/Sema/ropi-rwpi.c
@@ -0,0 +1,65 @@
+// OK with local initialization, rwpi with const gv and ropi with non-const gv.
+// RUN: %clang_cc1 -triple armv7 -DDEFAULT -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple armv7 -DROPI -mrelocation-model ropi -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple armv7 -DRWPI -mrelocation-model rwpi -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple armv7 -DROPI -DRWPI -mrelocation-model ropi-rwpi -fsyntax-only -verify %s
+
+extern int func(const int* const []);
+
+extern int gv;
+extern const int c_gv;
+
+void *p1 = &func;
+const void *p2 = &c_gv;
+const int *p_compound_literal_c = &(const int){1};
+
+void ropi_test() {
+  static void *sp1 = &func;
+  static const void *sp2 = &c_gv;
+  static char(*x)[7] = &"abcdef";
+  static const void *x2 = &__func__;
+  static const int *const arr[2] = {&c_gv, &c_gv};
+  static void *addr = &&label1;
+label1:
+  return;
+}
+
+void *p3 = &gv;
+int *p_compound_literal = &(int){1};
+
+void rwpi_test() {
+  static void *sp1 = &gv;
+  static int *const arr[2] = {&gv, &gv};
+}
+
+unsigned test() {
+  unsigned a = (unsigned)&func;
+  unsigned b = (unsigned)&gv;
+  unsigned c = (unsigned)&c_gv;
+  return a + b + c;
+}
+
+#ifdef DEFAULT
+// expected-no-diagnostics
+#endif
+
+#if defined(ROPI)
+// expected-error@12 {{initializer element is not a compile-time constant}}
+// expected-error@13 {{initializer element is not a compile-time constant}}
+// expected-error@14 {{initializer element is not a compile-time constant}}
+
+// expected-error@17 {{initializer element is not a compile-time constant}}
+// expected-error@18 {{initializer element is not a compile-time constant}}
+// expected-error@19 {{initializer element is not a compile-time constant}}
+// expected-error@20 {{initializer element is not a compile-time constant}}
+// expected-error@21 {{initializer element is not a compile-time constant}}
+// expected-error@22 {{initializer element is not a compile-time constant}}
+#endif
+
+#if defined(RWPI)
+// expected-error@27 {{initializer element is not a compile-time constant}}
+// expected-error@28 {{initializer element is not a compile-time constant}}
+
+// expected-error@31 {{initializer element is not a compile-time constant}}
+// expected-error@32 {{initializer element is not a compile-time constant}}
+#endif
Index: test/CodeGen/arm-ropi-rwpi.c
===
--- /dev/null
+++ test/CodeGen/arm-ropi-rwpi.c
@@ -0,0 +1,32 @@
+// REQUIRES: arm-registered-target
+
+// Below tests check if memcpy is not generated with ropi/rwpi for local var initialization.
+// RUN: %clang_cc1 -triple armv7 -S -emit-llvm -o - %s | FileCheck %s --check-prefix=DEFAULT
+// RUN: %clang_cc1 -triple armv7 -S -emit-llvm -mrelocation-model ropi  -o - %s | FileCheck %s --check-prefix=ROPI
+// RUN: %clang_cc1 -triple armv7 -S -emit-llvm -mrelocation-model rwpi  -o - %s | FileCheck %s --check-prefix=RWPI
+// RUN: %clang_cc1 -triple armv7 -S -emit-llvm -mrelocation-model ropi-rwpi  -o - %s | FileCheck %s --check-prefix=ROPI_RWPI
+
+extern int gv;
+extern const int c_gv;
+
+void test_local() {
+// DEFAULT-LABEL: @test_local
+// DEFAULT: call void @{{llvm.memcpy.*@test_local.x}}
+// DEFAULT: call void @{{llvm.memcpy.*@test_local.y}}
+
+// ROPI-LABEL: @test_local
+// ROPI: call void @{{llvm.memcpy.*@test_local.x}}
+// ROPI-NOT: call void@llvm.memcpy
+
+// RWPI-LABEL: @test_local
+// RWPI-NOT: call void@{{llvm.memcpy.*@test_local.x}}
+// RWPI: call void @{{llvm.memcpy.*@test_local.y}}
+
+// ROPI_RWPI-LABEL: @test_local
+// ROPI_RWPI-NOT: call void @llvm.memcpy
+
+  const int *x[] = {&gv, &gv, &gv}; // This is OK, no diagnostic.
+  func(x);
+  const int *y[] = {&c_gv, &c_gv, &c_gv}; // This is OK, no diagnostic.
+  func(y);
+}
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -610,7 +610,6 @@
   Args.hasArg(OPT_cl_unsafe_math_optimizations) ||
   Args.hasArg(OPT_cl_fast_relaxed_math);
   Opts.UnwindTables = Args.hasArg(OPT_munwind_tables);
-  Opts.RelocationModel = Args.getLastArgValue(OPT_mrelocation_model, "pic");
   Opts.ThreadMod

[PATCH] D27680: [CodeGen] Move lifetime.start of a variable when goto jumps back past its declaration

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: lib/CodeGen/CodeGenFunction.h:217
+  /// statements.
+  llvm::SmallVector LabelSeenStack;
+

Shouldn't this be maintained by some existing scoping structure like 
LexicalScope?



Comment at: lib/CodeGen/CodeGenFunction.h:236
+LabelSeenStack.back() = true;
+  }
+

A label in a nested scope acts like a label in outer scopes, too.


https://reviews.llvm.org/D27680



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

[PATCH] D26110: Add a check for GCC to the _LIBCPP_EXPLICIT define

[Marshall Clow via Phabricator via cfe-commits]

mclow.lists added a comment.

Ok, this is weird. It looks like the changes to <__config> got committed, but 
not the test.


https://reviews.llvm.org/D26110



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

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

[Dimitry Andric via Phabricator via cfe-commits]

dim updated this revision to Diff 85440.
dim added a comment.

In https://reviews.llvm.org/D28520#653360, @aaron.ballman wrote:

> In https://reviews.llvm.org/D28520#652607, @dim wrote:
>
> >
>


[...]

>> I'm really open to any variant, as long as something that works can get in 
>> before the 4.0.0 release. :)
> 
> I feel like there's still some confusion here (likely on my part). DeLesley 
> was asking if there was a way to turn this off for everyone *except* FreeBSD 
> (that is user-controllable), but your code turns it off specifically *for* 
> FreeBSD with no option to enable. The part that has me confused is that 
> FreeBSD is annotating their functionality specifically to enable thread 
> safety checking; it seems like turning that checking off rather than 
> supporting it is the wrong way to go. I think that may be why DeLesley was 
> saying to disable the functionality for non-FreeBSD systems while still 
> honoring it on FreeBSD, but if I'm confused, hopefully he'll clarify.

Ok, so let's go back to the previous variant, but with conditionals to be able 
to turn checking on, if so desired, using 
`_LIBCPP_ENABLE_THREAD_SAFETY_ATTRIBUTE`.  Checking is on by default for 
FreeBSD only, but can still be disabled explicitly by defining 
`_LIBCPP_DISABLE_THREAD_SAFETY_ATTRIBUTE`.


https://reviews.llvm.org/D28520

Files:
  include/__threading_support

Index: include/__threading_support
===
--- include/__threading_support
+++ include/__threading_support
@@ -40,14 +40,30 @@
 #define _LIBCPP_THREAD_ABI_VISIBILITY inline _LIBCPP_INLINE_VISIBILITY
 #endif
 
+#if defined(__FreeBSD__) && !defined(_LIBCPP_DISABLE_THREAD_SAFETY_ATTRIBUTE) && \
+!defined(_LIBCPP_ENABLE_THREAD_SAFETY_ATTRIBUTE)
+# define _LIBCPP_ENABLE_THREAD_SAFETY_ATTRIBUTE
+#endif
+
+#ifndef _LIBCPP_THREAD_SAFETY_ATTRIBUTE
+# if defined(__clang__) && __has_attribute(acquire_capability) && \
+ defined(_LIBCPP_ENABLE_THREAD_SAFETY_ATTRIBUTE)
+#  define _LIBCPP_THREAD_SAFETY_ATTRIBUTE(x) __attribute__((x))
+# else
+#  define _LIBCPP_THREAD_SAFETY_ATTRIBUTE(x)
+# endif
+#endif
+
 _LIBCPP_BEGIN_NAMESPACE_STD
 
 #if defined(_LIBCPP_HAS_THREAD_API_PTHREAD)
 // Mutex
-typedef pthread_mutex_t __libcpp_mutex_t;
+typedef pthread_mutex_t __libcpp_mutex_t
+_LIBCPP_THREAD_SAFETY_ATTRIBUTE(capability("mutex"));
 #define _LIBCPP_MUTEX_INITIALIZER PTHREAD_MUTEX_INITIALIZER
 
-typedef pthread_mutex_t __libcpp_recursive_mutex_t;
+typedef pthread_mutex_t __libcpp_recursive_mutex_t
+_LIBCPP_THREAD_SAFETY_ATTRIBUTE(capability("mutex"));
 
 // Condition Variable
 typedef pthread_cond_t __libcpp_condvar_t;
@@ -71,10 +87,12 @@
 #define _LIBCPP_TLS_DESTRUCTOR_CC
 #else
 // Mutex
-typedef SRWLOCK __libcpp_mutex_t;
+typedef SRWLOCK __libcpp_mutex_t
+_LIBCPP_THREAD_SAFETY_ATTRIBUTE(capability("mutex"));
 #define _LIBCPP_MUTEX_INITIALIZER SRWLOCK_INIT
 
-typedef CRITICAL_SECTION __libcpp_recursive_mutex_t;
+typedef CRITICAL_SECTION __libcpp_recursive_mutex_t
+_LIBCPP_THREAD_SAFETY_ATTRIBUTE(capability("mutex"));
 
 // Condition Variable
 typedef CONDITION_VARIABLE __libcpp_condvar_t;
@@ -103,25 +121,31 @@
 int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
-int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m);
+int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m)
+_LIBCPP_THREAD_SAFETY_ATTRIBUTE(acquire_capability(*__m));
 
 _LIBCPP_THREAD_ABI_VISIBILITY
-bool __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m);
+bool __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m)
+_LIBCPP_THREAD_SAFETY_ATTRIBUTE(try_acquire_capability(true, *__m));
 
 _LIBCPP_THREAD_ABI_VISIBILITY
-int __libcpp_recursive_mutex_unlock(__libcpp_recursive_mutex_t *__m);
+int __libcpp_recursive_mutex_unlock(__libcpp_recursive_mutex_t *__m)
+_LIBCPP_THREAD_SAFETY_ATTRIBUTE(release_capability(*__m));
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
-int __libcpp_mutex_lock(__libcpp_mutex_t *__m);
+int __libcpp_mutex_lock(__libcpp_mutex_t *__m)
+_LIBCPP_THREAD_SAFETY_ATTRIBUTE(acquire_capability(*__m));
 
 _LIBCPP_THREAD_ABI_VISIBILITY
-bool __libcpp_mutex_trylock(__libcpp_mutex_t *__m);
+bool __libcpp_mutex_trylock(__libcpp_mutex_t *__m)
+_LIBCPP_THREAD_SAFETY_ATTRIBUTE(try_acquire_capability(true, *__m));
 
 _LIBCPP_THREAD_ABI_VISIBILITY
-int __libcpp_mutex_unlock(__libcpp_mutex_t *__m);
+int __libcpp_mutex_unlock(__libcpp_mutex_t *__m)
+_LIBCPP_THREAD_SAFETY_ATTRIBUTE(release_capability(*__m));
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_mutex_destroy(__libcpp_mutex_t *__m);
@@ -134,11 +158,13 @@
 int __libcpp_condvar_broadcast(__libcpp_condvar_t* __cv);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
-int __libcpp_condvar_wait(__libcpp_condvar_t* __cv, __libcpp_mutex_t* __m);
+int __libcpp_condvar_wait(__libcpp_condvar_t* __cv, __libcpp_mutex_t* __m)
+

[libcxx] r292823 - Implement LWG#2778: basic_string_view is missing constexpr.

[Marshall Clow via cfe-commits]

Author: marshall
Date: Mon Jan 23 13:53:28 2017
New Revision: 292823

URL: http://llvm.org/viewvc/llvm-project?rev=292823&view=rev
Log:
Implement LWG#2778: basic_string_view is missing constexpr.

Added:
libcxx/trunk/test/std/strings/string.view/string.view.cons/assign.pass.cpp
Modified:
libcxx/trunk/include/string_view
libcxx/trunk/www/cxx1z_status.html

Modified: libcxx/trunk/include/string_view
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/string_view?rev=292823&r1=292822&r2=292823&view=diff
==
--- libcxx/trunk/include/string_view (original)
+++ libcxx/trunk/include/string_view Mon Jan 23 13:53:28 2017
@@ -206,7 +206,7 @@ public:
_LIBCPP_CONSTEXPR _LIBCPP_INLINE_VISIBILITY
basic_string_view(const basic_string_view&) _NOEXCEPT = default;
 
-   _LIBCPP_INLINE_VISIBILITY
+   _LIBCPP_CONSTEXPR_AFTER_CXX11 _LIBCPP_INLINE_VISIBILITY
basic_string_view& operator=(const basic_string_view&) _NOEXCEPT = 
default;
 
_LIBCPP_CONSTEXPR _LIBCPP_INLINE_VISIBILITY
@@ -235,16 +235,16 @@ public:
_LIBCPP_CONSTEXPR _LIBCPP_INLINE_VISIBILITY
const_iterator cend()   const _NOEXCEPT { return __data + __size; }
 
-   _LIBCPP_INLINE_VISIBILITY
+   _LIBCPP_CONSTEXPR_AFTER_CXX14 _LIBCPP_INLINE_VISIBILITY
const_reverse_iterator rbegin()   const _NOEXCEPT { return 
const_reverse_iterator(cend()); }
 
-   _LIBCPP_INLINE_VISIBILITY
+   _LIBCPP_CONSTEXPR_AFTER_CXX14 _LIBCPP_INLINE_VISIBILITY
const_reverse_iterator rend() const _NOEXCEPT { return 
const_reverse_iterator(cbegin()); }
 
-   _LIBCPP_INLINE_VISIBILITY
+   _LIBCPP_CONSTEXPR_AFTER_CXX14 _LIBCPP_INLINE_VISIBILITY
const_reverse_iterator crbegin()  const _NOEXCEPT { return 
const_reverse_iterator(cend()); }
 
-   _LIBCPP_INLINE_VISIBILITY
+   _LIBCPP_CONSTEXPR_AFTER_CXX14 _LIBCPP_INLINE_VISIBILITY
const_reverse_iterator crend()const _NOEXCEPT { return 
const_reverse_iterator(cbegin()); }
 
// [string.view.capacity], capacity

Added: 
libcxx/trunk/test/std/strings/string.view/string.view.cons/assign.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/strings/string.view/string.view.cons/assign.pass.cpp?rev=292823&view=auto
==
--- libcxx/trunk/test/std/strings/string.view/string.view.cons/assign.pass.cpp 
(added)
+++ libcxx/trunk/test/std/strings/string.view/string.view.cons/assign.pass.cpp 
Mon Jan 23 13:53:28 2017
@@ -0,0 +1,50 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+
+// 
+
+// constexpr basic_string_view& operator=(const basic_string_view &) noexcept 
= default;
+
+#include 
+#include 
+
+#include "test_macros.h"
+
+template
+#if TEST_STD_VER > 11
+constexpr
+#endif
+bool test (T sv0)
+{
+T sv1;
+sv1 = sv0;
+//  We can't just say "sv0 == sv1" here because string_view::compare
+//  isn't constexpr until C++17, and we want to support back to C++14
+return sv0.size() == sv1.size() && sv0.data() == sv1.data();
+}
+
+int main () {
+
+assert( test( "1234"));
+#ifdef _LIBCPP_HAS_NO_UNICODE_CHARS
+assert( test (u"1234"));
+assert( test (U"1234"));
+#endif
+assert( test   (L"1234"));
+
+#if TEST_STD_VER > 11
+static_assert( test({ "abc", 3}), "");
+#ifdef _LIBCPP_HAS_NO_UNICODE_CHARS
+static_assert( test ({u"abc", 3}), "");
+static_assert( test ({U"abc", 3}), "");
+#endif
+static_assert( test   ({L"abc", 3}), "");
+#endif
+}

Modified: libcxx/trunk/www/cxx1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1z_status.html?rev=292823&r1=292822&r2=292823&view=diff
==
--- libcxx/trunk/www/cxx1z_status.html (original)
+++ libcxx/trunk/www/cxx1z_status.html Mon Jan 23 13:53:28 2017
@@ -409,7 +409,7 @@
http://wg21.link/LWG2771";>2771Broken 
Effects of some basic_string::compare functions in terms of 
basic_string_viewIssaquahComplete
http://wg21.link/LWG2773";>2773Making 
std::ignore constexprIssaquah
http://wg21.link/LWG2777";>2777basic_string_view::copy should 
use char_traits::copyIssaquahComplete
-   http://wg21.link/LWG2778";>2778basic_string_view is missing 
constexprIssaquah
+   http://wg21.link/LWG2778";>2778basic_string_view is missing 
constexprIssaquahComplete
 
 
   
 
-  Last Updated: 19-Jan-2017
+  Last Updated: 23-Jan-2017
 
 
 


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

[libcxx] r292822 - Fixed a typo in __config that prevented the aligned new/delete tests from passing on Mac OS.

[Marshall Clow via cfe-commits]

Author: marshall
Date: Mon Jan 23 13:51:54 2017
New Revision: 292822

URL: http://llvm.org/viewvc/llvm-project?rev=292822&view=rev
Log:
Fixed a typo in __config that prevented the aligned new/delete tests from 
passing on Mac OS.

Modified:
libcxx/trunk/include/__config

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=292822&r1=292821&r2=292822&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Mon Jan 23 13:51:54 2017
@@ -851,7 +851,7 @@ template  struct __static_asse
 #if defined(__APPLE__)
 # if !defined(__MAC_OS_X_VERSION_MIN_REQUIRED) && \
  defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__)
-#   define __MAC_OS_X_VERSION_MIN_REQUIRED 
__ENVIROMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
+#   define __MAC_OS_X_VERSION_MIN_REQUIRED 
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
 # endif
 # if defined(__MAC_OS_X_VERSION_MIN_REQUIRED)
 #   if __MAC_OS_X_VERSION_MIN_REQUIRED < 1060


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

[PATCH] D28510: Reinstate CWG1607 restrictions on lambdas appearing inside certain constant-expressions

[Richard Smith via Phabricator via cfe-commits]

rsmith requested changes to this revision.
rsmith added a comment.
This revision now requires changes to proceed.

I don't think it's possible to check this in the way you're doing so here. In 
general, there's no way to know whether a constant expression will be part of a 
`typedef` declaration or function declaration until you've finished parsing it 
(when you're parsing the decl-specifiers in a declaration you don't know 
whether you're declaring a function or a variable, and the `typedef` keyword 
might appear later).

So I think you need a different approach here. How about tracking the set of 
contained lambdas on the `Declarator` and `DeclSpec` objects, and diagnose from 
`ActOnFunctionDeclarator` / `ActOnTypedefDeclarator` if the current expression 
evaluation context contains any lambdas? (Maybe when entering an expression 
evaluation context, pass an optional `SmallVectorImpl*` to `Sema` to 
collect the lambdas contained within the expression.)

There are some particularly "fun" cases to watch out for here:

  decltype([]{})
a, // ok
f(); // ill-formed

... that require us to track the lambdas in the `DeclSpec` separately from the 
lambdas in the `Declarator`.


Repository:
  rL LLVM

https://reviews.llvm.org/D28510



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

[PATCH] D28835: [coroutines] NFC: Refactor Sema::CoroutineBodyStmt construction.

[Richard Smith via Phabricator via cfe-commits]

rsmith added a comment.

Generally looks good, but we have a better way of modeling types with a 
trailing variable-length array that you should use.




Comment at: include/clang/AST/StmtCXX.h:299
 /// down the coroutine frame.
 class CoroutineBodyStmt : public Stmt {
   enum SubStmt {

Please use `llvm::TrailingObjects` to store the trailing variable-length 
`SubStmts` array.



Comment at: lib/Sema/SemaCoroutine.cpp:714-722
+// Try to form 'p.set_exception(std::current_exception());' to handle
+// uncaught exceptions.
+// TODO: Post WG21 Issaquah 2016 renamed set_exception to unhandled_exception
+// TODO: and dropped exception_ptr parameter. Make it so.
+
+  if (!PromiseRecordDecl)
+return true;

Reindent comments.


https://reviews.llvm.org/D28835



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

[PATCH] D28889: Change where we handle arg-dependent diagnose_if attributes

[Richard Smith via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: include/clang/Sema/Overload.h:758
 /// instead.
+/// FIXME: Now that it only alloates ImplicitConversionSequences, do we 
want
+/// to un-generalize this?

Typo "alloates"



Comment at: lib/Sema/SemaChecking.cpp:2490
 CallType);
+  diagnoseArgDependentDiagnoseIfAttrs(FDecl, /*ThisArg=*/nullptr, Args, Loc);
 }

Can this be moved inside `checkCall`?


https://reviews.llvm.org/D28889



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

[PATCH] D29027: [Stack Protection] Add remark for reasons why Stack Protection has been applied

[Richard Smith via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: include/clang/Basic/DiagnosticFrontendKinds.td:229
+def remark_ssp_applied_reason
+: Remark<"SSP applied to function due to %select{an unknown reason|a "
+ "call to alloca|a stack allocated buffer or struct containing a "

Can this "unknown reason" case actually happen? It seems like a bug that SSP 
insertion would not know why it's doing what it's doing.



Comment at: include/clang/Basic/DiagnosticFrontendKinds.td:229
+def remark_ssp_applied_reason
+: Remark<"SSP applied to function due to %select{an unknown reason|a "
+ "call to alloca|a stack allocated buffer or struct containing a "

rsmith wrote:
> Can this "unknown reason" case actually happen? It seems like a bug that SSP 
> insertion would not know why it's doing what it's doing.
Rather than the potentially-opaque initialism SSP, could you say "stack 
protector" here? That would match the flag name better.



Comment at: include/clang/Basic/DiagnosticFrontendKinds.td:230
+: Remark<"SSP applied to function due to %select{an unknown reason|a "
+ "call to alloca|a stack allocated buffer or struct containing a "
+ "buffer|the address of a local variable being taken|a function "

Do we actually know that the cause is a call to `alloca` rather than a VLA?



Comment at: include/clang/Basic/DiagnosticFrontendKinds.td:232
+ "buffer|the address of a local variable being taken|a function "
+ "attribute or use of -fstack-protector-all}0">,
+  InGroup;

These two cases seem very easy to tell apart: if `-fstack-protector-all` is 
specified, use that diagnostic, otherwise the LLVM attribute must have been 
from a source-level attribute.



Comment at: include/clang/Basic/DiagnosticGroups.td:911
+// function.
+def SSPReason : DiagGroup<"ssp-reason">;

The flags to control this are `-fstack-protector*`, so `-Rstack-protector` (or 
something starting `-Rstack-protector`) should be used here.


https://reviews.llvm.org/D29027



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

[PATCH] D28620: Guard __gnuc_va_list typedef

[Paul Robinson via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL292819: Guard __gnuc_va_list typedef. (authored by 
probinson).

Changed prior to commit:
  https://reviews.llvm.org/D28620?vs=84151&id=85430#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28620

Files:
  cfe/trunk/lib/Headers/stdarg.h
  cfe/trunk/test/Headers/stdarg-gnuc_va_list.c


Index: cfe/trunk/test/Headers/stdarg-gnuc_va_list.c
===
--- cfe/trunk/test/Headers/stdarg-gnuc_va_list.c
+++ cfe/trunk/test/Headers/stdarg-gnuc_va_list.c
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wsystem-headers -std=c99 %s
+// expected-no-diagnostics
+
+// Check that no warnings are emitted from stdarg.h if __gnuc_va_list has
+// previously been defined in another header file.
+typedef __builtin_va_list __va_list;
+typedef __va_list __gnuc_va_list;
+#define __GNUC_VA_LIST
+
+#include 
Index: cfe/trunk/lib/Headers/stdarg.h
===
--- cfe/trunk/lib/Headers/stdarg.h
+++ cfe/trunk/lib/Headers/stdarg.h
@@ -43,10 +43,9 @@
 #define va_copy(dest, src)  __builtin_va_copy(dest, src)
 #endif
 
-/* Hack required to make standard headers work, at least on Ubuntu */
 #ifndef __GNUC_VA_LIST
 #define __GNUC_VA_LIST 1
-#endif
 typedef __builtin_va_list __gnuc_va_list;
+#endif
 
 #endif /* __STDARG_H */


Index: cfe/trunk/test/Headers/stdarg-gnuc_va_list.c
===
--- cfe/trunk/test/Headers/stdarg-gnuc_va_list.c
+++ cfe/trunk/test/Headers/stdarg-gnuc_va_list.c
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wsystem-headers -std=c99 %s
+// expected-no-diagnostics
+
+// Check that no warnings are emitted from stdarg.h if __gnuc_va_list has
+// previously been defined in another header file.
+typedef __builtin_va_list __va_list;
+typedef __va_list __gnuc_va_list;
+#define __GNUC_VA_LIST
+
+#include 
Index: cfe/trunk/lib/Headers/stdarg.h
===
--- cfe/trunk/lib/Headers/stdarg.h
+++ cfe/trunk/lib/Headers/stdarg.h
@@ -43,10 +43,9 @@
 #define va_copy(dest, src)  __builtin_va_copy(dest, src)
 #endif
 
-/* Hack required to make standard headers work, at least on Ubuntu */
 #ifndef __GNUC_VA_LIST
 #define __GNUC_VA_LIST 1
-#endif
 typedef __builtin_va_list __gnuc_va_list;
+#endif
 
 #endif /* __STDARG_H */
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r292819 - Guard __gnuc_va_list typedef.

[Paul Robinson via cfe-commits]

Author: probinson
Date: Mon Jan 23 13:09:21 2017
New Revision: 292819

URL: http://llvm.org/viewvc/llvm-project?rev=292819&view=rev
Log:
Guard __gnuc_va_list typedef.

Differential Revision: http://reviews.llvm.org/D28620

Added:
cfe/trunk/test/Headers/stdarg-gnuc_va_list.c
Modified:
cfe/trunk/lib/Headers/stdarg.h

Modified: cfe/trunk/lib/Headers/stdarg.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/stdarg.h?rev=292819&r1=292818&r2=292819&view=diff
==
--- cfe/trunk/lib/Headers/stdarg.h (original)
+++ cfe/trunk/lib/Headers/stdarg.h Mon Jan 23 13:09:21 2017
@@ -43,10 +43,9 @@ typedef __builtin_va_list va_list;
 #define va_copy(dest, src)  __builtin_va_copy(dest, src)
 #endif
 
-/* Hack required to make standard headers work, at least on Ubuntu */
 #ifndef __GNUC_VA_LIST
 #define __GNUC_VA_LIST 1
-#endif
 typedef __builtin_va_list __gnuc_va_list;
+#endif
 
 #endif /* __STDARG_H */

Added: cfe/trunk/test/Headers/stdarg-gnuc_va_list.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/stdarg-gnuc_va_list.c?rev=292819&view=auto
==
--- cfe/trunk/test/Headers/stdarg-gnuc_va_list.c (added)
+++ cfe/trunk/test/Headers/stdarg-gnuc_va_list.c Mon Jan 23 13:09:21 2017
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wsystem-headers -std=c99 %s
+// expected-no-diagnostics
+
+// Check that no warnings are emitted from stdarg.h if __gnuc_va_list has
+// previously been defined in another header file.
+typedef __builtin_va_list __va_list;
+typedef __va_list __gnuc_va_list;
+#define __GNUC_VA_LIST
+
+#include 


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

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

[Eric Christopher via Phabricator via cfe-commits]

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

This looks fine to me now, might be good to get someone else to ack as well 
though.


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] D29038: [OpenCL] Accept logical NOT for pointer types in CL1.0 and CL1.1

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added inline comments.



Comment at: test/SemaOpenCL/logical-ops.cl:1-3
+// RUN: %clang_cc1 %s -verify -cl-std=CL1.1 -triple x86_64-unknown-linux-gnu
+// RUN: %clang_cc1 %s -verify -cl-std=CL1.2 -triple x86_64-unknown-linux-gnu
+

arsenm wrote:
> Should this have a 2.0 run line for good measure?
1.0 too I suppose


https://reviews.llvm.org/D29038



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

[PATCH] D29038: [OpenCL] Accept logical NOT for pointer types in CL1.0 and CL1.1

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added inline comments.



Comment at: test/SemaOpenCL/logical-ops.cl:1-3
+// RUN: %clang_cc1 %s -verify -cl-std=CL1.1 -triple x86_64-unknown-linux-gnu
+// RUN: %clang_cc1 %s -verify -cl-std=CL1.2 -triple x86_64-unknown-linux-gnu
+

Should this have a 2.0 run line for good measure?


https://reviews.llvm.org/D29038



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

[PATCH] D27257: [CodeCompletion] Ensure that ObjC root class completes instance methods from protocols and categories as well

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

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

Ok. Thanks Alex, LGTM


Repository:
  rL LLVM

https://reviews.llvm.org/D27257



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

[PATCH] D28860: [OpenCL] Diagnose write_only image3d when extension is disabled

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

The tests should be added to SemaOpenCL/extension-version.cl




Comment at: lib/Sema/SemaType.cpp:6683
+  // access qualifier unless the cl_khr_3d_image_writes extension is enabled.
+  if (CurType->isOCLImage3dWOType() &&
+  !S.getOpenCLOptions().isEnabled("cl_khr_3d_image_writes")) {

should modify OpenCLImageTypes.def for image types associated with an 
extension. The diagnostics will be emitted automatically.


https://reviews.llvm.org/D28860



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

Re: [libcxx] r291961 - Add _LIBCPP_DIAGNOSE_WARNING and _LIBCPP_DIAGNOSE_ERROR macros.

[George Burgess via cfe-commits]

The only plan that we have at the moment is basically for a
-Wno-user-defined-warnings-in-system-headers type of flag. I agree that it
would be nice if we could be more granular than this, so I'll think about
what we can do.

On Mon, Jan 23, 2017 at 8:36 AM, Nico Weber  wrote:

> This happens to fire in practice in protobuf. It's probably a true
> positive and it's cool that this warning found it, but it means we have to
> disable Wuser-defined-warnings for a bit -- which then disables all of
> these user-defined warnings. Right now there aren't any others, but it
> feels like we'd want to have the ability to turn individual user-defined
> warnings on or off instead of just having a single toggle for all of them.
> Are there plans for something like that?
>
> On Fri, Jan 13, 2017 at 5:02 PM, Eric Fiselier via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: ericwf
>> Date: Fri Jan 13 16:02:08 2017
>> New Revision: 291961
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=291961&view=rev
>> Log:
>> Add _LIBCPP_DIAGNOSE_WARNING and _LIBCPP_DIAGNOSE_ERROR macros.
>>
>> Clang recently added a `diagnose_if(cond, msg, type)` attribute
>> which can be used to generate diagnostics when `cond` is a constant
>> expression that evaluates to true. Otherwise no attribute has no
>> effect.
>>
>> This patch adds _LIBCPP_DIAGNOSE_ERROR/WARNING macros which
>> use this new attribute. Additionally this patch implements
>> a diagnostic message when a non-const-callable comparator is
>> given to a container.
>>
>> Note: For now the warning version of the diagnostic is useless
>> within libc++ since warning diagnostics are suppressed by the
>> system header pragma. I'm going to work on fixing this.
>>
>> Added:
>> libcxx/trunk/test/libcxx/containers/associative/non_const_co
>> mparator.fail.cpp
>> Modified:
>> libcxx/trunk/docs/UsingLibcxx.rst
>> libcxx/trunk/include/__config
>> libcxx/trunk/include/__tree
>> libcxx/trunk/include/map
>> libcxx/trunk/include/type_traits
>> libcxx/trunk/test/libcxx/compiler.py
>> libcxx/trunk/test/libcxx/test/config.py
>> libcxx/trunk/test/libcxx/test/format.py
>> libcxx/trunk/test/libcxx/utilities/tuple/tuple.tuple/diagnos
>> e_reference_binding.fail.cpp
>>
>> Modified: libcxx/trunk/docs/UsingLibcxx.rst
>> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/UsingL
>> ibcxx.rst?rev=291961&r1=291960&r2=291961&view=diff
>> 
>> ==
>> --- libcxx/trunk/docs/UsingLibcxx.rst (original)
>> +++ libcxx/trunk/docs/UsingLibcxx.rst Fri Jan 13 16:02:08 2017
>> @@ -173,3 +173,10 @@ thread safety annotations.
>>return Tup{"hello world", 42}; // explicit constructor called. OK.
>>  }
>>
>> +**_LIBCPP_DISABLE_ADDITIONAL_DIAGNOSTICS**:
>> +  This macro disables the additional diagnostics generated by libc++
>> using the
>> +  `diagnose_if` attribute. These additional diagnostics include checks
>> for:
>> +
>> +* Giving `set`, `map`, `multiset`, `multimap` a comparator which is
>> not
>> +  const callable.
>> +
>>
>> Modified: libcxx/trunk/include/__config
>> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__c
>> onfig?rev=291961&r1=291960&r2=291961&view=diff
>> 
>> ==
>> --- libcxx/trunk/include/__config (original)
>> +++ libcxx/trunk/include/__config Fri Jan 13 16:02:08 2017
>> @@ -1006,6 +1006,16 @@ _LIBCPP_FUNC_VIS extern "C" void __sanit
>>  #endif
>>  #endif
>>
>> +#if __has_attribute(diagnose_if) && !defined(_LIBCPP_DISABLE_ADDIT
>> IONAL_DIAGNOSTICS)
>> +# define _LIBCPP_DIAGNOSE_WARNING(...) \
>> +__attribute__((__diagnose_if__(__VA_ARGS__, "warning")))
>> +# define _LIBCPP_DIAGNOSE_ERROR(...) \
>> +__attribute__((__diagnose_if__(__VA_ARGS__, "error")))
>> +#else
>> +# define _LIBCPP_DIAGNOSE_WARNING(...)
>> +# define _LIBCPP_DIAGNOSE_ERROR(...)
>> +#endif
>> +
>>  #endif // __cplusplus
>>
>>  #endif // _LIBCPP_CONFIG
>>
>> Modified: libcxx/trunk/include/__tree
>> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__t
>> ree?rev=291961&r1=291960&r2=291961&view=diff
>> 
>> ==
>> --- libcxx/trunk/include/__tree (original)
>> +++ libcxx/trunk/include/__tree Fri Jan 13 16:02:08 2017
>> @@ -41,6 +41,10 @@ template 
>>  struct __value_type;
>>  #endif
>>
>> +template > +bool = is_empty<_Compare>::value && !__libcpp_is_final<_Compare>::
>> value>
>> +class __map_value_compare;
>> +
>>  template  class __map_node_destructor;
>>  template  class _LIBCPP_TEMPLATE_VIS __map_iterator;
>>  template  class _LIBCPP_TEMPLATE_VIS
>> __map_const_iterator;
>> @@ -955,6 +959,30 @@ private:
>>
>>  };
>>
>> +#ifndef _LIBCPP_CXX03_LANG
>> +template 
>> +struct __diagnose_tree_helper {
>> +  static constexpr bool __trigger_diagnostics()
>> +  _LIBCPP_DIAGNOSE_WARNING(!__is_const_compar

Re: r292800 - [analyzer] Fix memory space of static locals seen from nested blocks.

[Artem Dergachev via cfe-commits]

Hans,

Could we merge this one into the 4.0.0 release branch? It's a recent 
bugfix for the analyzer.


Thanks,
Artem.


On 1/23/17 7:57 PM, Artem Dergachev via cfe-commits wrote:

Author: dergachev
Date: Mon Jan 23 10:57:11 2017
New Revision: 292800

URL: http://llvm.org/viewvc/llvm-project?rev=292800&view=rev
Log:
[analyzer] Fix memory space of static locals seen from nested blocks.

When a block within a function accesses a function's static local variable,
this local is captured by reference rather than copied to the heap.

Therefore this variable's memory space is known: StaticGlobalSpaceRegion.
Used to be UnknownSpaceRegion, same as for stack locals.

Fixes a false positive in MacOSXAPIChecker.

rdar://problem/30105546
Differential revision: https://reviews.llvm.org/D28946

Modified:
 cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
 cfe/trunk/test/Analysis/dispatch-once.m

Modified: cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp?rev=292800&r1=292799&r2=292800&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/MemRegion.cpp Mon Jan 23 10:57:11 2017
@@ -776,6 +776,22 @@ getStackOrCaptureRegionForDeclContext(co
return (const StackFrameContext *)nullptr;
  }
  
+static CanQualType getBlockPointerType(const BlockDecl *BD, ASTContext &C) {

+  // FIXME: The fallback type here is totally bogus -- though it should
+  // never be queried, it will prevent uniquing with the real
+  // BlockCodeRegion. Ideally we'd fix the AST so that we always had a
+  // signature.
+  QualType T;
+  if (const TypeSourceInfo *TSI = BD->getSignatureAsWritten())
+T = TSI->getType();
+  if (T.isNull())
+T = C.VoidTy;
+  if (!T->getAs())
+T = C.getFunctionNoProtoType(T);
+  T = C.getBlockPointerType(T);
+  return C.getCanonicalType(T);
+}
+
  const VarRegion* MemRegionManager::getVarRegion(const VarDecl *D,
  const LocationContext *LC) {
const MemRegion *sReg = nullptr;
@@ -803,7 +819,7 @@ const VarRegion* MemRegionManager::getVa
  sReg = getGlobalsRegion();
  }
  
-  // Finally handle static locals.

+  // Finally handle locals.
} else {
  // FIXME: Once we implement scope handling, we will need to properly 
lookup
  // 'D' to the proper LocationContext.
@@ -816,9 +832,22 @@ const VarRegion* MemRegionManager::getVa
  
  const StackFrameContext *STC = V.get();
  
-if (!STC)

-  sReg = getUnknownRegion();
-else {
+if (!STC) {
+  if (D->isStaticLocal()) {
+const CodeTextRegion *fReg = nullptr;
+if (const auto *ND = dyn_cast(DC))
+  fReg = getFunctionCodeRegion(ND);
+else if (const auto *BD = dyn_cast(DC))
+  fReg = getBlockCodeRegion(BD, getBlockPointerType(BD, getContext()),
+LC->getAnalysisDeclContext());
+assert(fReg && "Unable to determine code region for a static local!");
+sReg = getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind, fReg);
+  } else {
+// We're looking at a block-captured local variable, which may be 
either
+// still local, or already moved to the heap. So we're not sure.
+sReg = getUnknownRegion();
+  }
+} else {
if (D->hasLocalStorage()) {
  sReg = isa(D) || isa(D)
 ? static_cast(getStackArgumentsRegion(STC))
@@ -831,22 +860,9 @@ const VarRegion* MemRegionManager::getVa
sReg = getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,

getFunctionCodeRegion(cast(STCD)));
  else if (const BlockDecl *BD = dyn_cast(STCD)) {
-  // FIXME: The fallback type here is totally bogus -- though it should
-  // never be queried, it will prevent uniquing with the real
-  // BlockCodeRegion. Ideally we'd fix the AST so that we always had a
-  // signature.
-  QualType T;
-  if (const TypeSourceInfo *TSI = BD->getSignatureAsWritten())
-T = TSI->getType();
-  if (T.isNull())
-T = getContext().VoidTy;
-  if (!T->getAs())
-T = getContext().getFunctionNoProtoType(T);
-  T = getContext().getBlockPointerType(T);
-
const BlockCodeRegion *BTR =
-getBlockCodeRegion(BD, C.getCanonicalType(T),
-   STC->getAnalysisDeclContext());
+  getBlockCodeRegion(BD, getBlockPointerType(BD, getContext()),
+ STC->getAnalysisDeclContext());
sReg = getGlobalsRegion(MemRegion::StaticGlobalSpaceRegionKind,
BTR);
  }

Modified: cfe/trunk/test/Analysis/dispatch-once.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/dispa

Re: r292558 - Add documentation for constexpr string builtin support.

[Richard Smith via cfe-commits]

On 22 January 2017 at 07:57, Kim Gräsman  wrote:

> Hi Richard,
>
> On Fri, Jan 20, 2017 at 1:58 AM, Richard Smith via cfe-commits
>  wrote:
> >
> > +String builtins
> > +---
> > +
> > +Clang provides constant expression evaluation support for builtins
> forms of
> > +the following functions from the C standard library 
> header:
> > +
> > +* ``memchr``
> > +* ``memcmp``
> > +* ``strchr``
>
> This should say , right?


Yes, thanks, fixed in r292811.


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

r292811 - Fix documentation typo from r292558.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Jan 23 12:17:46 2017
New Revision: 292811

URL: http://llvm.org/viewvc/llvm-project?rev=292811&view=rev
Log:
Fix documentation typo from r292558.

Modified:
cfe/trunk/docs/LanguageExtensions.rst

Modified: cfe/trunk/docs/LanguageExtensions.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LanguageExtensions.rst?rev=292811&r1=292810&r2=292811&view=diff
==
--- cfe/trunk/docs/LanguageExtensions.rst (original)
+++ cfe/trunk/docs/LanguageExtensions.rst Mon Jan 23 12:17:46 2017
@@ -1780,7 +1780,7 @@ String builtins
 ---
 
 Clang provides constant expression evaluation support for builtins forms of
-the following functions from the C standard library  header:
+the following functions from the C standard library  header:
 
 * ``memchr``
 * ``memcmp``


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

[PATCH] D28814: [OpenCL] Add missing address spaces in IR generation of Blocks

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: lib/CodeGen/CGBlocks.cpp:723
+? CGM.getNSConcreteStackBlock()
+: llvm::Constant::getNullValue(
+  CGM.getNSConcreteStackBlock()->getType());

should use CGM.getNullPointer to create a null pointer.



Comment at: lib/CodeGen/CGBlocks.cpp:1124
+ ? CGM.getNSConcreteGlobalBlock()
+ : llvm::Constant::getNullValue(
+   CGM.getNSConcreteGlobalBlock()->getType()));

should use CGM.getNullPointer to create a null pointer.


https://reviews.llvm.org/D28814



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

Re: [libcxx] r292607 - Don't default older GCC's to C++17, but C++14 or C++11 instead

[Hans Wennborg via cfe-commits]

Sounds good to me.

On Fri, Jan 20, 2017 at 11:38 AM, Eric Fiselier  wrote:
> We should merge this patch into the 4.0 release branch. It is needed to make
> "check-all" pass when using GCC 4, 5 and 6.
>
> /Eric
>
> On Fri, Jan 20, 2017 at 5:54 AM, Eric Fiselier via cfe-commits
>  wrote:
>>
>> Author: ericwf
>> Date: Fri Jan 20 06:54:45 2017
>> New Revision: 292607
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=292607&view=rev
>> Log:
>> Don't default older GCC's to C++17, but C++14 or C++11 instead
>>
>> Modified:
>> libcxx/trunk/test/libcxx/test/config.py
>>
>> Modified: libcxx/trunk/test/libcxx/test/config.py
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/test/config.py?rev=292607&r1=292606&r2=292607&view=diff
>>
>> ==
>> --- libcxx/trunk/test/libcxx/test/config.py (original)
>> +++ libcxx/trunk/test/libcxx/test/config.py Fri Jan 20 06:54:45 2017
>> @@ -423,6 +423,15 @@ class Configuration(object):
>>  if not std:
>>  # Choose the newest possible language dialect if none is
>> given.
>>  possible_stds = ['c++1z', 'c++14', 'c++11', 'c++03']
>> +if self.cxx.type == 'gcc':
>> +maj_v, _, _ = self.cxx.version
>> +maj_v = int(maj_v)
>> +if maj_v < 7:
>> +possible_stds.remove('c++1z')
>> +# FIXME: How many C++14 tests actually fail under GCC 5
>> and 6?
>> +# Should we XFAIL them individually instead?
>> +if maj_v <= 6:
>> +possible_stds.remove('c++14')
>>  for s in possible_stds:
>>  if self.cxx.hasCompileFlag('-std=%s' % s):
>>  std = s
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits