Add a test case for the change from SVN r372657, and for the
preexisting ARM identification.
Add a missing ArchDefinitionEntry for PECOFF/arm64, and tweak
the ArmNt case to set the architecture to armv7 (ArmNt never ran
on anything lower than that). (This avoids a case where
ArchSpec::MergeFrom would override the arch from arm to armv7 and
ArchSpec::CoreUpdated would reset the OS to unknown at the same time.)
Differential Revision: https://reviews.llvm.org/D67951
llvm-svn: 372741
These can appear in a different order depending on the relative
layout of the source and build trees.
Differential Revision: https://reviews.llvm.org/D67953
llvm-svn: 372740
In these cases, the register number should be calculated from
fpu_d0, not fpu_s0.
Differential Revision: https://reviews.llvm.org/D67892
llvm-svn: 372738
D67504 removed uses of `assigned` from OutputSection::addSection, which
makes `assigned` purely used in processSectionCommands() and its
callees. By replacing its references with `parent`, we can remove
`assigned`.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D67531
llvm-svn: 372735
Fixes PR38748
mergeSections() calls getOutputSectionName() to get output section
names. Two MergeInputSections may be merged even if they are made
different by SECTIONS commands.
This patch moves mergeSections() after processSectionCommands() and
addOrphanSections() to fix the issue. The new pass is renamed to
OutputSection::finalizeInputSections().
processSectionCommands() and addorphanSections() are changed to add
sections to InputSectionDescription::sectionBases.
finalizeInputSections() merges MergeInputSections and migrates
`sectionBases` to `sections`.
For the -r case, we drop an optimization that tries keeping sh_entsize
non-zero. This is for the simplicity of addOrphanSections(). The
updated merge-entsize2.s reflects the change.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D67504
llvm-svn: 372734
The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us.
llvm-svn: 372733
The static analyzer is warning about a potential null dereference, but we should be able to use cast<CmpInst> directly and if not assert will fire for us.
llvm-svn: 372732
Adding annotation function variants __tsan_write_range_pc and
__tsan_read_range_pc to annotate ranged access to memory while providing a
program counter for the access.
Differential Revision: https://reviews.llvm.org/D66885
llvm-svn: 372730
The static analyzer is warning about a potential null dereference, but we should be able to use cast<LandingPadInst> directly and if not assert will fire for us.
llvm-svn: 372727
The static analyzer is warning about a potential null dereference, but we should be able to use cast<Instruction> directly and if not assert will fire for us.
llvm-svn: 372726
Summary:
- store all macro references in the ParsedAST;
- unify the two variants of CollectMainFileMacros;
Reviewers: ilya-biryukov
Subscribers: MaskRay, jkorous, mgrang, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67496
llvm-svn: 372725
Similar to rL372717, we can force the splitting of extends of vector loads in
MVE, in order to use the better widening loads as opposed to going through
expensive extends. This adds a combine to early-on detect extends of loads and
split the load in two, from where normal legalisation will kick in and we get a
series of widening loads.
Differential Revision: https://reviews.llvm.org/D67909
llvm-svn: 372721
The static analyzer is warning about a potential null dereference, but we should be able to use cast<CallInst> directly and if not assert will fire for us.
llvm-svn: 372720
MVE does not have a simple sign extend instruction that can move elements
across lanes. We currently often end up moving each lane into and out of a GPR,
in order to get elements into the correct places. When we have a store of a
trunc (or a extend of a load), we can instead just split the store/load in two,
using the narrowing/widening load/store instructions from each half of the
vector.
This does that for stores. It happens very early in a store combine, so as to
easily detect the truncates. (It would be possible to do this later, but that
would involve looking through a buildvector of extract elements. Not impossible
but this way seemed simpler).
By enabling store combines we also get a vmovdrr combine for free, helping some
other tests.
Differential Revision: https://reviews.llvm.org/D67828
llvm-svn: 372717
Summary:
At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program
and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to
cause a few problems or inconveniences:
* It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible
for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default
(and we can't just close all the associated bug reports).
* Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux).
* We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS).
This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit.
If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module
configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information
than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the
`Darwin` module are their own external type module with their own files).
The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths
based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some
test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism),
but for now it works and makes the feature usable.
Reviewers: aprantl, shafik, jdoerfert
Reviewed By: aprantl
Subscribers: mgorny, abidh, JDevlieghere, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D67760
llvm-svn: 372716
In r372681 lang_cxx_11 and lang_cxx_14 were added to LanguageIDs
but they were not handled in the switch in VisitLinkageSpecDecl in
Modularize.cpp so at clang 8 complained with
/data/repo/master/clang-tools-extra/modularize/Modularize.cpp:583:13: error: enumeration values 'lang_cxx_11' and 'lang_cxx_14' not handled in switch [-Werror,-Wswitch]
switch (D->getLanguage()) {
^
1 error generated.
With this patch we now treat lang_cxx, lang_cxx_11 and lang_cxx_14 the
same way in the switch in VisitLinkageSpecDecl.
llvm-svn: 372714
Summary:
The functions different in two ways:
- getLLVMRegNum could return both "eh" and "other" dwarf register
numbers, while getLLVMRegNumFromEH only returned the "eh" number.
- getLLVMRegNum asserted if the register was not found, while the second
function returned -1.
The second distinction was pretty important, but it was very hard to
infer that from the function name. Aditionally, for the use case of
dumping dwarf expressions, we needed a function which can work with both
kinds of number, but does not assert.
This patch solves both of these issues by merging the two functions into
one, returning an Optional<unsigned> value. While the same thing could
be achieved by adding an "IsEH" argument to the (renamed)
getLLVMRegNumFromEH function, it seemed better to avoid the confusion of
two functions and put the choice of asserting into the hands of the
caller -- if he checks the Optional value, he can safely process
"untrusted" input, and if he blindly dereferences the Optional, he gets
the assertion.
I've updated all call sites to the new API, choosing between the two
options according to the function they were calling originally, except
that I've updated the usage in DWARFExpression.cpp to use the "safe"
method instead, and added a test case which would have previously
triggered an assertion failure when processing (incorrect?) dwarf
expressions.
Reviewers: dsanders, arsenm, JDevlieghere
Subscribers: wdng, aprantl, javed.absar, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67154
llvm-svn: 372710
Finding infinite loops is well-known to be impossible (halting problem).
However, it is possible to detect some obvious infinite loops, for example,
if the loop condition is not changed. Detecting such loops is beneficial
since the tests will hang on programs containing infinite loops so
testing-time detection may be costly in large systems. Obvious cases are
where the programmer forgets to increment/decrement the counter or
increments/decrements the wrong variable.
Differential Revision: https://reviews.llvm.org/D64736
-------
Broke some buildbots "No SOURCES given to target: obj.clangTidyBugproneModule"
llvm-svn: 372704
The log channels change depending on platform, so listing them breaks on
some platforms. Let's just check that the 'lldb' and 'dwarf' channels are
there which are independent of platform.
llvm-svn: 372701
Since these defines were added in LLVM SVN r189364 in 2013,
mingw-w64 got defines for S_I?GRP, S_IRWXG, S_I?OTH and S_IRWXO
in 2015.
Also change the existing defined(_MSC_VER) into ifndef S_IRUSR, for
consistency.
Differential Revision: https://reviews.llvm.org/D67910
llvm-svn: 372700
While debugging on those architectures might not be supported yet,
the generic code should still be buildable. This file accesses x86
specific fields in the CONTEXT struct.
Differential Revision: https://reviews.llvm.org/D67911
llvm-svn: 372699
When vectorisation is forced with a pragma, we optimise for min size, and we
need to emit runtime memory checks, then allow this code growth and don't run
in an assert like we currently do.
This is the result of D65197 and D66803, and was a use-case not really
considered before. If this now happens, we emit an optimisation remark warning
about the code-size expansion, which can be avoided by not forcing
vectorisation or possibly source-code modifications.
Differential Revision: https://reviews.llvm.org/D67764
llvm-svn: 372694
Finding infinite loops is well-known to be impossible (halting problem).
However, it is possible to detect some obvious infinite loops, for example,
if the loop condition is not changed. Detecting such loops is beneficial
since the tests will hang on programs containing infinite loops so
testing-time detection may be costly in large systems. Obvious cases are
where the programmer forgets to increment/decrement the counter or
increments/decrements the wrong variable.
Differential Revision: https://reviews.llvm.org/D64736
llvm-svn: 372693
We currently have two lists in the CompletionRequest that we
inherited from the old API: The complete list of arguments ignoring
where the user requested completion and the list of arguments that
stops at the cursor. Having two lists of arguments is confusing
and can lead to subtle errors, so let's remove the complete list
until we actually need it.
llvm-svn: 372692
Summary:
The ClangModulesDeclVendor is currently interpreting all injected `@import` statements in our expression
wrapper as modules that the user has explicitly requested to be persistently loaded. As we inject
`@import` statements with our std module prototype, the ClangModulesDeclVendor will start compiling
and loading unrelated C++ modules because it thinks the user has requested that it should load them. As
the ClangModulesDeclVendor is lacking the setup to compile these modules (e.g. it lacks the include paths),
it will then actually just fail to compile them and cause the whole expression evaluation to fail. This causes
these tests to fail on systems that enable the ClangModulesDeclVendor (such as macOS).
This patch fixes this by preventing the ClangModulesDeclVendor from interpreting `@import` statements
in the wrapper source code. This is done by check if the import happens in the fake source file containing
our wrapper code (which implies it was generated by LLDB).
This patch doesn't reenable the tests as there is more work needed to get the tests running on macOS (D67760)
Reviewers: aprantl, shafik, jingham
Subscribers: lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D61565
llvm-svn: 372690
Summary:
It is annoying that the clang-format tests aren't themselves clang-formatted, if you use a format on save option in VS or vim this file gets massively changed then you have to `git difftool` all the other changes back out, which is risky.
I know people don't like mass clang-format changes but sometimes it becomes unmanageable to not. There are no other changes here other than just the reformat.
clang-format tests all pass.
```
[==========] 691 tests from 21 test cases ran. (55990 ms total)
[ PASSED ] 691 tests.
```
Reviewers: klimek, owenpan, timwoj
Reviewed By: owenpan
Subscribers: cfe-commits
Tags: #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D67888
llvm-svn: 372689
Martin Storsjo