The C++ spec (3.6.1.3) says "The function `main` shall not be used within a program". This implies that it cannot recurse, so add the norecurse attribute to help the midend out a bit.
llvm-svn: 252902
Last time, this caused two Windows buildbots and a single ARM buildbot to fail.
I XFAIL'd the failing test on win32,win64 machines in order to see if the ARM
buildbot complains again.
llvm-svn: 252901
`DlAddrSymbolizer` is used on OS X when we're running inside a sandbox that prevents us from spawning an external symbolizer. This patch adds support for symbolication of globals (implements `SymbolizeData`) for `DlAddrSymbolizer`.
Differential Revision: http://reviews.llvm.org/D14613
llvm-svn: 252899
A very expected layout: source tree is in ~/src/llvm, the build directory is in
~/src/llvm-build, and the install location is in /usr/local/{lib,include}.
The DWARF information in /usr/local/lib/libLLVM.a for ilist.h points to
~/src/llvm-build/include/llvm/ADT/ilist.h. Now, when someone includes
"llvm/ADT/ilist.h" and links against /usr/local/lib/libLLVM.a. Disaster.
The DWARF information in libUser.so for ilist.h points to two locations: the one
in /usr/include, and the one in ~/src/llvm-build/include. LLDB gets confused.
Let's uniquify fully-qualified names and never trip on such a thing.
Differential Revision: http://reviews.llvm.org/D14549
llvm-svn: 252898
The default symbolizer, `llvm-symbolizer` provides sizes for global symbols. On OS X, we want to also allow using `atos` (because it's available everywhere and users don't need to copy/install it) and `dladdr` (it's the only available option when running in a sandbox). However, these symbolizers do not supply the symbol sizes, only names and starting addresses. This patch changes the reporting functions to hide the size of the symbol when this value is unavailable, and modifies tests to make this part of the report "optional".
Differential Revision: http://reviews.llvm.org/D14608
llvm-svn: 252896
I completely misunderstood what ARMISD::CMPZ means. It's not "compare equal to zero", it's "compare, only setting the zero/Z flag". It can either be equal-to-zero or not-equal-to-zero, and we weren't checking what sense it was.
If it's equal-to-zero, we can swap the operands around and pretend like it is not-equal-to-zero, which is both a bug fix and lets us handle more cases.
llvm-svn: 252891
Summary:
Support for R_MIPS_NONE allows us to parse MIPS16's usage of .reloc.
R_MIPS_32 was included to be able to better test the directive.
Targets can add their relocations by overriding MCAsmBackend::getFixupKind().
Subscribers: grosbach, rafael, majnemer, dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D13659
llvm-svn: 252888
Summary:
This patch overrides TargetFrameLowering::getFrameIndexReference() in order to
specify the correct register when the function needs dynamic stack realignment.
The values returned from this function are used in order to create DW_AT_locations
for DWARF info. These locations would use the wrong registers as it's been
reported in PR25028.
Reviewers: dsanders
Subscribers: dean, llvm-commits
Differential Revision: http://reviews.llvm.org/D13511
llvm-svn: 252882
There are plenty more instcombines we could probably do with bitreverse, but this seems like a very obvious and trivial starting point and was brought up by Hal in his review.
llvm-svn: 252879
Several backends have instructions to reverse the order of bits in an integer. Conceptually matching such patterns is similar to @llvm.bswap, and it was mentioned in http://reviews.llvm.org/D14234 that it would be best if these patterns were matched in InstCombine instead of reimplemented in every different target.
This patch introduces an intrinsic @llvm.bitreverse.i* that operates similarly to @llvm.bswap. For plumbing purposes there is also a new ISD node ISD::BITREVERSE, with simple expansion and promotion support.
The intention is that InstCombine's BSWAP detection logic will be extended to support BITREVERSE too, and @llvm.bitreverse intrinsics emitted (if the backend supports lowering it efficiently).
llvm-svn: 252878
This seems to be dead code – `system_malloc_zone` is initialized as null and we never assign to it. This code is apparently currently never executed (in ASan), but is causes trouble for the TSan OS X port. Let's replace the checks with `COMMON_MALLOC_ENTER` (`ENSURE_ASAN_INITED()`).
Differential Revision: http://reviews.llvm.org/D14334
llvm-svn: 252876
The TSan unit test build currently fails if we're also building the iOS parts of compiler-rt, because `TSAN_SUPPORTED_ARCH` contains ARM64. For unit tests, we need to filter this only to host architecture(s).
Differential Revision: http://reviews.llvm.org/D14604
llvm-svn: 252873
The initial buildbot run found a few missing bits in the initial XFAIL list
for the no-exceptions libc++ variant. These discrepancies are as follows:
[1] Following two tests need XFAILs on the no-exceptions library variant.
My local runs had these two disabled for other reasons (unsupported):
- localization/locales/locale/locale.cons/char_pointer.pass.cpp
- numerics/complex.number/complex.ops/complex_divide_complex.pass.cpp
[2] These three does not need XFAILs, they were failing on my local runs for
other reasons:
- depr/depr.c.headers/uchar_h.pass.cpp
- input.output/iostreams.base/ios/basic.ios.members/copyfmt.pass.cpp
- .../category.collate/locale.collate.byname/transform.pass.cpp
(these are failing on my box for the default build as well)
The current patch fixes both the cases above. Additionally, I've run the
following scan to make sure I've covered all the cases:
> grep ' catch \| try \| throw ' -R . | perl -pe 's|(.*?):.*|\1|' | sort | \
uniq > 1.txt
> grep 'libcpp-no-exceptions' -R . | perl -pe 's|(.*?):.*|\1|' | sort | \
uniq > 2.txt
> diff 1.txt 2.txt
This showed up a few extra interesting cases:
[3] These two tests do not use try/catch/throw statements, but they fail at
runtime. Need to be investigated, I've left the XFAILs in.
- std/thread/futures/futures.shared_future/dtor.pass.cpp
- std/thread/futures/futures.unique_future/dtor.pass.cpp
[4] These tests use a macro named TEST_HAS_NO_EXCEPTIONS to conditionally
exclude try/catch/throw statements when running without exceptions. I'm not
entirely sure why this was needed (AFAIK, we didn't have a no-exceptions
library build before). The macro's defintion is quite similar to that of
_LIBCPP_NO_EXCEPTIONS. I will investigate if this can be reused for my test
fixes or if it should be replaced with _LIBCPP_NO_EXCEPTIONS.
- std/experimental/any/*
Change-Id: I9ad1e0edd78f305406eaa0ab148b1ab693f7e26a
llvm-svn: 252870
In `MachOObjectFile::getSymbolType` we currently always return `SymbolRef::ST_Function` for symbols from any section. In order for llvm-symbolizer to correctly symbolize Mach-O globals, symbols from data and BSS sections should return `SymbolRef::ST_Data`.
Differential Revision: http://reviews.llvm.org/D14576
llvm-svn: 252867
Added "macro" option to "-debug-dump" flag, which trigger parsing and dumping of the ".debug_macinfo" section.
Differential Revision: http://reviews.llvm.org/D14294
llvm-svn: 252866
This adds part of the target info code, and adds modifications to
the build scripts so that AVR is recognized a supported, experimental
backend.
It does not include any AVR-specific code, just the bare sources required
for a backend to exist.
From D14039.
llvm-svn: 252865
A function can be marked as norecurse if:
* The SCC to which it belongs has cardinality 1; and either
a) It does not call any non-norecurse function. This includes self-recursion; or
b) It only has one callsite and the function that callsite is within is marked norecurse.
a) is best propagated bottom-up and b) is best propagated top-down.
We build up the norecurse attributes bottom-up using the existing SCC pass, and mark functions with no obvious recursion (but not provably norecurse) to sweep later, top-down.
llvm-svn: 252862
IVs of loops for which the loop header is in the subregion, but not the entire
loop may be incremented outside of the subregion and can consequently not be
kept private to the subregion. Instead, they need to and are modeled as virtual
loops in the iteration domains. As this is the case, generating new subregion
induction variables for such loops is not needed and indeed wrong as they would
hide the virtual induction variables modeled in the scop.
This fixes a miscompile in MultiSource/Benchmarks/Ptrdist/bc and
MultiSource/Benchmarks/nbench/. Thanks Michael and Johannes for their
investiagations and helpful observations regarding this bug.
llvm-svn: 252860
This encompasses several changes which are all interconnected:
- Use the MC framework for printing almost all instructions.
- AsmStrings are now live.
- This introduces an indirection between LLVM vregs and WebAssembly registers,
and a new pass, WebAssemblyRegNumbering, for computing a basic the mapping.
This addresses some basic issues with argument registers and unused registers.
- The way ARGUMENT instructions are handled no longer generates redundant
get_local+set_local for every argument.
This also changes the assembly syntax somewhat; most notably, MC's printing
use sigils on label names, so those are no longer present, and push/pop now
have a sigil to keep them unambiguous.
The usage of set_local/get_local/$push/$pop will continue to evolve
significantly. This patch is just one step of a larger change.
llvm-svn: 252858
The MIPS target requires specific dynamic section entries to be defined.
* DT_MIPS_RLD_VERSION and DT_MIPS_FLAGS store predefined values.
* DT_MIPS_BASE_ADDRESS holds base VA.
* DT_MIPS_LOCAL_GOTNO holds the number of local GOT entries.
* DT_MIPS_SYMTABNO holds the number of .dynsym entries.
* DT_MIPS_GOTSYM holds the index of the .dynsym entry
which corresponds to the first entry of the global part of GOT.
* DT_MIPS_RLD_MAP holds the address of the reserved space in the data segment.
* DT_MIPS_PLTGOT points to the .got.plt section if it exists.
* DT_PLTGOT holds the address of the GOT section.
See "Dynamic Section" in Chapter 5 in the following document for detailed
description: ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
Differential revision: http://reviews.llvm.org/D14450
llvm-svn: 252857
Summary:
The option outputs statistics in CSV format preceded by 1 header line.
This is intended for machine processing of the output.
-verbosity=0 should likely be set.
Differential Revision: http://reviews.llvm.org/D14600
llvm-svn: 252856
The MIPS ABI has requirements to sort the entries in the .dyn.sym section.
Symbols which are not in the GOT have to precede the symbols which are added to
the GOT. The latter must have the same order as the corresponding GOT entries.
Since these sorting requirements contradict those of the GNU hash section,
they cannot be used together.
Differential revision: http://reviews.llvm.org/D14281
llvm-svn: 252854
This function permits the mangling of a C++ 'structor. Depending on the ABI and
the declaration, the declaration may contain more than one associated symbol for
a given declaration. This allows the consumer to retrieve all of the associated
symbols for the declaration the cursor points to.
llvm-svn: 252853
This allows the return of a set of CXStrings from libclang. This is setup work
for an upcoming change to permit returning multiple mangled symbols.
llvm-svn: 252852
If an llvm.assume dominates the SCoP entry block and the assumed condition
can be expressed as an affine inequality we will now add it to the context.
Differential Revision: http://reviews.llvm.org/D14413
llvm-svn: 252851
James Molloy