There are a bunch of macros (__need_size_t etc) that request just one piece of
<stddef.h>; if any one of these is defined, we just directly include the
underlying header.
Note that <stddef.h> provides a ::nullptr_t. We don't want that available to
includers of <cstddef>, so instead of following the usual pattern where <cfoo>
includes <foo.h> then pulls things from :: into std:: with using-declarations,
we implement <stddef.h> and <cstddef> separately; both include <__nullptr> for
the definition of std::nullptr_t.
llvm-svn: 249761
The C standard requires that these be provided as functions even if they're
also provided as macros, and a strict reading of the C++ standard library rules
suggests that (for instance) &::isdigit == &::std::isdigit, so these wrappers
are technically non-conforming.
llvm-svn: 249475
Summary:
On OS X libc++ needs to reexport libc++abi's symbols in order for them to be provided. We explicitly list the symbols to reexport it libcxx/lib/libc++abi2.exp. This patch adds the symbols required by std::bad_array_length which have been missing for some time.
However there is a problem. std::bad_array_length was add to libc++abi in September of 2013 by commit r190479, about a year after everything else. Therefore I think older OS X version have libc++abi versions without std::bad_array_length. On those systems
libc++ won't build with this change because we will try and export undefined symbols.
The workaround I would write to support older systems depends on the amount of people who would need it. If only a small number of developers are affected it might be sufficient to provide a CMake switch like `LIBCPP_LIBCPPABI_HAS_BAD_ARRAY_LENGTH` which is
ON by default and can be disabled by those who need it. Otherwise I think we should try to automatically detect if the symbols are present in `/usr/lib/libc++abi.dylib` and configure accordingly. I would prefer the first solution because writing CMake sucks.
Reviewers: mclow.lists, aprantl
Subscribers: aprantl, cfe-commits
Differential Revision: http://reviews.llvm.org/D13445
llvm-svn: 249339
Summary:
Currently the test suite defaults to C++11 mode if no standard version is supplied to LIT using `--param=std=c++XX`. This patch changes that behavior so that the newest possible dialect is selected instead.
I have already patched the C++11 bot to explicitly specify `--param=std=c++11`. I'm just putting this up for review to see if anybody objects to this idea.
Reviewers: mclow.lists, jroelofs, danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13331
llvm-svn: 249226
Summary:
Hi Marshall,
Could you please test this patch and see if you run into the same linker errors we talked about?
I can't reproduce on linux or OS X.
Hopefully you can't find any problems and we can fix the C++03 bot.
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13337
llvm-svn: 249192
Summary:
In rL241532, atomic_support.h was added, which provides handling of
atomic operations for libc++. When atomic builtins are not available,
it emits a warning about being unsupported, but it still provides a
number of stubs for the required functions.
However, it misses a stub for `__libcpp_relaxed_store()`. Add it, by
using the same implementation as for `__libcpp_atomic_store()`.
(Note that I encountered this on arm-freebsd, which still defaults to
armv4, and does not have the runtime libcalls to support atomic
builtins. For now, I have simply disabled using them.)
Reviewers: mclow.lists, EricWF
Subscribers: theraven, cfe-commits, jroelofs, majnemer, aemerson
Differential Revision: http://reviews.llvm.org/D13051
llvm-svn: 248313
Richard Smith