Summary:
A few places in the library seem to behave unexpectedly when the library
is compiled or used with exceptions disabled. For example, not throwing
an exception when a pointer is NULL can lead us to dereference the pointer
later on, which is UB. This patch fixes such occurences.
It's hard to tell whether there are other places where the no-exceptions
mode misbehaves like this, because the replacement for throwing an
exception does not always seem to be abort()ing, but at least this
patch will improve the situation somewhat.
See http://lists.llvm.org/pipermail/libcxx-dev/2019-January/000172.html
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57761
llvm-svn: 353850
Summary:
Some implementations of fenv.h use macros to define the functions they provide. This can cause problems when `std::fegetround()` is spelled in source.
This patch adds a `fenv.h` header to libc++ for the sole purpose of turning those macros into real functions.
Reviewers: rsmith, mclow.lists, ldionne
Reviewed By: rsmith
Subscribers: mgorny, christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57729
llvm-svn: 353767
It turns out that I un-XFAILed too many tests in r353210: some tests
actually fail whether exceptions are enabled or not because they use
types that are marked as unavailable even when exceptions are disabled.
llvm-svn: 353215
Some tests are marked as failing on platforms where the dylib does not
provide the required exception classes. However, when testing with
exceptions disabled, those tests shouldn't be marked as failing.
llvm-svn: 353210
We're building tests with -nostdlib which means that we need to
explicitly include the builtins library. When using libgcc (default)
we can simply include -lgcc_s on the link line, but when using
compiler-rt builtins we need a complete path to the builtins library.
This path is already available in CMake as <PROJECT>_BUILTINS_LIBRARY,
so we just need to pass that path to lit and if config.compiler_rt is
true, link it to the test.
Prior to this patch, running tests when compiler-rt is being used as
the builtins library was broken as all tests would fail to link, but
with this change running tests when compiler-rt bultins library is
being used should be supported.
Differential Revision: https://reviews.llvm.org/D56701
llvm-svn: 353208
When the whole test only works starting at some version of the Standard,
use UNSUPPORTED lit markup instead of #ifdef TEST_STD_VER. This provides
more visibility into the test suite.
Reviewed as https://reviews.llvm.org/D57704.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 353206
This patch removes some vendor-specific availability XFAILs from the
test suite. In the future, when a new feature is introduced in the
dylib, an availability macro should be created and a matching lit
feature should be created. That way, the test suite can XFAIL whenever
the implementation lacks the necessary feature instead of being
cluttered by vendor-specific annotations.
Right now, those vendor-specific annotations are still somewhat cluttering
the test suite by being in `config.py`, but at least they are localized.
In the future, we could design a way to define those less intrusively or
even automatically based on the availability macros that already exist
in <__config>.
llvm-svn: 353201
There are several changes:
- Don't stringify Pythonized bools (that's why we're Pythonizing them)
- Support specifying target and sysroot via CMake variables
- Use consistent spelling for --target, --sysroot, --gcc-toolchain
llvm-svn: 353137
Summary:
Freestanding is *weird*. The standard allows it to differ in a bunch of odd
manners from regular C++, and the committee would like to improve that
situation. I'd like to make libc++ behave better with what freestanding should
be, so that it can be a tool we use in improving the standard. To do that we
need to try stuff out, both with "freestanding the language mode" and
"freestanding the library subset".
Let's start with the super basic: run the libc++ tests in freestanding, using
clang as the compiler, and see what works. The easiest hack to do this:
In utils/libcxx/test/config.py add:
self.cxx.compile_flags += ['-ffreestanding']
Run the tests and they all fail.
Why? Because in freestanding `main` isn't special. This "not special" property
has two effects: main doesn't get mangled, and main isn't allowed to omit its
`return` statement. The first means main gets mangled and the linker can't
create a valid executable for us to test. The second means we spew out warnings
(ew) and the compiler doesn't insert the `return` we omitted, and main just
falls of the end and does whatever undefined behavior (if you're luck, ud2
leading to non-zero return code).
Let's start my work with the basics. This patch changes all libc++ tests to
declare `main` as `int main(int, char**` so it mangles consistently (enabling us
to declare another `extern "C"` main for freestanding which calls the mangled
one), and adds `return 0;` to all places where it was missing. This touches 6124
files, and I apologize.
The former was done with The Magic Of Sed.
The later was done with a (not quite correct but decent) clang tool:
https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed
This works for most tests, though I did have to adjust a few places when e.g.
the test runs with `-x c`, macros are used for main (such as for the filesystem
tests), etc.
Once this is in we can create a freestanding bot which will prevent further
regressions. After that, we can start the real work of supporting C++
freestanding fairly well in libc++.
<rdar://problem/47754795>
Reviewers: ldionne, mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57624
llvm-svn: 353086
CMake has a standard way of setting target triple, sysroot and external
toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and
CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into
corresponding --target=, --sysroot= and --gcc-toolchain= variables add
included appended to CMAKE_<LANG>_FLAGS.
libunwind, libc++abi, libc++ provides their own mechanism through
<PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN
variables. These are also passed to lit via lit.site.cfg, and lit config
uses these to set the corresponding compiler flags when building tessts.
This means that there are two different ways of setting target, sysroot
and toolchain, but only one is properly supported in lit. This change
extends CMake build for libunwind, libc++abi and libc++ to also support
the CMake variables in addition to project specific ones in lit.
Differential Revision: https://reviews.llvm.org/D57670
llvm-svn: 353084
On my Windows system, __allocator is defined to nothing. This change fixes build errors of the below form:
In file included from algorithm:644:
functional(1492,31): error: expected member name or ';' after declaration specifiers
const _Alloc& __allocator() const { return __f_.second(); }
Differential Revision: https://reviews.llvm.org/D57355
llvm-svn: 352561
The meta-programming that attempted to form the invoke call expression
was not in a SFINAE context. This made it a hard error to provide
non-referencable types like 'void' or 'void (...) const'.
This patch fixes the error by checking the validity of the call
expression within a SFINAE context.
llvm-svn: 352522
glibc supports versioning, so it's possible to build against older
version and run against newer version. This is sometimes relied on
in practice, e.g. in Fuchsia build we build against older sysroot
(equivalent to Ubuntu Trusty) to cover the broadest possible range
of host systems, but that doesn't necessarily match the system that
binary is going to run on which may have newer version, in which case
the compile test used in curr_symbol is going to fail. Using runtime
check is more reliable.
Differential Revision: https://reviews.llvm.org/D56702
llvm-svn: 352425
The unordered_set and unordered_multiset iterators are specified in the standard as follows:
using iterator = implementation-defined; // see [container.requirements]
using const_iterator = implementation-defined; // see [container.requirements]
using local_iterator = implementation-defined; // see [container.requirements]
using const_local_iterator = implementation-defined; // see [container.requirements]
The pairs iterator/const_iterator and local_iterator/const_local_iterator
are not required to be the same. The reasonable requirement would be that
iterator can convert to const_iterator and local_iterator can convert to
const_local_iterator. This patch weakens the check and makes the test
more portable.
Reviewed as https://reviews.llvm.org/D56493.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 352083
...so the tests under test/std/utilities/any continue to
compile with MSVC's standard library.
While we're here, let's test >C++17 features when _HAS_CXX20.
llvm-svn: 351991
D56445 bumped the minimum Mac OS X version required for aligned
allocation from 10.13 to 10.14. This caused libc++ tests depending
on the old value to break.
This patch updates the XFAILs for those tests to include 10.13.
llvm-svn: 351670
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
D56445 bumped the minimum Mac OS X version required for aligned
allocation from 10.13 to 10.14. This caused libc++ tests depending
on the old value to break.
This patch updates the XFAILs for those tests to include 10.13.
llvm-svn: 351625
Summary:
FreeBSD ships a very old and deprecated ABI for std::pair where the copy and move constructors are not allowed to be trivial. D25389 change how this was implemented by introducing a non-trivial base class. This patch, introduced in October 2016, introduced an ABI bug that caused nested `std::pair` instantiations to have padding. For example:
```
using PairT = std::pair< std::pair<char, char>, char >;
static_assert(offsetof(PairT, first) == 0, "First member should exist at offset zero"); // Fails on FreeBSD!
```
The bug occurs because the base class for the first element (the nested pair) cannot be put at offset zero because the top-level pair already has the same base class laid out there.
This patch fixes that ABI bug by templating the dummy base class on the same parameters as the pair.
Technically this fix is an ABI break for users who depend on the "broken" ABI introduced in 2016. I'm putting this up for review so that the FreeBSD maintainers can sign off on fixing the ABI by breaking the ABI.
Another option, since we have to "break" the ABI to fix it, would be to move FreeBSD off the deprecated non-trivial pair ABI instead.
Also see:
* https://llvm.org/PR40230
* https://reviews.llvm.org/D21329
Reviewers: rsmith, dim, emaste
Reviewed By: rsmith
Subscribers: mclow.lists, krytarowski, christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D56357
llvm-svn: 351290
Summary:
Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See llvm.org/PR39713
This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used.
This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement.
I think we should commit this change immediately, and decide what we want to do about the ABI afterwards.
Reviewers: ldionne, EricWF
Reviewed By: ldionne, EricWF
Subscribers: jyknight, christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54814
llvm-svn: 351289
Summary:
This patch implements all the feature test macros libc++ currently supports, as specified by the standard or cppreference prior to C++2a.
The tests and `<version>` header are generated using a script. The script contains a table of each feature test macro, the headers it should be accessible from, and its values of each dialect of C++.
When a new feature test macro is added or needed, the table should be updated and the script re-run.
Reviewers: mclow.lists, jfb, serge-sans-paille
Reviewed By: mclow.lists
Subscribers: arphaman, jfb, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D56750
llvm-svn: 351286
Summary:
The tests need to create files larger than 2GB, but size_t is 32-bit
on a 32-bit system. Make use of explicit off64_t APIs so we can still
use a default off_t for the tests while enabling 64-bit file offsets
for create_file.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D56619
llvm-svn: 351225
libc++ allows changing the namespace, don't assume __1 in the test
to avoid the test failure if different namespace is being used.
Differential Revision: https://reviews.llvm.org/D56698
llvm-svn: 351220
Louis Dionne