[PATCH] D27402: [libc++] Implement pmr::monotonic_buffer_resource
EricWF created this revision.
EricWF added a reviewer: mclow.lists.
EricWF added a subscriber: cfe-commits.
Implemented from the LFTS v2 spec here:
https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#memory.resource.monotonic.buffer.
This patch could use some finishing touches, but for the most part it is a
complete implementation and tests.
https://reviews.llvm.org/D27402
Files:
include/experimental/__memory
include/experimental/memory_resource
src/experimental/memory_resource.cpp
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.ctor/buffer.pass.cpp
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.ctor/buffer_resource.pass.cpp
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.ctor/copy_move.pass.cpp
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.ctor/default.pass.cpp
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.ctor/dtor.pass.cpp
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.ctor/initial_size.pass.cpp
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.ctor/resource.pass.cpp
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/do_allocate.pass.cpp
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/do_deallocate.pass.cpp
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/release.pass.cpp
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/upstream_resource.pass.cpp
test/std/experimental/memory/memory.resource.pool/pool_options.pass.cpp
test/support/count_new.hpp
test/support/test_memory_resource.hpp
Index: test/support/test_memory_resource.hpp
===
--- test/support/test_memory_resource.hpp
+++ test/support/test_memory_resource.hpp
@@ -483,7 +483,8 @@
assert(false);
#endif
}
-
+next = static_cast(next) + s;
+space -= s;
return ret;
}
Index: test/support/count_new.hpp
===
--- test/support/count_new.hpp
+++ test/support/count_new.hpp
@@ -184,6 +184,10 @@
return disable_checking || n != last_new_size;
}
+bool checkLastNewSizeGreaterEq(int n) const {
+return disable_checking || last_new_size >= n;
+}
+
bool checkOutstandingArrayNewEq(int n) const
{
return disable_checking || n == outstanding_array_new;
Index: test/std/experimental/memory/memory.resource.pool/pool_options.pass.cpp
===
--- /dev/null
+++ test/std/experimental/memory/memory.resource.pool/pool_options.pass.cpp
@@ -0,0 +1,26 @@
+//===--===//
+//
+// 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.
+//
+//===--===//
+
+// UNSUPPORTED: c++98, c++03
+
+//
+
+// struct pool_options
+
+#include
+#include
+
+int main() {
+ using std::experimental::pmr::pool_options;
+ {
+const pool_options p;
+assert(p.max_blocks_per_chunk == 0);
+assert(p.largest_required_pool_block == 0);
+ }
+}
Index: test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/upstream_resource.pass.cpp
===
--- /dev/null
+++ test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/upstream_resource.pass.cpp
@@ -0,0 +1,46 @@
+//===--===//
+//
+// 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.
+//
+//===--===//
+
+// UNSUPPORTED: c++98, c++03
+
+//
+
+// class monotonic_buffer_resource
+
+// memory_resource *upstream_resource() const;
+
+#include
+#include
+#include
+
+#include "test_memory_resource.hpp"
+
+namespace ex = std::experimental::pmr;
+
+int main() {
+ using Res = TestResource;
+ Res R1;
+ {
+ex::monotonic_buffer_resource res;
+assert(res.upstream_resource() == ex::get_default_resource());
+assert(ex::get_default_resource() == ex::new_delete_resource());
+
+Res R;
+ex::set_default_resource(&R);
+ex::monotonic_buffer_resource res2;
+assert(res2.upstream_resource() == &R);
+
+ex::set_default_resource(ex::new_delete_resource());
+ }
+ {
+Res R;
+const ex::monotonic_buffer_resource
[PATCH] D27403: [OpenCL] Added a LIT test for ensuring address space mangling is done the same both in OpenCL1.2 and OpenCL2.0.
echuraev created this revision.
echuraev added a reviewer: Anastasia.
echuraev added subscribers: bader, cfe-commits, yaxunl.
https://reviews.llvm.org/D27403
Files:
test/CodeGenOpenCL/address-spaces-mangling.cl
Index: test/CodeGenOpenCL/address-spaces-mangling.cl
===
--- test/CodeGenOpenCL/address-spaces-mangling.cl
+++ test/CodeGenOpenCL/address-spaces-mangling.cl
@@ -1,6 +1,10 @@
// RUN: %clang_cc1 %s -ffake-address-space-map
-faddress-space-map-mangling=yes -triple %itanium_abi_triple -emit-llvm -o - |
FileCheck -check-prefix=ASMANG %s
// RUN: %clang_cc1 %s -ffake-address-space-map -faddress-space-map-mangling=no
-triple %itanium_abi_triple -emit-llvm -o - | FileCheck -check-prefix=NOASMANG
%s
+// We check that the address spaces are mangled the same in both version of
OpenCL
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=CL2.0 -emit-llvm -o
- | FileCheck -check-prefix=OCL %s
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=CL1.2 -emit-llvm -o
- | FileCheck -check-prefix=OCL %s
+
// We can't name this f as private is equivalent to default
// no specifier given address space so we get multiple definition
// warnings, but we do want it for comparison purposes.
@@ -28,3 +32,20 @@
void f(constant int *arg) { }
// ASMANG: @_Z1fPU3AS3i
// NOASMANG: @_Z1fPU10CLconstanti
+
+__attribute__((overloadable)) void foo(private char *);
+__attribute__((overloadable)) void foo(global char *);
+__attribute__((overloadable)) void foo(constant char *);
+__attribute__((overloadable)) void foo(local char *);
+
+void bar(global char *gp, constant char *cp, local char *lp) {
+ private char* pp;
+ // OCL: call spir_func void @_Z3fooPc
+ foo(pp);
+ // OCL: call spir_func void @_Z3fooPU3AS1c
+ foo(gp);
+ // OCL: call spir_func void @_Z3fooPU3AS2c
+ foo(cp);
+ // OCL: call spir_func void @_Z3fooPU3AS3c
+ foo(lp);
+}
Index: test/CodeGenOpenCL/address-spaces-mangling.cl
===
--- test/CodeGenOpenCL/address-spaces-mangling.cl
+++ test/CodeGenOpenCL/address-spaces-mangling.cl
@@ -1,6 +1,10 @@
// RUN: %clang_cc1 %s -ffake-address-space-map -faddress-space-map-mangling=yes -triple %itanium_abi_triple -emit-llvm -o - | FileCheck -check-prefix=ASMANG %s
// RUN: %clang_cc1 %s -ffake-address-space-map -faddress-space-map-mangling=no -triple %itanium_abi_triple -emit-llvm -o - | FileCheck -check-prefix=NOASMANG %s
+// We check that the address spaces are mangled the same in both version of OpenCL
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=CL2.0 -emit-llvm -o - | FileCheck -check-prefix=OCL %s
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=CL1.2 -emit-llvm -o - | FileCheck -check-prefix=OCL %s
+
// We can't name this f as private is equivalent to default
// no specifier given address space so we get multiple definition
// warnings, but we do want it for comparison purposes.
@@ -28,3 +32,20 @@
void f(constant int *arg) { }
// ASMANG: @_Z1fPU3AS3i
// NOASMANG: @_Z1fPU10CLconstanti
+
+__attribute__((overloadable)) void foo(private char *);
+__attribute__((overloadable)) void foo(global char *);
+__attribute__((overloadable)) void foo(constant char *);
+__attribute__((overloadable)) void foo(local char *);
+
+void bar(global char *gp, constant char *cp, local char *lp) {
+ private char* pp;
+ // OCL: call spir_func void @_Z3fooPc
+ foo(pp);
+ // OCL: call spir_func void @_Z3fooPU3AS1c
+ foo(gp);
+ // OCL: call spir_func void @_Z3fooPU3AS2c
+ foo(cp);
+ // OCL: call spir_func void @_Z3fooPU3AS3c
+ foo(lp);
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27345: [OpenMP] Sema and parsing for 'teams distribute parallel for' pragma
ABataev added inline comments. Comment at: lib/Basic/OpenMPKinds.cpp:721 DKind == OMPD_target_parallel_for_simd; // TODO add next directives. } You should consider this new directive as a parallel directive. And OMPD_teams_distribute_parallel_for_simd either. Comment at: lib/Basic/OpenMPKinds.cpp:757 Kind == OMPD_distribute_parallel_for_simd || Kind == OMPD_distribute_simd; // TODO add next directives. Should it be added here along with OMPD_teams_distribute_parallel_for_simd? https://reviews.llvm.org/D27345 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27387: [libc++] Add a key function for bad_function_call
EricWF added a reviewer: dexonsmith. EricWF added a subscriber: dexonsmith. EricWF added a comment. In https://reviews.llvm.org/D27387#613071, @smeenai wrote: > In https://reviews.llvm.org/D27387#612975, @EricWF wrote: > > > I wonder if we should consider this a breaking ABI change and control it > > using a `_LIBCPP_ABI` macro. @mclow.lists thoughts? > > > This is forward-compatible (as in clients built against an older libc++ would > be happy with this version) but not backwards-compatible (as in clients built > against this version would not be able to run against an older libc++). Has > libc++ been aiming to maintain compatibility in both directions? Hmm, I'm not exactly sure. We don't make backward incompatible changes to existing code often. I wonder if vendors like Apple require such backwards compatibility. Maybe @dexonsmith can weigh in? https://reviews.llvm.org/D27387 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27277: Make _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR user-settable
EricWF added a comment. @dim Do you still need this to fix the chromium bug? https://reviews.llvm.org/D27277 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26934: [libc++] Add _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
EricWF accepted this revision. EricWF added a comment. This revision is now accepted and ready to land. In https://reviews.llvm.org/D26934#604325, @smeenai wrote: > I'd prefer `#error`; that way we can eventually just drop the macro. Ideally > there wouldn't be too many users to begin with, since it was only introduced > two months ago, and it hasn't made its way to a release yet. If it hasn't even made it into a release then we probably don't need the `#error` at all. Feel free to commit with or w/o it. Either way this LGTM. https://reviews.llvm.org/D26934 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27167: [libc++] Support multibyte decimal_point and thousands_sep
EricWF added a comment. Huh, I thought I had already fixed this but apparently I forgot to commit the patch. You can find my fix here: https://reviews.llvm.org/D24218 https://reviews.llvm.org/D27167 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27204: [libcxxabi] Introduce an externally threaded libc++abi variant
EricWF added a comment.
My main issue with this patch (and https://reviews.llvm.org/D27206) is that
there are now two different CMake options for building two different external
threading libraries. I would much prefer having libc++abi use libc++'s
`__threading_support` header and `cxx_external_threads` library.
Comment at: CMakeLists.txt:124
+ This option may only be set to ON when LIBCXXABI_ENABLE_THREADS=ON." OFF)
+option(LIBCXX_HAS_EXTERNAL_THREAD_API
+ "Build libc++ with an externalized threading API.
It's weird that libc++abi needs to define a libc++ option? Can you elaborate on
the need for this?
Comment at: src/CMakeLists.txt:132
+if (LIBCXXABI_HAS_EXTERNAL_THREAD_API)
+ file(GLOB LIBCXXABI_EXTERNAL_THREADING_SUPPORT_SOURCES
../test/support/external_threads.cpp)
+
Do you really need to glob a single file?
Comment at: test/CMakeLists.txt:41
+if (LIBCXXABI_HAS_EXTERNAL_THREAD_API)
+ list(APPEND LIBCXXABI_TEST_DEPS "cxxabi_external_threads")
+endif()
Target names shouldn't be in quotes.
Comment at: test/CMakeLists.txt:45
+if (LIBCXX_HAS_EXTERNAL_THREAD_API)
+ list(APPEND LIBCXXABI_TEST_DEPS "cxx_external_threads")
+endif()
For the in-tree libc++/libc++abi builds libc++abi gets configured before
libc++, so I don't think libc++ target names are visible in this context.
Are you sure this works?
Comment at: test/libcxxabi/test/config.py:43
+# test_exception_storage_nodynmem.pass.cpp fails under this specific
configuration
+if self.get_lit_bool('cxxabi_ext_threads', False) and
self.get_lit_bool('libcxxabi_shared', False):
+
self.config.available_features.add('libcxxabi-shared-externally-threaded')
`libcxxabi_shared` should default to `True` like it does within the libc++
config.
Comment at: test/lit.cfg:21
# suffixes: A list of file extensions to treat as test files.
-config.suffixes = ['.cpp', '.s']
+config.suffixes = ['.pass.cpp', '.sh.s', '.sh.cpp']
I'm not sure I understand the reason for this change.
https://reviews.llvm.org/D27204
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26837: [analyzer] Litter the SVal/SymExpr/MemRegion class hierarchy with asserts.
baloghadamsoftware added inline comments.
Comment at: include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:282
+ static inline bool isCompoundType(QualType T) {
+return T->isArrayType() || T->isRecordType() ||
Could you please move this function into a separate patch? If I am right,
D27202 depends only on this function which could be accepted earlier than this
whole patch.
https://reviews.llvm.org/D26837
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27153: [libc++] Make __num_get_float hidden
EricWF added a comment. In https://reviews.llvm.org/D27153#606296, @smeenai wrote: > I'm having some second thoughts about this. Visibility for template functions > makes my head spin :/ Is there a general policy we've been following for > these? I didn't find much just scanning through other definitions. I would suggest adding the `inline` keyword so that implicit instantiation are marked hidden when `-fvisibility-inlines-hidden`. That should be sufficient to hide the implicit instantiations in `libc++.so`. https://reviews.llvm.org/D27153 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27277: Make _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR user-settable
dim abandoned this revision. dim added a comment. No, let's drop it. In the FreeBSD ports bug I have posted a patch to use `_LIBCPP_ABI_UNSTABLE ` instead, which appears to work fine. And at some point we'll update to `_LIBCPP_ABI_VERSION` 2, but not today. :) https://reviews.llvm.org/D27277 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27310: Handle tests for noexcept that expect a false value
rogfer01 updated this revision to Diff 80235.
rogfer01 added a comment.
- Rewrite the adjusted tests in the way suggested by @EricWF
- Also check that this test works in a GCC-built libcxx
https://reviews.llvm.org/D27310
Files:
test/libcxx/strings/iterators.exceptions.pass.cpp
Index: test/libcxx/strings/iterators.exceptions.pass.cpp
===
--- test/libcxx/strings/iterators.exceptions.pass.cpp
+++ test/libcxx/strings/iterators.exceptions.pass.cpp
@@ -7,7 +7,6 @@
//
//===--===//
//
-// XFAIL: libcpp-no-exceptions
//
// __libcpp_is_trivial_iterator
@@ -26,6 +25,15 @@
#include "test_macros.h"
#include "test_iterators.h"
+#ifndef TEST_HAS_NO_EXCEPTIONS
+constexpr bool expected = false;
+#else
+// Under libcpp-no-exceptions all noexcept expressions are trivially true, so
+// any check for a noexcept returning false must actually check for it being
+// true.
+constexpr bool expected = true;
+#endif
+
int main()
{
// basic tests
@@ -43,17 +51,17 @@
static_assert((
std::__libcpp_string_gets_noexcept_iterator > > ::value), "");
// iterators in the libc++ test suite
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+
static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+
static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
#if TEST_STD_VER >= 11
static_assert((
std::__libcpp_string_gets_noexcept_iterator
>::value), "");
#else
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
+
static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
#endif
//
Index: test/libcxx/strings/iterators.exceptions.pass.cpp
===
--- test/libcxx/strings/iterators.exceptions.pass.cpp
+++ test/libcxx/strings/iterators.exceptions.pass.cpp
@@ -7,7 +7,6 @@
//
//===--===//
//
-// XFAIL: libcpp-no-exceptions
//
// __libcpp_is_trivial_iterator
@@ -26,6 +25,15 @@
#include "test_macros.h"
#include "test_iterators.h"
+#ifndef TEST_HAS_NO_EXCEPTIONS
+constexpr bool expected = false;
+#else
+// Under libcpp-no-exceptions all noexcept expressions are trivially true, so
+// any check for a noexcept returning false must actually check for it being
+// true.
+constexpr bool expected = true;
+#endif
+
int main()
{
// basic tests
@@ -43,17 +51,17 @@
static_assert(( std::__libcpp_string_gets_noexcept_iterator > > ::value), "");
// iterators in the libc++ test suite
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
#if TEST_STD_VER >= 11
static_assert(( std::__libcpp_string_gets_noexcept_iterator >::value), "");
#else
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
#endif
//
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-c
[PATCH] D27310: Handle tests for noexcept that expect a false value
EricWF added a comment. Please address the inline comments before committing. Comment at: test/libcxx/strings/iterators.exceptions.pass.cpp:29 +#ifndef TEST_HAS_NO_EXCEPTIONS +constexpr bool expected = false; +#else We can't use constexpr because these tests run in C++03. However `const bool expected = ...` should give you a value you can use in constant expressions. https://reviews.llvm.org/D27310 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26896: [libcxx] Make constexpr char_traits and char_traits
EricWF added a comment.
The tests LGTM. The implementation still needs some tweaks. Thanks for working
on this.
Comment at: include/__config:925
+#if !__has_builtin(__builtin_memcpy)
+#define _LIBCPP_HAS_NO_BUILTIN_MEMCPY
AntonBikineev wrote:
> EricWF wrote:
> > What about GCC? Surely it implements some if not most of these.
> Thanks, good point. I've done it in the same way as it is done for
> __buitin_addressof. On the other hand, gcc has an option -fno-builtin to
> disable them. That way it *won't* compile. I try to stick to the current
> solution though.
A couple of problems with your usage of `_GNUC_VER`.
First `_GNUC_VER` is always 421 when using Clang, so the above check never
fails with Clang.
Second we require at least GCC 4.8/4.9. Don't bother configuring for anything
older than that.
Comment at: include/__string:213
-static inline int compare(const char_type* __s1, const char_type* __s2,
size_t __n) _NOEXCEPT
-{return __n == 0 ? 0 : memcmp(__s1, __s2, __n);}
-static inline size_t length(const char_type* __s) _NOEXCEPT {return
strlen(__s);}
-static inline const char_type* find(const char_type* __s, size_t __n,
const char_type& __a) _NOEXCEPT
-{return __n == 0 ? NULL : (const char_type*) memchr(__s,
to_int_type(__a), __n);}
+#if _LIBCPP_STD_VER > 14 && !defined(_LIBCPP_HAS_NO_CXX14_CONSTEXPR)
+static inline constexpr int
mclow.lists wrote:
> AntonBikineev wrote:
> > EricWF wrote:
> > > wow. This is #ifdef hell. Please find a way to do it with less (or
> > > hopefully no) conditional compilation blocks.
> > yep, this is generic hell. I want to cover as many cases as possible, i.e.
> > combinations of (is_constexpr x has_builtin_xxx) for every function. I'm
> > open to suggestions
> How about (for compare, say) you just forget about `memcmp`. Either call
> `__builtin_memcmp` if it is available, or use a hand-rolled loop.
>
> Note: gcc has had `__builtin_memcmp` since at least 4.8. (and it is constexpr)
>
> And just mark the function with `_LIBCPP_CONSTEXPR_AFTER_CXX14`.
Exactly what @mclow.lists said. That seems like the correct solution. We're
*always* going to have `__builtin_memcmp` for all of our supported compilers
AFAIK.
https://reviews.llvm.org/D26896
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27162: Support relaxed constexpr on chrono::duration operations
EricWF accepted this revision. EricWF added a comment. This revision is now accepted and ready to land. LGTM as well. https://reviews.llvm.org/D27162 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27310: Handle tests for noexcept that expect a false value
rogfer01 added inline comments. Comment at: test/libcxx/strings/iterators.exceptions.pass.cpp:29 +#ifndef TEST_HAS_NO_EXCEPTIONS +constexpr bool expected = false; +#else EricWF wrote: > We can't use constexpr because these tests run in C++03. However `const bool > expected = ...` should give you a value you can use in constant expressions. Ah, I was confused by the usage of C++11 headers in this file but I will use a `static const bool` instead. Thanks. https://reviews.llvm.org/D27310 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27310: Handle tests for noexcept that expect a false value
EricWF added inline comments. Comment at: test/libcxx/strings/iterators.exceptions.pass.cpp:29 +#ifndef TEST_HAS_NO_EXCEPTIONS +constexpr bool expected = false; +#else rogfer01 wrote: > EricWF wrote: > > We can't use constexpr because these tests run in C++03. However `const > > bool expected = ...` should give you a value you can use in constant > > expressions. > Ah, I was confused by the usage of C++11 headers in this file but I will use > a `static const bool` instead. Thanks. No worries. It is super confusing, especially since we can use `static_assert` but not `constexpr`. Libc++ goes out of its way to provide as much C++11 in C++03 as possible, but there are weird limitations. https://reviews.llvm.org/D27310 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27204: [libcxxabi] Introduce an externally threaded libc++abi variant
rmaprath added a comment. In https://reviews.llvm.org/D27204#613122, @EricWF wrote: > My main issue with this patch (and https://reviews.llvm.org/D27206) is that > there are now two different CMake options for building two different external > threading libraries. I would much prefer having libc++abi use libc++'s > `__threading_support` header and `cxx_external_threads` library. I would like to do that too! But I always viewed `libcxx` and `libcxxabi` as two independent libraries that should be usable on their own. In this case, binding `libcxxabi` to `__threading_support` from `libcxx` sounded wrong, because `__threading_support` is something internal to `libcxx` (e.g. all the functions there are prefixed with `__libcpp_` - there may be other `libcpp`-isms arising from `__config` in there too). Is that not a concern? I could give it a shot and try to merge the two APIs into one if not. https://reviews.llvm.org/D27204 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27204: [libcxxabi] Introduce an externally threaded libc++abi variant
EricWF added a comment. In https://reviews.llvm.org/D27204#613172, @rmaprath wrote: > In https://reviews.llvm.org/D27204#613122, @EricWF wrote: > > > My main issue with this patch (and https://reviews.llvm.org/D27206) is that > > there are now two different CMake options for building two different > > external threading libraries. I would much prefer having libc++abi use > > libc++'s `__threading_support` header and `cxx_external_threads` library. > > > I would like to do that too! > > But I always viewed `libcxx` and `libcxxabi` as two independent libraries > that should be usable on their own. In this case, binding `libcxxabi` to > `__threading_support` from `libcxx` sounded wrong, because > `__threading_support` is something internal to `libcxx` (e.g. all the > functions there are prefixed with `__libcpp_` - there may be other > `libcpp`-isms arising from `__config` in there too). Ironically I've always viewed `libcxxabi` as fully dependent on `libcxx` (and personally I would like to see the repos merged; Although using libc++ w/o libc++abi would still be supported). > Is that not a concern? I could give it a shot and try to merge the two APIs > into one if not. It's not a concern. Libc++abi already depends on libc++ internals to build (See the `#include "__refstring" in `stdlib_stdexcept.cpp`). https://reviews.llvm.org/D27204 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27310: Handle tests for noexcept that expect a false value
rogfer01 updated this revision to Diff 80238.
rogfer01 added a comment.
Do not use constexpr.
https://reviews.llvm.org/D27310
Files:
test/libcxx/strings/iterators.exceptions.pass.cpp
Index: test/libcxx/strings/iterators.exceptions.pass.cpp
===
--- test/libcxx/strings/iterators.exceptions.pass.cpp
+++ test/libcxx/strings/iterators.exceptions.pass.cpp
@@ -7,7 +7,6 @@
//
//===--===//
//
-// XFAIL: libcpp-no-exceptions
//
// __libcpp_is_trivial_iterator
@@ -26,6 +25,15 @@
#include "test_macros.h"
#include "test_iterators.h"
+#ifndef TEST_HAS_NO_EXCEPTIONS
+static const bool expected = false;
+#else
+// Under libcpp-no-exceptions all noexcept expressions are trivially true, so
+// any check for a noexcept returning false must actually check for it being
+// true.
+static const bool expected = true;
+#endif
+
int main()
{
// basic tests
@@ -43,17 +51,17 @@
static_assert((
std::__libcpp_string_gets_noexcept_iterator > > ::value), "");
// iterators in the libc++ test suite
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+
static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+
static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
#if TEST_STD_VER >= 11
static_assert((
std::__libcpp_string_gets_noexcept_iterator
>::value), "");
#else
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
+
static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
#endif
//
Index: test/libcxx/strings/iterators.exceptions.pass.cpp
===
--- test/libcxx/strings/iterators.exceptions.pass.cpp
+++ test/libcxx/strings/iterators.exceptions.pass.cpp
@@ -7,7 +7,6 @@
//
//===--===//
//
-// XFAIL: libcpp-no-exceptions
//
// __libcpp_is_trivial_iterator
@@ -26,6 +25,15 @@
#include "test_macros.h"
#include "test_iterators.h"
+#ifndef TEST_HAS_NO_EXCEPTIONS
+static const bool expected = false;
+#else
+// Under libcpp-no-exceptions all noexcept expressions are trivially true, so
+// any check for a noexcept returning false must actually check for it being
+// true.
+static const bool expected = true;
+#endif
+
int main()
{
// basic tests
@@ -43,17 +51,17 @@
static_assert(( std::__libcpp_string_gets_noexcept_iterator > > ::value), "");
// iterators in the libc++ test suite
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
#if TEST_STD_VER >= 11
static_assert(( std::__libcpp_string_gets_noexcept_iterator >::value), "");
#else
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
#endif
//
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27068: Improve string::find
EricWF added a comment. @mclow.lists I'm going to leave this review up to you. I don't see any immediate issues. https://reviews.llvm.org/D27068 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26376: Undef stdatomic.h macro definitions that are defining functions provided in libc++
EricWF added a comment. Yeah this seems like a configuration that simply can't be supported. I'm not sure if this patch is a great idea. https://reviews.llvm.org/D26376 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27204: [libcxxabi] Introduce an externally threaded libc++abi variant
rmaprath added a comment.
In https://reviews.llvm.org/D27204#613177, @EricWF wrote:
> In https://reviews.llvm.org/D27204#613172, @rmaprath wrote:
>
> > In https://reviews.llvm.org/D27204#613122, @EricWF wrote:
> >
> > > My main issue with this patch (and https://reviews.llvm.org/D27206) is
> > > that there are now two different CMake options for building two different
> > > external threading libraries. I would much prefer having libc++abi use
> > > libc++'s `__threading_support` header and `cxx_external_threads` library.
> >
> >
> > I would like to do that too!
> >
> > But I always viewed `libcxx` and `libcxxabi` as two independent libraries
> > that should be usable on their own. In this case, binding `libcxxabi` to
> > `__threading_support` from `libcxx` sounded wrong, because
> > `__threading_support` is something internal to `libcxx` (e.g. all the
> > functions there are prefixed with `__libcpp_` - there may be other
> > `libcpp`-isms arising from `__config` in there too).
>
>
> Ironically I've always viewed `libcxxabi` as fully dependent on `libcxx` (and
> personally I would like to see the repos merged; Although using libc++ w/o
> libc++abi would still be supported).
>
>
>
> > Is that not a concern? I could give it a shot and try to merge the two APIs
> > into one if not.
>
> It's not a concern. Libc++abi already depends on libc++ internals to build
> (See the `#include "__refstring" in `stdlib_stdexcept.cpp`).
Thanks for the clarification. I'll re-spin the patch.
Responses to inline comments follow, but some of those would go away with the
re-spin I imagine.
Comment at: CMakeLists.txt:124
+ This option may only be set to ON when LIBCXXABI_ENABLE_THREADS=ON." OFF)
+option(LIBCXX_HAS_EXTERNAL_THREAD_API
+ "Build libc++ with an externalized threading API.
EricWF wrote:
> It's weird that libc++abi needs to define a libc++ option? Can you elaborate
> on the need for this?
The `libcxxabi` test suite builds `libcxx` as part of running the test suite, I
thought a separate option would be appropriate here to allow users to select
which configuration they want to build `libcxx` for those tests.
Given the new knowledge I have, I think the right thing to do here is configure
`libcxx` to also use external threads when `libcxxabi` is configured to use
external threads, rather than providing a separate option here. Will fix.
Comment at: src/CMakeLists.txt:132
+if (LIBCXXABI_HAS_EXTERNAL_THREAD_API)
+ file(GLOB LIBCXXABI_EXTERNAL_THREADING_SUPPORT_SOURCES
../test/support/external_threads.cpp)
+
EricWF wrote:
> Do you really need to glob a single file?
Copy-paste, will fix.
Comment at: test/CMakeLists.txt:41
+if (LIBCXXABI_HAS_EXTERNAL_THREAD_API)
+ list(APPEND LIBCXXABI_TEST_DEPS "cxxabi_external_threads")
+endif()
EricWF wrote:
> Target names shouldn't be in quotes.
Will fix.
Comment at: test/CMakeLists.txt:45
+if (LIBCXX_HAS_EXTERNAL_THREAD_API)
+ list(APPEND LIBCXXABI_TEST_DEPS "cxx_external_threads")
+endif()
EricWF wrote:
> For the in-tree libc++/libc++abi builds libc++abi gets configured before
> libc++, so I don't think libc++ target names are visible in this context.
> Are you sure this works?
This worked fine for me. All my builds are in-tree as well.
I also checked if the order in which tests are run (whether `libcxx` runs
before `libcxxabi` and vice-versa) makes no difference.
I will double check still.
Comment at: test/libcxxabi/test/config.py:43
+# test_exception_storage_nodynmem.pass.cpp fails under this specific
configuration
+if self.get_lit_bool('cxxabi_ext_threads', False) and
self.get_lit_bool('libcxxabi_shared', False):
+
self.config.available_features.add('libcxxabi-shared-externally-threaded')
EricWF wrote:
> `libcxxabi_shared` should default to `True` like it does within the libc++
> config.
>
Not sure if I follow, I'm trying to detect this particular combination of
configs so that I can xfail a particular test.
Comment at: test/lit.cfg:21
# suffixes: A list of file extensions to treat as test files.
-config.suffixes = ['.cpp', '.s']
+config.suffixes = ['.pass.cpp', '.sh.s', '.sh.cpp']
EricWF wrote:
> I'm not sure I understand the reason for this change.
I should've put a comment. The test suite keeps trying to run
`test/support/external_threading.cpp` as a test case without this. Perhaps
there is a better way to handle that situation?
https://reviews.llvm.org/D27204
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27350: CFGBuilder: Fix crash when visiting delete expression on dependent type
klimek accepted this revision. klimek added a comment. This revision is now accepted and ready to land. lg https://reviews.llvm.org/D27350 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r288660 - Handle tests for noexcept that expect a false value
Author: rogfer01
Date: Mon Dec 5 05:05:09 2016
New Revision: 288660
URL: http://llvm.org/viewvc/llvm-project?rev=288660&view=rev
Log:
Handle tests for noexcept that expect a false value
Under libcpp-no-exceptions, noexcept is trivially true. Some tests expect in
the usual setting to return false, so adjust them to expect true under
libcpp-no-exceptions.
Differential Revision: https://reviews.llvm.org/D27310
Modified:
libcxx/trunk/test/libcxx/strings/iterators.exceptions.pass.cpp
Modified: libcxx/trunk/test/libcxx/strings/iterators.exceptions.pass.cpp
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/strings/iterators.exceptions.pass.cpp?rev=288660&r1=288659&r2=288660&view=diff
==
--- libcxx/trunk/test/libcxx/strings/iterators.exceptions.pass.cpp (original)
+++ libcxx/trunk/test/libcxx/strings/iterators.exceptions.pass.cpp Mon Dec 5
05:05:09 2016
@@ -7,7 +7,6 @@
//
//===--===//
//
-// XFAIL: libcpp-no-exceptions
//
// __libcpp_is_trivial_iterator
@@ -26,6 +25,15 @@
#include "test_macros.h"
#include "test_iterators.h"
+#ifndef TEST_HAS_NO_EXCEPTIONS
+static const bool expected = false;
+#else
+// Under libcpp-no-exceptions all noexcept expressions are trivially true, so
+// any check for a noexcept returning false must actually check for it being
+// true.
+static const bool expected = true;
+#endif
+
int main()
{
// basic tests
@@ -43,17 +51,17 @@ int main()
static_assert((
std::__libcpp_string_gets_noexcept_iterator > > ::value), "");
// iterators in the libc++ test suite
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+
static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+
static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
#if TEST_STD_VER >= 11
static_assert((
std::__libcpp_string_gets_noexcept_iterator
>::value), "");
#else
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
+
static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
#endif
//
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27310: Handle tests for noexcept that expect a false value
This revision was automatically updated to reflect the committed changes.
Closed by commit rL288660: Handle tests for noexcept that expect a false value
(authored by rogfer01).
Changed prior to commit:
https://reviews.llvm.org/D27310?vs=80238&id=80242#toc
Repository:
rL LLVM
https://reviews.llvm.org/D27310
Files:
libcxx/trunk/test/libcxx/strings/iterators.exceptions.pass.cpp
Index: libcxx/trunk/test/libcxx/strings/iterators.exceptions.pass.cpp
===
--- libcxx/trunk/test/libcxx/strings/iterators.exceptions.pass.cpp
+++ libcxx/trunk/test/libcxx/strings/iterators.exceptions.pass.cpp
@@ -7,7 +7,6 @@
//
//===--===//
//
-// XFAIL: libcpp-no-exceptions
//
// __libcpp_is_trivial_iterator
@@ -26,6 +25,15 @@
#include "test_macros.h"
#include "test_iterators.h"
+#ifndef TEST_HAS_NO_EXCEPTIONS
+static const bool expected = false;
+#else
+// Under libcpp-no-exceptions all noexcept expressions are trivially true, so
+// any check for a noexcept returning false must actually check for it being
+// true.
+static const bool expected = true;
+#endif
+
int main()
{
// basic tests
@@ -43,17 +51,17 @@
static_assert((
std::__libcpp_string_gets_noexcept_iterator > > ::value), "");
// iterators in the libc++ test suite
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+
static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+
static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
#if TEST_STD_VER >= 11
static_assert((
std::__libcpp_string_gets_noexcept_iterator
>::value), "");
#else
-
static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
+
static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
#endif
//
Index: libcxx/trunk/test/libcxx/strings/iterators.exceptions.pass.cpp
===
--- libcxx/trunk/test/libcxx/strings/iterators.exceptions.pass.cpp
+++ libcxx/trunk/test/libcxx/strings/iterators.exceptions.pass.cpp
@@ -7,7 +7,6 @@
//
//===--===//
//
-// XFAIL: libcpp-no-exceptions
//
// __libcpp_is_trivial_iterator
@@ -26,6 +25,15 @@
#include "test_macros.h"
#include "test_iterators.h"
+#ifndef TEST_HAS_NO_EXCEPTIONS
+static const bool expected = false;
+#else
+// Under libcpp-no-exceptions all noexcept expressions are trivially true, so
+// any check for a noexcept returning false must actually check for it being
+// true.
+static const bool expected = true;
+#endif
+
int main()
{
// basic tests
@@ -43,17 +51,17 @@
static_assert(( std::__libcpp_string_gets_noexcept_iterator > > ::value), "");
// iterators in the libc++ test suite
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
+static_assert(std::__libcpp_string_gets_noexcept_iterator >::value == expected, "");
#if TEST_STD_VER >= 11
static_assert(( std::__libcpp_string_gets_noexcept_iterator >::value), "");
#else
-static_assert((!std::__libcpp_string_gets_noexcept_iterator >::value), "");
+static_assert(std::__libcpp_string_gets_noexcept_iterato
Re: clang-format-vsix: versioning patch and show stderrors patch
Awesome, thanks for working on this. If you submit the patches via phabricator (http://llvm.org/docs/Phabricator.html) I'll get to it faster :) Feel free to directly add me as reviewer, btw (add 'klimek'). On Sat, Dec 3, 2016 at 6:53 AM Antonio Maiorano via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Hello, > > I have two patches for clang-format-vsix to offer up for review: > > 0001-clang-format-vsix-versioning.patch > clang-format-vsix: add a date stamp to the VSIX version number to ensure > upgradability > > Presently, the version number of the VSIX matches the LLVM version number. > However, as this number doesn't change often, it means that as we release > new versions of this VSIX, it will have the same version number, which > means users must first uninstall the old version before installing the new > one. With this change, we generate a 4th part to the version number that is > a date stamp (year, month, day); for example: 4.0.0.161203. > > > 0001-clang-format-vsix-show-stderrs.patch > clang-format-vsix: fail when clang-format outputs to stderr > > When clang-format outputs to stderr but returns 0, the extension will > format the code anyway. This happens, for instance, when there's a syntax > error or unknown value in a .clang-format file; the result is that the > extension silently formats using the fallback style without informing the > user of the problem. This change treats stderr output as an error, making > sure it gets displayed to the user, and not formatting the code. (I've also > attached a screenshot of the message box I now get when my .clang-format > has an invalid field named SomeInvalidField). > > > ___ > 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
[clang-tools-extra] r288662 - [change-namespace] get changing namespace to global correct.
Author: ioeric
Date: Mon Dec 5 05:17:04 2016
New Revision: 288662
URL: http://llvm.org/viewvc/llvm-project?rev=288662&view=rev
Log:
[change-namespace] get changing namespace to global correct.
Modified:
clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp
clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp
Modified: clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp
URL:
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp?rev=288662&r1=288661&r2=288662&view=diff
==
--- clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp (original)
+++ clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp Mon Dec 5
05:17:04 2016
@@ -210,7 +210,8 @@ std::string wrapCodeInNamespace(StringRe
if (Code.back() != '\n')
Code += "\n";
llvm::SmallVector NsSplitted;
- NestedNs.split(NsSplitted, "::");
+ NestedNs.split(NsSplitted, "::", /*MaxSplit=*/-1,
+ /*KeepEmpty=*/false);
while (!NsSplitted.empty()) {
// FIXME: consider code style for comments.
Code = ("namespace " + NsSplitted.back() + " {\n" + Code +
@@ -272,7 +273,9 @@ void ChangeNamespaceTool::registerMatche
// be "a::b". Declarations in this namespace will not be visible in the new
// namespace. If DiffOldNamespace is empty, Prefix will be a invalid name
"-".
llvm::SmallVector DiffOldNsSplitted;
- llvm::StringRef(DiffOldNamespace).split(DiffOldNsSplitted, "::");
+ llvm::StringRef(DiffOldNamespace)
+ .split(DiffOldNsSplitted, "::", /*MaxSplit=*/-1,
+ /*KeepEmpty=*/false);
std::string Prefix = "-";
if (!DiffOldNsSplitted.empty())
Prefix = (StringRef(FullOldNs).drop_back(DiffOldNamespace.size()) +
Modified:
clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp
URL:
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp?rev=288662&r1=288661&r2=288662&view=diff
==
--- clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp
(original)
+++ clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp
Mon Dec 5 05:17:04 2016
@@ -1114,6 +1114,42 @@ TEST_F(ChangeNamespaceTest, DerivedClass
EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
}
+TEST_F(ChangeNamespaceTest, MoveToGlobalNamespace) {
+ NewNamespace = "";
+ std::string Code = "namespace na {\n"
+ "class C_A {};\n"
+ "namespace nc {\n"
+ "class C_C {};"
+ "} // namespace nc\n"
+ "namespace nb {\n"
+ "class C_X {\n"
+ "public:\n"
+ " C_A a;\n"
+ " nc::C_C c;\n"
+ "};\n"
+ "class C_Y {\n"
+ " C_X x;\n"
+ "};\n"
+ "} // namespace nb\n"
+ "} // namespace na\n";
+ std::string Expected = "namespace na {\n"
+ "class C_A {};\n"
+ "namespace nc {\n"
+ "class C_C {};"
+ "} // namespace nc\n"
+ "\n"
+ "} // namespace na\n"
+ "class C_X {\n"
+ "public:\n"
+ " na::C_A a;\n"
+ " na::nc::C_C c;\n"
+ "};\n"
+ "class C_Y {\n"
+ " C_X x;\n"
+ "};\n";
+ EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
+}
+
} // anonymous namespace
} // namespace change_namespace
} // namespace clang
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r288664 - Clean out unused diagnostics. NFC.
Author: d0k Date: Mon Dec 5 05:30:24 2016 New Revision: 288664 URL: http://llvm.org/viewvc/llvm-project?rev=288664&view=rev Log: Clean out unused diagnostics. NFC. Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td?rev=288664&r1=288663&r2=288664&view=diff == --- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td (original) +++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td Mon Dec 5 05:30:24 2016 @@ -422,8 +422,6 @@ def err_unexpected_protocol_qualifier : "@implementation declaration cannot be protocol qualified">; def err_objc_unexpected_atend : Error< "'@end' appears where closing brace '}' is expected">; -def err_property_ivar_decl : Error< - "property synthesize requires specification of an ivar">; def err_synthesized_property_name : Error< "expected a property name in @synthesize">; def warn_semicolon_before_method_body : Warning< Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=288664&r1=288663&r2=288664&view=diff == --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original) +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Mon Dec 5 05:30:24 2016 @@ -1050,8 +1050,6 @@ def err_synthesize_category_decl : Error "@synthesize not allowed in a category's implementation">; def err_synthesize_on_class_property : Error< "@synthesize not allowed on a class property %0">; -def err_reference_property : Error< - "property of reference type is not supported">; def err_missing_property_interface : Error< "property implementation in a category with no category declaration">; def err_bad_category_property_decl : Error< @@ -1306,8 +1304,6 @@ def err_mismatched_exception_spec : Erro "exception specification in declaration does not match previous declaration">; def ext_mismatched_exception_spec : ExtWarn, InGroup; -def warn_mismatched_exception_spec_no_exceptions : ExtWarn, - InGroup>; def err_override_exception_spec : Error< "exception specification of overriding function is more lax than " "base version">; @@ -7943,8 +7939,6 @@ def warn_direct_super_initialize_call : InGroup; def err_ivar_use_in_class_method : Error< "instance variable %0 accessed in class method">; -def err_implicit_ivar_access : Error< - "instance variable %0 cannot be accessed because 'self' has been redeclared">; def err_private_ivar_access : Error<"instance variable %0 is private">, AccessControl; def err_protected_ivar_access : Error<"instance variable %0 is protected">, ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27350: CFGBuilder: Fix crash when visiting delete expression on dependent type
This revision was automatically updated to reflect the committed changes.
Closed by commit rL288665: CFGBuilder: Fix crash when visiting delete
expression on dependent type (authored by mboehme).
Changed prior to commit:
https://reviews.llvm.org/D27350?vs=80080&id=80246#toc
Repository:
rL LLVM
https://reviews.llvm.org/D27350
Files:
cfe/trunk/lib/Analysis/CFG.cpp
cfe/trunk/unittests/Analysis/CFGTest.cpp
Index: cfe/trunk/lib/Analysis/CFG.cpp
===
--- cfe/trunk/lib/Analysis/CFG.cpp
+++ cfe/trunk/lib/Analysis/CFG.cpp
@@ -3581,11 +3581,13 @@
autoCreateBlock();
appendStmt(Block, DE);
QualType DTy = DE->getDestroyedType();
- DTy = DTy.getNonReferenceType();
- CXXRecordDecl *RD = Context->getBaseElementType(DTy)->getAsCXXRecordDecl();
- if (RD) {
-if (RD->isCompleteDefinition() && !RD->hasTrivialDestructor())
- appendDeleteDtor(Block, RD, DE);
+ if (!DTy.isNull()) {
+DTy = DTy.getNonReferenceType();
+CXXRecordDecl *RD = Context->getBaseElementType(DTy)->getAsCXXRecordDecl();
+if (RD) {
+ if (RD->isCompleteDefinition() && !RD->hasTrivialDestructor())
+appendDeleteDtor(Block, RD, DE);
+}
}
return VisitChildren(DE);
Index: cfe/trunk/unittests/Analysis/CFGTest.cpp
===
--- cfe/trunk/unittests/Analysis/CFGTest.cpp
+++ cfe/trunk/unittests/Analysis/CFGTest.cpp
@@ -18,6 +18,41 @@
namespace analysis {
namespace {
+enum BuildResult {
+ ToolFailed,
+ ToolRan,
+ SawFunctionBody,
+ BuiltCFG,
+};
+
+class CFGCallback : public ast_matchers::MatchFinder::MatchCallback {
+public:
+ BuildResult TheBuildResult = ToolRan;
+
+ void run(const ast_matchers::MatchFinder::MatchResult &Result) override {
+const auto *Func = Result.Nodes.getNodeAs("func");
+Stmt *Body = Func->getBody();
+if (!Body)
+ return;
+TheBuildResult = SawFunctionBody;
+if (CFG::buildCFG(nullptr, Body, Result.Context, CFG::BuildOptions()))
+TheBuildResult = BuiltCFG;
+ }
+};
+
+BuildResult BuildCFG(const char *Code) {
+ CFGCallback Callback;
+
+ ast_matchers::MatchFinder Finder;
+ Finder.addMatcher(ast_matchers::functionDecl().bind("func"), &Callback);
+ std::unique_ptr Factory(
+ tooling::newFrontendActionFactory(&Finder));
+ std::vector Args = {"-std=c++11", "-fno-delayed-template-parsing"};
+ if (!tooling::runToolOnCodeWithArgs(Factory->create(), Code, Args))
+return ToolFailed;
+ return Callback.TheBuildResult;
+}
+
// Constructing a CFG for a range-based for over a dependent type fails (but
// should not crash).
TEST(CFG, RangeBasedForOverDependentType) {
@@ -27,30 +62,17 @@
" for (const Foo *TheFoo : Range) {\n"
" }\n"
"}\n";
+ EXPECT_EQ(SawFunctionBody, BuildCFG(Code));
+}
- class CFGCallback : public ast_matchers::MatchFinder::MatchCallback {
- public:
-bool SawFunctionBody = false;
-
-void run(const ast_matchers::MatchFinder::MatchResult &Result) override {
- const auto *Func = Result.Nodes.getNodeAs("func");
- Stmt *Body = Func->getBody();
- if (!Body)
-return;
- SawFunctionBody = true;
- std::unique_ptr cfg =
- CFG::buildCFG(nullptr, Body, Result.Context, CFG::BuildOptions());
- EXPECT_EQ(nullptr, cfg);
-}
- } Callback;
-
- ast_matchers::MatchFinder Finder;
- Finder.addMatcher(ast_matchers::functionDecl().bind("func"), &Callback);
- std::unique_ptr Factory(
- tooling::newFrontendActionFactory(&Finder));
- std::vector Args = {"-std=c++11", "-fno-delayed-template-parsing"};
- ASSERT_TRUE(tooling::runToolOnCodeWithArgs(Factory->create(), Code, Args));
- EXPECT_TRUE(Callback.SawFunctionBody);
+// Constructing a CFG containing a delete expression on a dependent type should
+// not crash.
+TEST(CFG, DeleteExpressionOnDependentType) {
+ const char *Code = "template\n"
+ "void f(T t) {\n"
+ " delete t;\n"
+ "}\n";
+ EXPECT_EQ(BuiltCFG, BuildCFG(Code));
}
} // namespace
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r288665 - CFGBuilder: Fix crash when visiting delete expression on dependent type
Author: mboehme
Date: Mon Dec 5 05:33:19 2016
New Revision: 288665
URL: http://llvm.org/viewvc/llvm-project?rev=288665&view=rev
Log:
CFGBuilder: Fix crash when visiting delete expression on dependent type
Summary:
CXXDeleteExpr::getDestroyedType() can return a null QualType if the destroyed
type is a dependent type. This patch protects against this.
Reviewers: klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27350
Modified:
cfe/trunk/lib/Analysis/CFG.cpp
cfe/trunk/unittests/Analysis/CFGTest.cpp
Modified: cfe/trunk/lib/Analysis/CFG.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/CFG.cpp?rev=288665&r1=288664&r2=288665&view=diff
==
--- cfe/trunk/lib/Analysis/CFG.cpp (original)
+++ cfe/trunk/lib/Analysis/CFG.cpp Mon Dec 5 05:33:19 2016
@@ -3581,11 +3581,13 @@ CFGBlock *CFGBuilder::VisitCXXDeleteExpr
autoCreateBlock();
appendStmt(Block, DE);
QualType DTy = DE->getDestroyedType();
- DTy = DTy.getNonReferenceType();
- CXXRecordDecl *RD = Context->getBaseElementType(DTy)->getAsCXXRecordDecl();
- if (RD) {
-if (RD->isCompleteDefinition() && !RD->hasTrivialDestructor())
- appendDeleteDtor(Block, RD, DE);
+ if (!DTy.isNull()) {
+DTy = DTy.getNonReferenceType();
+CXXRecordDecl *RD = Context->getBaseElementType(DTy)->getAsCXXRecordDecl();
+if (RD) {
+ if (RD->isCompleteDefinition() && !RD->hasTrivialDestructor())
+appendDeleteDtor(Block, RD, DE);
+}
}
return VisitChildren(DE);
Modified: cfe/trunk/unittests/Analysis/CFGTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Analysis/CFGTest.cpp?rev=288665&r1=288664&r2=288665&view=diff
==
--- cfe/trunk/unittests/Analysis/CFGTest.cpp (original)
+++ cfe/trunk/unittests/Analysis/CFGTest.cpp Mon Dec 5 05:33:19 2016
@@ -18,6 +18,41 @@ namespace clang {
namespace analysis {
namespace {
+enum BuildResult {
+ ToolFailed,
+ ToolRan,
+ SawFunctionBody,
+ BuiltCFG,
+};
+
+class CFGCallback : public ast_matchers::MatchFinder::MatchCallback {
+public:
+ BuildResult TheBuildResult = ToolRan;
+
+ void run(const ast_matchers::MatchFinder::MatchResult &Result) override {
+const auto *Func = Result.Nodes.getNodeAs("func");
+Stmt *Body = Func->getBody();
+if (!Body)
+ return;
+TheBuildResult = SawFunctionBody;
+if (CFG::buildCFG(nullptr, Body, Result.Context, CFG::BuildOptions()))
+TheBuildResult = BuiltCFG;
+ }
+};
+
+BuildResult BuildCFG(const char *Code) {
+ CFGCallback Callback;
+
+ ast_matchers::MatchFinder Finder;
+ Finder.addMatcher(ast_matchers::functionDecl().bind("func"), &Callback);
+ std::unique_ptr Factory(
+ tooling::newFrontendActionFactory(&Finder));
+ std::vector Args = {"-std=c++11",
"-fno-delayed-template-parsing"};
+ if (!tooling::runToolOnCodeWithArgs(Factory->create(), Code, Args))
+return ToolFailed;
+ return Callback.TheBuildResult;
+}
+
// Constructing a CFG for a range-based for over a dependent type fails (but
// should not crash).
TEST(CFG, RangeBasedForOverDependentType) {
@@ -27,30 +62,17 @@ TEST(CFG, RangeBasedForOverDependentType
" for (const Foo *TheFoo : Range) {\n"
" }\n"
"}\n";
+ EXPECT_EQ(SawFunctionBody, BuildCFG(Code));
+}
- class CFGCallback : public ast_matchers::MatchFinder::MatchCallback {
- public:
-bool SawFunctionBody = false;
-
-void run(const ast_matchers::MatchFinder::MatchResult &Result) override {
- const auto *Func = Result.Nodes.getNodeAs("func");
- Stmt *Body = Func->getBody();
- if (!Body)
-return;
- SawFunctionBody = true;
- std::unique_ptr cfg =
- CFG::buildCFG(nullptr, Body, Result.Context, CFG::BuildOptions());
- EXPECT_EQ(nullptr, cfg);
-}
- } Callback;
-
- ast_matchers::MatchFinder Finder;
- Finder.addMatcher(ast_matchers::functionDecl().bind("func"), &Callback);
- std::unique_ptr Factory(
- tooling::newFrontendActionFactory(&Finder));
- std::vector Args = {"-std=c++11",
"-fno-delayed-template-parsing"};
- ASSERT_TRUE(tooling::runToolOnCodeWithArgs(Factory->create(), Code, Args));
- EXPECT_TRUE(Callback.SawFunctionBody);
+// Constructing a CFG containing a delete expression on a dependent type should
+// not crash.
+TEST(CFG, DeleteExpressionOnDependentType) {
+ const char *Code = "template\n"
+ "void f(T t) {\n"
+ " delete t;\n"
+ "}\n";
+ EXPECT_EQ(BuiltCFG, BuildCFG(Code));
}
} // namespace
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27408: [analyzer] RetainCountChecker: remove unused enum value; NFC.
NoQ created this revision.
NoQ added reviewers: zaks.anna, dcoughlin.
NoQ added a subscriber: cfe-commits.
`OwnedSymbol` is not used anywhere; `OwnedAllocatedSymbol` is used instead. I
couldn't grasp the intended difference between the two, maybe we should remove
it?
https://reviews.llvm.org/D27408
Files:
include/clang/StaticAnalyzer/Checkers/ObjCRetainCount.h
lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
Index: lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
+++ lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
@@ -740,7 +740,7 @@
ObjCAllocRetE(gcenabled
? RetEffect::MakeGCNotOwned()
: (usesARC ? RetEffect::MakeNotOwned(RetEffect::ObjC)
- : RetEffect::MakeOwned(RetEffect::ObjC, true))),
+ : RetEffect::MakeOwned(RetEffect::ObjC))),
ObjCInitRetE(gcenabled
? RetEffect::MakeGCNotOwned()
: (usesARC ? RetEffect::MakeNotOwned(RetEffect::ObjC)
@@ -1086,7 +1086,7 @@
FName == "IOOpenFirmwarePathMatching") {
// Part of . (IOKit)
// This should be addressed using a API table.
- S = getPersistentSummary(RetEffect::MakeOwned(RetEffect::CF, true),
+ S = getPersistentSummary(RetEffect::MakeOwned(RetEffect::CF),
DoNothing, DoNothing);
} else if (FName == "IOServiceGetMatchingService" ||
FName == "IOServiceGetMatchingServices") {
@@ -1116,7 +1116,7 @@
// passed to CGBitmapContextCreateWithData is released via
// a callback and doing full IPA to make sure this is done correctly.
ScratchArgs = AF.add(ScratchArgs, 8, StopTracking);
- S = getPersistentSummary(RetEffect::MakeOwned(RetEffect::CF, true),
+ S = getPersistentSummary(RetEffect::MakeOwned(RetEffect::CF),
DoNothing, DoNothing);
} else if (FName == "CVPixelBufferCreateWithPlanarBytes") {
// FIXES:
@@ -1284,7 +1284,7 @@
RetainSummaryManager::getCFSummaryCreateRule(const FunctionDecl *FD) {
assert (ScratchArgs.isEmpty());
- return getPersistentSummary(RetEffect::MakeOwned(RetEffect::CF, true));
+ return getPersistentSummary(RetEffect::MakeOwned(RetEffect::CF));
}
const RetainSummary *
@@ -1314,7 +1314,7 @@
}
if (D->hasAttr())
-return RetEffect::MakeOwned(RetEffect::CF, true);
+return RetEffect::MakeOwned(RetEffect::CF);
if (D->hasAttr())
return RetEffect::MakeNotOwned(RetEffect::CF);
@@ -1427,7 +1427,7 @@
case OMF_new:
case OMF_copy:
case OMF_mutableCopy:
-ResultEff = RetEffect::MakeOwned(RetEffect::CF, true);
+ResultEff = RetEffect::MakeOwned(RetEffect::CF);
break;
default:
ResultEff = RetEffect::MakeNotOwned(RetEffect::CF);
@@ -1449,7 +1449,7 @@
if (cocoa::isCocoaObjectRef(RetTy))
ResultEff = ObjCAllocRetE;
else if (coreFoundation::isCFObjectRef(RetTy))
-ResultEff = RetEffect::MakeOwned(RetEffect::CF, true);
+ResultEff = RetEffect::MakeOwned(RetEffect::CF);
break;
case OMF_autorelease:
ReceiverEff = Autorelease;
@@ -1580,7 +1580,7 @@
// The next methods are allocators.
const RetainSummary *AllocSumm = getPersistentSummary(ObjCAllocRetE);
const RetainSummary *CFAllocSumm =
-getPersistentSummary(RetEffect::MakeOwned(RetEffect::CF, true));
+getPersistentSummary(RetEffect::MakeOwned(RetEffect::CF));
// Create the "retain" selector.
RetEffect NoRet = RetEffect::MakeNoRet();
@@ -3067,8 +3067,7 @@
// No work necessary.
break;
-case RetEffect::OwnedAllocatedSymbol:
-case RetEffect::OwnedSymbol: {
+case RetEffect::OwnedAllocatedSymbol: {
SymbolRef Sym = CallOrMsg.getReturnValue().getAsSymbol();
if (!Sym)
break;
Index: include/clang/StaticAnalyzer/Checkers/ObjCRetainCount.h
===
--- include/clang/StaticAnalyzer/Checkers/ObjCRetainCount.h
+++ include/clang/StaticAnalyzer/Checkers/ObjCRetainCount.h
@@ -118,8 +118,6 @@
/// Indicates that no retain count information is tracked for
/// the return value.
NoRet,
-/// Indicates that the returned value is an owned (+1) symbol.
-OwnedSymbol,
/// Indicates that the returned value is an owned (+1) symbol and
/// that it should be treated as freshly allocated.
OwnedAllocatedSymbol,
@@ -163,8 +161,7 @@
ObjKind getObjKind() const { return O; }
bool isOwned() const {
-return K == OwnedSymbol || K == OwnedAllocatedSymbol ||
-K == OwnedWhenTrackedReceiver;
+return K == OwnedAllocatedSymbol || K == OwnedWhenTrackedReceiver;
}
bool notOwned() const {
@@ -179,8 +176,8 @@
return RetEffect(OwnedW
[PATCH] D27409: [analyzer] RetainCountChecker: The callback in dispatch_data_create() doesn't free the return symbol.
NoQ created this revision.
NoQ added reviewers: zaks.anna, dcoughlin.
NoQ added a subscriber: cfe-commits.
The hack that was previously applied to `CGBitmapContextCreateWithData()` is
now extended to another function, `dispatch_data_create()`.
This function accepts a callback block, and the analyzer erroneously assumes
that this callback may free up some data, which results in being unable to
detect a leak of the `dispatch_data_t` object. In fact, the callback only frees
the buffer that is passed into the function, but the returned object should be
released separately unless in ARC mode.
https://reviews.llvm.org/D27409
Files:
lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
test/Analysis/dispatch-data-leak.m
Index: test/Analysis/dispatch-data-leak.m
===
--- /dev/null
+++ test/Analysis/dispatch-data-leak.m
@@ -0,0 +1,59 @@
+// RUN: %clang_cc1 -w -triple x86_64-apple-macosx10.12.0 -fblocks -analyze
-analyzer-checker=core,osx.cocoa,unix.Malloc -verify %s
+// RUN: %clang_cc1 -w -triple x86_64-apple-macosx10.12.0 -fblocks -fobjc-arc
-analyze -analyzer-checker=core,osx.cocoa,unix.Malloc -verify %s
+
+#include "Inputs/system-header-simulator.h"
+#include "Inputs/system-header-simulator-objc.h"
+
+#define NON_ARC !__has_feature(objc_arc)
+
+#define DISPATCH_QUEUE_SERIAL NULL
+
+#define DISPATCH_DATA_DESTRUCTOR_DEFAULT NULL
+#define DISPATCH_DATA_DESTRUCTOR_FREE (_dispatch_data_destructor_free)
+#define DISPATCH_DATA_DESTRUCTOR_MUNMAP (_dispatch_data_destructor_munmap)
+
+#define OS_OBJECT_RETURNS_RETAINED __attribute__((__ns_returns_retained__))
+#define DISPATCH_RETURNS_RETAINED OS_OBJECT_RETURNS_RETAINED
+
+@protocol OS_dispatch_data
+@end
+@protocol OS_dispatch_queue
+@end
+@protocol OS_dispatch_queue_attr
+@end
+
+typedef NSObject *dispatch_data_t;
+typedef NSObject *dispatch_queue_t;
+typedef NSObject *dispatch_queue_attr_t;
+
+typedef void (^dispatch_block_t)(void);
+
+dispatch_queue_t dispatch_get_main_queue(void);
+
+DISPATCH_RETURNS_RETAINED dispatch_queue_t
+dispatch_queue_create(const char *_Nullable label,
+ dispatch_queue_attr_t _Nullable attr);
+
+DISPATCH_RETURNS_RETAINED dispatch_data_t
+dispatch_data_create(const void *buffer, size_t size,
+ dispatch_queue_t _Nullable queue,
+ dispatch_block_t _Nullable destructor);
+
+void clang_analyzer_printState();
+
+char buf[1024];
+void find_all_three_leaks() {
+ char *malloc_buf;
+ dispatch_data_t data;
+ dispatch_queue_t q;
+
+ malloc_buf = malloc(1024);
+ data = dispatch_data_create(buf, 1024, dispatch_get_main_queue(), ^{}); //
expected-warning{{Potential leak of memory pointed to by 'malloc_buf'}}
+#if NON_ARC
+ // expected-warning@-2{{Potential leak of an object stored into 'data'}}
+#endif
+ q = dispatch_queue_create("hello", DISPATCH_QUEUE_SERIAL);
+#if NON_ARC
+ // expected-warning@-2{{Potential leak of an object stored into 'q'}}
+#endif
+}
Index: lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
+++ lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
@@ -953,7 +953,8 @@
if (IdentifierInfo *Name = FC->getDecl()->getIdentifier()) {
// When the CGBitmapContext is deallocated, the callback here will free
// the associated data buffer.
-if (Name->isStr("CGBitmapContextCreateWithData"))
+if (Name->isStr("CGBitmapContextCreateWithData") ||
+Name->isStr("dispatch_data_create"))
RE = S->getRetEffect();
}
}
Index: test/Analysis/dispatch-data-leak.m
===
--- /dev/null
+++ test/Analysis/dispatch-data-leak.m
@@ -0,0 +1,59 @@
+// RUN: %clang_cc1 -w -triple x86_64-apple-macosx10.12.0 -fblocks -analyze -analyzer-checker=core,osx.cocoa,unix.Malloc -verify %s
+// RUN: %clang_cc1 -w -triple x86_64-apple-macosx10.12.0 -fblocks -fobjc-arc -analyze -analyzer-checker=core,osx.cocoa,unix.Malloc -verify %s
+
+#include "Inputs/system-header-simulator.h"
+#include "Inputs/system-header-simulator-objc.h"
+
+#define NON_ARC !__has_feature(objc_arc)
+
+#define DISPATCH_QUEUE_SERIAL NULL
+
+#define DISPATCH_DATA_DESTRUCTOR_DEFAULT NULL
+#define DISPATCH_DATA_DESTRUCTOR_FREE (_dispatch_data_destructor_free)
+#define DISPATCH_DATA_DESTRUCTOR_MUNMAP (_dispatch_data_destructor_munmap)
+
+#define OS_OBJECT_RETURNS_RETAINED __attribute__((__ns_returns_retained__))
+#define DISPATCH_RETURNS_RETAINED OS_OBJECT_RETURNS_RETAINED
+
+@protocol OS_dispatch_data
+@end
+@protocol OS_dispatch_queue
+@end
+@protocol OS_dispatch_queue_attr
+@end
+
+typedef NSObject *dispatch_data_t;
+typedef NSObject *dispatch_queue_t;
+typedef NSObject *dispatch_queue_attr_t;
+
+typedef void (^dispatch_block_t)(void);
+
+dispatch_queue_t dispatch_get_main_queue(void);
+
+DISPATCH_RETURNS_RETAIN
[PATCH] D27410: Always issue vtables when generating coverage instrumentation
FlameTop created this revision.
FlameTop added a reviewer: rsmith.
FlameTop added a subscriber: cfe-commits.
The provided test shows a case where enabling coverage instrumentation causes a
link error during building. Normally the all the base class items (vtable,
ctors and dtors) would be removed in an optimized build. But when building with
coverage instrumentation the ctors and dtors are always issued and access the
vtable. However, the vtable remains with external linkage. As nobody ever
instantiates the base class the vtable remains undefined and causes a link
error.
This patch changes the behavior when deciding the vtable linkage when
generating coverage instrumentation. vtables are always generated as local
linkonce objects.
This is slightly wasteful of link time and target storage but the profile
instrumentation is performed too early (as far as I can see) to not instrument
ctors/dtors that will later be discarded.
https://reviews.llvm.org/D27410
Files:
llvm/tools/clang/lib/CodeGen/CGVTables.cpp
llvm/tools/clang/test/CodeGenCXX/vtable-coverage-gen.cpp
Index: llvm/tools/clang/test/CodeGenCXX/vtable-coverage-gen.cpp
===
--- /dev/null
+++ llvm/tools/clang/test/CodeGenCXX/vtable-coverage-gen.cpp
@@ -0,0 +1,51 @@
+// RUN: %clang_cc1 -O2 -fprofile-instrument=clang -fcoverage-mapping %s
-emit-llvm -o %t
+// RUN: FileCheck %s < %t
+// CHECK: @_ZTV8Category = linkonce_odr unnamed_addr constant {{.*}}, comdat,
+
+class Category
+{
+ public:
+ Category() {}
+ virtual ~Category() {}
+
+ static const Category *Get(int source);
+
+
+ protected:
+ const char *const ITEM_KEY_CONSOLE_ID = "consoleId";
+
+};
+
+
+
+class CategoryAboutMe : public Category
+{
+ public:
+ CategoryAboutMe() {}
+ virtual ~CategoryAboutMe() {}
+
+ protected:
+};
+
+
+//static
+const Category *
+Category::Get(int source)
+{
+ static CategoryAboutMe s_categoryAboutMe;
+
+ switch (source) {
+ case 0:
+ return &s_categoryAboutMe;
+ default:
+ return __null;
+ }
+ return 0;
+}
+
+
+int main(int argc, char const *argv[])
+{
+ /* code */
+ return 0;
+}
\ No newline at end of file
Index: llvm/tools/clang/lib/CodeGen/CGVTables.cpp
===
--- llvm/tools/clang/lib/CodeGen/CGVTables.cpp
+++ llvm/tools/clang/lib/CodeGen/CGVTables.cpp
@@ -715,9 +715,17 @@
const FunctionDecl *def = nullptr;
if (keyFunction->hasBody(def))
keyFunction = cast(def);
-
switch (keyFunction->getTemplateSpecializationKind()) {
case TSK_Undeclared:
+// if we are generating profile instrumentation ensure
+// vtables are always issued locally as the constructors
+// and destructors are always issued.
+if (CodeGenOpts.hasProfileClangInstr() ||
+CodeGenOpts.hasProfileIRInstr())
+ return !Context.getLangOpts().AppleKext ?
+ llvm::GlobalVariable::LinkOnceODRLinkage :
+ llvm::Function::InternalLinkage;
+LLVM_FALLTHROUGH;
case TSK_ExplicitSpecialization:
assert((def || CodeGenOpts.OptimizationLevel > 0) &&
"Shouldn't query vtable linkage without key function or "
@@ -821,6 +829,12 @@
bool CodeGenVTables::isVTableExternal(const CXXRecordDecl *RD) {
assert(RD->isDynamicClass() && "Non-dynamic classes have no VTable.");
+ // if we are generating profile instrumentation, issue the vtables locally as
+ // the constructors and destructors will always be issued.
+ if (CGM.getCodeGenOpts().hasProfileClangInstr() ||
+ CGM.getCodeGenOpts().hasProfileIRInstr())
+return false;
+
// We always synthesize vtables if they are needed in the MS ABI. MSVC
doesn't
// emit them even if there is an explicit template instantiation.
if (CGM.getTarget().getCXXABI().isMicrosoft())
Index: llvm/tools/clang/test/CodeGenCXX/vtable-coverage-gen.cpp
===
--- /dev/null
+++ llvm/tools/clang/test/CodeGenCXX/vtable-coverage-gen.cpp
@@ -0,0 +1,51 @@
+// RUN: %clang_cc1 -O2 -fprofile-instrument=clang -fcoverage-mapping %s -emit-llvm -o %t
+// RUN: FileCheck %s < %t
+// CHECK: @_ZTV8Category = linkonce_odr unnamed_addr constant {{.*}}, comdat,
+
+class Category
+{
+ public:
+ Category() {}
+ virtual ~Category() {}
+
+ static const Category *Get(int source);
+
+
+ protected:
+ const char *const ITEM_KEY_CONSOLE_ID = "consoleId";
+
+};
+
+
+
+class CategoryAboutMe : public Category
+{
+ public:
+ CategoryAboutMe() {}
+ virtual ~CategoryAboutMe() {}
+
+ protected:
+};
+
+
+//static
+const Category *
+Category::Get(int source)
+{
+ static CategoryAboutMe s_categoryAboutMe;
+
+ switch (source) {
+ case 0:
+ return &s_categoryAboutMe;
+ default:
+ return __null;
+ }
+ return 0;
+}
+
+
+int main(int argc, char const *argv[])
+{
+ /* code */
+ return 0;
+}
\ No newline at end of file
Index: llvm/tools/clang/lib/CodeGen/CGV
Re: [PATCH] D27387: [libc++] Add a key function for bad_function_call
I haven't looked at the patch, but yes, many developers on our platform back-deploy to older OS versions (and we support that via Clang flags, e.g., -miphoneos-version-min=8.0). They always build against the newest SDK/headers. -- dpnes > On Dec 5, 2016, at 00:35, Eric Fiselier via Phabricator > wrote: > > EricWF added a reviewer: dexonsmith. > EricWF added a subscriber: dexonsmith. > EricWF added a comment. > > In https://reviews.llvm.org/D27387#613071, @smeenai wrote: > >> In https://reviews.llvm.org/D27387#612975, @EricWF wrote: >> >>> I wonder if we should consider this a breaking ABI change and control it >>> using a `_LIBCPP_ABI` macro. @mclow.lists thoughts? >> >> >> This is forward-compatible (as in clients built against an older libc++ >> would be happy with this version) but not backwards-compatible (as in >> clients built against this version would not be able to run against an older >> libc++). Has libc++ been aiming to maintain compatibility in both directions? > > > Hmm, I'm not exactly sure. We don't make backward incompatible changes to > existing code often. I wonder if vendors like Apple require such backwards > compatibility. Maybe @dexonsmith can weigh in? > > > https://reviews.llvm.org/D27387 > > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D27387: [libc++] Add a key function for bad_function_call
Are the minimum versions detectable in the processor? If so it seems like we could safely configure this change that way. /Eric On Mon, Dec 5, 2016 at 7:37 AM, Duncan Exon Smith wrote: > I haven't looked at the patch, but yes, many developers on our platform > back-deploy to older OS versions (and we support that via Clang flags, > e.g., -miphoneos-version-min=8.0). They always build against the newest > SDK/headers. > > -- dpnes > > > On Dec 5, 2016, at 00:35, Eric Fiselier via Phabricator < > revi...@reviews.llvm.org> wrote: > > > > EricWF added a reviewer: dexonsmith. > > EricWF added a subscriber: dexonsmith. > > EricWF added a comment. > > > > In https://reviews.llvm.org/D27387#613071, @smeenai wrote: > > > >> In https://reviews.llvm.org/D27387#612975, @EricWF wrote: > >> > >>> I wonder if we should consider this a breaking ABI change and control > it using a `_LIBCPP_ABI` macro. @mclow.lists thoughts? > >> > >> > >> This is forward-compatible (as in clients built against an older libc++ > would be happy with this version) but not backwards-compatible (as in > clients built against this version would not be able to run against an > older libc++). Has libc++ been aiming to maintain compatibility in both > directions? > > > > > > Hmm, I'm not exactly sure. We don't make backward incompatible changes > to existing code often. I wonder if vendors like Apple require such > backwards compatibility. Maybe @dexonsmith can weigh in? > > > > > > https://reviews.llvm.org/D27387 > > > > > > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26564: Use PIC relocation mode by default for PowerPC64 ELF
joerg added a comment. Ping https://reviews.llvm.org/D26564 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27140: Allow clang to write compilation database records
joerg added a comment. Ping Repository: rL LLVM https://reviews.llvm.org/D27140 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: clang-format-vsix: versioning patch and show stderrors patch
Hi Manuel, Okay, I'll submit both patches via phabricator as you recommend. I'll add you, and I'll add Hans Wennborg and Zachary Turner, who were both involved with the first clang-format-vsix patch I worked on: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20161128/178569.html Does that make sense? I'm still learning the common workflow for submitting patches :) - Antonio On Mon, 5 Dec 2016 at 06:24 Manuel Klimek wrote: Awesome, thanks for working on this. If you submit the patches via phabricator (http://llvm.org/docs/Phabricator.html) I'll get to it faster :) Feel free to directly add me as reviewer, btw (add 'klimek'). On Sat, Dec 3, 2016 at 6:53 AM Antonio Maiorano via cfe-commits < cfe-commits@lists.llvm.org> wrote: Hello, I have two patches for clang-format-vsix to offer up for review: 0001-clang-format-vsix-versioning.patch clang-format-vsix: add a date stamp to the VSIX version number to ensure upgradability Presently, the version number of the VSIX matches the LLVM version number. However, as this number doesn't change often, it means that as we release new versions of this VSIX, it will have the same version number, which means users must first uninstall the old version before installing the new one. With this change, we generate a 4th part to the version number that is a date stamp (year, month, day); for example: 4.0.0.161203. 0001-clang-format-vsix-show-stderrs.patch clang-format-vsix: fail when clang-format outputs to stderr When clang-format outputs to stderr but returns 0, the extension will format the code anyway. This happens, for instance, when there's a syntax error or unknown value in a .clang-format file; the result is that the extension silently formats using the fallback style without informing the user of the problem. This change treats stderr output as an error, making sure it gets displayed to the user, and not formatting the code. (I've also attached a screenshot of the message box I now get when my .clang-format has an invalid field named SomeInvalidField). ___ 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] D27409: [analyzer] RetainCountChecker: The callback in dispatch_data_create() doesn't free the return symbol.
NoQ updated this revision to Diff 80264.
NoQ added a comment.
Update the comments in the surrounding code accordingly.
https://reviews.llvm.org/D27409
Files:
lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
test/Analysis/dispatch-data-leak.m
Index: test/Analysis/dispatch-data-leak.m
===
--- /dev/null
+++ test/Analysis/dispatch-data-leak.m
@@ -0,0 +1,59 @@
+// RUN: %clang_cc1 -w -triple x86_64-apple-macosx10.12.0 -fblocks -analyze
-analyzer-checker=core,osx.cocoa,unix.Malloc -verify %s
+// RUN: %clang_cc1 -w -triple x86_64-apple-macosx10.12.0 -fblocks -fobjc-arc
-analyze -analyzer-checker=core,osx.cocoa,unix.Malloc -verify %s
+
+#include "Inputs/system-header-simulator.h"
+#include "Inputs/system-header-simulator-objc.h"
+
+#define NON_ARC !__has_feature(objc_arc)
+
+#define DISPATCH_QUEUE_SERIAL NULL
+
+#define DISPATCH_DATA_DESTRUCTOR_DEFAULT NULL
+#define DISPATCH_DATA_DESTRUCTOR_FREE (_dispatch_data_destructor_free)
+#define DISPATCH_DATA_DESTRUCTOR_MUNMAP (_dispatch_data_destructor_munmap)
+
+#define OS_OBJECT_RETURNS_RETAINED __attribute__((__ns_returns_retained__))
+#define DISPATCH_RETURNS_RETAINED OS_OBJECT_RETURNS_RETAINED
+
+@protocol OS_dispatch_data
+@end
+@protocol OS_dispatch_queue
+@end
+@protocol OS_dispatch_queue_attr
+@end
+
+typedef NSObject *dispatch_data_t;
+typedef NSObject *dispatch_queue_t;
+typedef NSObject *dispatch_queue_attr_t;
+
+typedef void (^dispatch_block_t)(void);
+
+dispatch_queue_t dispatch_get_main_queue(void);
+
+DISPATCH_RETURNS_RETAINED dispatch_queue_t
+dispatch_queue_create(const char *_Nullable label,
+ dispatch_queue_attr_t _Nullable attr);
+
+DISPATCH_RETURNS_RETAINED dispatch_data_t
+dispatch_data_create(const void *buffer, size_t size,
+ dispatch_queue_t _Nullable queue,
+ dispatch_block_t _Nullable destructor);
+
+void clang_analyzer_printState();
+
+char buf[1024];
+void find_all_three_leaks() {
+ char *malloc_buf;
+ dispatch_data_t data;
+ dispatch_queue_t q;
+
+ malloc_buf = malloc(1024);
+ data = dispatch_data_create(buf, 1024, dispatch_get_main_queue(), ^{}); //
expected-warning{{Potential leak of memory pointed to by 'malloc_buf'}}
+#if NON_ARC
+ // expected-warning@-2{{Potential leak of an object stored into 'data'}}
+#endif
+ q = dispatch_queue_create("hello", DISPATCH_QUEUE_SERIAL);
+#if NON_ARC
+ // expected-warning@-2{{Potential leak of an object stored into 'q'}}
+#endif
+}
Index: lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
+++ lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
@@ -953,7 +953,10 @@
if (IdentifierInfo *Name = FC->getDecl()->getIdentifier()) {
// When the CGBitmapContext is deallocated, the callback here will free
// the associated data buffer.
-if (Name->isStr("CGBitmapContextCreateWithData"))
+// The callback in dispatch_data_create frees the buffer, but not
+// the data object.
+if (Name->isStr("CGBitmapContextCreateWithData") ||
+Name->isStr("dispatch_data_create"))
RE = S->getRetEffect();
}
}
Index: test/Analysis/dispatch-data-leak.m
===
--- /dev/null
+++ test/Analysis/dispatch-data-leak.m
@@ -0,0 +1,59 @@
+// RUN: %clang_cc1 -w -triple x86_64-apple-macosx10.12.0 -fblocks -analyze -analyzer-checker=core,osx.cocoa,unix.Malloc -verify %s
+// RUN: %clang_cc1 -w -triple x86_64-apple-macosx10.12.0 -fblocks -fobjc-arc -analyze -analyzer-checker=core,osx.cocoa,unix.Malloc -verify %s
+
+#include "Inputs/system-header-simulator.h"
+#include "Inputs/system-header-simulator-objc.h"
+
+#define NON_ARC !__has_feature(objc_arc)
+
+#define DISPATCH_QUEUE_SERIAL NULL
+
+#define DISPATCH_DATA_DESTRUCTOR_DEFAULT NULL
+#define DISPATCH_DATA_DESTRUCTOR_FREE (_dispatch_data_destructor_free)
+#define DISPATCH_DATA_DESTRUCTOR_MUNMAP (_dispatch_data_destructor_munmap)
+
+#define OS_OBJECT_RETURNS_RETAINED __attribute__((__ns_returns_retained__))
+#define DISPATCH_RETURNS_RETAINED OS_OBJECT_RETURNS_RETAINED
+
+@protocol OS_dispatch_data
+@end
+@protocol OS_dispatch_queue
+@end
+@protocol OS_dispatch_queue_attr
+@end
+
+typedef NSObject *dispatch_data_t;
+typedef NSObject *dispatch_queue_t;
+typedef NSObject *dispatch_queue_attr_t;
+
+typedef void (^dispatch_block_t)(void);
+
+dispatch_queue_t dispatch_get_main_queue(void);
+
+DISPATCH_RETURNS_RETAINED dispatch_queue_t
+dispatch_queue_create(const char *_Nullable label,
+ dispatch_queue_attr_t _Nullable attr);
+
+DISPATCH_RETURNS_RETAINED dispatch_data_t
+dispatch_data_create(const void *buffer, size_t size,
+ dispatch_queue_t _Nullable queue,
+ dispatch_block_t _Nullable destructor);
+
+void clang_analyzer_pr
[PATCH] D27005: [lit] Support custom parsers in parseIntegratedTestScript
jroelofs added a comment. LGTM https://reviews.llvm.org/D27005 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D24218: [libc++] Fix support for multibyte thousands_sep and decimal_point in moneypunct_byname and numpunct_byname.
vangyzen added inline comments.
Comment at: src/locale.cpp:4339
if (loc == nullptr)
__throw_runtime_error("numpunct_byname::numpunct_byname"
" failed to construct for " + string(nm));
While you're here, you might change `char` to `wchar_t`.
Comment at: src/locale.cpp:4348
__grouping_ = lc->grouping;
// locallization for truename and falsename is not available
}
Maybe fix the spelling of "localization".
https://reviews.llvm.org/D24218
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27167: [libc++] Support multibyte decimal_point and thousands_sep
vangyzen abandoned this revision. vangyzen added a comment. I'm abandoning this revision because https://reviews.llvm.org/D24218 is clearly superior. https://reviews.llvm.org/D27167 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: clang-format-vsix: versioning patch and show stderrors patch
On Mon, Dec 5, 2016 at 3:53 PM Antonio Maiorano wrote: > Hi Manuel, > > Okay, I'll submit both patches via phabricator as you recommend. I'll add > you, and I'll add Hans Wennborg and Zachary Turner, who were both involved > with the first clang-format-vsix patch I worked on: > http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20161128/178569.html > > Does that make sense? I'm still learning the common workflow for > submitting patches :) > Yep, perfect. Thanks!! > > - Antonio > > > > On Mon, 5 Dec 2016 at 06:24 Manuel Klimek wrote: > > Awesome, thanks for working on this. If you submit the patches via > phabricator (http://llvm.org/docs/Phabricator.html) I'll get to it faster > :) Feel free to directly add me as reviewer, btw (add 'klimek'). > > On Sat, Dec 3, 2016 at 6:53 AM Antonio Maiorano via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > > Hello, > > I have two patches for clang-format-vsix to offer up for review: > > 0001-clang-format-vsix-versioning.patch > clang-format-vsix: add a date stamp to the VSIX version number to ensure > upgradability > > Presently, the version number of the VSIX matches the LLVM version number. > However, as this number doesn't change often, it means that as we release > new versions of this VSIX, it will have the same version number, which > means users must first uninstall the old version before installing the new > one. With this change, we generate a 4th part to the version number that is > a date stamp (year, month, day); for example: 4.0.0.161203. > > > 0001-clang-format-vsix-show-stderrs.patch > clang-format-vsix: fail when clang-format outputs to stderr > > When clang-format outputs to stderr but returns 0, the extension will > format the code anyway. This happens, for instance, when there's a syntax > error or unknown value in a .clang-format file; the result is that the > extension silently formats using the fallback style without informing the > user of the problem. This change treats stderr output as an error, making > sure it gets displayed to the user, and not formatting the code. (I've also > attached a screenshot of the message box I now get when my .clang-format > has an invalid field named SomeInvalidField). > > > ___ > 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] D27300: [OpenCL] Fix SPIR version generation.
Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Thanks! https://reviews.llvm.org/D27300 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27403: [OpenCL] Added a LIT test for ensuring address space mangling is done the same both in OpenCL1.2 and OpenCL2.0.
Anastasia added inline comments. Comment at: test/CodeGenOpenCL/address-spaces-mangling.cl:36 + +__attribute__((overloadable)) void foo(private char *); +__attribute__((overloadable)) void foo(global char *); Just trying to understand what we are missing in the current testing. Does the additional code test something different from the previous one? Could we reuse the old test but just run it with the other OpenCL versions? Also do we have any different behavior in the mangler depending on OpenCL versions? https://reviews.llvm.org/D27403 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27408: [analyzer] RetainCountChecker: remove unused enum value; NFC.
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.
I suspect allocated owned means that the analyzer saw the allocation site.
Removing dead code is great! Thanks. This looks good to me other than the name
of the method that I commented about.
Comment at: include/clang/StaticAnalyzer/Checkers/ObjCRetainCount.h:179
- static RetEffect MakeOwned(ObjKind o, bool isAllocated = false) {
-return RetEffect(isAllocated ? OwnedAllocatedSymbol : OwnedSymbol, o);
+ static RetEffect MakeOwned(ObjKind o) {
+return RetEffect(OwnedAllocatedSymbol, o);
Should we rename into MakeAllocatedOwned()?
https://reviews.llvm.org/D27408
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26657: [Sema] Respect DLL attributes more faithfully
hans accepted this revision.
hans added a comment.
This revision is now accepted and ready to land.
lgtm
Comment at: lib/Sema/SemaTemplate.cpp:7710
+(Context.getTargetInfo().getCXXABI().isMicrosoft() ||
+ Context.getTargetInfo().getTriple().isWindowsItaniumEnvironment())) {
+ // In the MS ABI, an explicit instantiation definition can add a dll
smeenai wrote:
> hans wrote:
> > smeenai wrote:
> > > hans wrote:
> > > > Why the isWindowsItaniumEnvironment check? I'd expect checking for the
> > > > MS ABI is sufficient?
> > > windows-itanium in general tries to stick to MSVC semantics for
> > > dllexport/import annotations (unlike Cygwin and MinGW which kinda do
> > > their own thing). This is consistent with the conditional for the
> > > previous case (lines 7691 to 7693 in this diff).
> > Oh I see, this seems to be a new thing, starting with e.g. r284288.
> >
> > Seems fine then, but I'm a little worried that we're adding another
> > variable into the matrix here. IIRC, we key dll attribute behaviour off
> > `getCXXABI().isMicrosoft()` in lots of places.
> You're right; the current situation isn't ideal. I can clean that up in a
> follow-up.
Sounds good.
https://reviews.llvm.org/D26657
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27409: [analyzer] RetainCountChecker: The callback in dispatch_data_create() doesn't free the return symbol.
zaks.anna added inline comments.
Comment at: test/Analysis/dispatch-data-leak.m:50
+
+ malloc_buf = malloc(1024);
+ data = dispatch_data_create(buf, 1024, dispatch_get_main_queue(), ^{}); //
expected-warning{{Potential leak of memory pointed to by 'malloc_buf'}}
I think we should remove testing of malloc -it does not add anything here and
is a bit confusing since one might think that malloc_"but is related to the
dispatch test case.
https://reviews.llvm.org/D27409
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27408: [analyzer] RetainCountChecker: remove unused enum value; NFC.
dcoughlin added inline comments.
Comment at: include/clang/StaticAnalyzer/Checkers/ObjCRetainCount.h:179
- static RetEffect MakeOwned(ObjKind o, bool isAllocated = false) {
-return RetEffect(isAllocated ? OwnedAllocatedSymbol : OwnedSymbol, o);
+ static RetEffect MakeOwned(ObjKind o) {
+return RetEffect(OwnedAllocatedSymbol, o);
zaks.anna wrote:
> Should we rename into MakeAllocatedOwned()?
I think the current use of 'OwnedAllocatedSymbol' more closely matches what is
conveyed by the name and documentation of 'OwnedSymbol', so it might be better
to remove 'OwnedSymbol' (as Artem has done) and then immediately rename all
occurrences of 'OwnedAllocatedSymbol' to 'OwnedSymbol'. There are plenty of
places where the analyzer doesn't see the allocation site and yet yields
'OwnedAllocatedSymbol', so I don't think the current implementation matches its
name.
https://reviews.llvm.org/D27408
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27334: [OpenCL] Ambiguous function call.
Anastasia added a comment.
In https://reviews.llvm.org/D27334#612858, @bader wrote:
> In https://reviews.llvm.org/D27334#611703, @Anastasia wrote:
>
> > This change seems to modify normal C behavior again. Is there any strong
> > motivation for doing this and if yes could it be done generically with C?
>
>
> Motivation:
>
> // Non-portable OpenCL 1.2 code
> __kernel void foo(global float* out) {
> out[get_global_id(0)] = sin(get_global_id(0));
> }
>
>
> This program compiles fine on OpenCL platform w/o doubles support and fails
> otherwise.
> If OpenCL driver supports doubles it provides at least two versions of 'sin'
> built-in math function and compiler will not be able to choose the right one
> for 'size_t' argument.
> The goal of this warning is to let OpenCL developer know about potential
> issues with code portability.
I would argue this improves the portability much as it can also be misleading
in some situations (because it refers to a potentially hypothetical problem).
For example there can be builtin functions that only have a float parameter
(without a double version of it). This is for example the case with read_image
functions that take a float coordinate value between 0 and 1. Unfortunately
this warning won't be triggered on read_image functions because there is an
overload candidate with an int type of the same parameter too. But we can't
exclude this situations to appear in the future or from some vendor extensions
or even custom OpenCL code.
https://reviews.llvm.org/D27334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27299: [Sema] C++11 opaque enums should avoid the "case value not in enumerated type" switch warning
arphaman added inline comments. Comment at: lib/Sema/SemaStmt.cpp:1165 if (!hasCasesNotInSwitch) SS->setAllEnumCasesCovered(); ahatanak wrote: > This function used to call setAllEnumCasesCovered() when parsing a switch > statement with an opaque enum condition, but this patch changes the behavior. > I couldn't tell whether isAllEnumCasesCovered should return true or false for > such switch statements, but was this change intentional? You're right, good catch! Originally it wasn't intentional, but I've looked over this change and it seems like the right change to me. We can't know if we actually covered all enum cases when checking an opaque enum because we don't know which cases the enum has (unless we have a switch that covers all the of possible values of the enum's integer type)! It seems that the previous behaviour was incorrect. Repository: rL LLVM https://reviews.llvm.org/D27299 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D25660: [Analyzer] Checker for iterators dereferenced beyond their range.
zaks.anna added a comment. Also, have you evaluated this on real codebases? What results do you see? Are there any false positives found? Are there any true positives found? https://reviews.llvm.org/D25660 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26196: Add support for non-zero null pointer for C and OpenCL
yaxunl added a comment. ping https://reviews.llvm.org/D26196 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27409: [analyzer] RetainCountChecker: The callback in dispatch_data_create() doesn't free the return symbol.
dcoughlin added a comment. Looks good to me! To ease the future maintenance burden I would suggest moving the test into 'retain-release-arc.m' unless it really needs to be in its own separate file. Comment at: test/Analysis/dispatch-data-leak.m:59 +#endif +} I think it would also be good to also add tests showing that we don't warn when the object is properly released. It would be good to test both ObjC -release (under MRR) and the `dispatch_release()` macro (under MRR and ARC). https://reviews.llvm.org/D27409 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D27334: [OpenCL] Ambiguous function call.
On 5 Dec 2016 9:42 am, "Anastasia Stulova via Phabricator via cfe-commits" <
cfe-commits@lists.llvm.org> wrote:
Anastasia added a comment.
In https://reviews.llvm.org/D27334#612858, @bader wrote:
> In https://reviews.llvm.org/D27334#611703, @Anastasia wrote:
>
> > This change seems to modify normal C behavior again. Is there any
strong motivation for doing this and if yes could it be done generically
with C?
>
>
> Motivation:
>
> // Non-portable OpenCL 1.2 code
> __kernel void foo(global float* out) {
> out[get_global_id(0)] = sin(get_global_id(0));
> }
>
>
> This program compiles fine on OpenCL platform w/o doubles support
Perhaps that is the problem (that there are two modes that do different
things)? Could we make the double overload be present but unselectable to
diagnose this problem in that mode too?
and fails otherwise.
> If OpenCL driver supports doubles it provides at least two versions of
'sin' built-in math function and compiler will not be able to choose the
right one for 'size_t' argument.
Do you have a real example? If someone passes an integer to 'sin', I think
there's a better warning we can give them :)
> The goal of this warning is to let OpenCL developer know about potential
issues with code portability.
I would argue this improves the portability much as it can also be
misleading in some situations (because it refers to a potentially
hypothetical problem). For example there can be builtin functions that only
have a float parameter (without a double version of it). This is for
example the case with read_image functions that take a float coordinate
value between 0 and 1. Unfortunately this warning won't be triggered on
read_image functions because there is an overload candidate with an int
type of the same parameter too. But we can't exclude this situations to
appear in the future or from some vendor extensions or even custom OpenCL
code.
https://reviews.llvm.org/D27334
___
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] D27418: [X86][inline-asm] Add support for MS 'EVEN' directive
m_zuckerman added a comment. lgtm Repository: rL LLVM https://reviews.llvm.org/D27418 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D16533: Bug 20796 - GCC's -Wstrict-prototypes warning not implemented in Clang
arphaman updated this revision to Diff 80285.
arphaman marked 2 inline comments as done.
arphaman added a comment.
The updated patch addresses Bruno's comments.
Repository:
rL LLVM
https://reviews.llvm.org/D16533
Files:
include/clang/Basic/DiagnosticSemaKinds.td
lib/Sema/SemaDecl.cpp
lib/Sema/SemaType.cpp
test/Sema/warn-strict-prototypes.c
test/Sema/warn-strict-prototypes.m
Index: test/Sema/warn-strict-prototypes.m
===
--- /dev/null
+++ test/Sema/warn-strict-prototypes.m
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -fsyntax-only -Wstrict-prototypes -verify -fblocks %s
+
+@interface Foo
+
+@property (nonatomic, copy) void (^noProtoBlock)(); // expected-warning {{this function declaration is not a prototype}}
+@property (nonatomic, copy) void (^block)(void); // no warning
+
+- doStuff:(void (^)()) completionHandler; // expected-warning {{this function declaration is not a prototype}}
+- doOtherStuff:(void (^)(void)) completionHandler; // no warning
+
+@end
+
+void foo() {
+ void (^block)() = // expected-warning {{this function declaration is not a prototype}}
+^void(int arg) { // no warning
+ };
+ void (^block2)(void) = // no warning
+ ^void() { // expected-warning {{this function declaration is not a prototype}}
+ };
+}
Index: test/Sema/warn-strict-prototypes.c
===
--- /dev/null
+++ test/Sema/warn-strict-prototypes.c
@@ -0,0 +1,62 @@
+// RUN: %clang_cc1 -fsyntax-only -Wstrict-prototypes -verify %s
+// RUN: %clang_cc1 -fsyntax-only -Wstrict-prototypes -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+
+// function declaration with unspecified params
+void foo1(); // expected-warning {{this function declaration is not a prototype}}
+ // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:11}:"void"
+// function declaration with 0 params
+void foo2(void);
+
+// function definition with 0 params(for both cases),
+// valid according to 6.7.5.3/14
+void foo1() {}
+void foo2(void) {}
+
+// function type typedef unspecified params
+typedef void foo3(); // expected-warning {{this function declaration is not a prototype}}
+ // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:19-[[@LINE-1]]:19}:"void"
+
+// global fp unspecified params
+void (*foo4)(); // expected-warning {{this function declaration is not a prototype}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:14-[[@LINE-1]]:14}:"void"
+
+// struct member fp unspecified params
+struct { void (*foo5)(); } s; // expected-warning {{this function declaration is not a prototype}}
+ // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:23-[[@LINE-1]]:23}:"void"
+
+// param fp unspecified params
+void bar2(void (*foo6)()) { // expected-warning {{this function declaration is not a prototype}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:24-[[@LINE-1]]:24}:"void"
+ // local fp unspecified params
+ void (*foo7)() = 0; // expected-warning {{this function declaration is not a prototype}}
+ // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:16-[[@LINE-1]]:16}:"void"
+ // array fp unspecified params
+ void (*foo8[2])() = {0}; // expected-warning {{this function declaration is not a prototype}}
+ // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:19-[[@LINE-1]]:19}:"void"
+}
+
+// function type cast using using an anonymous function declaration
+void bar3(void) {
+ // casting function w/out prototype to unspecified params function type
+ (void)(void(*)()) foo1; // expected-warning {{this function declaration is not a prototype}}
+ // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:18-[[@LINE-1]]:18}:"void"
+ // .. specified params
+ (void)(void(*)(void)) foo1;
+}
+
+// K&R function definition not preceded by full prototype
+int foo9(a, b) // expected-warning {{old-style function definition is not preceded by a prototype}}
+ int a, b;
+{
+ return a + b;
+}
+
+// Function declaration with no types
+void foo10(); // expected-warning {{this function declaration is not a prototype}}
+ // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:12-[[@LINE-1]]:12}:"void"
+// K&R function definition with incomplete param list declared
+void foo10(p, p2) void *p; {} // expected-warning {{old-style function definition is not preceded by a prototype}}
+
+// K&R function definition with previous prototype declared is not diagnosed.
+void foo11(int p, int p2);
+void foo11(p, p2) int p; int p2; {}
Index: lib/Sema/SemaType.cpp
===
--- lib/Sema/SemaType.cpp
+++ lib/Sema/SemaType.cpp
@@ -4320,6 +4320,19 @@
if (FTI.isAmbiguous)
warnAboutAmbiguousFunction(S, D, DeclType, T);
+ // GNU warning -Wstrict-prototypes
+ // Warn if a function declaration is without a prototype.
+ // This warning is issued for all kin
Re: [PATCH] D27387: [libc++] Add a key function for bad_function_call
Yes, they are: -- $ clang -dM -x c /dev/null -E -mmacosx-version-min=10.10.0 | grep VERSION_MIN #define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 101000 -- However, they're somewhat awkward, extremely vendor-specific, and unrelated to libc++ version numbers. I think a separate ABI flag would be easiest to manage. > On 2016-Dec-05, at 06:44, Eric Fiselier wrote: > > s/processor/preprocessor > > On Mon, Dec 5, 2016 at 7:43 AM, Eric Fiselier wrote: > Are the minimum versions detectable in the processor? If so it seems like we > could safely configure this change that way. > > /Eric > > On Mon, Dec 5, 2016 at 7:37 AM, Duncan Exon Smith > wrote: > I haven't looked at the patch, but yes, many developers on our platform > back-deploy to older OS versions (and we support that via Clang flags, e.g., > -miphoneos-version-min=8.0). They always build against the newest > SDK/headers. > > -- dpnes > > > On Dec 5, 2016, at 00:35, Eric Fiselier via Phabricator > > wrote: > > > > EricWF added a reviewer: dexonsmith. > > EricWF added a subscriber: dexonsmith. > > EricWF added a comment. > > > > In https://reviews.llvm.org/D27387#613071, @smeenai wrote: > > > >> In https://reviews.llvm.org/D27387#612975, @EricWF wrote: > >> > >>> I wonder if we should consider this a breaking ABI change and control it > >>> using a `_LIBCPP_ABI` macro. @mclow.lists thoughts? > >> > >> > >> This is forward-compatible (as in clients built against an older libc++ > >> would be happy with this version) but not backwards-compatible (as in > >> clients built against this version would not be able to run against an > >> older libc++). Has libc++ been aiming to maintain compatibility in both > >> directions? > > > > > > Hmm, I'm not exactly sure. We don't make backward incompatible changes to > > existing code often. I wonder if vendors like Apple require such backwards > > compatibility. Maybe @dexonsmith can weigh in? > > > > > > https://reviews.llvm.org/D27387 > > > > > > > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26949: [libc++abi] Clean up visibility
compnerd added a comment.
I really like the clean up this does. It removes the unnecessary usage of the
GCC pragmas and cleans up the definitions by using the headers more properly.
Comment at: src/abort_message.h:19
-__attribute__((visibility("hidden"), noreturn))
+_LIBCXXABI_HIDDEN __attribute__((noreturn))
void abort_message(const char* format, ...)
Please clang-format this declaration.
Comment at: src/private_typeinfo.cpp:61
-#pragma GCC visibility push(hidden)
-
-inline
+static inline
bool
I think that if you are making this static inline, we should hoist this out
into a standalone helper outside of the `__cxxabiv1` namespace.
https://reviews.llvm.org/D26949
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r288682 - [Sema] Respect DLL attributes more faithfully
Author: smeenai
Date: Mon Dec 5 12:01:35 2016
New Revision: 288682
URL: http://llvm.org/viewvc/llvm-project?rev=288682&view=rev
Log:
[Sema] Respect DLL attributes more faithfully
On MSVC, if an implicit instantiation already exists and an explicit
instantiation definition with a DLL attribute is created, the DLL
attribute still takes effect. Make clang match this behavior for
exporting.
Differential Revision: https://reviews.llvm.org/D26657
Modified:
cfe/trunk/lib/Sema/SemaTemplate.cpp
cfe/trunk/test/CodeGenCXX/dllexport.cpp
cfe/trunk/test/CodeGenCXX/windows-itanium-dllexport.cpp
Modified: cfe/trunk/lib/Sema/SemaTemplate.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplate.cpp?rev=288682&r1=288681&r2=288682&view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplate.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplate.cpp Mon Dec 5 12:01:35 2016
@@ -7435,6 +7435,30 @@ static bool ScopeSpecifierHasTemplateId(
return false;
}
+/// Make a dllexport or dllimport attr on a class template specialization take
+/// effect.
+static void dllExportImportClassTemplateSpecialization(
+Sema &S, ClassTemplateSpecializationDecl *Def) {
+ auto *A = cast_or_null(getDLLAttr(Def));
+ assert(A && "dllExportImportClassTemplateSpecialization called "
+ "on Def without dllexport or dllimport");
+
+ // We reject explicit instantiations in class scope, so there should
+ // never be any delayed exported classes to worry about.
+ assert(S.DelayedDllExportClasses.empty() &&
+ "delayed exports present at explicit instantiation");
+ S.checkClassLevelDLLAttribute(Def);
+
+ // Propagate attribute to base class templates.
+ for (auto &B : Def->bases()) {
+if (auto *BT = dyn_cast_or_null(
+B.getType()->getAsCXXRecordDecl()))
+ S.propagateDLLAttrToBaseClassTemplate(Def, A, BT, B.getLocStart());
+ }
+
+ S.referenceDLLExportedClassMethods();
+}
+
// Explicit instantiation of a class template specialization
DeclResult
Sema::ActOnExplicitInstantiation(Scope *S,
@@ -7681,24 +7705,33 @@ Sema::ActOnExplicitInstantiation(Scope *
getDLLAttr(Specialization)->clone(getASTContext()));
A->setInherited(true);
Def->addAttr(A);
-
-// We reject explicit instantiations in class scope, so there should
-// never be any delayed exported classes to worry about.
-assert(DelayedDllExportClasses.empty() &&
- "delayed exports present at explicit instantiation");
-checkClassLevelDLLAttribute(Def);
-
-// Propagate attribute to base class templates.
-for (auto &B : Def->bases()) {
- if (auto *BT = dyn_cast_or_null(
- B.getType()->getAsCXXRecordDecl()))
-propagateDLLAttrToBaseClassTemplate(Def, A, BT, B.getLocStart());
-}
-
-referenceDLLExportedClassMethods();
+dllExportImportClassTemplateSpecialization(*this, Def);
}
}
+// Fix a TSK_ImplicitInstantiation followed by a
+// TSK_ExplicitInstantiationDefinition
+if (Old_TSK == TSK_ImplicitInstantiation &&
+Specialization->hasAttr() &&
+(Context.getTargetInfo().getCXXABI().isMicrosoft() ||
+ Context.getTargetInfo().getTriple().isWindowsItaniumEnvironment())) {
+ // In the MS ABI, an explicit instantiation definition can add a dll
+ // attribute to a template with a previous implicit instantiation.
+ // MinGW doesn't allow this. We limit clang to only adding dllexport, to
+ // avoid potentially strange codegen behavior. For example, if we extend
+ // this conditional to dllimport, and we have a source file calling a
+ // method on an implicitly instantiated template class instance and then
+ // declaring a dllimport explicit instantiation definition for the same
+ // template class, the codegen for the method call will not respect the
+ // dllimport, while it will with cl. The Def will already have the DLL
+ // attribute, since the Def and Specialization will be the same in the
+ // case of Old_TSK == TSK_ImplicitInstantiation, and we already added the
+ // attribute to the Specialization; we just need to make it take effect.
+ assert(Def == Specialization &&
+ "Def and Specialization should match for implicit instantiation");
+ dllExportImportClassTemplateSpecialization(*this, Def);
+}
+
// Set the template specialization kind. Make sure it is set before
// instantiating the members which will trigger ASTConsumer callbacks.
Specialization->setTemplateSpecializationKind(TSK);
Modified: cfe/trunk/test/CodeGenCXX/dllexport.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/dllexport.cpp?rev=288682&r1=288681&r2=288682&view=diff
==
--- cfe/trunk/test/CodeGenCXX/dl
[PATCH] D26657: [Sema] Respect DLL attributes more faithfully
This revision was automatically updated to reflect the committed changes.
Closed by commit rL288682: [Sema] Respect DLL attributes more faithfully
(authored by smeenai).
Changed prior to commit:
https://reviews.llvm.org/D26657?vs=80193&id=80289#toc
Repository:
rL LLVM
https://reviews.llvm.org/D26657
Files:
cfe/trunk/lib/Sema/SemaTemplate.cpp
cfe/trunk/test/CodeGenCXX/dllexport.cpp
cfe/trunk/test/CodeGenCXX/windows-itanium-dllexport.cpp
Index: cfe/trunk/lib/Sema/SemaTemplate.cpp
===
--- cfe/trunk/lib/Sema/SemaTemplate.cpp
+++ cfe/trunk/lib/Sema/SemaTemplate.cpp
@@ -7435,6 +7435,30 @@
return false;
}
+/// Make a dllexport or dllimport attr on a class template specialization take
+/// effect.
+static void dllExportImportClassTemplateSpecialization(
+Sema &S, ClassTemplateSpecializationDecl *Def) {
+ auto *A = cast_or_null(getDLLAttr(Def));
+ assert(A && "dllExportImportClassTemplateSpecialization called "
+ "on Def without dllexport or dllimport");
+
+ // We reject explicit instantiations in class scope, so there should
+ // never be any delayed exported classes to worry about.
+ assert(S.DelayedDllExportClasses.empty() &&
+ "delayed exports present at explicit instantiation");
+ S.checkClassLevelDLLAttribute(Def);
+
+ // Propagate attribute to base class templates.
+ for (auto &B : Def->bases()) {
+if (auto *BT = dyn_cast_or_null(
+B.getType()->getAsCXXRecordDecl()))
+ S.propagateDLLAttrToBaseClassTemplate(Def, A, BT, B.getLocStart());
+ }
+
+ S.referenceDLLExportedClassMethods();
+}
+
// Explicit instantiation of a class template specialization
DeclResult
Sema::ActOnExplicitInstantiation(Scope *S,
@@ -7681,24 +7705,33 @@
getDLLAttr(Specialization)->clone(getASTContext()));
A->setInherited(true);
Def->addAttr(A);
-
-// We reject explicit instantiations in class scope, so there should
-// never be any delayed exported classes to worry about.
-assert(DelayedDllExportClasses.empty() &&
- "delayed exports present at explicit instantiation");
-checkClassLevelDLLAttribute(Def);
-
-// Propagate attribute to base class templates.
-for (auto &B : Def->bases()) {
- if (auto *BT = dyn_cast_or_null(
- B.getType()->getAsCXXRecordDecl()))
-propagateDLLAttrToBaseClassTemplate(Def, A, BT, B.getLocStart());
-}
-
-referenceDLLExportedClassMethods();
+dllExportImportClassTemplateSpecialization(*this, Def);
}
}
+// Fix a TSK_ImplicitInstantiation followed by a
+// TSK_ExplicitInstantiationDefinition
+if (Old_TSK == TSK_ImplicitInstantiation &&
+Specialization->hasAttr() &&
+(Context.getTargetInfo().getCXXABI().isMicrosoft() ||
+ Context.getTargetInfo().getTriple().isWindowsItaniumEnvironment())) {
+ // In the MS ABI, an explicit instantiation definition can add a dll
+ // attribute to a template with a previous implicit instantiation.
+ // MinGW doesn't allow this. We limit clang to only adding dllexport, to
+ // avoid potentially strange codegen behavior. For example, if we extend
+ // this conditional to dllimport, and we have a source file calling a
+ // method on an implicitly instantiated template class instance and then
+ // declaring a dllimport explicit instantiation definition for the same
+ // template class, the codegen for the method call will not respect the
+ // dllimport, while it will with cl. The Def will already have the DLL
+ // attribute, since the Def and Specialization will be the same in the
+ // case of Old_TSK == TSK_ImplicitInstantiation, and we already added the
+ // attribute to the Specialization; we just need to make it take effect.
+ assert(Def == Specialization &&
+ "Def and Specialization should match for implicit instantiation");
+ dllExportImportClassTemplateSpecialization(*this, Def);
+}
+
// Set the template specialization kind. Make sure it is set before
// instantiating the members which will trigger ASTConsumer callbacks.
Specialization->setTemplateSpecializationKind(TSK);
Index: cfe/trunk/test/CodeGenCXX/dllexport.cpp
===
--- cfe/trunk/test/CodeGenCXX/dllexport.cpp
+++ cfe/trunk/test/CodeGenCXX/dllexport.cpp
@@ -771,6 +771,13 @@
// M32-DAG: define weak_odr dllexport x86_thiscallcc %struct.ExplicitInstantiationDeclExportedDefTemplate* @"\01??0?$ExplicitInstantiationDeclExportedDefTemplate@H@@QAE@XZ"
// G32-DAG: define weak_odr x86_thiscallcc void @_ZN44ExplicitInstantiationDeclExportedDefTemplateIiE1fEv
+template struct ImplicitInstantiationExplicitInstantiationDefExportedTemplate { void f() {} };
+ImplicitInstantiationExplicitInstantiationDefExportedTemplate ImplicitInstantiat
[PATCH] D25417: [libcxxabi] Fix alignment of allocated exceptions in 32 bit builds
compnerd accepted this revision. compnerd added a comment. This revision is now accepted and ready to land. I thought we had gotten this merged already. Oops. LGTM with the minor tweak for windows. Comment at: src/fallback_malloc.cpp:206 +return fallback_malloc(size); } Given that libc++abi has some Windows support and usage (e.g. MinGW), we should change this to: void *dest; #if defined(_WIN32) if ((dest = _aligned_malloc(size, alignof(__aligned_type)) == nullptr) return fallback_malloc(size); return dest; #else if (::posix_memalign(&dest, alignof(__aligned_type), size) == 0) return dest; return fallback_malloc(size); #endif https://reviews.llvm.org/D25417 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27420: Fix stack-use-after-scope in EvaluateImplicitExceptionSpec
vitalybuka created this revision. vitalybuka added a reviewer: rsmith. vitalybuka added subscribers: cfe-commits, aizatsky. getExceptionSpec returns structure with pointers to temporarily object created by computeImplicitExceptionSpec. https://reviews.llvm.org/D27420 Files: lib/Sema/SemaDeclCXX.cpp Index: lib/Sema/SemaDeclCXX.cpp === --- lib/Sema/SemaDeclCXX.cpp +++ lib/Sema/SemaDeclCXX.cpp @@ -6100,7 +6100,8 @@ return; // Evaluate the exception specification. - auto ESI = computeImplicitExceptionSpec(*this, Loc, MD).getExceptionSpec(); + auto IES = computeImplicitExceptionSpec(*this, Loc, MD); + auto ESI = IES.getExceptionSpec(); // Update the type of the special member to use it. UpdateExceptionSpec(MD, ESI); Index: lib/Sema/SemaDeclCXX.cpp === --- lib/Sema/SemaDeclCXX.cpp +++ lib/Sema/SemaDeclCXX.cpp @@ -6100,7 +6100,8 @@ return; // Evaluate the exception specification. - auto ESI = computeImplicitExceptionSpec(*this, Loc, MD).getExceptionSpec(); + auto IES = computeImplicitExceptionSpec(*this, Loc, MD); + auto ESI = IES.getExceptionSpec(); // Update the type of the special member to use it. UpdateExceptionSpec(MD, ESI); ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RE: [PATCH] D27334: [OpenCL] Ambiguous function call.
> Perhaps that is the problem (that there are two modes that do different
> things)? Could we make the double overload be present but unselectable to
> diagnose this problem in that mode too?
If we could resolve the overload candidate to prefer ‘int -> float’ than
‘int->double’, it would work best.
From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard Smith
Sent: 05 December 2016 17:53
To: Bruno Cardoso Lopes via Phabricator;
reviews+d27334+public+f2c5a66032c4c...@reviews.llvm.org
Cc: alexey.ba...@intel.com; egor.chur...@gmail.com; yaxun@amd.com;
Anastasia Stulova; cfe-commits@lists.llvm.org
Subject: Re: [PATCH] D27334: [OpenCL] Ambiguous function call.
On 5 Dec 2016 9:42 am, "Anastasia Stulova via Phabricator via cfe-commits"
mailto:cfe-commits@lists.llvm.org>> wrote:
Anastasia added a comment.
In https://reviews.llvm.org/D27334#612858, @bader wrote:
> In https://reviews.llvm.org/D27334#611703, @Anastasia wrote:
>
> > This change seems to modify normal C behavior again. Is there any strong
> > motivation for doing this and if yes could it be done generically with C?
>
>
> Motivation:
>
> // Non-portable OpenCL 1.2 code
> __kernel void foo(global float* out) {
> out[get_global_id(0)] = sin(get_global_id(0));
> }
>
>
> This program compiles fine on OpenCL platform w/o doubles support
Perhaps that is the problem (that there are two modes that do different
things)? Could we make the double overload be present but unselectable to
diagnose this problem in that mode too?
and fails otherwise.
> If OpenCL driver supports doubles it provides at least two versions of 'sin'
> built-in math function and compiler will not be able to choose the right one
> for 'size_t' argument.
Do you have a real example? If someone passes an integer to 'sin', I think
there's a better warning we can give them :)
> The goal of this warning is to let OpenCL developer know about potential
> issues with code portability.
I would argue this improves the portability much as it can also be misleading
in some situations (because it refers to a potentially hypothetical problem).
For example there can be builtin functions that only have a float parameter
(without a double version of it). This is for example the case with read_image
functions that take a float coordinate value between 0 and 1. Unfortunately
this warning won't be triggered on read_image functions because there is an
overload candidate with an int type of the same parameter too. But we can't
exclude this situations to appear in the future or from some vendor extensions
or even custom OpenCL code.
https://reviews.llvm.org/D27334
___
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] D25435: Add -femit-accurate-debug-info to emit more debug info for sample pgo profile collection
danielcdh added a comment. ping https://reviews.llvm.org/D25435 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r288685 - Fix stack-use-after-scope in EvaluateImplicitExceptionSpec
Author: vitalybuka Date: Mon Dec 5 12:30:22 2016 New Revision: 288685 URL: http://llvm.org/viewvc/llvm-project?rev=288685&view=rev Log: Fix stack-use-after-scope in EvaluateImplicitExceptionSpec Summary: getExceptionSpec returns structure with pointers to temporarily object created by computeImplicitExceptionSpec. Reviewers: rsmith Subscribers: aizatsky, cfe-commits Differential Revision: https://reviews.llvm.org/D27420 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=288685&r1=288684&r2=288685&view=diff == --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original) +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Mon Dec 5 12:30:22 2016 @@ -6100,7 +6100,8 @@ void Sema::EvaluateImplicitExceptionSpec return; // Evaluate the exception specification. - auto ESI = computeImplicitExceptionSpec(*this, Loc, MD).getExceptionSpec(); + auto IES = computeImplicitExceptionSpec(*this, Loc, MD); + auto ESI = IES.getExceptionSpec(); // Update the type of the special member to use it. UpdateExceptionSpec(MD, ESI); ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27420: Fix stack-use-after-scope in EvaluateImplicitExceptionSpec
This revision was automatically updated to reflect the committed changes. Closed by commit rL288685: Fix stack-use-after-scope in EvaluateImplicitExceptionSpec (authored by vitalybuka). Changed prior to commit: https://reviews.llvm.org/D27420?vs=80290&id=80292#toc Repository: rL LLVM https://reviews.llvm.org/D27420 Files: cfe/trunk/lib/Sema/SemaDeclCXX.cpp Index: cfe/trunk/lib/Sema/SemaDeclCXX.cpp === --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp @@ -6100,7 +6100,8 @@ return; // Evaluate the exception specification. - auto ESI = computeImplicitExceptionSpec(*this, Loc, MD).getExceptionSpec(); + auto IES = computeImplicitExceptionSpec(*this, Loc, MD); + auto ESI = IES.getExceptionSpec(); // Update the type of the special member to use it. UpdateExceptionSpec(MD, ESI); Index: cfe/trunk/lib/Sema/SemaDeclCXX.cpp === --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp @@ -6100,7 +6100,8 @@ return; // Evaluate the exception specification. - auto ESI = computeImplicitExceptionSpec(*this, Loc, MD).getExceptionSpec(); + auto IES = computeImplicitExceptionSpec(*this, Loc, MD); + auto ESI = IES.getExceptionSpec(); // Update the type of the special member to use it. UpdateExceptionSpec(MD, ESI); ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27422: Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec
vitalybuka created this revision. vitalybuka added a reviewer: rsmith. vitalybuka added subscribers: cfe-commits, aizatsky. Similar to r288685. getExceptionSpec returned structure with pointers to temporarily object created by computeImplicitExceptionSpec. https://reviews.llvm.org/D27422 Files: lib/Sema/SemaDeclCXX.cpp Index: lib/Sema/SemaDeclCXX.cpp === --- lib/Sema/SemaDeclCXX.cpp +++ lib/Sema/SemaDeclCXX.cpp @@ -6299,8 +6299,8 @@ CallingConv CC = Context.getDefaultCallingConvention(/*IsVariadic=*/false, /*IsCXXMethod=*/true); FunctionProtoType::ExtProtoInfo EPI(CC); - EPI.ExceptionSpec = computeImplicitExceptionSpec(*this, MD->getLocation(), MD) - .getExceptionSpec(); + auto IES = computeImplicitExceptionSpec(*this, MD->getLocation(), MD); + EPI.ExceptionSpec = IES.getExceptionSpec(); const FunctionProtoType *ImplicitType = cast( Context.getFunctionType(Context.VoidTy, None, EPI)); Index: lib/Sema/SemaDeclCXX.cpp === --- lib/Sema/SemaDeclCXX.cpp +++ lib/Sema/SemaDeclCXX.cpp @@ -6299,8 +6299,8 @@ CallingConv CC = Context.getDefaultCallingConvention(/*IsVariadic=*/false, /*IsCXXMethod=*/true); FunctionProtoType::ExtProtoInfo EPI(CC); - EPI.ExceptionSpec = computeImplicitExceptionSpec(*this, MD->getLocation(), MD) - .getExceptionSpec(); + auto IES = computeImplicitExceptionSpec(*this, MD->getLocation(), MD); + EPI.ExceptionSpec = IES.getExceptionSpec(); const FunctionProtoType *ImplicitType = cast( Context.getFunctionType(Context.VoidTy, None, EPI)); ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27304: [PATCH] [Sema][X86] Don't allow floating-point return types when SSE is disabled
mkuper added a comment. If there are real-life usecases, then GCC-compatible behavior is probably better than just rejecting it outright, so I'm retracting my comment from PR30426. (I would probably have liked x86_64 with -mno-sse2 and no -msoft-float to be an error, but I would also like a pony, so...) https://reviews.llvm.org/D27304 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26376: Undef stdatomic.h macro definitions that are defining functions provided in libc++
mehdi_amini added a comment.
In https://reviews.llvm.org/D26376#597614, @mclow.lists wrote:
> More info - The following code:
>
> #include
> int main () {}
>
>
> fails to compile on either gcc 6.2 (locally), gcc 7 head (online compiler) or
> MSVC (online compiler).
Interesting, that lead me to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
which describes the issue I believe.
One of the example is that we should guarantee ABI compatibility between C and
C++ for such code:
#ifdef __cplusplus
#include
using namespace std;
#else
#include
#endif
struct s {
atomic_int i;
};
Do you know if we're providing this guarantee today?
In https://reviews.llvm.org/D26376#613186, @EricWF wrote:
> Yeah this seems like a configuration that simply can't be supported. I'm not
> sure if this patch is a great idea.
OK, let's abandon this then!
https://reviews.llvm.org/D26376
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27422: Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec
This revision was automatically updated to reflect the committed changes. Closed by commit rL288689: Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec (authored by vitalybuka). Changed prior to commit: https://reviews.llvm.org/D27422?vs=80299&id=80300#toc Repository: rL LLVM https://reviews.llvm.org/D27422 Files: cfe/trunk/lib/Sema/SemaDeclCXX.cpp Index: cfe/trunk/lib/Sema/SemaDeclCXX.cpp === --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp @@ -6299,8 +6299,8 @@ CallingConv CC = Context.getDefaultCallingConvention(/*IsVariadic=*/false, /*IsCXXMethod=*/true); FunctionProtoType::ExtProtoInfo EPI(CC); - EPI.ExceptionSpec = computeImplicitExceptionSpec(*this, MD->getLocation(), MD) - .getExceptionSpec(); + auto IES = computeImplicitExceptionSpec(*this, MD->getLocation(), MD); + EPI.ExceptionSpec = IES.getExceptionSpec(); const FunctionProtoType *ImplicitType = cast( Context.getFunctionType(Context.VoidTy, None, EPI)); Index: cfe/trunk/lib/Sema/SemaDeclCXX.cpp === --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp @@ -6299,8 +6299,8 @@ CallingConv CC = Context.getDefaultCallingConvention(/*IsVariadic=*/false, /*IsCXXMethod=*/true); FunctionProtoType::ExtProtoInfo EPI(CC); - EPI.ExceptionSpec = computeImplicitExceptionSpec(*this, MD->getLocation(), MD) - .getExceptionSpec(); + auto IES = computeImplicitExceptionSpec(*this, MD->getLocation(), MD); + EPI.ExceptionSpec = IES.getExceptionSpec(); const FunctionProtoType *ImplicitType = cast( Context.getFunctionType(Context.VoidTy, None, EPI)); ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r288689 - Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec
Author: vitalybuka Date: Mon Dec 5 13:25:00 2016 New Revision: 288689 URL: http://llvm.org/viewvc/llvm-project?rev=288689&view=rev Log: Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec Summary: Similar to r288685. getExceptionSpec returned structure with pointers to temporarily object created by computeImplicitExceptionSpec. Reviewers: rsmith Subscribers: aizatsky, cfe-commits Differential Revision: https://reviews.llvm.org/D27422 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=288689&r1=288688&r2=288689&view=diff == --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original) +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Mon Dec 5 13:25:00 2016 @@ -6299,8 +6299,8 @@ void Sema::CheckExplicitlyDefaultedMembe CallingConv CC = Context.getDefaultCallingConvention(/*IsVariadic=*/false, /*IsCXXMethod=*/true); FunctionProtoType::ExtProtoInfo EPI(CC); - EPI.ExceptionSpec = computeImplicitExceptionSpec(*this, MD->getLocation(), MD) - .getExceptionSpec(); + auto IES = computeImplicitExceptionSpec(*this, MD->getLocation(), MD); + EPI.ExceptionSpec = IES.getExceptionSpec(); const FunctionProtoType *ImplicitType = cast( Context.getFunctionType(Context.VoidTy, None, EPI)); ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27153: [libc++] Make __num_get_float hidden
smeenai added a comment. In https://reviews.llvm.org/D27153#613140, @EricWF wrote: > In https://reviews.llvm.org/D27153#606296, @smeenai wrote: > > > I'm having some second thoughts about this. Visibility for template > > functions makes my head spin :/ Is there a general policy we've been > > following for these? I didn't find much just scanning through other > > definitions. > > > I would suggest adding the `inline` keyword so that implicit instantiation > are marked hidden when `-fvisibility-inlines-hidden`. That should be > sufficient to hide the implicit instantiations in `libc++.so`. I thought about that as well. It's slightly less intrusive, since it would only change the visibility for clients using `-fvisibility-inlines-hidden`. It also seems like a more roundabout way of going about hiding these symbols though, and we definitely don't want the compiler using the `inline` as a hint to actually perform inlining for this particular function (from what I understand, `inline` is mostly ignored as far as inlining goes, but it might have some effect on the compiler's cost models or something). I feel like, if the goal is to have these symbols hidden (and I think they should be), annotating the visibility explicitly is a better approach than marking as `inline`. What are your thoughts on that? https://reviews.llvm.org/D27153 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26934: [libc++] Add _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
This revision was automatically updated to reflect the committed changes.
Closed by commit rL288690: [libc++] Add _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
(authored by smeenai).
Changed prior to commit:
https://reviews.llvm.org/D26934?vs=79359&id=80304#toc
Repository:
rL LLVM
https://reviews.llvm.org/D26934
Files:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/docs/UsingLibcxx.rst
libcxx/trunk/include/__config
libcxx/trunk/include/__config_site.in
Index: libcxx/trunk/docs/UsingLibcxx.rst
===
--- libcxx/trunk/docs/UsingLibcxx.rst
+++ libcxx/trunk/docs/UsingLibcxx.rst
@@ -149,3 +149,9 @@
This macro is used to enable -Wthread-safety annotations on libc++'s
``std::mutex`` and ``std::lock_guard``. By default these annotations are
disabled and must be manually enabled by the user.
+
+**_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS**:
+ This macro is used to disable all visibility annotations inside libc++.
+ Defining this macro and then building libc++ with hidden visibility gives a
+ build of libc++ which does not export any symbols, which can be useful when
+ building statically for inclusion into another library.
Index: libcxx/trunk/include/__config_site.in
===
--- libcxx/trunk/include/__config_site.in
+++ libcxx/trunk/include/__config_site.in
@@ -21,6 +21,6 @@
#cmakedefine _LIBCPP_HAS_MUSL_LIBC
#cmakedefine _LIBCPP_HAS_THREAD_API_PTHREAD
#cmakedefine _LIBCPP_HAS_THREAD_API_EXTERNAL
-#cmakedefine _LIBCPP_DISABLE_DLL_IMPORT_EXPORT
+#cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
#endif // _LIBCPP_CONFIG_SITE
Index: libcxx/trunk/include/__config
===
--- libcxx/trunk/include/__config
+++ libcxx/trunk/include/__config
@@ -510,7 +510,7 @@
#ifdef _WIN32
-#if defined(_LIBCPP_DISABLE_DLL_IMPORT_EXPORT)
+#if defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
# define _LIBCPP_DLL_VIS
# define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
# define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
@@ -546,18 +546,30 @@
#endif // _WIN32
#ifndef _LIBCPP_HIDDEN
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
#define _LIBCPP_HIDDEN __attribute__ ((__visibility__("hidden")))
+#else
+#define _LIBCPP_HIDDEN
+#endif
#endif
#ifndef _LIBCPP_FUNC_VIS
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
#define _LIBCPP_FUNC_VIS __attribute__ ((__visibility__("default")))
+#else
+#define _LIBCPP_FUNC_VIS
+#endif
#endif
#ifndef _LIBCPP_TYPE_VIS
-# if __has_attribute(__type_visibility__)
-#define _LIBCPP_TYPE_VIS __attribute__ ((__type_visibility__("default")))
+# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
+#if __has_attribute(__type_visibility__)
+# define _LIBCPP_TYPE_VIS __attribute__ ((__type_visibility__("default")))
+#else
+# define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
+#endif
# else
-#define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
+#define _LIBCPP_TYPE_VIS
# endif
#endif
@@ -574,19 +586,23 @@
#endif
#ifndef _LIBCPP_EXCEPTION_ABI
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
#define _LIBCPP_EXCEPTION_ABI __attribute__ ((__visibility__("default")))
+#else
+#define _LIBCPP_EXCEPTION_ABI
+#endif
#endif
#ifndef _LIBCPP_ENUM_VIS
-# if __has_attribute(__type_visibility__)
+# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) && __has_attribute(__type_visibility__)
#define _LIBCPP_ENUM_VIS __attribute__ ((__type_visibility__("default")))
# else
#define _LIBCPP_ENUM_VIS
# endif
#endif
#ifndef _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
-# if __has_attribute(__type_visibility__)
+# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) && __has_attribute(__type_visibility__)
#define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS __attribute__ ((__type_visibility__("default")))
# else
#define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
@@ -598,15 +614,27 @@
#endif
#ifndef _LIBCPP_INLINE_VISIBILITY
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
#define _LIBCPP_INLINE_VISIBILITY __attribute__ ((__visibility__("hidden"), __always_inline__))
+#else
+#define _LIBCPP_INLINE_VISIBILITY __attribute__ ((__always_inline__))
+#endif
#endif
#ifndef _LIBCPP_ALWAYS_INLINE
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
#define _LIBCPP_ALWAYS_INLINE __attribute__ ((__visibility__("hidden"), __always_inline__))
+#else
+#define _LIBCPP_ALWAYS_INLINE __attribute__ ((__always_inline__))
+#endif
#endif
#ifndef _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY
-# define _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY __attribute__((__visibility__("default"), __always_inline__))
+# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
+# define _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY __attribute__((__visibility__("default"), __always_inline__))
+# else
+# define _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY __attribute__((
[libcxx] r288690 - [libc++] Add _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
Author: smeenai
Date: Mon Dec 5 13:40:12 2016
New Revision: 288690
URL: http://llvm.org/viewvc/llvm-project?rev=288690&view=rev
Log:
[libc++] Add _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
It's useful to be able to disable visibility annotations entirely; for
example, if we're building libc++ static to include in another library,
and we don't want any libc++ functions getting exported out of that
library. This is a generalization of _LIBCPP_DISABLE_DLL_IMPORT_EXPORT.
Differential Revision: https://reviews.llvm.org/D26934
Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/docs/UsingLibcxx.rst
libcxx/trunk/include/__config
libcxx/trunk/include/__config_site.in
Modified: libcxx/trunk/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=288690&r1=288689&r2=288690&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Mon Dec 5 13:40:12 2016
@@ -518,7 +518,7 @@ config_define_if(LIBCXX_HAS_MUSL_LIBC _L
# static library only we modify the headers to disable DLL import/export.
if (DEFINED WIN32 AND LIBCXX_ENABLE_STATIC AND NOT LIBCXX_ENABLE_SHARED)
message(STATUS "Generating custom __config for non-DLL Windows build")
- config_define(ON _LIBCPP_DISABLE_DLL_IMPORT_EXPORT)
+ config_define(ON _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
endif()
if (LIBCXX_NEEDS_SITE_CONFIG)
Modified: libcxx/trunk/docs/UsingLibcxx.rst
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/UsingLibcxx.rst?rev=288690&r1=288689&r2=288690&view=diff
==
--- libcxx/trunk/docs/UsingLibcxx.rst (original)
+++ libcxx/trunk/docs/UsingLibcxx.rst Mon Dec 5 13:40:12 2016
@@ -149,3 +149,9 @@ thread safety annotations.
This macro is used to enable -Wthread-safety annotations on libc++'s
``std::mutex`` and ``std::lock_guard``. By default these annotations are
disabled and must be manually enabled by the user.
+
+**_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS**:
+ This macro is used to disable all visibility annotations inside libc++.
+ Defining this macro and then building libc++ with hidden visibility gives a
+ build of libc++ which does not export any symbols, which can be useful when
+ building statically for inclusion into another library.
Modified: libcxx/trunk/include/__config
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=288690&r1=288689&r2=288690&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Mon Dec 5 13:40:12 2016
@@ -510,7 +510,7 @@ namespace std {
#ifdef _WIN32
-#if defined(_LIBCPP_DISABLE_DLL_IMPORT_EXPORT)
+#if defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
# define _LIBCPP_DLL_VIS
# define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
# define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
@@ -546,18 +546,30 @@ namespace std {
#endif // _WIN32
#ifndef _LIBCPP_HIDDEN
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
#define _LIBCPP_HIDDEN __attribute__ ((__visibility__("hidden")))
+#else
+#define _LIBCPP_HIDDEN
+#endif
#endif
#ifndef _LIBCPP_FUNC_VIS
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
#define _LIBCPP_FUNC_VIS __attribute__ ((__visibility__("default")))
+#else
+#define _LIBCPP_FUNC_VIS
+#endif
#endif
#ifndef _LIBCPP_TYPE_VIS
-# if __has_attribute(__type_visibility__)
-#define _LIBCPP_TYPE_VIS __attribute__ ((__type_visibility__("default")))
+# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
+#if __has_attribute(__type_visibility__)
+# define _LIBCPP_TYPE_VIS __attribute__ ((__type_visibility__("default")))
+#else
+# define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
+#endif
# else
-#define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
+#define _LIBCPP_TYPE_VIS
# endif
#endif
@@ -574,11 +586,15 @@ namespace std {
#endif
#ifndef _LIBCPP_EXCEPTION_ABI
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
#define _LIBCPP_EXCEPTION_ABI __attribute__ ((__visibility__("default")))
+#else
+#define _LIBCPP_EXCEPTION_ABI
+#endif
#endif
#ifndef _LIBCPP_ENUM_VIS
-# if __has_attribute(__type_visibility__)
+# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) &&
__has_attribute(__type_visibility__)
#define _LIBCPP_ENUM_VIS __attribute__ ((__type_visibility__("default")))
# else
#define _LIBCPP_ENUM_VIS
@@ -586,7 +602,7 @@ namespace std {
#endif
#ifndef _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
-# if __has_attribute(__type_visibility__)
+# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) &&
__has_attribute(__type_visibility__)
#define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS __attribute__
((__type_visibility__("default")))
# else
#define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
@@ -598,15 +614,27 @@ namespace std {
#endif
Re: [PATCH] D26376: Undef stdatomic.h macro definitions that are defining functions provided in libc++
On 5 December 2016 at 11:34, Mehdi AMINI via Phabricator <
revi...@reviews.llvm.org> wrote:
> mehdi_amini added a comment.
>
> In https://reviews.llvm.org/D26376#597614, @mclow.lists wrote:
>
> > More info - The following code:
> >
> > #include
> > int main () {}
> >
> >
> > fails to compile on either gcc 6.2 (locally), gcc 7 head (online
> compiler) or MSVC (online compiler).
>
>
> Interesting, that lead me to https://gcc.gnu.org/bugzilla/
> show_bug.cgi?id=60932 which describes the issue I believe.
>
> One of the example is that we should guarantee ABI compatibility between C
> and C++ for such code:
>
> #ifdef __cplusplus
> #include
> using namespace std;
> #else
> #include
> #endif
>
> struct s {
> atomic_int i;
> };
>
> Do you know if we're providing this guarantee today?
If by "we" you mean libc++, then yes, it does everything it can to provide
this guarantee -- its atomic is a wrapper around an _Atomic(T).
If by "we" you also include Clang, and you include the case where
is the libstdc++ version, then results are more mixed -- GCC and libstdc++
made some very poor decisions early on regarding the size and alignment of
atomic for some types T (such as char[3]), and Clang's _Atomic(T) /
does not replicate those poor choices. If I remember
correctly, this is fixed in more recent versions of libstdc++.
In https://reviews.llvm.org/D26376#613186, @EricWF wrote:
>
> > Yeah this seems like a configuration that simply can't be supported. I'm
> not sure if this patch is a great idea.
>
>
> OK, let's abandon this then!
>
>
> https://reviews.llvm.org/D26376
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26950: [libc++abi] Add _LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS
This revision was automatically updated to reflect the committed changes.
Closed by commit rL288692: [libc++abi] Add
_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS (authored by smeenai).
Changed prior to commit:
https://reviews.llvm.org/D26950?vs=78809&id=80306#toc
Repository:
rL LLVM
https://reviews.llvm.org/D26950
Files:
libcxxabi/trunk/include/__cxxabi_config.h
Index: libcxxabi/trunk/include/__cxxabi_config.h
===
--- libcxxabi/trunk/include/__cxxabi_config.h
+++ libcxxabi/trunk/include/__cxxabi_config.h
@@ -22,7 +22,7 @@
#endif
#if defined(_WIN32)
- #if defined(_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+ #if defined(_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS)
#define _LIBCXXABI_HIDDEN
#define _LIBCXXABI_DATA_VIS
#define _LIBCXXABI_FUNC_VIS
@@ -39,13 +39,20 @@
#define _LIBCXXABI_TYPE_VIS __declspec(dllimport)
#endif
#else
- #define _LIBCXXABI_HIDDEN __attribute__((__visibility__("hidden")))
- #define _LIBCXXABI_DATA_VIS __attribute__((__visibility__("default")))
- #define _LIBCXXABI_FUNC_VIS __attribute__((__visibility__("default")))
- #if __has_attribute(__type_visibility__)
- #define _LIBCXXABI_TYPE_VIS __attribute__((__type_visibility__("default")))
+ #if !defined(_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS)
+ #define _LIBCXXABI_HIDDEN __attribute__((__visibility__("hidden")))
+ #define _LIBCXXABI_DATA_VIS __attribute__((__visibility__("default")))
+ #define _LIBCXXABI_FUNC_VIS __attribute__((__visibility__("default")))
+ #if __has_attribute(__type_visibility__)
+ #define _LIBCXXABI_TYPE_VIS __attribute__((__type_visibility__("default")))
+ #else
+ #define _LIBCXXABI_TYPE_VIS __attribute__((__visibility__("default")))
+ #endif
#else
- #define _LIBCXXABI_TYPE_VIS __attribute__((__visibility__("default")))
+ #define _LIBCXXABI_HIDDEN
+ #define _LIBCXXABI_DATA_VIS
+ #define _LIBCXXABI_FUNC_VIS
+ #define _LIBCXXABI_TYPE_VIS
#endif
#endif
Index: libcxxabi/trunk/include/__cxxabi_config.h
===
--- libcxxabi/trunk/include/__cxxabi_config.h
+++ libcxxabi/trunk/include/__cxxabi_config.h
@@ -22,7 +22,7 @@
#endif
#if defined(_WIN32)
- #if defined(_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+ #if defined(_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS)
#define _LIBCXXABI_HIDDEN
#define _LIBCXXABI_DATA_VIS
#define _LIBCXXABI_FUNC_VIS
@@ -39,13 +39,20 @@
#define _LIBCXXABI_TYPE_VIS __declspec(dllimport)
#endif
#else
- #define _LIBCXXABI_HIDDEN __attribute__((__visibility__("hidden")))
- #define _LIBCXXABI_DATA_VIS __attribute__((__visibility__("default")))
- #define _LIBCXXABI_FUNC_VIS __attribute__((__visibility__("default")))
- #if __has_attribute(__type_visibility__)
- #define _LIBCXXABI_TYPE_VIS __attribute__((__type_visibility__("default")))
+ #if !defined(_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS)
+ #define _LIBCXXABI_HIDDEN __attribute__((__visibility__("hidden")))
+ #define _LIBCXXABI_DATA_VIS __attribute__((__visibility__("default")))
+ #define _LIBCXXABI_FUNC_VIS __attribute__((__visibility__("default")))
+ #if __has_attribute(__type_visibility__)
+ #define _LIBCXXABI_TYPE_VIS __attribute__((__type_visibility__("default")))
+ #else
+ #define _LIBCXXABI_TYPE_VIS __attribute__((__visibility__("default")))
+ #endif
#else
- #define _LIBCXXABI_TYPE_VIS __attribute__((__visibility__("default")))
+ #define _LIBCXXABI_HIDDEN
+ #define _LIBCXXABI_DATA_VIS
+ #define _LIBCXXABI_FUNC_VIS
+ #define _LIBCXXABI_TYPE_VIS
#endif
#endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxxabi] r288692 - [libc++abi] Add _LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS
Author: smeenai
Date: Mon Dec 5 13:42:11 2016
New Revision: 288692
URL: http://llvm.org/viewvc/llvm-project?rev=288692&view=rev
Log:
[libc++abi] Add _LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS
It's useful to be able to disable visibility annotations entirely; for
example, if we're building libc++abi static to include in another library,
and we don't want any libc++abi functions getting exported out of that
library. This is a generalization of _LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT.
Differential Revision: https://reviews.llvm.org/D26950
Modified:
libcxxabi/trunk/include/__cxxabi_config.h
Modified: libcxxabi/trunk/include/__cxxabi_config.h
URL:
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/include/__cxxabi_config.h?rev=288692&r1=288691&r2=288692&view=diff
==
--- libcxxabi/trunk/include/__cxxabi_config.h (original)
+++ libcxxabi/trunk/include/__cxxabi_config.h Mon Dec 5 13:42:11 2016
@@ -22,7 +22,7 @@
#endif
#if defined(_WIN32)
- #if defined(_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+ #if defined(_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS)
#define _LIBCXXABI_HIDDEN
#define _LIBCXXABI_DATA_VIS
#define _LIBCXXABI_FUNC_VIS
@@ -39,13 +39,20 @@
#define _LIBCXXABI_TYPE_VIS __declspec(dllimport)
#endif
#else
- #define _LIBCXXABI_HIDDEN __attribute__((__visibility__("hidden")))
- #define _LIBCXXABI_DATA_VIS __attribute__((__visibility__("default")))
- #define _LIBCXXABI_FUNC_VIS __attribute__((__visibility__("default")))
- #if __has_attribute(__type_visibility__)
- #define _LIBCXXABI_TYPE_VIS __attribute__((__type_visibility__("default")))
+ #if !defined(_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS)
+ #define _LIBCXXABI_HIDDEN __attribute__((__visibility__("hidden")))
+ #define _LIBCXXABI_DATA_VIS __attribute__((__visibility__("default")))
+ #define _LIBCXXABI_FUNC_VIS __attribute__((__visibility__("default")))
+ #if __has_attribute(__type_visibility__)
+ #define _LIBCXXABI_TYPE_VIS __attribute__((__type_visibility__("default")))
+ #else
+ #define _LIBCXXABI_TYPE_VIS __attribute__((__visibility__("default")))
+ #endif
#else
- #define _LIBCXXABI_TYPE_VIS __attribute__((__visibility__("default")))
+ #define _LIBCXXABI_HIDDEN
+ #define _LIBCXXABI_DATA_VIS
+ #define _LIBCXXABI_FUNC_VIS
+ #define _LIBCXXABI_TYPE_VIS
#endif
#endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27383: Add a new clang-format style option ObjCBlockResetsIndent.
yixiang added a comment.
Discover a case where my code breaks. When the block signature has a return
type in it, the indent doesn't gets reset properly. I need to fix this.
// clang-format -style='{ObjCBlockResetsIndent: true}' test.m
[self callAsyncMethodWithParam:2
withCompletionHandler:id ^ (BOOL success) {
if (true) {
return nil;
} else {
return nil;
}
}];
Expected result
// clang-format -style='{ObjCBlockResetsIndent: true}' test.m
[self callAsyncMethodWithParam:2
withCompletionHandler:id ^ (BOOL success) {
if (true) {
return nil;
} else {
return nil;
}
}];
https://reviews.llvm.org/D27383
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27424: Add the diagnose_if attribute to clang.
george.burgess.iv created this revision.
george.burgess.iv added reviewers: rsmith, aaron.ballman.
george.burgess.iv added subscribers: EricWF, cfe-commits.
This patch adds the `diagnose_if` attribute to clang.
`diagnose_if` is meant to be a less powerful version of `enable_if`: it doesn't
interact with overload resolution at all, and if the condition in the
`diagnose_if` attribute can't be evaluated, compilation proceeds as though said
`diagnose_if` attribute was not present. It can be used to emit either errors
or warnings, like so:
void foo(int a) __attribute__((diagnose_if(a > 10, "a is too large!",
"error")));
void bar(int a) __attribute__((diagnose_if(a > 10, "this takes a long time if
a is larger than 10.", "warning")));
void baz(int a) __attribute__((diagnose_if(1, "don't use me anymore",
"warning")));
void run(int a) {
foo(10);
foo(11); // error: a is too large
foo(a);
bar(10);
bar(11); // warning: this takes a long time if a is larger than 10.
bar(a);
void (*b)(int) = baz; // warning: don't use me anymore.
}
Under the hood, we have two kinds of `diagnose_if` attributes: ones that are
dependent on the value of arguments (which are handled a lot like `enable_if`),
and ones that aren't (which are treated like `unavailable`/`deprecated`
attributes). This split made this attribute *substantially* less complex to
implement, since it lets us reuse existing code
https://reviews.llvm.org/D27424
Files:
include/clang/Basic/Attr.td
include/clang/Basic/AttrDocs.td
include/clang/Basic/DiagnosticCommonKinds.td
include/clang/Basic/DiagnosticGroups.td
include/clang/Basic/DiagnosticSemaKinds.td
include/clang/Sema/Overload.h
include/clang/Sema/Sema.h
lib/Parse/ParseDecl.cpp
lib/Sema/SemaDeclAttr.cpp
lib/Sema/SemaExpr.cpp
lib/Sema/SemaOverload.cpp
lib/Sema/SemaTemplateInstantiateDecl.cpp
test/Sema/diagnose_if.c
test/SemaCXX/diagnose_if.cpp
Index: test/SemaCXX/diagnose_if.cpp
===
--- /dev/null
+++ test/SemaCXX/diagnose_if.cpp
@@ -0,0 +1,352 @@
+// RUN: %clang_cc1 %s -verify -fno-builtin -std=c++11
+
+#define _diagnose_if(...) __attribute__((diagnose_if(__VA_ARGS__)))
+
+namespace type_dependent {
+template
+void neverok() _diagnose_if(!T(), "oh no", "error") {} // expected-note 4{{from diagnose_if}}
+
+template
+void alwaysok() _diagnose_if(T(), "oh no", "error") {}
+
+template
+void alwayswarn() _diagnose_if(!T(), "oh no", "warning") {} // expected-note 4{{from diagnose_if}}
+
+template
+void neverwarn() _diagnose_if(T(), "oh no", "warning") {}
+
+void runAll() {
+ alwaysok();
+ alwaysok();
+
+ {
+void (*pok)() = alwaysok;
+pok = &alwaysok;
+ }
+
+ neverok(); // expected-error{{oh no}}
+ neverok(); // expected-error{{oh no}}
+
+ {
+void (*pok)() = neverok; // expected-error{{oh no}}
+ }
+ {
+void (*pok)();
+pok = &neverok; // expected-error{{oh no}}
+ }
+
+ alwayswarn(); // expected-warning{{oh no}}
+ alwayswarn(); // expected-warning{{oh no}}
+ {
+void (*pok)() = alwayswarn; // expected-warning{{oh no}}
+pok = &alwayswarn; // expected-warning{{oh no}}
+ }
+
+ neverwarn();
+ neverwarn();
+ {
+void (*pok)() = neverwarn;
+pok = &neverwarn;
+ }
+}
+
+template
+void errorIf(T a) _diagnose_if(T() != a, "oh no", "error") {} // expected-note {{candidate disabled: oh no}}
+
+template
+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}}
+
+ warnIf(0);
+ warnIf(1); // expected-warning{{oh no}}
+}
+}
+
+namespace value_dependent {
+template
+void neverok() _diagnose_if(N == 0 || N != 0, "oh no", "error") {} // expected-note 4{{from diagnose_if}}
+
+template
+void alwaysok() _diagnose_if(N == 0 && N != 0, "oh no", "error") {}
+
+template
+void alwayswarn() _diagnose_if(N == 0 || N != 0, "oh no", "warning") {} // expected-note 4{{from diagnose_if}}
+
+template
+void neverwarn() _diagnose_if(N == 0 && N != 0, "oh no", "warning") {}
+
+void runAll() {
+ alwaysok<0>();
+ alwaysok<1>();
+
+ {
+void (*pok)() = alwaysok<0>;
+pok = &alwaysok<0>;
+ }
+
+ neverok<0>(); // expected-error{{oh no}}
+ neverok<1>(); // expected-error{{oh no}}
+
+ {
+void (*pok)() = neverok<0>; // expected-error{{oh no}}
+ }
+ {
+void (*pok)();
+pok = &neverok<0>; // expected-error{{oh no}}
+ }
+
+ alwayswarn<0>(); // expected-warning{{oh no}}
+ alwayswarn<1>(); // expected-warning{{oh no}}
+ {
+void (*pok)() = alwayswarn<0>; // expected-warning{{oh no}}
+pok = &alwayswarn<0>; // expected-warning{{oh no}}
+ }
+
+ neverwarn<0>();
+ neverwarn<1>();
+ {
+void (*pok)() = neverwarn<0>;
+pok = &neverwarn<0>;
+ }
+}
+
+template
+void errorIf(int a) _diagnose_if(N != a, "oh no", "error") {} // expected-note {{candidate disabled: oh no}}
+
+template
+vo
r288696 - [analyzer] Print type for SymbolRegionValues when dumping to stream
Author: ddcc
Date: Mon Dec 5 14:30:11 2016
New Revision: 288696
URL: http://llvm.org/viewvc/llvm-project?rev=288696&view=rev
Log:
[analyzer] Print type for SymbolRegionValues when dumping to stream
Reviewers: NoQ, dcoughlin, zaks.anna
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27365
Modified:
cfe/trunk/lib/StaticAnalyzer/Core/SymbolManager.cpp
cfe/trunk/test/Analysis/expr-inspection.c
Modified: cfe/trunk/lib/StaticAnalyzer/Core/SymbolManager.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/SymbolManager.cpp?rev=288696&r1=288695&r2=288696&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/SymbolManager.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/SymbolManager.cpp Mon Dec 5 14:30:11 2016
@@ -85,7 +85,8 @@ void SymbolMetadata::dumpToStream(raw_os
void SymbolData::anchor() { }
void SymbolRegionValue::dumpToStream(raw_ostream &os) const {
- os << "reg_$" << getSymbolID() << "<" << R << ">";
+ os << "reg_$" << getSymbolID()
+ << '<' << getType().getAsString() << ' ' << R << '>';
}
bool SymExpr::symbol_iterator::operator==(const symbol_iterator &X) const {
Modified: cfe/trunk/test/Analysis/expr-inspection.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/expr-inspection.c?rev=288696&r1=288695&r2=288696&view=diff
==
--- cfe/trunk/test/Analysis/expr-inspection.c (original)
+++ cfe/trunk/test/Analysis/expr-inspection.c Mon Dec 5 14:30:11 2016
@@ -7,7 +7,7 @@ void clang_analyzer_printState();
void clang_analyzer_numTimesReached();
void foo(int x) {
- clang_analyzer_dump(x); // expected-warning{{reg_$0}}
+ clang_analyzer_dump(x); // expected-warning{{reg_$0}}
int y = 1;
clang_analyzer_printState();
for (; y < 3; ++y)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27365: [analyzer] Print type for SymbolRegionValues when dumping to stream
ddcc updated this revision to Diff 80310.
ddcc added a comment.
Fix rebase
https://reviews.llvm.org/D27365
Files:
lib/StaticAnalyzer/Core/SymbolManager.cpp
test/Analysis/expr-inspection.c
Index: test/Analysis/expr-inspection.c
===
--- test/Analysis/expr-inspection.c
+++ test/Analysis/expr-inspection.c
@@ -7,7 +7,7 @@
void clang_analyzer_numTimesReached();
void foo(int x) {
- clang_analyzer_dump(x); // expected-warning{{reg_$0}}
+ clang_analyzer_dump(x); // expected-warning{{reg_$0}}
int y = 1;
clang_analyzer_printState();
for (; y < 3; ++y)
Index: lib/StaticAnalyzer/Core/SymbolManager.cpp
===
--- lib/StaticAnalyzer/Core/SymbolManager.cpp
+++ lib/StaticAnalyzer/Core/SymbolManager.cpp
@@ -85,7 +85,8 @@
void SymbolData::anchor() { }
void SymbolRegionValue::dumpToStream(raw_ostream &os) const {
- os << "reg_$" << getSymbolID() << "<" << R << ">";
+ os << "reg_$" << getSymbolID()
+ << '<' << getType().getAsString() << ' ' << R << '>';
}
bool SymExpr::symbol_iterator::operator==(const symbol_iterator &X) const {
Index: test/Analysis/expr-inspection.c
===
--- test/Analysis/expr-inspection.c
+++ test/Analysis/expr-inspection.c
@@ -7,7 +7,7 @@
void clang_analyzer_numTimesReached();
void foo(int x) {
- clang_analyzer_dump(x); // expected-warning{{reg_$0}}
+ clang_analyzer_dump(x); // expected-warning{{reg_$0}}
int y = 1;
clang_analyzer_printState();
for (; y < 3; ++y)
Index: lib/StaticAnalyzer/Core/SymbolManager.cpp
===
--- lib/StaticAnalyzer/Core/SymbolManager.cpp
+++ lib/StaticAnalyzer/Core/SymbolManager.cpp
@@ -85,7 +85,8 @@
void SymbolData::anchor() { }
void SymbolRegionValue::dumpToStream(raw_ostream &os) const {
- os << "reg_$" << getSymbolID() << "<" << R << ">";
+ os << "reg_$" << getSymbolID()
+ << '<' << getType().getAsString() << ' ' << R << '>';
}
bool SymExpr::symbol_iterator::operator==(const symbol_iterator &X) const {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27365: [analyzer] Print type for SymbolRegionValues when dumping to stream
This revision was automatically updated to reflect the committed changes.
Closed by commit rL288696: [analyzer] Print type for SymbolRegionValues when
dumping to stream (authored by ddcc).
Changed prior to commit:
https://reviews.llvm.org/D27365?vs=80310&id=80311#toc
Repository:
rL LLVM
https://reviews.llvm.org/D27365
Files:
cfe/trunk/lib/StaticAnalyzer/Core/SymbolManager.cpp
cfe/trunk/test/Analysis/expr-inspection.c
Index: cfe/trunk/lib/StaticAnalyzer/Core/SymbolManager.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/SymbolManager.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/SymbolManager.cpp
@@ -85,7 +85,8 @@
void SymbolData::anchor() { }
void SymbolRegionValue::dumpToStream(raw_ostream &os) const {
- os << "reg_$" << getSymbolID() << "<" << R << ">";
+ os << "reg_$" << getSymbolID()
+ << '<' << getType().getAsString() << ' ' << R << '>';
}
bool SymExpr::symbol_iterator::operator==(const symbol_iterator &X) const {
Index: cfe/trunk/test/Analysis/expr-inspection.c
===
--- cfe/trunk/test/Analysis/expr-inspection.c
+++ cfe/trunk/test/Analysis/expr-inspection.c
@@ -7,7 +7,7 @@
void clang_analyzer_numTimesReached();
void foo(int x) {
- clang_analyzer_dump(x); // expected-warning{{reg_$0}}
+ clang_analyzer_dump(x); // expected-warning{{reg_$0}}
int y = 1;
clang_analyzer_printState();
for (; y < 3; ++y)
Index: cfe/trunk/lib/StaticAnalyzer/Core/SymbolManager.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/SymbolManager.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/SymbolManager.cpp
@@ -85,7 +85,8 @@
void SymbolData::anchor() { }
void SymbolRegionValue::dumpToStream(raw_ostream &os) const {
- os << "reg_$" << getSymbolID() << "<" << R << ">";
+ os << "reg_$" << getSymbolID()
+ << '<' << getType().getAsString() << ' ' << R << '>';
}
bool SymExpr::symbol_iterator::operator==(const symbol_iterator &X) const {
Index: cfe/trunk/test/Analysis/expr-inspection.c
===
--- cfe/trunk/test/Analysis/expr-inspection.c
+++ cfe/trunk/test/Analysis/expr-inspection.c
@@ -7,7 +7,7 @@
void clang_analyzer_numTimesReached();
void foo(int x) {
- clang_analyzer_dump(x); // expected-warning{{reg_$0}}
+ clang_analyzer_dump(x); // expected-warning{{reg_$0}}
int y = 1;
clang_analyzer_printState();
for (; y < 3; ++y)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26376: Undef stdatomic.h macro definitions that are defining functions provided in libc++
mehdi_amini abandoned this revision. mehdi_amini added a comment. Thanks for the information! Closing this. https://reviews.llvm.org/D26376 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27360: [clang] Fix D26214: Move error handling out of MC and to the callers.
mgrang added a comment. Moved error checking up to the driver and added another test case. https://reviews.llvm.org/D27360 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27360: [clang] Fix D26214: Move error handling out of MC and to the callers.
mgrang updated this revision to Diff 80314.
https://reviews.llvm.org/D27360
Files:
include/clang/Basic/DiagnosticDriverKinds.td
lib/Driver/Tools.cpp
test/Driver/defsym.s
tools/driver/cc1as_main.cpp
Index: tools/driver/cc1as_main.cpp
===
--- tools/driver/cc1as_main.cpp
+++ tools/driver/cc1as_main.cpp
@@ -426,10 +426,13 @@
// Set values for symbols, if any.
for (auto &S : Opts.SymbolDefs) {
-if (Ctx.setSymbolValue(Parser->getStreamer(), S)) {
- Failed = true;
- break;
-}
+auto Pair = StringRef(S).split('=');
+auto Sym = Pair.first;
+auto Val = Pair.second;
+int64_t Value;
+// We have already error checked this in the driver.
+Val.getAsInteger(0, Value);
+Ctx.setSymbolValue(Parser->getStreamer(), Sym, Value);
}
if (!Failed) {
Index: test/Driver/defsym.s
===
--- test/Driver/defsym.s
+++ test/Driver/defsym.s
@@ -17,6 +17,21 @@
// CHECK-DEFSYM-ERR1: error: defsym must be of the form: sym=value: abc=
// RUN: not %clang -c -integrated-as -o /dev/null %s \
-// RUN: -Wa,-defsym,abc=1a2b3c \
+// RUN: -Wa,-defsym,=123 \
// RUN: 2>&1 | FileCheck %s --check-prefix=CHECK-DEFSYM-ERR2
-// CHECK-DEFSYM-ERR2: error: Value is not an integer: 1a2b3c
+// CHECK-DEFSYM-ERR2: error: defsym must be of the form: sym=value: =123
+
+// RUN: not %clang -c -integrated-as -o /dev/null %s \
+// RUN: -Wa,-defsym,abc=1a2b3c \
+// RUN: 2>&1 | FileCheck %s --check-prefix=CHECK-DEFSYM-ERR3
+// CHECK-DEFSYM-ERR3: error: Value is not an integer: 1a2b3c
+
+// RUN: not %clang -c -integrated-as -o /dev/null %s \
+// RUN: -Wa,-defsym \
+// RUN: 2>&1 | FileCheck %s --check-prefix=CHECK-DEFSYM-ERR4
+
+// RUN: not %clang -c -integrated-as -o /dev/null %s \
+// RUN: -Wa,-defsym, \
+// RUN: 2>&1 | FileCheck %s --check-prefix=CHECK-DEFSYM-ERR4
+
+// CHECK-DEFSYM-ERR4: error: defsym must be of the form: sym=value: -defsym
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -3116,6 +3116,24 @@
Value.startswith("-mhwdiv") || Value.startswith("-march")) {
// Do nothing, we'll validate it later.
} else if (Value == "-defsym") {
+ if (A->getNumValues() != 2) {
+D.Diag(diag::err_drv_defsym_invalid_format) << Value;
+break;
+ }
+ const char *S = A->getValue(1);
+ auto Pair = StringRef(S).split('=');
+ auto Sym = Pair.first;
+ auto SVal = Pair.second;
+
+ if (Sym.empty() || SVal.empty()) {
+D.Diag(diag::err_drv_defsym_invalid_format) << S;
+break;
+ }
+ int64_t IVal;
+ if (SVal.getAsInteger(0, IVal)) {
+D.Diag(diag::err_drv_defsym_invalid_symval) << SVal;
+break;
+ }
CmdArgs.push_back(Value.data());
TakeNextArg = true;
} else {
Index: include/clang/Basic/DiagnosticDriverKinds.td
===
--- include/clang/Basic/DiagnosticDriverKinds.td
+++ include/clang/Basic/DiagnosticDriverKinds.td
@@ -277,4 +277,6 @@
InGroup;
def err_drv_unsupported_linker : Error<"unsupported value '%0' for -linker
option">;
+def err_drv_defsym_invalid_format : Error<"defsym must be of the form:
sym=value: %0">;
+def err_drv_defsym_invalid_symval : Error<"Value is not an integer: %0">;
}
Index: tools/driver/cc1as_main.cpp
===
--- tools/driver/cc1as_main.cpp
+++ tools/driver/cc1as_main.cpp
@@ -426,10 +426,13 @@
// Set values for symbols, if any.
for (auto &S : Opts.SymbolDefs) {
-if (Ctx.setSymbolValue(Parser->getStreamer(), S)) {
- Failed = true;
- break;
-}
+auto Pair = StringRef(S).split('=');
+auto Sym = Pair.first;
+auto Val = Pair.second;
+int64_t Value;
+// We have already error checked this in the driver.
+Val.getAsInteger(0, Value);
+Ctx.setSymbolValue(Parser->getStreamer(), Sym, Value);
}
if (!Failed) {
Index: test/Driver/defsym.s
===
--- test/Driver/defsym.s
+++ test/Driver/defsym.s
@@ -17,6 +17,21 @@
// CHECK-DEFSYM-ERR1: error: defsym must be of the form: sym=value: abc=
// RUN: not %clang -c -integrated-as -o /dev/null %s \
-// RUN: -Wa,-defsym,abc=1a2b3c \
+// RUN: -Wa,-defsym,=123 \
// RUN: 2>&1 | FileCheck %s --check-prefix=CHECK-DEFSYM-ERR2
-// CHECK-DEFSYM-ERR2: error: Value is not an integer: 1a2b3c
+// CHECK-DEFSYM-ERR2: error: defsym must be of the form: sym=value: =123
+
+// RUN: not %clang -c -integrated-as -o /dev/null %s \
+// RUN: -Wa,-defsym,abc=1a2b3c \
+// RUN: 2>&1 | FileCheck %s --check-prefix=CHECK-DEFSYM-ERR3
+// CHECK-DEFSYM-ERR3: error: Value is not an integer: 1a2b3c
+
+
[PATCH] D14274: Add alloc_size attribute to clang
george.burgess.iv added a comment. Ping :) https://reviews.llvm.org/D14274 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27429: [Chrono][Darwin] On Darwin use CLOCK_UPTIME_RAW instead of CLOCK_MONOTONIC
bruno created this revision.
bruno added reviewers: mclow.lists, dexonsmith, EricWF.
bruno added a subscriber: cfe-commits.
CLOCK_MONOTONIC is only defined on Darwin on libc versions >= 1133 and its
behaviour differs from Linux. CLOCK_UPTIME on Darwin actually matches
CLOCK_MONOTONIC on Linux, due to historical coincidence (Linux doesn't match
POSIX here but Darwin does). Use CLOCK_UPTIME_RAW on Darwin since the _RAW
version gives nanosecond precision and is lower overhead.
https://reviews.llvm.org/D27429
Files:
src/chrono.cpp
Index: src/chrono.cpp
===
--- src/chrono.cpp
+++ src/chrono.cpp
@@ -75,8 +75,19 @@
steady_clock::now() _NOEXCEPT
{
struct timespec tp;
+#if defined(__APPLE__) && defined(CLOCK_UPTIME_RAW)
+// CLOCK_MONOTONIC is only defined on Darwin on libc versions >= 1133 and
+// its behaviour differs from Linux.
+// CLOCK_UPTIME on Darwin actually matches CLOCK_MONOTONIC on Linux, due to
+// historical coincidence (Linux doesn't match POSIX here but Darwin does).
+// Use CLOCK_UPTIME_RAW on Darwin since the _RAW version gives nanosecond
+// precision and is lower overhead.
+if (0 != clock_gettime(CLOCK_UPTIME_RAW, &tp))
+__throw_system_error(errno, "clock_gettime(CLOCK_UPTIME_RAW) failed");
+#else
if (0 != clock_gettime(CLOCK_MONOTONIC, &tp))
__throw_system_error(errno, "clock_gettime(CLOCK_MONOTONIC) failed");
+#endif
return time_point(seconds(tp.tv_sec) + nanoseconds(tp.tv_nsec));
}
Index: src/chrono.cpp
===
--- src/chrono.cpp
+++ src/chrono.cpp
@@ -75,8 +75,19 @@
steady_clock::now() _NOEXCEPT
{
struct timespec tp;
+#if defined(__APPLE__) && defined(CLOCK_UPTIME_RAW)
+// CLOCK_MONOTONIC is only defined on Darwin on libc versions >= 1133 and
+// its behaviour differs from Linux.
+// CLOCK_UPTIME on Darwin actually matches CLOCK_MONOTONIC on Linux, due to
+// historical coincidence (Linux doesn't match POSIX here but Darwin does).
+// Use CLOCK_UPTIME_RAW on Darwin since the _RAW version gives nanosecond
+// precision and is lower overhead.
+if (0 != clock_gettime(CLOCK_UPTIME_RAW, &tp))
+__throw_system_error(errno, "clock_gettime(CLOCK_UPTIME_RAW) failed");
+#else
if (0 != clock_gettime(CLOCK_MONOTONIC, &tp))
__throw_system_error(errno, "clock_gettime(CLOCK_MONOTONIC) failed");
+#endif
return time_point(seconds(tp.tv_sec) + nanoseconds(tp.tv_nsec));
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27140: Allow clang to write compilation database records
arichardson added a comment. It would also be good to append --sysroot=DEFAULT_SYSROOT if DEFAULT_SYSROOT is not empty and there is no explicit --sysroot flag. That way the compilation database can also be consumed by a libclang based too that does not have the same DEFAULT_SYSROOT set. Repository: rL LLVM https://reviews.llvm.org/D27140 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r288721 - CodeGen: fix windows itanium RTTI in EH mode
Author: compnerd
Date: Mon Dec 5 16:40:20 2016
New Revision: 288721
URL: http://llvm.org/viewvc/llvm-project?rev=288721&view=rev
Log:
CodeGen: fix windows itanium RTTI in EH mode
When emitting RTTI for EH only, we would mark the locally defined (LinkOnceODR)
RTTI definition as dllimport, which is incorrect. Ensure that if we are
generating the type information for EH only, it is marked as LinkOnceODR and we
do not make it dllimport.
Modified:
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/test/CodeGenCXX/windows-itanium-type-info.cpp
Modified: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp?rev=288721&r1=288720&r2=288721&view=diff
==
--- cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp Mon Dec 5 16:40:20 2016
@@ -3133,7 +3133,7 @@ llvm::Constant *ItaniumRTTIBuilder::Buil
if (DLLExport || (RD && RD->hasAttr())) {
TypeName->setDLLStorageClass(llvm::GlobalValue::DLLExportStorageClass);
GV->setDLLStorageClass(llvm::GlobalValue::DLLExportStorageClass);
-} else if (RD && RD->hasAttr()) {
+} else if (CGM.getLangOpts().RTTI && RD && RD->hasAttr()) {
TypeName->setDLLStorageClass(llvm::GlobalValue::DLLImportStorageClass);
GV->setDLLStorageClass(llvm::GlobalValue::DLLImportStorageClass);
Modified: cfe/trunk/test/CodeGenCXX/windows-itanium-type-info.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/windows-itanium-type-info.cpp?rev=288721&r1=288720&r2=288721&view=diff
==
--- cfe/trunk/test/CodeGenCXX/windows-itanium-type-info.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/windows-itanium-type-info.cpp Mon Dec 5 16:40:20
2016
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -triple i686-windows-itanium -fdeclspec -emit-llvm %s -o -
| FileCheck %s
+// RUN: %clang_cc1 -triple i686-windows-itanium -fdeclspec -fcxx-exceptions
-emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple i686-windows-itanium -fdeclspec -fcxx-exceptions
-fno-rtti -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-EH-IMPORT
namespace __cxxabiv1 {
class __declspec(dllexport) __fundamental_type_info {
@@ -19,6 +20,10 @@ derived::~derived() {
method();
}
+void f() {
+ throw base();
+}
+
// CHECK-DAG: @_ZTIi = dllexport constant
// CHECK-DAG: @_ZTSi = dllexport constant
@@ -30,3 +35,6 @@ derived::~derived() {
// CHECK-DAG: @_ZTS4base = external dllimport constant
// CHECK-NOT: @_ZTV4base = external dllimport constant
+// CHECK-EH-IMPORT: @_ZTS4base = linkonce_odr constant
+// CHECK-EH-IMPORT: @_ZTI4base = linkonce_odr constant
+
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26960: [docs] Use x86_64 and i386 instead of x86 as arch for triples.
This revision was automatically updated to reflect the committed changes. Closed by commit rL288723: [docs] Use x86_64 and i386 instead of x86 as arch for triples. (authored by fhahn). Changed prior to commit: https://reviews.llvm.org/D26960?vs=78842&id=80332#toc Repository: rL LLVM https://reviews.llvm.org/D26960 Files: cfe/trunk/docs/CrossCompilation.rst Index: cfe/trunk/docs/CrossCompilation.rst === --- cfe/trunk/docs/CrossCompilation.rst +++ cfe/trunk/docs/CrossCompilation.rst @@ -78,14 +78,14 @@ on when assembling or linking. The triple has the general format ``---``, where: - * ``arch`` = ``x86``, ``arm``, ``thumb``, ``mips``, etc. + * ``arch`` = ``x86_64``, ``i386``, ``arm``, ``thumb``, ``mips``, etc. * ``sub`` = for ex. on ARM: ``v5``, ``v6m``, ``v7a``, ``v7m``, etc. * ``vendor`` = ``pc``, ``apple``, ``nvidia``, ``ibm``, etc. * ``sys`` = ``none``, ``linux``, ``win32``, ``darwin``, ``cuda``, etc. * ``abi`` = ``eabi``, ``gnu``, ``android``, ``macho``, ``elf``, etc. The sub-architecture options are available for their own architectures, -of course, so "x86v7a" doesn't make sense. The vendor needs to be +of course, so "x86v7a" doesn't make sense. The vendor needs to be specified only if there's a relevant change, for instance between PC and Apple. Most of the time it can be omitted (and Unknown) will be assumed, which sets the defaults for the specified architecture. Index: cfe/trunk/docs/CrossCompilation.rst === --- cfe/trunk/docs/CrossCompilation.rst +++ cfe/trunk/docs/CrossCompilation.rst @@ -78,14 +78,14 @@ on when assembling or linking. The triple has the general format ``---``, where: - * ``arch`` = ``x86``, ``arm``, ``thumb``, ``mips``, etc. + * ``arch`` = ``x86_64``, ``i386``, ``arm``, ``thumb``, ``mips``, etc. * ``sub`` = for ex. on ARM: ``v5``, ``v6m``, ``v7a``, ``v7m``, etc. * ``vendor`` = ``pc``, ``apple``, ``nvidia``, ``ibm``, etc. * ``sys`` = ``none``, ``linux``, ``win32``, ``darwin``, ``cuda``, etc. * ``abi`` = ``eabi``, ``gnu``, ``android``, ``macho``, ``elf``, etc. The sub-architecture options are available for their own architectures, -of course, so "x86v7a" doesn't make sense. The vendor needs to be +of course, so "x86v7a" doesn't make sense. The vendor needs to be specified only if there's a relevant change, for instance between PC and Apple. Most of the time it can be omitted (and Unknown) will be assumed, which sets the defaults for the specified architecture. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D27430: [libc++] Annotate template methods with visibility
smeenai created this revision.
smeenai added reviewers: EricWF, mclow.lists.
smeenai added subscribers: cfe-commits, thakis.
https://reviews.llvm.org/D25208 switches `_LIBCPP_TYPE_VIS` to expand to
default visibility
instead of default type visibility, in order to ease building libc++
with hidden visibility. With that change made, any template methods of a
class marked `_LIBCPP_TYPE_VIS` will also get default visibility when
implicitly instantiated, which is not desirable for clients of libc++
headers who wish to control their visibility; a similar issue led to
PR30642. Annotate all problematic methods with an explicit visibility
specifier in order to avoid this issue.
The problematic methods were found by applying https://reviews.llvm.org/D25208
and then running
https://github.com/smeenai/bad-visibility-finder. The small methods were
marked for inlining; the larger ones marked hidden.
https://reviews.llvm.org/D27430
Files:
include/__locale
include/__mutex_base
include/condition_variable
include/future
include/mutex
include/thread
Index: include/thread
===
--- include/thread
+++ include/thread
@@ -389,6 +389,7 @@
}
template
+_LIBCPP_HIDDEN
thread::thread(_Fp __f)
{
Index: include/mutex
===
--- include/mutex
+++ include/mutex
@@ -252,6 +252,7 @@
};
template
+_LIBCPP_HIDDEN
bool
timed_mutex::try_lock_until(const chrono::time_point<_Clock, _Duration>& __t)
{
@@ -295,6 +296,7 @@
};
template
+_LIBCPP_HIDDEN
bool
recursive_timed_mutex::try_lock_until(const chrono::time_point<_Clock, _Duration>& __t)
{
Index: include/future
===
--- include/future
+++ include/future
@@ -588,6 +588,7 @@
};
template
+_LIBCPP_HIDDEN
future_status
__assoc_sub_state::wait_until(const chrono::time_point<_Clock, _Duration>& __abs_time) const
{
@@ -1716,6 +1717,7 @@
};
template
+_LIBCPP_HIDDEN
promise::promise(allocator_arg_t, const _Alloc& __a0)
{
typedef __assoc_sub_state_alloc<_Alloc> _State;
Index: include/condition_variable
===
--- include/condition_variable
+++ include/condition_variable
@@ -191,6 +191,7 @@
};
template
+_LIBCPP_HIDDEN
void
condition_variable_any::wait(_Lock& __lock)
{
@@ -212,6 +213,7 @@
}
template
+_LIBCPP_HIDDEN
cv_status
condition_variable_any::wait_until(_Lock& __lock,
const chrono::time_point<_Clock, _Duration>& __t)
Index: include/__mutex_base
===
--- include/__mutex_base
+++ include/__mutex_base
@@ -368,14 +368,16 @@
#ifndef _LIBCPP_HAS_NO_THREADS
template
+inline _LIBCPP_INLINE_VISIBILITY
void
condition_variable::wait(unique_lock& __lk, _Predicate __pred)
{
while (!__pred())
wait(__lk);
}
template
+_LIBCPP_HIDDEN
cv_status
condition_variable::wait_until(unique_lock& __lk,
const chrono::time_point<_Clock, _Duration>& __t)
@@ -386,6 +388,7 @@
}
template
+_LIBCPP_HIDDEN
bool
condition_variable::wait_until(unique_lock& __lk,
const chrono::time_point<_Clock, _Duration>& __t,
@@ -400,6 +403,7 @@
}
template
+_LIBCPP_HIDDEN
cv_status
condition_variable::wait_for(unique_lock& __lk,
const chrono::duration<_Rep, _Period>& __d)
Index: include/__locale
===
--- include/__locale
+++ include/__locale
@@ -162,6 +162,7 @@
}
template
+inline _LIBCPP_INLINE_VISIBILITY
locale
locale::combine(const locale& __other) const
{
@@ -316,6 +317,7 @@
};
template
+inline _LIBCPP_INLINE_VISIBILITY
bool
locale::operator()(const basic_string<_CharT, _Traits, _Allocator>& __x,
const basic_string<_CharT, _Traits, _Allocator>& __y) const
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D25208: [libc++] Make _LIBCPP_TYPE_VIS export members
smeenai updated this revision to Diff 80334.
smeenai added a comment.
Rebasing
https://reviews.llvm.org/D25208
Files:
docs/DesignDocs/VisibilityMacros.rst
include/__config
Index: include/__config
===
--- include/__config
+++ include/__config
@@ -563,18 +563,22 @@
#ifndef _LIBCPP_TYPE_VIS
# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
-#if __has_attribute(__type_visibility__)
-# define _LIBCPP_TYPE_VIS __attribute__ ((__type_visibility__("default")))
-#else
-# define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
-#endif
+#define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
# else
#define _LIBCPP_TYPE_VIS
# endif
#endif
#ifndef _LIBCPP_TYPE_VIS_ONLY
-# define _LIBCPP_TYPE_VIS_ONLY _LIBCPP_TYPE_VIS
+# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
+#if __has_attribute(__type_visibility__)
+# define _LIBCPP_TYPE_VIS_ONLY __attribute__
((__type_visibility__("default")))
+#else
+# define _LIBCPP_TYPE_VIS_ONLY __attribute__ ((__visibility__("default")))
+#endif
+# else
+#define _LIBCPP_TYPE_VIS_ONLY
+# endif
#endif
#ifndef _LIBCPP_FUNC_VIS_ONLY
Index: docs/DesignDocs/VisibilityMacros.rst
===
--- docs/DesignDocs/VisibilityMacros.rst
+++ docs/DesignDocs/VisibilityMacros.rst
@@ -41,17 +41,17 @@
A synonym for `_LIBCPP_INLINE_VISIBILITY`
**_LIBCPP_TYPE_VIS**
+ Mark a type's typeinfo, vtable and members as having default visibility.
+ This attribute cannot be used on class templates.
+
+**_LIBCPP_TYPE_VIS_ONLY**
Mark a type's typeinfo and vtable as having default visibility.
- `_LIBCPP_TYPE_VIS`. This macro has no effect on the visibility of the
- type's member functions. This attribute cannot be used on class templates.
+ This macro has no effect on the visibility of the type's member functions.
**GCC Behavior**: GCC does not support Clang's `type_visibility(...)`
attribute. With GCC the `visibility(...)` attribute is used and member
functions are affected.
-**_LIBCPP_TYPE_VIS_ONLY**
- The same as `_LIBCPP_TYPE_VIS` except that it may be applied to templates.
-
**Windows Behavior**: DLLs do not support dllimport/export on class
templates.
The macro has an empty definition on this platform.
Index: include/__config
===
--- include/__config
+++ include/__config
@@ -563,18 +563,22 @@
#ifndef _LIBCPP_TYPE_VIS
# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
-#if __has_attribute(__type_visibility__)
-# define _LIBCPP_TYPE_VIS __attribute__ ((__type_visibility__("default")))
-#else
-# define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
-#endif
+#define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
# else
#define _LIBCPP_TYPE_VIS
# endif
#endif
#ifndef _LIBCPP_TYPE_VIS_ONLY
-# define _LIBCPP_TYPE_VIS_ONLY _LIBCPP_TYPE_VIS
+# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
+#if __has_attribute(__type_visibility__)
+# define _LIBCPP_TYPE_VIS_ONLY __attribute__ ((__type_visibility__("default")))
+#else
+# define _LIBCPP_TYPE_VIS_ONLY __attribute__ ((__visibility__("default")))
+#endif
+# else
+#define _LIBCPP_TYPE_VIS_ONLY
+# endif
#endif
#ifndef _LIBCPP_FUNC_VIS_ONLY
Index: docs/DesignDocs/VisibilityMacros.rst
===
--- docs/DesignDocs/VisibilityMacros.rst
+++ docs/DesignDocs/VisibilityMacros.rst
@@ -41,17 +41,17 @@
A synonym for `_LIBCPP_INLINE_VISIBILITY`
**_LIBCPP_TYPE_VIS**
+ Mark a type's typeinfo, vtable and members as having default visibility.
+ This attribute cannot be used on class templates.
+
+**_LIBCPP_TYPE_VIS_ONLY**
Mark a type's typeinfo and vtable as having default visibility.
- `_LIBCPP_TYPE_VIS`. This macro has no effect on the visibility of the
- type's member functions. This attribute cannot be used on class templates.
+ This macro has no effect on the visibility of the type's member functions.
**GCC Behavior**: GCC does not support Clang's `type_visibility(...)`
attribute. With GCC the `visibility(...)` attribute is used and member
functions are affected.
-**_LIBCPP_TYPE_VIS_ONLY**
- The same as `_LIBCPP_TYPE_VIS` except that it may be applied to templates.
-
**Windows Behavior**: DLLs do not support dllimport/export on class templates.
The macro has an empty definition on this platform.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D25208: [libc++] Make _LIBCPP_TYPE_VIS export members
smeenai added a comment. https://reviews.llvm.org/D27430 should unblock this. https://reviews.llvm.org/D25208 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r288728 - Adjust libc++ test infastructure to fully support modules
Author: ericwf Date: Mon Dec 5 17:16:07 2016 New Revision: 288728 URL: http://llvm.org/viewvc/llvm-project?rev=288728&view=rev Log: Adjust libc++ test infastructure to fully support modules This patch overhalls the libc++ test format/configuration in order to fully support modules. By "fully support" I mean get almost all of the tests passing. The main hurdle for doing this is handling tests that `#define _LIBCPP_FOO` macros to test a different configuration. This patch deals with these tests in the following ways: 1. For tests that define single `_LIBCPP_ABI_FOO` macros have been annotated with `// MODULES_DEFINES: _LIBCPP_ABI_FOO`. This allows the test suite to define the macro on the command line so it uses a different set of modules. 2. Tests for libc++'s debug mode (which define custom `_LIBCPP_ASSERT`) are automatically detected by the test suite and are compiled and run with modules disabled. This patch also cleans up how the `CXXCompiler` helper class handles enabling/disabling language features. NOTE: This patch uses `LIT` features which were only committed to LLVM today. If this patch breaks running the libc++ tests you probably need to update LLVM. Modified: libcxx/trunk/include/module.modulemap libcxx/trunk/test/libcxx/atomics/libcpp-has-no-threads.fail.cpp libcxx/trunk/test/libcxx/compiler.py libcxx/trunk/test/libcxx/containers/sequences/deque/incomplete.pass.cpp libcxx/trunk/test/libcxx/strings/iterators.noexcept.pass.cpp libcxx/trunk/test/libcxx/test/config.py libcxx/trunk/test/libcxx/test/format.py libcxx/trunk/test/libcxx/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex_mangling.pass.cpp libcxx/trunk/test/libcxx/thread/thread.mutex/thread_safety_lock_guard.pass.cpp libcxx/trunk/test/libcxx/thread/thread.mutex/thread_safety_lock_unlock.pass.cpp libcxx/trunk/test/libcxx/thread/thread.mutex/thread_safety_missing_unlock.fail.cpp libcxx/trunk/test/libcxx/thread/thread.mutex/thread_safety_requires_capability.pass.cpp libcxx/trunk/test/libcxx/utilities/utility/pairs/pairs.pair/non_trivial_copy_move_ABI.pass.cpp libcxx/trunk/test/std/experimental/utilities/tuple/tuple.apply/return_type.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_adopt_lock.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_assign.fail.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_copy.fail.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex.fail.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex_cxx03.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_types.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.shared/thread.lock.shared.cons/mutex.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.shared/thread.lock.shared.cons/mutex_duration.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.shared/thread.lock.shared.cons/mutex_time_point.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.unique/thread.lock.unique.cons/mutex_duration.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.unique/thread.lock.unique.cons/mutex_time_point.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.mutex.requirements/thread.shared_mutex.requirements/thread.shared_mutex.class/lock.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.mutex.requirements/thread.shared_mutex.requirements/thread.shared_mutex.class/lock_shared.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.mutex.requirements/thread.shared_mutex.requirements/thread.shared_mutex.class/try_lock_shared.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.mutex.requirements/thread.sharedtimedmutex.requirements/thread.sharedtimedmutex.class/lock.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.mutex.requirements/thread.sharedtimedmutex.requirements/thread.sharedtimedmutex.class/lock_shared.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.mutex.requirements/thread.sharedtimedmutex.requirements/thread.sharedtimedmutex.class/try_lock_for.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.mutex.requirements/thread.sharedtimedmutex.requirements/thread.sharedtimedmutex.class/try_lock_shared.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.mutex.requirements/thread.sharedtimedmutex.requirements/thread.sharedtimedmutex.class/try_lock_shared_for.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.mutex.requirements/thread.sharedtimedmutex.requirements/thread.sharedtimedmutex.class/try_lock_sha
r288723 - [docs] Use x86_64 and i386 instead of x86 as arch for triples.
Author: fhahn Date: Mon Dec 5 16:52:20 2016 New Revision: 288723 URL: http://llvm.org/viewvc/llvm-project?rev=288723&view=rev Log: [docs] Use x86_64 and i386 instead of x86 as arch for triples. Summary: x86 is not a valid arch for target triples, but x86_64 and i386 are. Reviewers: rengolin, silvas Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D26960 Modified: cfe/trunk/docs/CrossCompilation.rst Modified: cfe/trunk/docs/CrossCompilation.rst URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/CrossCompilation.rst?rev=288723&r1=288722&r2=288723&view=diff == --- cfe/trunk/docs/CrossCompilation.rst (original) +++ cfe/trunk/docs/CrossCompilation.rst Mon Dec 5 16:52:20 2016 @@ -78,14 +78,14 @@ go ahead, creating code for the host pla on when assembling or linking. The triple has the general format ``---``, where: - * ``arch`` = ``x86``, ``arm``, ``thumb``, ``mips``, etc. + * ``arch`` = ``x86_64``, ``i386``, ``arm``, ``thumb``, ``mips``, etc. * ``sub`` = for ex. on ARM: ``v5``, ``v6m``, ``v7a``, ``v7m``, etc. * ``vendor`` = ``pc``, ``apple``, ``nvidia``, ``ibm``, etc. * ``sys`` = ``none``, ``linux``, ``win32``, ``darwin``, ``cuda``, etc. * ``abi`` = ``eabi``, ``gnu``, ``android``, ``macho``, ``elf``, etc. The sub-architecture options are available for their own architectures, -of course, so "x86v7a" doesn't make sense. The vendor needs to be +of course, so "x86v7a" doesn't make sense. The vendor needs to be specified only if there's a relevant change, for instance between PC and Apple. Most of the time it can be omitted (and Unknown) will be assumed, which sets the defaults for the specified architecture. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r288730 - Add modules for any/optional/variant
Author: ericwf
Date: Mon Dec 5 17:33:19 2016
New Revision: 288730
URL: http://llvm.org/viewvc/llvm-project?rev=288730&view=rev
Log:
Add modules for any/optional/variant
Modified:
libcxx/trunk/include/module.modulemap
Modified: libcxx/trunk/include/module.modulemap
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/module.modulemap?rev=288730&r1=288729&r2=288730&view=diff
==
--- libcxx/trunk/include/module.modulemap (original)
+++ libcxx/trunk/include/module.modulemap Mon Dec 5 17:33:19 2016
@@ -205,6 +205,10 @@ module std [system] {
export initializer_list
export *
}
+ module any {
+header "any"
+export *
+ }
module array {
header "array"
export initializer_list
@@ -331,6 +335,10 @@ module std [system] {
header "numeric"
export *
}
+ module optional {
+header "optional"
+export *
+ }
module ostream {
header "ostream"
// FIXME: should re-export ios, streambuf?
@@ -435,6 +443,10 @@ module std [system] {
export initializer_list
export *
}
+ module variant {
+header "variant"
+export *
+ }
module vector {
header "vector"
export initializer_list
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r288732 - Warn on unsigned zero in call to std::max
Author: rtrieu
Date: Mon Dec 5 17:41:46 2016
New Revision: 288732
URL: http://llvm.org/viewvc/llvm-project?rev=288732&view=rev
Log:
Warn on unsigned zero in call to std::max
New default warning that triggers when an unsigned zero is used in a call to
std::max. For unsigned values, zero is the minimum value, so any call to
std::max is always equal to the other value. A common pattern was to take
the max of zero and the difference of two unsigned values, not taking into
account that unsigned values wrap around below zero. This warning also emits
a note with a fixit hint to remove the zero and call to std::max.
Modified:
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaChecking.cpp
Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=288732&r1=288731&r2=288732&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Mon Dec 5 17:41:46 2016
@@ -256,6 +256,7 @@ def LoopAnalysis : DiagGroup<"loop-analy
def MalformedWarningCheck : DiagGroup<"malformed-warning-check">;
def Main : DiagGroup<"main">;
def MainReturnType : DiagGroup<"main-return-type">;
+def MaxUnsignedZero : DiagGroup<"max-unsigned-zero">;
def MissingBraces : DiagGroup<"missing-braces">;
def MissingDeclarations: DiagGroup<"missing-declarations">;
def : DiagGroup<"missing-format-attribute">;
Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=288732&r1=288731&r2=288732&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Mon Dec 5 17:41:46
2016
@@ -53,6 +53,14 @@ def warn_pointer_abs : Warning<
"taking the absolute value of %select{pointer|function|array}0 type %1 is
suspicious">,
InGroup;
+def warn_max_unsigned_zero : Warning<
+ "taking the max of "
+ "%select{a value and unsigned zero|unsigned zero and a value}0 "
+ "is always equal to the other value">,
+ InGroup;
+def note_remove_max_call : Note<
+ "remove call to max function and unsigned zero argument">;
+
def warn_infinite_recursive_function : Warning<
"all paths through this function will call itself">,
InGroup, DefaultIgnore;
Modified: cfe/trunk/include/clang/Sema/Sema.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=288732&r1=288731&r2=288732&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Mon Dec 5 17:41:46 2016
@@ -9802,6 +9802,9 @@ private:
const FunctionDecl *FDecl,
IdentifierInfo *FnInfo);
+ void CheckMinZero(const CallExpr *Call, const FunctionDecl *FDecl,
+IdentifierInfo *FnInfo);
+
void CheckMemaccessArguments(const CallExpr *Call,
unsigned BId,
IdentifierInfo *FnName);
Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=288732&r1=288731&r2=288732&view=diff
==
--- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
+++ cfe/trunk/lib/Sema/SemaChecking.cpp Mon Dec 5 17:41:46 2016
@@ -2518,6 +2518,8 @@ bool Sema::CheckFunctionCall(FunctionDec
return false;
CheckAbsoluteValueFunction(TheCall, FDecl, FnInfo);
+ CheckMinZero(TheCall, FDecl, FnInfo);
+
if (getLangOpts().ObjC1)
DiagnoseCStringFormatDirectiveInCFAPI(*this, FDecl, Args, NumArgs);
@@ -6767,6 +6769,91 @@ void Sema::CheckAbsoluteValueFunction(co
Call->getCallee()->getSourceRange(), NewAbsKind, ArgType);
}
+//===--- CHECK: Warn on use of std::max and unsigned zero.
r---===//
+static bool IsFunctionStdMax(const FunctionDecl *FDecl) {
+ if (!FDecl)
+return false;
+
+ if (!FDecl->getIdentifier() || !FDecl->getIdentifier()->isStr("max"))
+return false;
+
+ const NamespaceDecl *ND = dyn_cast(FDecl->getDeclContext());
+
+ while (ND && ND->isInlineNamespace()) {
+ND = dyn_cast(ND->getDeclContext());
+ }
+
+ if (!ND || !ND->getIdentifier() || !ND->getIdentifier()->isStr("std"))
+return false;
+
+ if (!isa(ND->getDeclContext()))
+return false;
+
+ return true;
+}
+
+void Sema::CheckMinZero(const CallExpr *Call, const FunctionDecl *FDecl,
+IdentifierInfo *FnInfo) {
+ if (!Call || !FDec
[libcxx] r288733 - Add module definitions for string_view
Author: ericwf
Date: Mon Dec 5 17:53:23 2016
New Revision: 288733
URL: http://llvm.org/viewvc/llvm-project?rev=288733&view=rev
Log:
Add module definitions for string_view
Modified:
libcxx/trunk/include/module.modulemap
libcxx/trunk/include/string_view
Modified: libcxx/trunk/include/module.modulemap
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/module.modulemap?rev=288733&r1=288732&r2=288733&view=diff
==
--- libcxx/trunk/include/module.modulemap (original)
+++ libcxx/trunk/include/module.modulemap Mon Dec 5 17:53:23 2016
@@ -393,6 +393,14 @@ module std [system] {
module string {
header "string"
export initializer_list
+export string_view
+export __string
+export *
+ }
+ module string_view {
+header "string_view"
+export initializer_list
+export __string
export *
}
module strstream {
@@ -468,6 +476,7 @@ module std [system] {
module __split_buffer { header "__split_buffer" export * }
module __sso_allocator { header "__sso_allocator" export * }
module __std_stream { header "__std_stream" export * }
+ module __string { header "__string" export * }
module __tree { header "__tree" export * }
module __tuple { header "__tuple" export * }
module __undef_min_max { header "__undef_min_max" export * }
Modified: libcxx/trunk/include/string_view
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/string_view?rev=288733&r1=288732&r2=288733&view=diff
==
--- libcxx/trunk/include/string_view (original)
+++ libcxx/trunk/include/string_view Mon Dec 5 17:53:23 2016
@@ -164,7 +164,10 @@ namespace std {
#include <__config>
#include <__string>
+#include
#include
+#include
+#include
#include <__debug>
#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
