The tool reports verbose output for the DWARF debug location coverage.
The llvm-locstats for each variable or formal parameter DIE computes what
percentage from the code section bytes, where it is in scope, it has
location description. The line 0 shows the number (and the percentage) of
DIEs with no location information, but the line 100 shows the number (and
the percentage) of DIEs where there is location information in all code
section bytes (where the variable or parameter is in the scope). The line
50..59 shows the number (and the percentage) of DIEs where the location
information is in between 50 and 59 percentage of its scope covered.
The tool will be very useful for tracking improvements regarding the
"debugging optimized code" support with LLVM ecosystem.
Differential Revision: https://reviews.llvm.org/D66526
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371520 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts r369486 (git commit 8d18384809957cc923752e10a86adab129e3df48)
The opt-viewer tests don't pass after this change, and fixing them isn't
trivial. opt-viewer.py imports optmap, which requires adjusting
pythonpath, which is more work than I'm willing to do to fix forward.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@370095 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Since these files depend on the built python modules, they need to use
the right python binary to run them. So use configure_file
to set the right shebang line.
Patch By: cbiesinger (Christian Biesinger)
Reviewers: chandlerc, beanz, anemet
Reviewed By: anemet
Subscribers: compnerd, JDevlieghere, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65983
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@369486 91177308-0d34-0410-b5e6-96231b3b80d8
It is sometimes useful to have the C++ standard library linked into the
assembly when compiling clang, particularly when distributing a compiler
onto systems that don't have a copy of stdlibc++ or libc++ installed.
This functionality should work with either GCC or Clang as the host
compiler, though statically linking libc++ (as may be required for
licensing purposes) is only possible if the host compiler is Clang with
a copy of libc++ available.
Differential Revision: https://reviews.llvm.org/D65603
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@368907 91177308-0d34-0410-b5e6-96231b3b80d8
lldb recently added a tablegen tool. In order to properly cross compile
lldb standalone there needs to be a mechanism to generate the native
lldb build, analgous to what's done for the NATIVE llvm build. Thus,
we can simply modify this setup to allow for any project to be used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366514 91177308-0d34-0410-b5e6-96231b3b80d8
Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's
Python support to 2.7. Now that both LLVM and LLDB both support Python
3, there's no longer a need to put an arbitrary limit on this.
However, instead of removing the variable, r365692 expanded the list,
which has the (presumably unintentional) side-effect of expression
preference for Python 3.
Instead, as Michal proposed in the original code review, we should just
not set the list at all, and let CMake pick whatever Python interpreter
you have in your path.
This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm,
clang and lld. I've also updated the docs with the default behavior and
how to force a different Python version to be used.
Differential revision: https://reviews.llvm.org/D64894
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366447 91177308-0d34-0410-b5e6-96231b3b80d8
This follows the RFC <http://lists.llvm.org/pipermail/llvm-dev/2019-July/133724.html>.
Follow-on commits will add appropriate release notes changes etc.
Pushing this now and in a minimal form so there is reasonable time before 9.0
branches to resolve any issues arising from e.g. the backend being exposed on
different sanitizer setups.
The current builder for RISC-V is on the staging build-bot
<http://lab.llvm.org:8014/builders/llvm-riscv-linux>, however with the RISCV
backend being built by default it won't provide any real additional coverage.
We will shortly set up a builder that runs the test-suite in qemu-user.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366331 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
CMake+Xcode doesn't seem to handle targets that only have object
sources. This patch works around that limitation by adding a dummy
soruce file to any library target that is generated by llvm_add_library
when object libraries are generated.
Object libraries are generated whenever llvm_add_library is passed more
than one library type, which is now the default case for clang static
libraries (which generate STATIC and OBJECT libraries).
Reviewers: zturner, compnerd, joanlluch
Reviewed By: joanlluch
Subscribers: joanlluch, xbolva00, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64300
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@365365 91177308-0d34-0410-b5e6-96231b3b80d8
This extracts the LLVM distribution target handling into a support module.
Extraction will enable us to restructure the builds to support multiple
distribution configurations (e.g. developer and user) to permit us to build the
development package and the user package at once.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363440 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
It is useful to build with _XOPEN_SOURCE defined on AIX, enabling X/Open
and POSIX compatibility mode, to work around stray macros and other
bugs in the headers provided by the system and build compiler.
This patch adds the config to cmake to build with _XOPEN_SOURCE defined
on AIX with a few exceptions. Google Test internals require access to
platform specific thread info constructs on AIX so in that case we build
with _ALL_SOURCE defined instead. Libclang also uses header which needs
_ALL_SOURCE on AIX so we leave that as is as well.
We also add building on AIX with the large file API and doing CMake
header checks with X/OPEN definitions so the results are consistent with
the environment that will be present in the build.
Reviewers: hubert.reinterpretcast, xingxue, andusy
Reviewed By: hubert.reinterpretcast
Subscribers: mgorny, jsji, cfe-commits, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D62533
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362808 91177308-0d34-0410-b5e6-96231b3b80d8
Recommit of r361790 that was temporarily reverted in r361793 due to bot breakage.
Summary:
The following changes were required to fix these tests:
1) Change LLVM_ENABLE_PLUGINS to an option and move it to
llvm/CMakeLists.txt with an appropriate default -- which matches
the original default behavior.
2) Move the plugins directory from clang/test/Analysis
clang/lib/Analysis. It's not enough to add an exclude to the
lit.local.cfg file because add_lit_testsuites recurses the tree and
automatically adds the appropriate `check-` targets, which don't
make sense for the plugins because they aren't tests and don't
have `RUN` statements.
Here's a list of the `clang-check-anlysis*` targets with this
change:
```
$ ninja -t targets all| sed -n "s/.*\/\(check[^:]*\):.*/\1/p" | sort -u | grep clang-analysis
check-clang-analysis
check-clang-analysis-checkers
check-clang-analysis-copypaste
check-clang-analysis-diagnostics
check-clang-analysis-engine
check-clang-analysis-exploration_order
check-clang-analysis-html_diagnostics
check-clang-analysis-html_diagnostics-relevant_lines
check-clang-analysis-inlining
check-clang-analysis-objc
check-clang-analysis-unified-sources
check-clang-analysis-z3
```
3) Simplify the logic and only include the subdirectories under
clang/lib/Analysis/plugins if LLVM_ENABLE_PLUGINS is set.
Reviewed By: NoQ
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62445
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362328 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM CMake build already uses libtool instead of ar when building
for Apple platform and we should be using the same when building
runtimes. To do so, this change extracts the logic for finding
libtool into a separate file and then uses it from both the LLVM
build as well as the LLVM runtimes build.
Differential Revision: https://reviews.llvm.org/D62769
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362313 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts r361790 (git commit fe5eaab2b5b4523886bd63aebcfea8cfce586fa1)
It's causing buildbot breakage, so reverting while I investigate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361793 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The following changes were required to fix these tests:
1) Change LLVM_ENABLE_PLUGINS to an option and move it to
llvm/CMakeLists.txt with an appropriate default -- which matches
the original default behavior.
2) Move the plugins directory from clang/test/Analysis
clang/lib/Analysis. It's not enough to add an exclude to the
lit.local.cfg file because add_lit_testsuites recurses the tree and
automatically adds the appropriate `check-` targets, which don't
make sense for the plugins because they aren't tests and don't
have `RUN` statements.
Here's a list of the `clang-check-anlysis*` targets with this
change:
```
$ ninja -t targets all| sed -n "s/.*\/\(check[^:]*\):.*/\1/p" | sort -u | grep clang-analysis
check-clang-analysis
check-clang-analysis-checkers
check-clang-analysis-copypaste
check-clang-analysis-diagnostics
check-clang-analysis-engine
check-clang-analysis-exploration_order
check-clang-analysis-html_diagnostics
check-clang-analysis-html_diagnostics-relevant_lines
check-clang-analysis-inlining
check-clang-analysis-objc
check-clang-analysis-unified-sources
check-clang-analysis-z3
```
3) Simplify the logic and only include the subdirectories under
clang/lib/Analysis/plugins if LLVM_ENABLE_PLUGINS is set.
Reviewed By: NoQ
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62445
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361790 91177308-0d34-0410-b5e6-96231b3b80d8
The current code iterates over the combination of LLVM_EXTERNAL_PROJECTS
and LLVM_ENABLE_PROJECTS, but then disables projects that are only in
the former. If a project is in LLVM_EXTERNAL_PROJECTS, it should be
enabled.
See also llvm-commits thread on r354060.
Differential revision: https://reviews.llvm.org/D62289
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361751 91177308-0d34-0410-b5e6-96231b3b80d8
Enable CMake policy 77. This alters the behavior of option. The old behavior
would remove the value of the option from the cache and create a new one. The
new behavior does not create the variable if it is defined already. This ensures
that subsequent reconfigures will behave identically. This seems better than the
setting of OLD - the desire is to ensure that it is set to OLD or NEW.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361307 91177308-0d34-0410-b5e6-96231b3b80d8
The unwind tables (`.eh_frame`, `.arm.extab`) add a significant chunk of data to
the final binaries. These should not be needed normally, particularly when
exceptions are disabled. This enables shrinking `lldb-server` by ~18% (3 MiB)
when built with gold.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@359819 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357976 91177308-0d34-0410-b5e6-96231b3b80d8
Simplify building with particular C++ standards by replacing the
specific "enable standard X" flags with a flag that allows specifying
the standard you want directly.
We preserve compatibility with the existing flags so that anyone with
those flags in existing caches won't break mysteriously.
Differential Revision: https://reviews.llvm.org/D60399
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357899 91177308-0d34-0410-b5e6-96231b3b80d8
As discovered in D56774 the command line gets to long, so use a response file
to give the script the libs. This change has been tested and is confirmed
working for me.
Commited on behalf of Jakob Bornecrantz.
Differential Revision: https://reviews.llvm.org/D56781
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356443 91177308-0d34-0410-b5e6-96231b3b80d8
When LLVM_ENABLE_PROJECTS is set, CMake assumes the project
directories are all side-by-side. This is not always the case and
there's no reason to expect it if LLVM_EXTERNAL_<proj>_SOURCE_DIR is
set. Honor that setting if it exists and allow the build configuration
to continue.
Differential Revision: https://reviews.llvm.org/D49672
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354693 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM r353148, changed the circumstances in which the project source directory variables are created to only create them for LLVM projects. This patch initializes the directory variables for projects specified in `LLVM_EXTERNAL_PROJECTS` as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354060 91177308-0d34-0410-b5e6-96231b3b80d8
If you want to build clang-tools-extra with monorepo, just add it to
LLVM_ENABLE_PROJECTS like with other projects.
See also "Separating clang-tools-extra from clang in LLVM_ENABLE_PROJECTS"
on cfe-dev.
Differential Revision: https://reviews.llvm.org/D58157
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354057 91177308-0d34-0410-b5e6-96231b3b80d8
We iterate over the list and only enable projects from that list that
are present in LLVM_ENABLE_PROJECTS and disable all other projects. Most
users will only specify clang in LLVM_ENABLE_PROJECTS and expect
clang-tools-extra to be implicitly enabled, so remove clang-tools-extra
from LLVM_ALL_PROJECTS so that it doesn't get disabled instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353354 91177308-0d34-0410-b5e6-96231b3b80d8
Make LLVM_ALL_PROJECTS reflect all top-level directories in the monorepo
rather than an arbitrary subset. clang-tools-extra is technically
unnecessary since it gets enabled by clang, but having it there for
consistency shouldn't hurt either.
Differential Revision: https://reviews.llvm.org/D57843
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353346 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang and lldb. They were both similar,
but different. They were both broken in their own ways, for example the
one used by Clang didn't properly handle monorepo resulting in an
incorrect version information reported by Clang.
This change unifies two the scripts by introducing a new script that's
used from both LLVM, Clang and lldb, ensures that the new script
supports both monorepo and standalone SVN and Git setups, and removes
the old scripts.
Differential Revision: https://reviews.llvm.org/D57063
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353268 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM_ENABLED_PROJECT and reconfigured it had no effect on what
projects were actually built. This was very confusing behaviour. The
reason for this is that the value of the `LLVM_TOOL_<PROJECT>_BUILD`
variables are already set.
The problem here is that we have two sources of truth:
* The projects listed in LLVM_ENABLE_PROJECTS.
* The projects enabled/disabled with LLVM_TOOL_<PROJECT>_BUILD.
At configure time we have no real way of knowing which source of truth
the user wants so we apply the following heuristic:
If the user ever sets `LLVM_ENABLE_PROJECTS` in the CMakeCache then that
is used as the single source of truth and we force the
`LLVM_TOOL_<PROJECT>_BUILD` CMake cache variables to have the
appropriate values that match the contents of the
`LLVM_ENABLE_PROJECTS`. If the user never sets `LLVM_ENABLE_PROJECTS`
then they can continue to use and set the `LLVM_TOOL_<PROJECT>_BUILD`
variables as the "source of truth".
The problem with this approach is that if the user ever tries to use
both `LLVM_ENABLE_PROJECTS` and `LLVM_TOOL_<PROJECT>_BUILD` for the same
build directory then any user set value for `LLVM_TOOL_<PROJECT>_BUILD`
variables will get overwriten, likely without the user noticing.
Hopefully the above shouldn't matter in practice because the
LLVM_TOOL_<PROJECT>_BUILD variables are not documented, but
LLVM_ENABLE_PROJECTS is.
We should probably deprecate the `LLVM_TOOL_<PROJECT>_BUILD`
variables at some point by turning them into to regular CMake
variables that don't live in the CMake cache.
Differential Revision: https://reviews.llvm.org/D57535
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353148 91177308-0d34-0410-b5e6-96231b3b80d8
Reverting D57264 again, it looks like we're down to two bots that need fixing:
polly-amd64-linux
polly-arm-linux
They both have old versions of libstdc++ and recent clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@352954 91177308-0d34-0410-b5e6-96231b3b80d8
