For Java, don't do any of the deviations from Google Style that Chromium style
does for C++.
Chromium's Java follows Android Java style [1], which is roughly Google Java
style with an indent of 4 and a continuation indent of 8.
1: https://source.android.com/source/code-style.html
llvm-svn: 222839
summary of changes:
Cleanup: Use "line_number" API instead of hardcoded source lines
Combine child.sendline with previous child.send command.
test_lldbmi_tokens: Add test for MI tokens.
test_lldbmi_badpathexe: Remove check for prompt so test for bad path can be enabled.
Patch from dawn@burble.org.
llvm-svn: 222838
They don't test what they claim to because LD_PRELOAD applies to "not" instead
of the actual test binary. And all Android tests run with LD_PRELOAD anyway.
llvm-svn: 222835
OpenCL v2.0 s6.5.5 restricts conversion of pointers to different address spaces:
- the named address spaces (__global, __local, and __private) => __generic - implicitly converted;
- __generic => named - with an explicit cast;
- named <=> named - disallowed;
- __constant <=> any other - disallowed.
llvm-svn: 222834
To support it in the frontend, the following has been added:
- generic address space type attribute;
- documentation for the OpenCL address space attributes;
- parsing of __generic(generic) keyword;
- test code for the parser and diagnostics.
llvm-svn: 222831
This mostly entails adding relocations, however there are a couple of
changes to existing relocations:
1. R_AARCH64_NONE is defined to be zero rather than 256
R_AARCH64_NONE has been defined to be zero for a long time elsewhere
e.g. binutils and glibc since the submission of the AArch64 port in
2012 so this is required for compatibility.
2. R_AARCH64_TLSDESC_ADR_PAGE renamed to R_AARCH64_TLSDESC_ADR_PAGE21
I don't think there is any way for relocation names to leak out of LLVM
so this should not break anything.
Tested with check-all with no regressions.
llvm-svn: 222821
including SAE mode and memory operand.
Added AVX512_maskable_scalar template, that should cover all scalar instructions in the future.
The main difference between AVX512_maskable_scalar<> and AVX512_maskable<> is using X86select instead of vselect.
I need it, because I can't create vselect node for MVT::i1 mask for scalar instruction.
http://reviews.llvm.org/D6378
llvm-svn: 222820
In the initialization list of IOHandlerConfirm, *this is basically casting
IOHandlerConfirm to its base IOHandlerDelegate and passing it to constructor of
IOHandlerEditline which uses it and crashes as constructor of IOHandlerDelegate
is still not called. Re-ordering the base classes makes sure that constructor of
IOHandlerDelegate runs first.
It would be good to have a test case for this case too.
llvm-svn: 222816
that we actually have an object to register first.
For MachO objects, RuntimeDyld::LoadedObjectInfo::getObjectForDebug returns an
empty OwningBinary<ObjectFile> which was causing crashes in the GDB registration
code.
llvm-svn: 222812
The RuntimeDyld cleanup patch r222810 turned on GDB registration for MachO
objects. I expected this to be harmless, but it seems to have broken on
MacsOS. Temporarily disabling debugger registration while I dig in to what's
gone wrong.
llvm-svn: 222811
Previously, when loading an object file, RuntimeDyld (1) took ownership of the
ObjectFile instance (and associated MemoryBuffer), (2) potentially modified the
object in-place, and (3) returned an ObjectImage that managed ownership of the
now-modified object and provided some convenience methods. This scheme accreted
over several years as features were tacked on to RuntimeDyld, and was both
unintuitive and unsafe (See e.g. http://llvm.org/PR20722).
This patch fixes the issue by removing all ownership and in-place modification
of object files from RuntimeDyld. Existing behavior, including debugger
registration, is preserved.
Noteworthy changes include:
(1) ObjectFile instances are now passed to RuntimeDyld by const-ref.
(2) The ObjectImage and ObjectBuffer classes have been removed entirely, they
existed to model ownership within RuntimeDyld, and so are no longer needed.
(3) RuntimeDyld::loadObject now returns an instance of a new class,
RuntimeDyld::LoadedObjectInfo, which can be used to construct a modified
object suitable for registration with the debugger, following the existing
debugger registration scheme.
(4) The JITRegistrar class has been removed, and the GDBRegistrar class has been
re-written as a JITEventListener.
This should fix http://llvm.org/PR20722 .
llvm-svn: 222810
We don't yet support pointer-to-member template arguments that have undergone
pointer-to-member conversions, mostly because we don't have a mangling for them yet.
llvm-svn: 222807
Opening a file using openFileForWrite and closing it using close
was asymmetric. It also had a subtle portability problem (details are
described in the commit message for r219189).
llvm-svn: 222802
This was basically benign resource leak on Unix, but on Windows
it could cause builds to fail because opened file descriptor
prevents other processes from moving or removing the file.
llvm-svn: 222799
Since (v)pslldq / (v)psrldq instructions resolve to a single input argument it is useful to match it much earlier than we currently do - this prevents more complicated shuffles (notably insertion into a zero vector) matching before it.
Differential Revision: http://reviews.llvm.org/D6409
llvm-svn: 222796
Expose llvm::DIBuilder::insertDbgValueIntrinsic as
DIBuilder.InsertValueAtEnd in the Go bindings, to support attaching
debug metadata to register values.
Patch by Andrew Wilkins!
Differential Revision: http://reviews.llvm.org/D6374
llvm-svn: 222790
Lang Hames