All the compilers we support provide these builtins. We don't
need to do a configuration dance anymore.
This patch also cleans up some dead or almost dead
C++11 feature detection macros.
llvm-svn: 364047
Summary:
The type timespec is unconditionally used in __threading_support.
Since the C library is only required to provide it in C11, this might
cause problems for platforms with external thread porting layer (i.e.
when _LIBCPP_HAS_THREAD_API_EXTERNAL is defined) with pre-C11
C libraries.
In our downstream port of libc++ we used to provide a definition of
timespec in __external_threading, but this solution is not ideal
because timespec is not a reserved name.
This patch renames timespec into __libcpp_timespec_t in the
thread-related parts of libc++. For all cases except external
threading this type is an alias for ::timespec (and no functional
changes are intended).
In case of external threading it is expected that the
__external_threading header will either provide a similar typedef (if
timespec is available in the vendor's C library) or provide a
definition of __libcpp_timespec_t compatible with POSIX timespec.
Reviewers: ldionne, mclow.lists, EricWF
Reviewed By: ldionne
Subscribers: dexonsmith, libcxx-commits, christof, carwil
Tags: #libc
Differential Revision: https://reviews.llvm.org/D63328
llvm-svn: 364012
This is a re-application of r362986 (which was reverted in r363688) with fixes
for the issue that caused it to be reverted.
Thanks to Arthur O'Dwyer for the patch.
Differential Revision: https://reviews.llvm.org/D58587
llvm-svn: 363968
Summary:
AIX system headers need stdint.h and inttypes.h to be re-enterable when macro _STD_TYPES_T is defined so that limit macro definitions such as UINT32_MAX can be found. This patch attempts to allow that on AIX.
Reviewers: hubert.reinterpretcast, jasonliu, mclow.lists, EricWF
Reviewed by: hubert.reinterpretcast, mclow.lists
Subscribers: jfb, jsji, christof, cfe-commits, libcxx-commits, llvm-commits
Tags: #LLVM, #clang, #libc++
Differential Revision: https://reviews.llvm.org/D59253
llvm-svn: 363939
This was found to be broken on Clang trunk. This is a revert of the
following commits (the subsequent commits added XFAILs to the tests
that were missing from the original submission):
r362986: Implement deduction guides for map/multimap.
r363014: Add some XFAILs
r363097: Add more XFAILs
r363197: Add even more XFAILs
llvm-svn: 363688
Summary:
The class ctype_base in the header <__locale> contains masks for
character classification functions, which are kept in sync with
platform's C library, hence it contains many special cases.
The value of the bit mask __regex_word in the header <regex> must not
clash with those bit masks.
Currently the default case (i.e. unknown platform/C library) is
handled incorrectly: the __regex_word clashes with ctype_base::punct.
To avoid replicating the whole list of platforms in <regex> this patch
defines __regex_word in <__locale>, so that it is always kept in sync
with other masks.
Reviewers: ldionne, mclow.lists, EricWF
Reviewed By: ldionne
Subscribers: krytarowski, christof, dexonsmith, pbarrio, simon_tatham, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D63284
llvm-svn: 363363
Summary:
This patch make G++03 explicitly unsupported with libc++, as discussed on the mailing lists.
Below is the rational for this decision.
----------------------------------------------------------------------------------------------------
libc++ claims to support GCC with C++03 ("G++03"), and this is a problem for our users.
Our C++03 users are all using Clang. They must be. Less than 9% of the C++03 tests pass with GCC [1][2]. No non-trivial C++ program could work.
Attempting to support G++03 impacts our QoI considerably. Unlike Clang, G++03 offers almost no C++11 extensions. If we could remove all the fallbacks for G++03, it would mean libc++ could::
* Improve Correctness:
Every `#ifdef _LIBCPP_HAS_NO_<C++11-feature>` is a bug manifest. It exists to admit for deviant semantics.
* Achieve ABI stability between C++03 and C++11
Differences between our C++03 and C++Rest branches contain ABI bugs. For example `std::nullptr_t` and `std::function::operator()(...)` are currently incompatible between C++11 and C++03, but could be fixed.
* Decrease Compile Times and Memory Usage:
Writing efficient SFINAE requires C++11. Using alias templates, libc++ could reduce the number of instantiations it produces substantially.
* Decrease Binary Size
Similar to the last point, G++03 forces metaprogramming techniques that emit more debug information [3] [4]. Compared to libstdc++, debug information size increases of +10% are not uncommon.
Reviewers: ldionne, mclow.lists, EricWF
Reviewed By: ldionne, EricWF
Subscribers: zoecarver, aprantl, dexonsmith, arphaman, libcxx-commits, #libc
Differential Revision: https://reviews.llvm.org/D63154
llvm-svn: 363219
When applied to a typedef or alias template, the [[nodebug]] attribute
makes the typedef transparent to the debugger, so instead of seeing
`std::__function::__alloc_func<remove_reference<void(&)()>::type,
allocator<remove_reference<void(&)()>, void()>::_Target` you see
`void(&)()` as the type of the variable in your debugger.
Removing all this SFINAE noise from debug info has huge binary size
wins, in addition to improving the readability.
For now this change is on by default. Users can override it by
specifying -D_LIBCPP_NODEBUG_TYPE=
llvm-svn: 363117
As we gear up to drop support for GCC in C++03, we should make clear
what our C++03 mode is, the C++11 extensions it provides,
and the C++11 extensions it depends on.
The section of this document discussing user-facing extensions has
been left blank while the community discusses new directions. For now
it's just a warning to users.
Additionally, the document contains examples of how these extensions
should be used and why. For example, using alias templates over class
templates.
llvm-svn: 363110
Summary:
This is not mandated by the Standard, but it's nonetheless a nice
property to have, especially since it's so easy to implement. It
also shrinks our bug list!
PR41714
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62618
llvm-svn: 363075
Summary:
Following the discussion on the libcxx-dev mailing list
(http://lists.llvm.org/pipermail/libcxx-dev/2019-May/000358.html),
this implements the new policy for handling experimental features and
their deprecation. We basically add a deprecation warning for
std::experimental::filesystem, and we remove a bunch of <experimental/*>
headers that were now empty.
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, arphaman, libcxx-commits, jfb
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62428
llvm-svn: 363072
std::function uses a standard allocator to manage its memory, however
standard allocators are templates and using them correctly requires
a stupid amount of instantiations. This leads to a substantial increase
in debug info and object sizes.
This patch addresses the issue by dropping the allocator when possible
and using raw new and delete to get memory.
This change decreases the object file size for the test func.wrap.func.con/F.pass.cpp by 33% and the final binary by 29% (when compiled with -g -ggnu-pubnames -gpubnames).
It also roughly halfs the number of entries in the pubnames and pubtype
sections.
llvm-svn: 362865
