Commit Graph

38 Commits

Author SHA1 Message Date
dim
c8b9e1b4f1 Pull in r242623 from upstream libc++ trunk (by Eric Fiselier):
Enable and fix warnings during the build.

  Although CMake adds warning flags, they are ignored in the libc++ headers
  because the headers '#pragma system header' themselves.

  This patch disables the system header pragma when building libc++ and fixes
  the warnings that arose.

  The warnings fixed were:
  1. <memory> - anonymous structs are a GNU extension
  2. <functional> - anonymous structs are a GNU extension.
  3. <__hash_table> - Embedded preprocessor directives have undefined behavior.
  4. <string> - Definition is missing noexcept from declaration.
  5. <__std_stream> - Unused variable.

This should fix building world (in particular libatf-c++) with -std=c++11.

Reported by:	Oliver Hartmann <ohartman@zedat.fu-berlin.de>
2015-10-09 21:04:28 +00:00
dim
95fe0d0f46 Remove empty line again from libc++'s iostream.cpp. This was used to
force updates to this file, so it will be rebuilt by the fixed clang
from r289072.
2015-10-09 18:23:10 +00:00
dim
7f7d0087c0 Temporarily revert upstream llvm trunk r240144 (by Michael Zolotukhin):
[SLP] Vectorize for all-constant entries.

This should fix libc++'s iostream initialization SIGBUSing on amd64,
whenever the global cout symbol is not aligned to 16 bytes.

Some further explanation: libc++'s iostream.cpp contains the definitions
of std::cout, std::cerr and so on.  These global objects are effectively
declared with an alignment of 8 bytes.  When an executable is linked
against libc++.so, it can sometimes get a copy of the global object,
which is then at the same alignment.

However, with clang 3.7.0, the initialization of these global objects
will incorrectly use SSE instructions (e.g. movdqa), whenever the
optimization level is high enough, and SSE is enabled, such as on amd64.
When any of these objects is not aligned to 16 bytes, this will result
in a SIGBUS during iostream initialization.  In contrast, clang 3.6.x
and earlier took the 8 byte alignment into consideration, and avoided
SSE for those particular operations.

After bisecting of upstream changes, I found that the above revision
caused the change of this behavior, so I am reverting it now as a
workaround, while a discussion and test case is being prepared for
upstream.
2015-10-09 18:21:45 +00:00
dim
eebb6d6061 Partially revert r288121, removing the workaround for arm < v6. Since
r288125, the required atomic library calls are available in compiler-rt.

The added stub for __libcpp_relaxed_store() can stay as a fallback; I
have also committed it upstream.
2015-09-22 20:48:12 +00:00
dim
4ddf2ffb86 Work around clang emitting libcalls to __atomic_add_fetch() and friends
in libc++, on __ARM_ARCH < 6.  Additionally, supply the missing stub
__libcpp_relaxed_store(), as proposed in http://reviews.llvm.org/D13051

NOTE: this needs to be fixed properly later on, by supplying library
functions implementing atomic operations for arm < v6.  We should
probably take those from sys/arm/arm/stdatomic.c, and stuff them into
either libgcc or compiler-rt.
2015-09-22 17:34:51 +00:00
dim
ea5248cdc1 Update libc++ to 3.7.0 release. 2015-09-16 22:26:52 +00:00
dim
16bd101dd1 Pull in r233552 from upstream libc++ trunk (by Eric Fiselier):
[libcxx] Fix PR22771 - Support access control SFINAE in the library
  version of is_convertible.

  Summary:
  Currently the conversion check does not take place in a context where
  access control SFINAE is applied. This patch changes the context of
  the test expression so that SFINAE occurs if access control does not
  permit the conversion.

  Related bug: https://llvm.org/bugs/show_bug.cgi?id=22771

  Reviewers: mclow.lists, rsmith, dim

  Reviewed By: dim

  Subscribers: dim, rodrigc, emaste, cfe-commits

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

This fixes building clang, and other programs using libc++, with newer
versions of gcc (specifically, gcc 4.8 and higher).

Reported by:	rodrigc
MFC after:	1 week
2015-03-30 19:36:33 +00:00
dim
0796c9ad8a Fix another -Wunused-local-typedef warning in libc++, in include/__tree.
MFC after:	3 days
2015-03-07 22:55:31 +00:00
dim
4ea94bd2cb Pull in r228344 from upstream libc++ trunk (by Eric Fiselier):
Get tests running with warnings. Fix warnings in headers and tests

