Differential Revision: https://reviews.llvm.org/D67937
M lib/builtins/fp_add_impl.inc
M lib/builtins/fp_lib.h
M lib/builtins/fp_trunc_impl.inc
llvm-svn: 372684
This patch enables compiler-rt on SPARC targets. Most of the changes are straightforward:
- Add 32 and 64-bit sparc to compiler-rt
- lib/builtins/fp_lib.h needed to check if the int128_t and uint128_t types exist (which they don't on sparc)
There's one issue of note: many asan tests fail to compile on Solaris/SPARC:
fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported.
Therefore, while asan is still built, both asan and ubsan-with-asan testing is disabled. The
goal is to check if asan keeps compiling on Solaris/SPARC. This serves asan in gcc,
which doesn't have the problem above and works just fine.
With this patch, sparcv9-sun-solaris2.11 test results are pretty good:
Failing Tests (9):
Builtins-sparc-sunos :: divtc3_test.c
Builtins-sparcv9-sunos :: compiler_rt_logbl_test.c
Builtins-sparcv9-sunos :: divtc3_test.c
[...]
UBSan-Standalone-sparc :: TestCases/TypeCheck/misaligned.cpp
UBSan-Standalone-sparcv9 :: TestCases/TypeCheck/misaligned.cpp
The builtin failures are due to Bugs 42493 and 42496. The tree contained a few additonal
patches either currently in review or about to be submitted.
Tested on sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D40943
llvm-svn: 365880
Update formatting to use the LLVM style.
This is part of the cleanup proposed in "[RFC] compiler-rt builtins
cleanup and refactoring".
Differential Revision: https://reviews.llvm.org/D60351
llvm-svn: 359410
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
Summary:
The complex division builtins (div?c3) use logb methods from libm to scale numbers during division and avoid rounding issues. However, these come from libm, meaning anyone that uses --rtlib=compiler-rt also has to include -lm. Implement logb* methods for standard ieee 754 floats so we can avoid -lm on those platforms, falling back to the old behavior (using either logb() or `__builtin_logb()`) when not supported.
These new methods are defined internally as `__compiler_rt_logb` so as not to conflict with the libm definitions in any way.
This fixes just the libm methods mentioned in PR32279 and PR28652. libc is still required, although that seems to not be an issue.
Note: this is proposed as an alternative to just adding -lm: D49330.
Reviewers: efriedma, compnerd, scanon, echristo
Reviewed By: echristo
Subscribers: jsji, echristo, nemanjai, dberris, mgorny, kbarton, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49514
llvm-svn: 342917
__inline is a vendor specific spelling for inline. clang and gcc treat it the
same as inline, and is available in MSVC 2013 which does not implement C99
(VS2015 supports the inline keyword though). This will allow us to build the
builtins using MSVC.
llvm-svn: 249953
