This patch enable DFSan for AArch64 (39-bit VMA). All tests are passing
but:
* test/dfsan/custom.cc
Due an invalid access in dl_iterate_phdr instrumentation (commenting out
this function make the testcase to pass). The test is XFAIL for aarch64
for now.
llvm-svn: 243688
This uncovered latent bugs previously:
http://reviews.llvm.org/D10403
...but it's time to try again because internal tests aren't finding more.
If time passes and no other bugs are reported, we can remove this cl::opt.
llvm-svn: 243687
Summary:
Using u64 as type for offset changes its value, changing starting address for map in file.
This patch solves Bug 24151, which raises issue while mapping file in mips32.
Patch by Mohit Bhakkad
Reviewers: dsanders, kcc
Subscribers: hans, llvm-commits, samsonov, nitesh.jain, sagar, bhushan, jaydeep
Differential Revision: http://reviews.llvm.org/D11588
llvm-svn: 243686
Summary: Also provide the associated assertion when CodeGen starts.
Reviewers: echristo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11654
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 243682
Previously embedded interpreters were handled as ad-hoc source
files compiled into source/Interpreter. This made it hard to
disable a specific interpreter, or to add support for other
interpreters and allow the developer to choose which interpreter(s)
were enabled for a particular build.
This patch converts script interpreters over to a plugin-based system.
Script interpreters now live in source/Plugins/ScriptInterpreter, and
the canonical LLDB interpreter, ScriptInterpreterPython, is moved there
as well.
Any new code interfacing with the Python C API must live in this location
from here on out. Additionally, generic code should never need to
reference or make assumptions about the presence of a specific interpreter
going forward.
Differential Revision: http://reviews.llvm.org/D11431
Reviewed By: Greg Clayton
llvm-svn: 243681
We want to convince the NT loader not to map these sections into memory.
A good first step is to move them to the end of the executable.
Differential Revision: http://reviews.llvm.org/D11655
llvm-svn: 243680
It is common practice to keep constructors lightweight. The reasons
include:
- The vtable during the constructor's execution is set to the static
type of the object, not to the vtable of the derived class. That is,
method calls behave differently in constructors and ordinary methods.
This way it is possible to call unimplemented methods of abstract
classes, which usually results in a segmentation fault.
- If an exception is thrown in the constructor, the destructor is not
called, potentially leaking memory.
- Code in constructors cannot be called in a regular way, e.g. from
non-constructor methods of derived classes.
- Because it is common practice, people may not expect the constructor
to do more than initializing data and skip them when looking for bugs.
Not all of these are applicable to LLVM (e.g. exceptions are disabled).
This patch refactors out the computational work in the constructors of
Scop and IslAst into regular init functions and introduces static
create-functions as replacement.
Differential revision: http://reviews.llvm.org/D11491
Reviewers: grosser, jdoerfert
llvm-svn: 243677
Summary: Verify that running in optimized mode while checking for use-after-dtor errors, does not generate tail call invocation of destructor. This avoids possible error where stack frame for the destructor is eliminated, making tracking down the errors more difficult.
Reviewers: eugenis, kcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11614
simplified test cases
updated line numbering on test
renamed test
llvm-svn: 243675
Summary:
If we used unnamed pipes instead of named pipes, we can avoid having the
file system littered with debugserver-named-pipes if lldb-server happens to
crash for whatever reason. Also, on some buggy systems, it's possible to be
able to create but not to delete a fifo. Ideally, support for unnamed pipes
should be added to debugserver as well, so we can avoid the `#ifdef` here.
Reviewers: clayborg, vharron, chying
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11609
llvm-svn: 243667
The patch changes the SLPVectorizer::vectorizeStores to choose the immediate
succeeding or preceding candidate for a store instruction when it has multiple
consecutive candidates. In this way it has better chance to find more slp
vectorization opportunities.
Differential Revision: http://reviews.llvm.org/D10445
llvm-svn: 243666
In llvm commit r243581, a reverse range adapter was added which allows
us to change code such as
for (auto I = Fields.rbegin(), E = Fields.rend(); I != E; ++I) {
in to
for (const FieldDecl *I : llvm::reverse(Fields))
This commit changes a few of the places in clang which are eligible to use
this new adapter.
llvm-svn: 243663
I'm not sure what reasons the comment here could have
had for not setting these. Without these set, there is
an assertion hit during DWARF emission.
llvm-svn: 243661
Copy implementation of applyFixup from AArch64 with AArch64 bits
ripped out.
Tests will be included with a later commit. Several other
problems must be fixed before binary debug info emission
will work.
llvm-svn: 243660
These tests were creating a modules.idx file in my clang checkout, not
the build directory or temp.
All the other tests in this directory use -fmodules-cache-path=%t so
updated these to match.
llvm-svn: 243657
Copying the already existing code for x86 to ARM to set the correct CPU
features when using -mcpu=native. We can already detect the CPU name
but we were not setting the correct feature bits.
Moving fpu/hwdiv down to make sure they override whatever we set the
default to be.
No tests because this is native detection, and not all ARM-enabled builds
will hapen at a specific CPU, or even ARM. I have tested locally and it
works as expected.
Fixes PR12794.
llvm-svn: 243656
Summary:
Replace the switch on instruction opcode with a switch on register size.
This way we don't need to update the switch statement when we add new
SMRD variants.
Reviewers: arsenm
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11601
llvm-svn: 243652
Summary:
This function is never called. isReallyTriviallyReMaterializable() is
the function that should be implemented instead.
Reviewers: arsenm
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11620
llvm-svn: 243651
Summary:
Patch by Nitesh Jain and Jaydeep Patil with a small revision to use ABIs rather
than Architecture Revisions (which currently imply particular ABIs).
Fixes test_demangle.pass.cpp (PR24149).
Subscribers: mclow.lists, jaydeep, nitesh.jain, hans, cfe-commits
Differential Revision: http://reviews.llvm.org/D11483
llvm-svn: 243645
The memory-sanitizer build bot reported:
==5574== WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f03089e15f6 in
clang::Parser::TryAltiVecTokenOutOfLine(clang::DeclSpec&,
clang::SourceLocation, char const*&, unsigned int&, bool&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:6290:11
This is because the "Ident_pixel" variable was uninitialized
in the getLangOpts().ZVector case, but we'd still call into
clang::Parser::TryAltiVecTokenOutOfLine, which uses the variable.
The simplest fix for this without sprinkling !getLangOpts().ZVector
checks all over the code seems to be to just initialize the variable
to nullptr; this will then do the right thing on ZVector.
Checked in to unbreak the build bots.
llvm-svn: 243644
This patch adds support for the System Z vector built-in functions.
The API-defined header file has the name vecintrin.h.
The user-level functions are defined in the same style as the clang
version of altivec.h, making heavy use of the __overloadable__ and
__always_inline__ attributes. Where possible the functions expand to
generic operations rather than specific built-in functions, in the hope
that that form can be optimised better.
Where a built-in routine is specified to require an immediate integer
argument, the __enable_if__ attribute is used to verify the argument is
in fact constant and in the appropriate range.
Based on a patch by Richard Sandiford.
llvm-svn: 243643
The z13 vector facility has an associated language extension,
closely modeled on AltiVec/VSX. The main differences are:
- vector long, vector float and vector pixel are not supported
- vector long long and vector double are supported (like VSX)
- comparison operators return a vector rather than a scalar integer
- shift operators behave like the OpenCL shift operators
- vector bool is only supported as argument to certain operators;
some operators allow mixing a bool with a non-bool vector
This patch adds clang support for the extension. It is closely modelled
on the AltiVec support. Similarly to the -faltivec option, there's a
new -fzvector option to enable the extensions (as well as an -mzvector
alias for compatibility with GCC). There's also a separate LangOpt.
The extension as implemented here is intended to be compatible with
the -mzvector extension recently implemented by GCC.
Based on a patch by Richard Sandiford.
Differential Revision: http://reviews.llvm.org/D11001
llvm-svn: 243642
Update the debug info in the check-lines because the change in r243638
introduced a constant initialization before the prologue's end as part
of a register spill.
llvm-svn: 243640
Summary:
This hidden option would disable code generation through FastISel by
default. It was removed from the available options and from the
Fast-ISel tests that required it in order to run the tests.
Reviewers: dsanders
Subscribers: qcolombet, llvm-commits
Differential Revision: http://reviews.llvm.org/D11610
llvm-svn: 243638
Summary:
Previously, we would sign-extend non-boolean negative constants and
zero-extend otherwise. This was problematic for PHI instructions with
negative values that had a type with bitwidth less than that of the
register used for materialization.
More specifically, ComputePHILiveOutRegInfo() assumes the constants
present in a PHI node are zero extended in their container and
afterwards deduces the known bits.
For example, previously we would materialize an i16 -4 with the
following instruction:
addiu $r, $zero, -4
The register would end-up with the 32-bit 2's complement representation
of -4. However, ComputePHILiveOutRegInfo() would generate a constant
with the upper 16-bits set to zero. The SelectionDAG builder would use
that information to generate an AssertZero node that would remove any
subsequent trunc & zero_extend nodes.
In theory, we should modify ComputePHILiveOutRegInfo() to consult
target-specific hooks about the way they prefer to materialize the
given constants. However, git-blame reports that this specific code
has not been touched since 2011 and it seems to be working well for every
target so far.
Reviewers: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11592
llvm-svn: 243636
OpenMP 4.1 introduces optional argument '(n)' for 'ordered' clause, where 'n' is a number of loops that immediately follow the directive.
'n' must be constant positive integer expressions and it must be less or equal than the number of the loops in the resulting loop nest.
Patch adds parsing and semantic analysis for this optional argument.
llvm-svn: 243635
Summary:
Mips doesn't implement unw_getcontext() or libunwind::Registers_*::jumpto() yet
so we must disable libunwind for this release.
Reviewers: hans
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11563
llvm-svn: 243633
Eric Christopher