This fixes a number of -Wunused-local-typedef warnings in libc++ headers.

MFC after:	3 days
2015-03-07 22:53:15 +00:00
dim
80c1930a95 Import libc++ trunk r224926. This fixes a number of bugs, completes
C++14 support[1], adds more C++1z features[2], and fixes the following
LWG issues[3]:

1450: Contradiction in regex_constants
2003: String exception inconsistency in erase.
2075: Progress guarantees, lock-free property, and scheduling
      assumptions
2104: unique_lock move-assignment should not be noexcept
2112: User-defined classes that cannot be derived from
2132: std::function ambiguity
2135: Unclear requirement for exceptions thrown in
      condition_variable::wait()
2142: packaged_task::operator() synchronization too broad?
2182: Container::[const_]reference types are misleadingly specified
2186: Incomplete action on async/launch::deferred
2188: Reverse iterator does not fully support targets that overload
      operator&
2193: Default constructors for standard library containers are explicit
2205: Problematic postconditions of regex_match and regex_search
2213: Return value of std::regex_replace
2240: Probable misuse of term "function scope" in [thread.condition]
2252: Strong guarantee on vector::push_back() still broken with C++11?
2257: Simplify container requirements with the new algorithms
2258: a.erase(q1, q2) unable to directly return q2
2263: Comparing iterators and allocator pointers with different
      const-character
2268: Setting a default argument in the declaration of a member
      function assign of std::basic_string
2271: regex_traits::lookup_classname specification unclear
2272: quoted should use char_traits::eq for character comparison
2278: User-defined literals for Standard Library types
2280: begin / end for arrays should be constexpr and noexcept
2285: make_reverse_iterator
2288: Inconsistent requirements for shared mutexes
2291: std::hash is vulnerable to collision DoS attack
2293: Wrong facet used by num_put::do_put
2299: Effects of inaccessible key_compare::is_transparent type are not
      clear
2301: Why is std::tie not constexpr?
2304: Complexity of count in unordered associative containers
2306: match_results::reference should be value_type&, not const
      value_type&
2308: Clarify container destructor requirements w.r.t. std::array
2313: tuple_size should always derive from integral_constant<size_t, N>
2314: apply() should return decltype(auto) and use decay_t before
      tuple_size
2315: weak_ptr should be movable
2316: weak_ptr::lock() should be atomic
2317: The type property queries should be UnaryTypeTraits returning
      size_t
2320: select_on_container_copy_construction() takes allocators, not
      containers
2322: Associative(initializer_list, stuff) constructors are
      underspecified
2323: vector::resize(n, t)'s specification should be simplified
2324: Insert iterator constructors should use addressof()
2329: regex_match()/regex_search() with match_results should forbid
      temporary strings
2330: regex("meow", regex::icase) is technically forbidden but should
      be permitted
2332: regex_iterator/regex_token_iterator should forbid temporary
      regexes
2339: Wording issue in nth_element
2341: Inconsistency between basic_ostream::seekp(pos) and
      basic_ostream::seekp(off, dir)
2344: quoted()'s interaction with padding is unclear
2346: integral_constant's member functions should be marked noexcept
2350: min, max, and minmax should be constexpr
2356: Stability of erasure in unordered associative containers
2357: Remaining "Assignable" requirement
2359: How does regex_constants::nosubs affect basic_regex::mark_count()?
2360: reverse_iterator::operator*() is unimplementable

[1] http://libcxx.llvm.org/cxx1y_status.html
[2] http://libcxx.llvm.org/cxx1z_status.html
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html

Exp-run:	antoine
MFC after:	1 month
2015-01-15 21:17:36 +00:00
dim
4eb40d1e51 Pull in r200010 from upstream libc++ trunk (by Marshall Clow):
Rename some internal templates to avoid conflict with complier
  intrinsics. __is_constructible --> __libcpp_is_constructible,
  __is_nothrow_constructible --> __libcpp_is_nothrow_constructible, and
  __is_nothrow_assignable --> __libcpp_is_nothrow_assignable. No
  functionality change.

