We need to make sure that if you change the builtin filter lists CMake re-generates its configurations so it includes the right builtins in the generated libraries.
llvm-svn: 248852
Summary: This ports functionality from the clang_macho_embedded.mk platform makefile over to CMake.
Reviewers: bogner, samsonov, bob.wilson
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13226
llvm-svn: 248850
This adds a new name for ARM32 (armhf). We now force that the default build for
ARM32 (arm) to be soft-float ABI. This has a corresponding clang change to look
for these names based on the floating point ABI. The functions are built
identically (the functions are marked as AAPCS, so the calling convention does
not change, as per the RTABI specification), however, the object file contains
attributes indicating the build configuration which the linker will ensure are
not mix and matched. We now built the appropriate named archive so that we can
link properly.
llvm-svn: 248648
There are lingering issues building the atomic builtins with various versions of gcc. To unblock people we can only include them on Apple platforms where they are more tested.
llvm-svn: 248386
Summary:
Building the builtins on Darwin platforms is a bit complicated. This is a first-pass implementation of the functionality from clang_darwin.mk into CMake.
When building the builtins on Darwin we have layers of blacklists that we apply based on platform, architecture, and minimum supported OS version.
Reviewers: bogner, filcab, bob.wilson, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13059
llvm-svn: 248383
Summary:
I broke building the builtins with r245967. This fixes them on Linux and builds them properly for Darwin.
The old code could not be made to work on Darwin as a result of the refactoring of add_compiler_rt_runtime, so I had to rework the way they are built for Darwin. This solution is not ideal and will be fixed in subsequent commits. I just want to get this in so everything is working again.
Reviewers: samsonov, chh, compnerd, bogner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12500
llvm-svn: 246487
Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists.
This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features.
Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov
Subscribers: beanz, rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D12292
llvm-svn: 245970
Summary:
Currently CMake doesn't build builtins for AArch64 and if one does this anyway
it's likely that at least `__multc3`, `__floatditf` and `__floatunditf` will be
missing. There is actually more builtins to add, but these come from
different libc implementations, thus providing them makes compiler-rt for
AArch64 good enough at least for basic usage.
Builtins implementation were originally taken from FreeBSD project:
* [[ https://reviews.freebsd.org/D2173 | __multc3 ]]
* [[ https://reviews.freebsd.org/D2174 | __floatditf and __floatunditf ]]
Until they have been tested to find mistakes in `__float*` functions.
`__floatditf` was based on `__floatsitf`, which had the same mistakes
(fixed it in r243746).
Version of the builtins in this patch are fixed and complemented with basic
tests. Additionally they were tested via GCC's torture (this is what revealed
these issues).
P.S. Ed (author of FreeBSD patches) asked for feedback on the list some time ago (here [[ http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/084064.html | here ]])
and got no response, but it seems to be worth adding these builtins as is and
extracting common part later.
Reviewers: howard.hinnant, t.p.northover, jmolloy, enefaim, rengolin, zatrazz
Subscribers: asl, emaste, samsonov, aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D11679
llvm-svn: 245296
This applies default compiler flags to .S files, in particular removing
the "-pedantic" option, which is desirable because there is nothing to
reasonably warn about; and the only thing that gcc warns about is that
you allegedly can't correctly invoke GLUE2 in lib/builtins/assembly.h
on platforms for which USER_LABEL_PREFIX is the empty string.
In the gcc bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33305 that
added the warning, a commenter notes that giving a macro of zero characters
to another macro is not precisely the same as failing to supply an argument,
and "there is a widespread belief in C++ community that such usage is valid".
Unfortunately the only way to silence the warning is to avoid -pedantic.
Differential Revision: http://reviews.llvm.org/D10713
llvm-svn: 243446
The is so that we can avoid using libgcc and use compiler-rt with
mingw-w64.
Related driver patch
http://reviews.llvm.org/D11077
I have tested this with mingw-w64 and everything seems to be in order.
I also sent this patch to the mingw-w64 mailing list for them to look at.
Patch by Martell Malone.
Differential Revision: http://reviews.llvm.org/D11085
llvm-svn: 242539
Mostly uninteresting, except:
- in __extendXfYf2, when checking if the number is normal, the old
code relied on the unsignedness of src_rep_t, which is a problem
when sizeof(src_rep_t) < sizeof(int): the result gets promoted to
int, the signedness of which breaks the comparison.
I added an explicit cast; it shouldn't affect other types.
- we can't pass __fp16, so src_t and src_rep_t are the same.
- the gnu_*_ieee symbols are simply duplicated definitions, as aliases
are problematic on mach-o (where only weak aliases are supported;
that's not what we want).
Differential Revision: http://reviews.llvm.org/D9693
llvm-svn: 237161
Use unwind.h to get the declarations for unwinding interfaces. This header is
already provided by clang and gcc, so this adds no additional dependencies for
building the builtins library. It avoids the duplication which may drift over
time though.
llvm-svn: 225990
This is needed so we can produce -i686- named libraries for
x86 Android (which is i686-linux-android).
An alternative solution would be keeping the "i386" name internally and
tweaking the OUTPUT_NAME of compiler-rt libraries.
llvm-svn: 218761
Add the missing AEABI functions that are part of the base platform ABI
specification. The provided implementation does the bare minimum to avoid
requiring libc headers. This permits the use of compiler-rt on bare-metal
environments which conform to EABI.
llvm-svn: 217322
The architecture specific implementation of routines would be built and included
along with the generic implementation. This would result in multiple
definitions of those symbols.
The linker is free to select either of the two. Most of the time, this
shouldn't be too terrible as the forward iteration should catch the architecture
version due to the ordering. Rather than relying on the linker and build
infrastructure ordering things in a specific manner, only provide the
architecture version when available.
This reduces the size of compiler-rt, simplifies inspection of the library
implementations, and guarantees that the desired version is selected at a
slightly complex build system.
llvm-svn: 214040
Re-apply SVN r213684 which was reverted in SVN r213724 since it broke the
build bots. Add a tweak to enable inclusion of the assembly sources in
standalone build as well.
Original commit message:
This patch address the PR20360. The CMake assembler build system
ignores the .S assembly files in builtins library build. This patch
fixes the issue.
llvm-svn: 214013
The CMake assembler build system ignores the .S assembly files in builtins
library build. This patch fixes the issue.
Patch by: Sumanth Gundapaneni
llvm-svn: 213684
Call it "libclang_rt.builtins-<arch>.a" to be consistent
with sanitizers/profile libraries naming. Modify Makefile
and CMake build systems and Clang driver accordingly.
Fixes PR19822.
llvm-svn: 209473
Soon there will be an option to build compiler-rt parts as shared libraries
on Linux. Extracted from http://llvm-reviews.chandlerc.com/D3042
by Yuri Gribov.
llvm-svn: 205183
Since these are primarily useful for deeply embedded targets where code size is
very important, they are each in a separate file making use of infrastructure
in sync-ops.h. This allows a linker to include just the functions that are
actually used.
rdar://problem/14736665
llvm-svn: 202812
Chris Bieneman