Unfortunately, the creation of (the default) output file, a.out races with all
the other tests in this directory. When the wrong one is read by macho-dump,
the test fails.
llvm-svn: 212269
With this change all values passed through blacklisted functions
become fully initialized. Previous behavior was to initialize all
loads in blacklisted functions, but apply normal shadow propagation
logic for all other operation.
This makes blacklist applicable in a wider range of situations.
It also makes code for blacklisted functions a lot shorter, which
works as yet another workaround for PR17409.
llvm-svn: 212268
With this change all values passed through blacklisted functions
become fully initialized. Previous behavior was to initialize all
loads in blacklisted functions, but apply normal shadow propagation
logic for all other operation.
This makes blacklist applicable in a wider range of situations.
It also makes code for blacklisted functions a lot shorter, which
works as yet another workaround for PR17409.
llvm-svn: 212265
Summary:
Because a global created by GetOrCreateLLVMGlobal() is not finalised until later viz:
extern char a[];
char f(){ return a[5];}
char a[10];
Change MangledDeclNames to use a MapVector rather than a DenseMap so that the
Metadata is output in order of original declaration, so to make deterministic
and improve human readablity.
Differential Revision: http://reviews.llvm.org/D4176
llvm-svn: 212263
This operation was classified as a binary operation in the widening
logic for some reason (clearly, untested). It is in fact a unary
operation. Add a RUN line to a test to exercise this for x86.
Note that again the vector widening strategy doesn't regress anything
and in one case removes a totally unecessary instruction that we
couldn't avoid when promoting the element type.
llvm-svn: 212257
The Itanium rules are not appropriate for the MS ABI. RTTI data is
_never_ imported and thus is never available_externally. It is either
internal (if the type's linkage is internal) or linkonce_odr.
This also means that classes which inherit from dllimport'd bases force
their translation unit to duplicate the entirety of the RTTI data of
that base.
Interestingly, the complete object locator can never be referenced by
translation units which import the class.
This fixes PR20106.
llvm-svn: 212256
mode.
This also runs the test in that mode which would reproduce the crash.
What I love is that *every single FIXME* in the test is addressed by
switching to widening.
llvm-svn: 212254
This corrects SVN r212196's naming change to use the proper prefix of
`__builtin_arm_` instead of `__builtin_`.
Thanks to Yi Kong for pointing out the incorrect naming!
llvm-svn: 212253
Finkel, Eric Christopher, and a bunch of other people I'm probably
forgetting (sorry), add an option to the x86 backend to widen vectors
during type legalization rather than promote them.
This still would promote vNi1 vectors to get the masks right, but would
widen other vectors. A lot of experiments are piling up right now
showing that widening should probably be the default legalization
strategy outside of vNi1 cases, but it is very hard to test the
rammifications of that and fix bugs in widening-based legalization
without an option that enables it. I'll be checking in tests shortly
that use this option to exercise cases where widening doesn't work well
and hopefully we'll be able to switch fully to this soon.
llvm-svn: 212249
Now that we have a lib/MC/MCAnalysis, the dependency was there just because
of two helper classes. Move the two over to MC.
This will allow IRObjectFile to parse inline assembly.
llvm-svn: 212248
Also, forgot to say in the commit message of r212238: Library authors will
see a warning about this issue if they build with -Wsystem-headers.
llvm-svn: 212243
vector type legalization strategies in a more fine grained manner, and
change the legalization of several v1iN types and v1f32 to be widening
rather than scalarization on AArch64.
This fixes an assertion failure caused by scalarizing nodes like "v1i32
trunc v1i64". As v1i64 is legal it will fail to scalarize v1i32.
This also provides a foundation for other targets to have more granular
control over how vector types are legalized.
Patch by Hao Liu, reviewed by Tim Northover. I'm committing it to allow
some work to start taking place on top of this patch as it adds some
really important hooks to the backend that I'd like to immediately start
using. =]
http://reviews.llvm.org/D4322
llvm-svn: 212242
r210091 made initialization checking more strict in c++11 mode. LWG2193 is
about changing standard libraries to still be valid under these new rules,
but older libstdc++ (e.g. libstdc++4.6 in -D_GLIBCXX_DEBUG=1 mode, or stlport)
do not implement that yet. So fall back to the C++03 semantics for container
classes in system headers below the std namespace.
llvm-svn: 212238
This reverts commit r212205.
Reverting this again, still seeing crashes when building compiler-rt...
Sorry for the continued noise, not sure why I'm failing to reproduce
this locally.
llvm-svn: 212226
See http://reviews.llvm.org/D4366 for details.
Change by Paul Paul Osmialowski
Today this is the only problem that I'm facing trying to cross-compile lldb for AArch64 using Linaro's toolchain.
PTRACE_GETREGS, PTRACE_SETREGS, PTRACE_GETFPREGS, PTRACE_SETFPREGS are not defined for AArch64
These things can be defined different ways for other architectures, e.g. for x86_64 Linux, asm/ptrace-abi.h defines them as preprocessor constants while sys/ptrace.h defines them in enum along with corresponding PT_* preprocessor constants
NativeProcessLinux.cpp includes sys/ptrace.h
To avoid accidental redefinition of enums with preprocessor constants, I'm proposing this patch which first checks for PT_* preprocessor constants then checks for PTRACE_* constants then when it still can not find them, it defines preprocessor constants.
Similar approach was already used for PTRACE_GETREGSET and PTRACE_SETREGSET constants; in this case however it was easier, since enum values in sys/ptrace.h and preprocessor constants shared all exactly the same names (e.g. there's no additional PT_GETREGSET name defined).
llvm-svn: 212225
This new multiclass, avx512_perm_table_3src derives from the current one and
provides the Pat<>. The next patch will add another Pat<> that uses the
writemask.
Note that I dropped the type annotation from the intrinsic call, i.e.: (v16f32
VR512:$src1) -> R512:$src1. I think that this should be fine (at least many
intrinsic calls don't provide them) and it greatly reduces the number of
template arguments.
llvm-svn: 212222
This includes assembler and codegen support (see the new tests in
avx512-encodings.s and avx512-shuffle.ll).
<rdar://problem/17492620>
llvm-svn: 212221
Windows does support pipes, but they do so in a slightly different way. Added a Host layer which abstracts the use of pipes into a new Pipe class that everyone can use.
Windows benefits include:
- Being able to interrupt running processes when IO is directly hooked up
- being able to interrupt long running python scripts
- being able to interrupt anything based on ConnectionFileDescriptor
llvm-svn: 212220
Tim Northover