Pull in r206805 from upstream libc++ trunk (by Marshall Clow):

  Use compiler intrinsic __is_constructible if available

This should fix building parts of world with -std=c++11 enabled.

Reported by:	Oliver Hartmann <ohartman@zedat.fu-berlin.de>
MFC after:	1 week
2015-01-01 22:49:17 +00:00
dim
e07a0f7cd7 Pull in r209785 from upstream libc++ trunk (by Marshall Clow):
Fix a problem exposed by r208825, which caused bind (and other bits of
  libc++) to stop working. And tests

This fix is needed to support clang 3.5.0 and higher, which are more
strict about forming pointer-to-function types with cv-qualifiers or
ref-qualifiers.  See also the upstream PR <http://llvm.org/PR19742> and
<http://llvm.org/viewvc/llvm-project?rev=208825&view=rev>

Reported by:	amdmi3
MFC after:	3 days
2014-12-01 15:02:49 +00:00
bapt
af449b2b72 Do not define bad_array_new_length::bad_array_new_length in libc++ anymore
when used in combinaison with libcxxrt since it is now defined there already.
This fixes building world
2014-10-21 21:49:06 +00:00
bapt
c075956fba Import patch from libc++ r197313 which allows using libc++ headers with gcc
Differential Revision:	https://reviews.freebsd.org/D942
Reviewed by:	imp
2014-10-13 22:30:08 +00:00
dim
5936c1d76a In r260015, I renamed several identifiers to avoid -Wsystem-header
warnings.  In r261283, I imported libc++ 3.4 release, but this contained
one identifier that had not been renamed yet, leading to a compilation
error when using -std=c++1y.  Fix the compilation error by correctly
renaming the identifier.

Reported by:	rcarter@pinyon.org
PR:		base/192139
MFC after:	3 days
2014-08-23 15:54:22 +00:00
dim
f594ba5e57 Pull in r214736 from upstream libc++ trunk (by Marshall Clow):
Fix PR#20520 - predicate called too many times in list::remove_if.
  Add tests for list, forward_list, and the std::remove_if algorithm

This fixes an issue where std::list<>::remove_if() and remove() could
erroneously visit elements twice.

Reported by:	Dominic Fandrey <kamikaze@bsdforen.de>
PR:		192303
MFC after:	3 days
2014-08-08 21:27:33 +00:00
dim
93a64e66d4 Pull in r201021 from upstream libc++ trunk:
Fix for PR18735 - self-assignment for map/multimap gives incorrect
  results in C++03

(Please note: that is an LLVM PR identifier, not a FreeBSD one.)

Reported by:	rakuco
MFC after:	3 days
2014-03-13 23:09:48 +00:00
dim
79abbab7d9 Pull in r199848 from upstream libc++ trunk:
Const qualify __mem_fn call operator

  QOI improvement.

  Differential Revision: http://llvm-reviews.chandlerc.com/D2059

This should help with building recent versions of Mesa.  See also:
https://bugs.freedesktop.org/show_bug.cgi?id=75505

Reported by:	dumbbell
MFC after:	3 days
2014-03-05 20:01:04 +00:00
dim
5c48f599e6 An ABI incompatibility crept into the libc++ 3.4 import in r261283. It
was caused by upstream libc++ commit r194536, which aimed to make the
headers more standards-compliant, by making std::pair's copy constructor
trivial.  Unfortunately, this could cause certain C++ applications using
shared libraries built against the previous version of libc++ to crash.

Fix the ABI incompatibility by making std::pair's copy constructor
non-trivial again.

Please note: Any C++ applications or shared libraries built with libc++
between r261283 and this revision should be recompiled.

Reported by:	stefanf
MFC after:	3 weeks
X-MFC-With:	r261283
2014-02-12 18:14:49 +00:00
dim
5830d897a4 Apply a cleaner solution for the sign warnings that can occur when
compiling libc++'s <locale> header with -Wsystem-headers on.

This has also been submitted upstream.

Reported by:	asomers
2014-02-07 21:17:20 +00:00
eadler
5257c486eb HEAD is not buildable for the past day. Commit a 'quick fix' in order to permit
buildworld to complete.

Reviewed by:	theraven
2014-02-07 18:10:34 +00:00
dim
0b319638e3 Import libc++ 3.4 release. This contains a lot of bugfixes, and some
preliminary support for C++1y.

