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
Differential Revision: https://reviews.llvm.org/D67937
M lib/builtins/fp_add_impl.inc
M lib/builtins/fp_lib.h
M lib/builtins/fp_trunc_impl.inc
llvm-svn: 372684
This patch provides support for DW_LANG_C_plus_plus_11,
DW_LANG_C_plus_plus_14 tags in the Clang C++ frontend.
Patch by Sourabh Singh Tomar!
Differential Revision: https://reviews.llvm.org/D67613
Reapplies r372663 after adapting a failing test in the LLDB testsuite.
llvm-svn: 372681
Summary:
Fold
or(ashr(subNSW(Y, X), ScalarSizeInBits(Y)-1), X)
into
X s> Y ? -1 : X
https://rise4fun.com/Alive/d8Ab
clamp255 is a common operator in image processing, can be implemented
in a shifty way "(255 - X) >> 31 | X & 255". Fold shift into select
enables more optimization, e.g., vmin generation for ARM target.
Reviewers: lebedev.ri, efriedma, spatel, kparzysz, bcahoon
Reviewed By: lebedev.ri
Subscribers: kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67800
llvm-svn: 372678
We were miscompiling switch value comparisons with the wrong signedness, which
shows up when we have things like switch case values with i1 types, which end up
being legalized incorrectly.
Fixes PR43383
llvm-svn: 372675
Summary:
MemoryPhis may be needed following a Def insertion inthe IDF of all the
new accesses added (phis + potentially a def). Ensure this also occurs when
only the new MemoryPhis are the defining accesses.
Note: The need for computing IDF here is because of new Phis added with
edges incoming from unreachable code, Phis that had previously been
simplified. The preferred solution is to not reintroduce such Phis.
This patch is the needed fix while working on the preferred solution.
Reviewers: george.burgess.iv
Subscribers: Prazek, sanjoy.google, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67927
llvm-svn: 372673
Summary:
Clamp negative to zero and clamp positive to allOnes are common
operation in image saturation.
Add tests for shifty implementation of clamping, as prepare work for
folding:
and(ashr(subNSW(Y, X), ScalarSizeInBits(Y)-1), X) --> X s> 0 ? X : 0;
or(ashr(subNSW(Y, X), ScalarSizeInBits(Y)-1), X) --> X s> Y ? allOnes : X.
Reviewers: lebedev.ri, efriedma, spatel, kparzysz, bcahoon
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67798
llvm-svn: 372671
This patch extends the Makefile.rules to build NeXT-style frameworks. It
also fixes a bug in the clean logic that would accidentally delete the
.mm source file instead of the .o object file.
Thanks a lot to Adrian who was instrumental is getting this to work!
llvm-svn: 372669
Some compilers have trouble converting unique_ptr<PathSensitiveBugReport> to
unique_ptr<BugReport> causing some functions to fail to compile.
Changing the return type of the functions that fail to compile does not
appear to have any issues.
I ran into this issue building with clang 3.8 on Ubuntu 16.04.
llvm-svn: 372668
When a cold path is outlined, the value tracking in the assumption cache may be
invalidated due to the code motion. We would previously trip an assertion in
subsequent passes (but required the passes to happen in a single run as the
assumption cache is shared across the passes). Invalidating the cache ensures
that we get the correct information when needed with the legacy pass manager as
well.
llvm-svn: 372667
Add support for creating universal binaries which
can contain an archive.
Differential revision: https://reviews.llvm.org/D67758
Test plan: make check-all
llvm-svn: 372666
is available
In rL372232, we treated names showing up in profile as not cold when
profile-sample-accurate is enabled. This caused 70k size regression in
Chrome/Android. The patch put a guard and only enable the change when
profile symbol list is available, i.e., keep the old behavior when profile
symbol list is not available.
Differential Revision: https://reviews.llvm.org/D67931
llvm-svn: 372665
This patch provides support for DW_LANG_C_plus_plus_11,
DW_LANG_C_plus_plus_14 tags in the Clang C++ frontend.
Patch by Sourabh Singh Tomar!
Differential Revision: https://reviews.llvm.org/D67613
llvm-svn: 372663
Raphael Isemann