Clang r219557 introduces libcalls to complex multiply/divide functions.
Since these functions are not available in iOS for arm64 devices, add them to
the static libraries.
llvm-svn: 219715
We should check whether the compiler & linker support ARM64 before attempting
to build a version of compiler-rt for it. Otherwise things will go badly.
rdar://problem/18575597
llvm-svn: 219332
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
asan_cxx containts replacements for new/delete operators, and should
only be linked in C++ mode. We plan to start building this part
with exception support to make new more standard-compliant.
See https://code.google.com/p/address-sanitizer/issues/detail?id=295
for more details.
llvm-svn: 208609
Move functions around to prepare for some other changes.
- Merge InstrProfilingExtras.h with InstrProfiling.h. There's no
benefit to having these split.
- Rename InstrProfilingExtras.c to InstrProfilingFile.c.
- Split actual buffer writing code out of InstrProfiling.c into
InstrProfilingBuffer.c.
- Drive-by corrections of a couple of header comments.
<rdar://problem/15943240>
llvm-svn: 204497
Instead of relying on explicit static initialization from translation
units, create a new file, InstrProfilingRuntime.cc, with an
__llvm_pgo_runtime variable. After this commit (and its pair in clang),
the driver will create a use of this variable. Unless the user defines
their own version, the new object file will get pulled in, including
that C++ static initialization that calls
__llvm_pgo_register_write_atexit.
The result is that, at least on Darwin, static initialization typically
consists of a single function call, which registers a writeout functino
atexit. Furthermore, users can skip even this behaviour by defining
their own __llvm_pgo_runtime.
<rdar://problem/15943240>
llvm-svn: 204380
Currently we register instrumentation data at runtime to determine the
bounds of the sections where the data lives. Soon we'll implement
platform-specific linker magic to determine this at link time.
Move this logic to a separate file, so that our build system can choose
the correct platform-specific code.
No functionality change intended.
<rdar://problem/15943240>
llvm-svn: 204299
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
When actually compiling we use clang for the final .dylib creation stage, so we
should ask it what linker it'll use when detecting support for our
architectures.
llvm-svn: 201845
When the locale of a shell is set other than English locales or the C locale,
The word 'Target' may be translated. Thus, with e.g. ja_JP locale, compiler-rt
couldn't be built properly. Forcing LANG=C fixes the problem.
Patch by Ogino Masanori.
llvm-svn: 201506
Clang now uses the *-apple-macho triples for embedded targets using MachO. The
environment makes less pretences to be running an actual Mach kernel with all
the support that would imply, so a few changes are needed to the build scripts:
+ The Apple way of detecting endianness applies in all cases so drop the
__MACH__ test.
+ A quick rename since "darwin_embedded" no longer makes any sense. If there's
no Mach going on, there's certainly no Darwin.
+ Change how we test for support for a platform. The functions we build don't
need any SDK support (stdio.h, ...) so we don't need to check for it.
llvm-svn: 199731
This is fairly minimal support for instrumentation based PGO. The data
format is inefficient, and the output file name is hardcoded to
pgo-data.
llvm-svn: 198638
We need to filter out architectures that the compiler hasn't been built to
target (most likely the ARM ones) before attemptint to build a version of
libcompiler_rt.
This can result in a completely empty library (e.g. soft-float doesn't have any
x86 variants), in which case we shouldn't even try the build
llvm-svn: 197028
This should build a separate set of embedded runtime libraries, supporting the
option product:
{PIC, static} x { Hard-float, soft-float }
The emphasis is on ARM platforms (Cortex-M4F, Cortex-M3, Cortex-M0) but X86
variants are also built where possible.
rdar://problem/10817205
llvm-svn: 194873
DataFlowSanitizer is a generalised dynamic data flow analysis.
Unlike other Sanitizer tools, this tool is not designed to detect a
specific class of bugs on its own. Instead, it provides a generic
dynamic data flow analysis framework to be used by clients to help
detect application-specific issues within their own code.
Differential Revision: http://llvm-reviews.chandlerc.com/D967
llvm-svn: 187924
restriction from the GCDAProfile.c"
Bill added a much more effective way of coping with the use of errno and
other system interactions for Darwin for now by disabling it on that
platform. Building against the SDK stuff is more fundamental to the
darwin build process.
llvm-svn: 184929
darwin.
After talking with Jim Grosbach pretty extensively, he was OK with me
punting on this to the Apple folks.
We agreed that the correct fix is either to extend the fake SDK headers
in compiler-rt to support the rest of libc needed by GCDAProfiling.c or
to teach the make build to test for the existence of a suitable SDK on
the system prior to building it. Both of these require someone with
access to the SDK which I don't have, and the latter (my preferred
solution) requires understanding the strange compiler-rt make build
system. Punting to Dan Dunbar or one of the others who support this
stuff on ios to write the appropriate fix, and we can let the build bots
proceed in the mean time.
llvm-svn: 184816
Bob Wilson