| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 150449
|
|
|
|
|
|
|
| |
Clang patch (flags) will follow shortly.
The run-time library will also follow, but not immediately.
llvm-svn: 150423
|
|
|
|
|
|
| |
llvm part
llvm-svn: 150102
|
|
|
|
| |
llvm-svn: 149967
|
|
|
|
|
|
|
|
|
| |
but with a critical fix to the SelectionDAG code that optimizes copies
from strings into immediate stores: the previous code was stopping reading
string data at the first nul. Address this by adding a new argument to
llvm::getConstantStringInfo, preserving the behavior before the patch.
llvm-svn: 149800
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test to fail.
These are:
r149348
r149351
r149352
r149354
r149356
r149357
r149361
r149362
r149364
r149365
llvm-svn: 149470
|
|
|
|
|
|
| |
ConstantDataArray::getString instead.
llvm-svn: 149365
|
|
|
|
| |
llvm-svn: 149300
|
|
|
|
|
|
|
|
| |
http://code.google.com/p/address-sanitizer/issues/detail?id=32)
The redzones emitted by AddressSanitizer for CFString instances confuse the linker and are of little use, so we shouldn't add them.
llvm-svn: 149243
|
|
|
|
| |
llvm-svn: 149172
|
|
|
|
| |
llvm-svn: 148846
|
|
|
|
| |
llvm-svn: 148697
|
|
|
|
|
|
| |
don't instrument the function at all on x86_32 if it has a large asm blob
llvm-svn: 147953
|
|
|
|
| |
llvm-svn: 147667
|
|
|
|
|
|
| |
This improves the readability of global-buffer-overflow reports.
llvm-svn: 146698
|
|
|
|
|
|
| |
false positive. compiler part.
llvm-svn: 146688
|
|
|
|
|
|
| |
builds). This should be done in the run-time.
llvm-svn: 146527
|
|
|
|
|
|
| |
asan issue 17
llvm-svn: 146503
|
|
|
|
| |
llvm-svn: 146409
|
|
|
|
| |
llvm-svn: 146379
|
|
|
|
|
|
| |
malloc chicken-and-egg situation on Android and probably on other flavours of Linux. Patch by eugenis@google.com.
llvm-svn: 146284
|
|
|
|
| |
llvm-svn: 145880
|
|
|
|
|
|
| |
call; use report_fatal_error when blacklist file can not be found
llvm-svn: 145611
|
|
|
|
| |
llvm-svn: 145420
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gcc, though I thought it was older (my gcc 4.4 has it as a local patch. Whoops!)
This fixes PR10589.
Also add some debugging statements.
Remove GcnoFiles, the mapping from CompilationUnit to raw_ostream. Now that we
start by iterating over each CU and descending into them, there's no need to
maintain a mapping.
llvm-svn: 145208
|
|
|
|
| |
llvm-svn: 145092
|
|
|
|
|
|
| |
large chunks of inline assembler
llvm-svn: 144962
|
|
|
|
|
|
| |
r144933. For some reason this compiles on linux
llvm-svn: 144936
|
|
|
|
|
|
| |
asan; add a test check that asan does not touch linkonce_odr
llvm-svn: 144933
|
|
|
|
| |
llvm-svn: 144758
|
|
|
|
| |
llvm-svn: 144648
|
|
|
|
| |
llvm-svn: 143634
|
|
|
|
| |
llvm-svn: 140169
|
|
|
|
|
|
| |
complete length.
llvm-svn: 140167
|
|
|
|
| |
llvm-svn: 140156
|
|
|
|
| |
llvm-svn: 140154
|
|
|
|
|
|
| |
GCOVLines is always accessed through a StringMap where the key is FileName.
llvm-svn: 140151
|
|
|
|
|
|
| |
the utility routine is already available in DebugInfo.
llvm-svn: 140145
|
|
|
|
|
|
| |
getFirstNonPHI so that it will skip over the landingpad instructions as well.
llvm-svn: 138537
|
|
|
|
|
|
| |
of debug info.
llvm-svn: 137972
|
|
|
|
|
|
| |
named mdnode.
llvm-svn: 137890
|
|
|
|
|
|
| |
check for a LandingPadInst.
llvm-svn: 137745
|
|
|
|
| |
llvm-svn: 137712
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specified in the same file that the library itself is created. This is
more idiomatic for CMake builds, and also allows us to correctly specify
dependencies that are missed due to bugs in the GenLibDeps perl script,
or change from compiler to compiler. On Linux, this returns CMake to
a place where it can relably rebuild several targets of LLVM.
I have tried not to change the dependencies from the ones in the current
auto-generated file. The only places I've really diverged are in places
where I was seeing link failures, and added a dependency. The goal of
this patch is not to start changing the dependencies, merely to move
them into the correct location, and an explicit form that we can control
and change when necessary.
This also removes a serialization point in the build because we don't
have to scan all the libraries before we begin building various tools.
We no longer have a step of the build that regenerates a file inside the
source tree. A few other associated cleanups fall out of this.
This isn't really finished yet though. After talking to dgregor he urged
switching to a single CMake macro to construct libraries with both
sources and dependencies in the arguments. Migrating from the two macros
to that style will be a follow-up patch.
Also, llvm-config is still generated with GenLibDeps.pl, which means it
still has slightly buggy dependencies. The internal CMake
'llvm-config-like' macro uses the correct explicitly specified
dependencies however. A future patch will switch llvm-config generation
(when using CMake) to be based on these deps as well.
This may well break Windows. I'm getting a machine set up now to dig
into any failures there. If anyone can chime in with problems they see
or ideas of how to solve them for Windows, much appreciated.
llvm-svn: 136433
|
|
|
|
|
|
|
| |
obviously big endian. :-)
PR10502
llvm-svn: 136111
|
|
|
|
| |
llvm-svn: 135904
|
|
|
|
|
|
| |
ArrayRef.
llvm-svn: 135761
|
|
|
|
|
|
| |
ConstantExpr::getInBoundsGetElementPtr to use ArrayRef.
llvm-svn: 135673
|
|
|
|
| |
llvm-svn: 135375
|
|
|
|
| |
llvm-svn: 135265
|