llvm-svn: 178874

llvm-svn: 178873

[sanitizer] found a bug by code inspection: CHECK(a=b) instead of CHECK(a==b). Was puzzled why lint did not catch it. Turns out this check was disabled for asan source. fix all cases and enable the check

llvm-svn: 178872

Change unittests/ExecutionEngine/Makefile to include Makefile.config before
TARGET_HAS_JIT flag is checked.

Fixes bug: http://llvm.org/bugs/show_bug.cgi?id=15669

llvm-svn: 178871

The prefixes and names used are now identical to 32-bit ARM, which is also
expected to remain unchanged.

If we made this change after a release, we'd probably have to support both
variants for a while, but I think since AArch64 exists only on trunk now, it's
acceptable to simply swap them now.

llvm-svn: 178870

Respect Addend when processing MCJIT relocations to local/global symbols.

When the RuntimeDyldELF::processRelocationRef routine finds the target
symbol of a relocation in the local or global symbol table, it performs
a section-relative relocation:

    Value.SectionID = lsi->second.first;
    Value.Addend = lsi->second.second;

At this point, however, any Addend that might have been specified in
the original relocation record is lost.  This is somewhat difficult to
trigger for relocations within the code section since they usually
do not contain non-zero Addends (when built with the default JIT code
model, in any case).  However, the problem can be reliably triggered
by a relocation within the data section caused by code like:

 int test[2] = { -1, 0 };
 int *p = &test[1];

The initializer of "p" will need a relocation to "test + 4".  On
platforms using RelA relocations this means an Addend of 4 is required.
Current code ignores this addend when processing the relocation,
resulting in incorrect execution.

Fixed by taking the Addend into account when processing relocations
to symbols found in the local or global symbol table.

Tested on x86_64-linux and powerpc64-linux.

llvm-svn: 178869

llvm-svn: 178868

To be used with static libstdc++.

llvm-svn: 178866

llvm-svn: 178865

llvm-svn: 178864

llvm-svn: 178862

llvm-svn: 178861

This fixed llvm.org/PR15670

Before:
aaaaaaaaa a = aaaaaaaaaaaaaaaaaaaa, b = bbbbbbbbbbbbbbbbbbbb,
                                    c = cccccccccccccccccccc,
                                    d = dddddddddddddddddddd;
aaaaaaaaa *a = aaaaaaaaaaaaaaaaaaa, *b = bbbbbbbbbbbbbbbbbbb,
                                     *c = ccccccccccccccccccc,
                                      *d = ddddddddddddddddddd;

After:
aaaaaaaaa a = aaaaaaaaaaaaaaaaaaaa, b = bbbbbbbbbbbbbbbbbbbb,
          c = cccccccccccccccccccc, d = dddddddddddddddddddd;
aaaaaaaaa *a = aaaaaaaaaaaaaaaaaaa, *b = bbbbbbbbbbbbbbbbbbb,
          *c = ccccccccccccccccccc, *d = ddddddddddddddddddd;

llvm-svn: 178860

llvm-svn: 178859

llvm-svn: 178858

[ASan] init-order checker tests: move constexpr test that requires -std=c++11 to a separate test case. Check that structs with no ctor but non-trivial dtor are ignored.

llvm-svn: 178857

Allow EmitConstantInit() to emit constant initializers for objects with trivial constructors and non-trivial destructors. Test that such objects are ignored by init-order checker.

llvm-svn: 178856

llvm-svn: 178855

llvm-svn: 178854

[Sanitizer] Use a common mutex to prevent mixing reports from different sanitizers. This fixes PR15516

llvm-svn: 178853

llvm-svn: 178852

Fix for PR14824: "Optimization arm_ldst_opt inserts newly generated instruction vldmia at incorrect position".
Patch introduces memory operands tracking in ARMLoadStoreOpt::LoadStoreMultipleOpti. For each register it keeps the order of load operations as it was before optimization pass.
It is kind of deep improvement of fix proposed by Hao: http://llvm.org/bugs/show_bug.cgi?id=14824#c4
But it also tracks conflicts between different register classes (e.g. D2 and S5).
For more details see:
Bug description: http://llvm.org/bugs/show_bug.cgi?id=14824
LLVM Commits discussion: 
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130311/167936.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130318/168688.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130325/169376.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130401/170238.html

llvm-svn: 178851

llvm-svn: 178850

llvm-svn: 178849

llvm-svn: 178848

llvm-svn: 178847

Add two initial settings for the PlatformDarwinKernel plugin,

plugin.platform.darwin-kernel.search-locally-for-kexts [true|false]
plugin.platform.darwin-kernel.kext-directories [directory list]

llvm-svn: 178846

This change fixes a bug that I introduced in r178058. After a register is
scavenged using one of the available spills slots the instruction defining the
virtual register needs to be moved to after the spill code. The scavenger has
already processed the defining instruction so that registers killed by that
instruction are available for definition in that same instruction. Unfortunately,
after this, the scavenger needs to iterate through the spill code and then
visit, again, the instruction that defines the now-scavenged register. In order
to avoid confusion, the register scavenger needs the ability to 'back up'
through the spill code so that it can again process the instructions in the
appropriate order. Prior to this fix, once the scavenger reached the
just-moved instruction, it would assert if it killed any registers because,
having already processed the instruction, it believed they were undefined.

Unfortunately, I don't yet have a small test case. Thanks to Pranav Bhandarkar
for diagnosing the problem and testing this fix.

llvm-svn: 178845

descriptions for compares

llvm-svn: 178844

Sorry for so many commits, but llvm is still building on my ppc vm.

llvm-svn: 178843

llvm-svn: 178842

llvm-svn: 178841

llvm-svn: 178840

Looks like there is a big endian/little endian problem here. Loosen the
test to try to get the bots green while llvm builds on a ppc qemu vm.

The failure was in http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/

llvm-svn: 178839

InputFile is being pulled from the Archive library to resolve a symbol. 

The buffer which was being used was already being handed over to the
MemoryBuffer object and was being accessed after the hand over. 

Moving it before the buffer is handed over.

llvm-svn: 178838

llvm-svn: 178837

from the current Target, if there is one, else back off to getting
the currently selected platform from the Debugger (as it ws doing
previously.)

Remove code from DynamicLoaderDarwinKernel that was setting the platform
in both the Target and in the Debugger.

llvm-svn: 178836

llvm-svn: 178835

The statement passed to isTrackedFamily() might be a user defined function calling malloc; in this case we got AF_NONE family for this function.
Now the allocation family is derived from Sym, that holds a family of a real allocator.

This commit is also a movement towards getting rid of tracking memory allocating by unknown means.

llvm-svn: 178834

llvm-svn: 178833