| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
No functional change.
llvm-svn: 217934
|
| |
|
|
|
|
| |
The wrong value was returned and the unittest did not cover the stub dylib case.
llvm-svn: 217933
|
| |
|
|
| |
llvm-svn: 217932
|
| |
|
|
|
|
| |
CMake builds already do so.
llvm-svn: 217931
|
| |
|
|
|
|
| |
getLibraryShortNameByIndex() error handling.
llvm-svn: 217930
|
| |
|
|
|
|
|
|
|
|
| |
I don't remember that crash on mmap in internal allocator
ever yielded anything useful, only crashes in rare wierd untested situations.
One of the reasons for crash was to catch if tsan starts allocating
clocks using mmap. Tsan does not allocate clocks using internal_alloc anymore.
Solve it once and for all by allowing mmaps.
llvm-svn: 217929
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This required a new hook called hasLoadLinkedStoreConditional to know whether
to expand atomics to LL/SC (ARM, AArch64, in a future patch Power) or to
CmpXchg (X86).
Apart from that, the new code in AtomicExpandPass is mostly moved from
X86AtomicExpandPass. The main result of this patch is to get rid of that
pass, which had lots of code duplicated with AtomicExpandPass.
llvm-svn: 217928
|
| |
|
|
|
|
| |
case is a fairly bullet-proof recipe for disaster. Use the * enabling feature to workaround this. Fixes rdar://18358649
llvm-svn: 217927
|
| |
|
|
|
|
| |
instructions when truncate, sext, or zext were created. Fix that.
llvm-svn: 217926
|
| |
|
|
|
|
| |
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217925
|
| |
|
|
|
|
| |
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217924
|
| |
|
|
|
|
| |
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217923
|
| |
|
|
|
|
| |
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217922
|
| |
|
|
|
|
| |
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217921
|
| |
|
|
|
|
| |
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217920
|
| |
|
|
|
|
| |
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217919
|
| |
|
|
|
|
| |
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217918
|
| |
|
|
|
|
| |
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217917
|
| |
|
|
|
|
| |
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217916
|
| |
|
|
|
|
| |
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217915
|
| |
|
|
|
|
| |
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217914
|
| |
|
|
|
|
|
|
| |
Not used yet.
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217913
|
| |
|
|
|
|
|
|
|
|
| |
Not used yet...
v2: Correct int/uint behavior
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217912
|
| |
|
|
|
|
|
|
| |
We were missing the local versions of the atom_* before
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 217911
|
| |
|
|
|
|
|
|
|
|
|
| |
We would end up marking the vtable of the derived class as used for no
reason. Because the call itself is qualified, it is never virtual, and
the vtable of the derived class isn't helpful. We would end up rejecting
code that MSVC accepts for no benefit.
See http://crbug.com/413478
llvm-svn: 217910
|
| |
|
|
| |
llvm-svn: 217909
|
| |
|
|
|
|
| |
Fixes https://code.google.com/p/thread-sanitizer/issues/detail?id=75
llvm-svn: 217908
|
| |
|
|
| |
llvm-svn: 217907
|
| |
|
|
| |
llvm-svn: 217906
|
| |
|
|
|
|
|
|
|
|
| |
not be read in where N was the number of LC_THREAD load commands.
I now properly increment the ncmds for each LC_THREAD and now core files are saved correctly.
<rdar://problem/18312703>
llvm-svn: 217905
|
| |
|
|
|
|
| |
Antao
llvm-svn: 217904
|
| |
|
|
| |
llvm-svn: 217903
|
| |
|
|
|
|
| |
it's called. Add tests to mismatch to make sure it can't be blindsided by such an evil iterator. More tests for other algorithms forthcoming. Thanks to STL for pointing this out at CppCon and Yakov Galka for opening LWG issue #2133
llvm-svn: 217902
|
| |
|
|
|
|
|
|
|
|
| |
(signed/unsigned)integer to quad-precision conversion.
Submitted by GuanHong Liu.
Differential Revision: http://reviews.llvm.org/D2805
llvm-svn: 217901
|
| |
|
|
| |
llvm-svn: 217900
|
| |
|
|
|
|
| |
getNoopForMachoTarget().
llvm-svn: 217899
|
| |
|
|
|
|
|
|
|
| |
On darwin, the linker tools records which dylib (DSO) each undefined was found
in, and then at runtime, the loader (dyld) only looks in that one specific
dylib for each undefined symbol. Now that llvm-objdump can display that info
I can write test cases.
llvm-svn: 217898
|
| |
|
|
|
|
| |
This should fix the mingw bootstrap.
llvm-svn: 217897
|
| |
|
|
|
|
|
|
|
|
|
| |
Translate -lfoo to -lfoo.lib while making sure that -lfoo.lib stays as
-lfoo.lib. Also, these arguments were being passed twice: once
explicitly via AddAllArgs, and again implicitly as linker inputs. Now
they are passed once.
Fixes PR20868.
llvm-svn: 217895
|
| |
|
|
|
|
| |
Johnathan Wakeley for the bug report
llvm-svn: 217894
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First step done in this commit is to get flush out enough of the
SymbolizerGetOpInfo() routine to symbolic an X86_64 hello world .o and
its loading of the literal string and call to printf. Also the code to
symbolicate the X86_64_RELOC_SUBTRACTOR relocation and a test is also
added to show a slightly more complicated case.
Next will be to flush out enough of SymbolizerSymbolLookUp() to get the
literal string “Hello world” printed as a comment on the instruction that load
the pointer to it.
llvm-svn: 217893
|
| |
|
|
| |
llvm-svn: 217892
|
| |
|
|
|
|
| |
that suppresses all children, that is)
llvm-svn: 217891
|
| |
|
|
|
|
|
|
|
| |
warning.
Before we would emit two warnings if the header guard was wrong and the comment
on a trailing #endif also needed fixing.
llvm-svn: 217890
|
| |
|
|
| |
llvm-svn: 217889
|
| |
|
|
|
|
| |
llvm::DenseMap. This helps avoid a certain class of spins per <rdar://problem/18160764>
llvm-svn: 217888
|
| |
|
|
|
|
|
|
|
| |
MSVC 2012 cannot infer any move special members, but it will call them
if available. MSVC 2013 cannot infer move assignment. Therefore,
explicitly implement the special members for the ExecutionContext class
and its contained types.
llvm-svn: 217887
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By class-instance values I mean 'Class<Arg>' in 'Class<Arg>.Field' or in
'Other<Class<Arg>>' (syntactically s SimpleValue). This is to differentiate
from unnamed/anonymous record definitions (syntactically an ObjectBody) which
are not affected by this change.
Consider the testcase:
class Struct<int i> {
int I = !shl(i, 1);
int J = !shl(I, 1);
}
class Class<Struct s> {
int Class_J = s.J;
}
multiclass MultiClass<int i> {
def Def : Class<Struct<i>>;
}
defm Defm : MultiClass<2>;
Before this fix, DefmDef.Class_J yields !shl(I, 1) instead of 8.
This is the sequence of events. We start with this:
multiclass MultiClass<int i> {
def Def : Class<Struct<i>>;
}
During ParseDef the anonymous object for the class-instance value is created:
multiclass Multiclass<int i> {
def anonymous_0 : Struct<i>;
def Def : Class<NAME#anonymous_0>;
}
Then class Struct<i> is added to anonymous_0. Also Class<NAME#anonymous_0> is
added to Def:
multiclass Multiclass<int i> {
def anonymous_0 {
int I = !shl(i, 1);
int J = !shl(I, 1);
}
def Def {
int Class_J = NAME#anonymous_0.J;
}
}
So far so good but then we move on to instantiating this in the defm
by substituting the template arg 'i'.
This is how the anonymous prototype looks after fully instantiating.
defm Defm = {
def Defmanonymous_0 {
int I = 4;
int J = !shl(I, 1);
}
Note that we only resolved the reference to the template arg. The
non-template-arg reference in 'J' has not been resolved yet.
Then we go on to instantiating the Def prototype:
def DefmDef {
int Class_J = NAME#anonymous_0.J;
}
Which is resolved to Defmanonymous_0.J and then to !shl(I, 1).
When we fully resolve each record in a defm, Defmanonymous_0.J does get set
to 8 but that's too late for its use.
The patch adds a new attribute to the Record class that indicates that this
def is actually a class-instance value that may be *used* by other defs in a
multiclass. (This is unlike regular defs which don't reference each other and
thus can be resolved indepedently.) They are then fully resolved before the
other defs while the multiclass is instantiated.
I added vg_leak to the new test. I am not sure if this is necessary but I
don't think I have a way to test it. I can also check in without the XFAIL
and let the bots test this part.
Also tested that X86.td.expanded and AAarch64.td.expanded were unchange before
and after this change. (This issue triggering this problem is a WIP patch.)
Part of <rdar://problem/17688758>
llvm-svn: 217886
|
| |
|
|
| |
llvm-svn: 217885
|
| |
|
|
|
|
| |
and suggesting a more correct way to write the first
llvm-svn: 217884
|