MFC after:	3 weeks
2014-01-30 07:44:22 +00:00
dim
dd147a8455 In libc++'s type_traits header, avoid warnings (activated by our use of
-Wsystem-headers) about potential keyword compatibility problems, by
adding a __libcpp prefix to the applicable identifiers.

Upstream is still debating about this, but we need it now, to be able to
import clang 3.4.

MFC after:	3 days
2013-12-28 20:54:08 +00:00
decke
cd8e388205 ename internal function test() to avoid name clashes with
common macros. This fixes ports like mysql 5.6 which has an
internal macro called test.

Approved by:	re (gjb)
Discussed with:	theraven
2013-10-06 10:12:11 +00:00
theraven
214e4f8fe6 Import new libcxxrt / libc++. This brings some bug fixes, including a potential race condition for static initialisers. 2013-07-10 16:28:24 +00:00
dim
43f25c3919 Fix warnings from newer clang versions about constexpr member functions
not being implicitly const in libc++'s <chrono> header.  The warnings
have been introduced because of new language rules recently adopted by
the C++ WG.  More info:

<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3598.html>

MFC after:	3 days
2013-05-28 20:11:28 +00:00
dim
815a6cc1e3 Merge libc++ trunk r180598. Contains several minor cleanups and bug
fixes, no major changes.

MFC after:	2 weeks
2013-04-27 22:47:52 +00:00
theraven
d19c702291 Import new libc++ to head. Various small fixes and cleanups.
MFC after:	2 weeks
2013-02-07 15:45:28 +00:00
theraven
58e590440b Merge new libc++ into head. 2012-11-29 13:35:44 +00:00
dim
efc7663168 Pull in r168610 from upstream libc++:
When using libc++ headers on FreeBSD, in combination with -std=c++98,
  -ansi or -std=c++03, the long long type is not supported.  So in this
  case, several functions and types, like lldiv_t, strtoll(), are not
  declared.

This should make it possible to use the libc++ headers in c++98 mode.

Note: libc++ is originally designed as a c++0x or higher library, so you
should still take care when using it with c++98 or c++03.

Noted by:	Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>
MFC after:	1 week
2012-11-26 21:32:31 +00:00
theraven
8af97236b4 Import new version of libc++ into base. 2012-11-13 03:27:43 +00:00
dim
a4f9a8cbfb Fix two -Wsystem-header warnings in libc++ that were exposed by the new
ATF import.  These have also been sent upstream.

MFC after:	1 month
2012-10-22 19:06:00 +00:00
dim
708d8e446e Import libc++ trunk r165949. Among other improvements and bug fixes,
this has many visibility problems fixed, which should help with
compiling certain ports that exercise C++11 mode (i.e. Firefox).

Also, belatedly add the LICENSE.TXT and accompanying CREDITS.TXT files,
which are referred to in all the source files.

MFC after:	1 month
2012-10-22 18:25:04 +00:00
dim
1728b56bf3 Fix dangling else in libc++'s __bit_reference header. This has also
been sent upstream.

MFC after:	3 days
2012-06-01 06:55:01 +00:00
theraven
011d8001e2 Import new version of libc++. Among other improvements, this comes with an
<atomic> header that works with clang 3.1 (and, importantly, the pre-3.1
snapshot currently in head)
2012-05-03 17:44:07 +00:00
theraven
eccfeea8a5 Import a slightly newer libc++, with some bugs fixed that were found by running
the test suite on FreeBSD.

Approved by:	dim (mentor)
2012-03-14 14:40:22 +00:00
theraven
7bd22d0949 Import new versions of libcxxrt and libc++.
Please tests any C++ code you care about with -stdlib=libc++!

Approved by:	dim (mentor)
2012-03-14 00:09:36 +00:00
theraven
ad5598305f Import libc++ / libcxxrt into base. Not build by default yet (use
MK_LIBCPLUSPLUS=yes to enable).  This is a work-in-progress.  It works for
me, but is not guaranteed to work for anyone else and may eat your dog.

To build C++ using libc++, add -stdlib=libc++ to your CXX and LD flags.

Bug reports welcome, bug fixes even more welcome...

Approved by:	dim (mentor)
2011-11-25 20:59:04 +00:00