In this case, CMake doesn't know about the c++abi target within the
same CMake run.
This reverts this aspect back to how it was before SVN r357811.
Differential Revision: https://reviews.llvm.org/D60448
llvm-svn: 358009
// 0 - (X sdiv C) -> (X sdiv -C) provided the negation doesn't overflow.
This fold has been around for many years and nobody noticed the potential
vector miscompile from overflow until recently...
So it seems unlikely that there's much demand for a vector sdiv optimization
on arbitrary vector constants, so just limit the matching to splat constants
to avoid the possible bug.
Differential Revision: https://reviews.llvm.org/D60426
llvm-svn: 358005
Summary:
The current llvm/clang et al. project can be built with the latest developer toolset (devtoolset-8) on RHEL, which provides GCC 8.2.1.
However, the result compiler will not identify this toolset itself when compiling programs, which is of course not desirable.
After the patch - which simply adds the name of the developer toolset to the existing list - it gets identified and selected, as shown below:
[bamboo@bamboo llvm-project]$ clang -v
clang version 9.0.0 (https://github.com/llvm/llvm-project.gite5ac385fb1)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/bamboo/llvm/bin
Found candidate GCC installation: /opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1
Found candidate GCC installation: /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7
Found candidate GCC installation: /opt/rh/devtoolset-8/root/usr/lib/gcc/x86_64-redhat-linux/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Selected GCC installation: /opt/rh/devtoolset-8/root/usr/lib/gcc/x86_64-redhat-linux/8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
Patch By: Radu-Adrian Popescu
Reviewers: tstellar, fedor.sergeev
Reviewed By: tstellar
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59987
llvm-svn: 358002
This patch factors out mappings of scalar maths functions to their vector
counterparts from TargetLibraryInfo.cpp to a separate VecFuncs.def file. Such
mappings are currently available for Accelerate framework, and SVML library.
This is in support of the follow-up: https://reviews.llvm.org/D59881
Patch by pjeeva01
Differential revision: https://reviews.llvm.org/D60211
llvm-svn: 358001
Summary:
Use optimized hashing while writing time trace by join two hashes to one.
Used for -ftime-trace option.
Reviewers: rnk, takuto.ikuta
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60404
llvm-svn: 357998
Previously the tests in lld for RISC-V were given in yaml format as
LLVM's RISC-V assembler support was incomplete. Now that the
assembler/disassembler has matured we can rewrite all tests to use
LLVM's tools.
Differential Revision: https://reviews.llvm.org/D60415
llvm-svn: 357996
The code previously specified a 32-bit range for R_RISCV_HI20 and
R_RISCV_LO12_[IS], however this is incorrect as the maximum offset on
RV64 that can be formed from the immediate of lui and the displacement
of an I-type or S-type instruction is -0x80000800 to 0x7ffff7ff. There
is also the same issue with a c.lui and LO12 pair, whose actual
addressable range should be -0x20800 to 0x1f7ff.
The tests will be included in the next patch that converts all RISC-V
tests to use llvm-mc instead of yaml2obj, as assembler support has
matured enough to write tests in them.
Differential Revision: https://reviews.llvm.org/D60414
llvm-svn: 357995
Summary:
At Mozilla we are using this tool in order to perform review-time static-analysis, since some patches contain a large number of files we've discovered this issue, where `stderr` gets mixed with `stdout` thus obfuscating our possibility to parse the output.
The patch that we are currently use can be found [here](https://searchfox.org/mozilla-central/source/build/build-clang/clang-tidy-8.patch).
This is just an upstream of the original patch.
Reviewers: JonasToth
Reviewed By: JonasToth
Subscribers: cfe-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D60453
llvm-svn: 357994
When bitcasting from a source op to a larger bitwidth op, split the demanded bits and OR them on top of one another and demand those merged bits in the SimplifyDemandedBits call on the source op.
llvm-svn: 357992
Summary:
With MergeValues() removed, amend DebugLocEntry's constructor so that it
takes multiple values rather than a single, and keep non-fragment values
in OpenRanges, as this allows some cleanup of the code in
buildLocationList().
Reviewers: aprantl, dblaikie, loladiro
Reviewed By: aprantl
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D59303
llvm-svn: 357988
Make sure ASTImporter::Import_New(const Decl *) returns
a Expected<const Decl *> and not Expected<Decl *> to
make the clang/unittests/AST/ASTImporterTest.cpp compile
without the warning
clang/unittests/AST/ASTImporterTest.cpp:117:12: error: no viable conversion from 'Expected<clang::Decl *>' to 'Expected<const clang::Decl *>'
return Imported;
(I got the above when building with clang 3.6).
llvm-svn: 357985
Summary:
Some of these were present in files which should never be read by swig
(and we also had one in the interface file, which is only read by swig).
They are probably leftovers from the time when we were running swig over
lldb headers directly.
While writing this patch, I noticed that some of the #ifdefs were
guarding public functions that were operating on lldb_private data
types. While it wasn't strictly necessary for this patch, I made these
private, as nobody should really be accessing them. This can potentially
break existing code if it happened to use these methods, though it will
only break at build time -- if someone builds against an old header, he
should still be able to link to a new lldb library, since the functions
are still there.
We could keep these public for backward compatbility, but I would argue
that if anyone was actually using these functions for anything, his code
is already broken.
Reviewers: JDevlieghere, clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60400
llvm-svn: 357984
This fixes the following doxygen warning when building the lldb-cpp-doc
target.
This commit fixes:
SBStructuredData.h:94 warning: Found unknown command `\dst'
SBStructuredData.h:97 warning: Found unknown command `\dst'
SBStructuredData.h:98 warning: Found unknown command `\dst'
SBStructuredData.h:100 warning: Found unknown command `\dst'
SBStructuredData.h:104 warning: Found unknown command `\dst'
Patch by: Konrad Kleine
Differential revision: https://reviews.llvm.org/D60443
llvm-svn: 357983
There was a space missing in some the documentation for
lldb::BreakpointsWriteToFile.
This fixes the following doxygen error when building the lldb-cpp-doc
target:
llvm-project/lldb/include/lldb/API/SBTarget.h:775 warning: Found
unknown command `\btrue'
Patch by: Konrad Kleine
Differential revision: https://reviews.llvm.org/D60442
llvm-svn: 357980
Summary:
This will make it easier to expand on the documentation in the future
that avoids cluttering the code.
rdar://problem/49476995
Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka
Subscribers: #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D60398
llvm-svn: 357978
Standalone builds of projects other than llvm itself (lldb, libcxx,
etc) include HandleLLVMOptions but not the top level llvm CMakeLists,
so we need to set this variable here to ensure that it always has a
value.
This should fix the build issues some folks have been seeing.
llvm-svn: 357976
Summary:
This patch adds support for parsing STACK CFI records from breakpad
files. The expressions specifying the values of registers are not
parsed.The idea is that these will be handed off to the postfix
expression -> dwarf compiler, once it is extracted from the internals of
the NativePDB plugin.
Reviewers: clayborg, amccarth, markmentovai
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D60268
llvm-svn: 357975
Summary:
The MergeValues() function would try to merge two entries if they shared
the same beginning label. Having the same beginning label means that the
former entry's range would be empty; however, after D55919 we no longer
create entries for empty ranges, so we can no longer land in a situation
where that check in MergeValues would succeed. Instead, the "merging" is
done by keeping the live values from the preceding empty ranges in
OpenRanges, and adding them to the first non-empty range.
Reviewers: aprantl, dblaikie, loladiro
Reviewed By: aprantl
Subscribers: llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D59301
llvm-svn: 357974
The composite existed to simplify some other tablegen code and not really in an
important way. Remove the combined field and just calculate the vector size
using two ifs.
llvm-svn: 357972
The instruction's document this as W0 for the VEX encoding. But there's a
footnote mentioning that VEX.W is ignored in 64-bit mode. And the main VEX
encoding description says the VEX.W bit is ignored for instructions that are
equivalent to a legacy SSE instruction that uses REX.W to select a GPR which
would apply here.
By making this match EVEX we can remove a special case of allowing EVEX2VEX to
turn an EVEX.WIG instruction into VEX.W0.
llvm-svn: 357971
Switch part of the computeOverflowForSignedAdd() implementation to
use Range.isAllNegative() rather than KnownBits.isNegative() and
similar. They do the same thing, but using the ConstantRange methods
allows dropping the KnownBits variables more easily in D60420.
llvm-svn: 357969
I have occasional crashes coming from SBThread::GetExtendedBacktraceThread. The
symptom is that we got true back from HasThreadScope - so we should have a valid
live thread, but then when we go to use the thread, it is not good anymore and we
crash.
I can't spot any obvious cause for this crash, but in looking for same I noticed
that in the current code we check that the thread is valid, THEN we take the stop
locker. We really should do that in the other order, and ensure that the process
will stay stopped before we check our thread is still good. That's what this patch does.
<rdar://problem/47478205>
llvm-svn: 357963
It's been on in Android for a while without causing problems, so it's time
to make it the default and remove the flag.
Differential Revision: https://reviews.llvm.org/D60355
llvm-svn: 357960
This changes the operand type from v4f32/v2f64 to iPTR which seems more correct. But that doesn't seem to do anything other than change the comments in X86GenDAGISel.inc. Probably because we use a ComplexPattern to do the matching so there's no autogenerated code to change.
llvm-svn: 357959
Martin Storsjo