| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 258600
|
|
|
|
|
|
|
|
|
|
| |
Summary: It looks like this snuck through in r256143/D15383.
Reviewers: ruiu, grimar
Differential Revision: http://reviews.llvm.org/D16500
llvm-svn: 258599
|
|
|
|
| |
llvm-svn: 258598
|
|
|
|
|
|
|
|
|
| |
Previously it failed to add NumArgRegs to the offset and so clobbered an
already-used register. Now just start the numbering after the arg regs
and don't duplicate the add. Test coverage for this coming shortly with
the implementation of byval.
llvm-svn: 258597
|
|
|
|
|
|
|
|
| |
In the Itanium ABI, vtable may be emitted speculatively as an
available_externally global. Such vtable may not be present at the
link time and should not have a corresponding CFI bit set entry.
llvm-svn: 258596
|
|
|
|
|
|
|
|
|
|
|
| |
The html reports are huge -- every issue in a given file results in a separate
copy of the source code, in HTML form, for the file. This gets very large
quickly and it doesn't make sense to check this into a reference repository.
Also remove the log when generating reference results because it can leak
absolute path names. We still keep both the html and the log around when
producing non-reference results.
llvm-svn: 258594
|
|
|
|
| |
llvm-svn: 258593
|
|
|
|
| |
llvm-svn: 258592
|
|
|
|
|
|
| |
Initialize the IdentifierInfo pointer. Hope this fixes the buildbot breakage.
llvm-svn: 258591
|
|
|
|
|
|
| |
and successes
llvm-svn: 258589
|
|
|
|
|
|
|
|
| |
Since Unicode support is different in Py2 and Py3, Py3 was throwing
exceptions about being unable to decode the file with the default
encoding.
llvm-svn: 258588
|
|
|
|
| |
llvm-svn: 258587
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Windows 10 loader spawns threads at startup, so
tests which count threads or assume that a given user
thread will be at a specific index are incorrect in
this case. The fix here is to use the standard mechanisms
for getting the stopped thread (which is all we are
really interested in anyway) and correlating them with
the breakpoints that were set, and doing checks against
those things.
This fixes about 6 tests on Windows 10.
llvm-svn: 258586
|
|
|
|
|
|
|
|
|
|
|
|
| |
The python test run target started failing recently.
I tracked it down to what looks like the passing of
environment variables into the python script.
This locally fixes the vast majority of errors that
were ultimately inferior test build command failures.
Not sure what caused that to start happening.
llvm-svn: 258585
|
|
|
|
|
|
| |
the offset of a field
llvm-svn: 258584
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was an off by one error because the StringRef.substr functions
second argument is a length, not the end index.
Also updated a few ELF files which failed when run on Jenkins with paths
including the @ character. This is often used in Jenkins for shared
workspace plugin.
Reviewed by Rui Ueyama
llvm-svn: 258583
|
|
|
|
|
|
|
|
|
|
|
| |
by stripping the path. Follow-up to r258555.
This is safe because only one PCH per CU is currently supported for
module debugging.
rdar://problem/24301262
llvm-svn: 258582
|
|
|
|
|
|
|
| |
Running mt.exe to make the manifest is really slow. Disabling manifest
generation doesn't seem to break anything.
llvm-svn: 258581
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cleanups in C++ are a little weird. They are only guaranteed to be
reliably executed if, and only if, there is a viable catch handler which
can handle the exception.
This means that reachability of a cleanup is lexically determined by it
being nested with a try-block which unwinds to a catch. It is *cannot*
be reasoned about by examining the control flow edges leaving a cleanup.
Usually this is not a problem. It becomes a problem when there are *no*
edges out of a cleanup because we believed that code post-dominated by
the cleanup is dead. In LLVM's case, this code is what informs the
personality routine about the presence of a suitable catch handler.
However, the lack of edges to that catch handler makes the handler
become unreachable which causes us to remove it. By removing the
handler, the cleanup becomes unreachable.
Instead, inject a catch-all handler with every cleanup that has no
unwind edges. This will allow us to properly unwind the stack.
This fixes PR25997.
llvm-svn: 258580
|
|
|
|
|
|
| |
the AST matcher reference after fixing the issue. Thanks to Richard for noticing the issue and bringing it to my attention!
llvm-svn: 258579
|
|
|
|
|
|
| |
Filed a bug to investigate later: llvm.org/pr26265
llvm-svn: 258578
|
|
|
|
|
|
| |
There's already a pr: https://llvm.org/bugs/show_bug.cgi?id=25819
llvm-svn: 258577
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in MachOObjectFile::getSymbolByIndex() when a Mach-O file has
a symbol table load command but the number of symbols are zero.
The code in MachOObjectFile::symbol_begin_impl() should not be
assuming there is a symbol at index 0, in cases there is no symbol
table load command or the count of symbol is zero. So I also fixed
that. And needed to fix MachOObjectFile::symbol_end_impl() to
also do the same thing for no symbol table or one with zero entries.
The code in MachOObjectFile::getSymbolByIndex() should trigger
the report_fatal_error() for programmatic errors for any index when
there is no symbol table load command and not return the end iterator.
So also fixed that. Note there is no test case as this is a programmatic
error.
The test case using the file macho-invalid-bad-symbol-index has
a symbol table load command with its number of symbols (nsyms)
is zero. Which was incorrectly testing the bad triggering of the
report_fatal_error() in in MachOObjectFile::getSymbolByIndex().
This test case is an invalid Mach-O file but not for that reason.
It appears this Mach-O file use to have an nsyms value of 11,
and what makes this Mach-O file invalid is the counts and
indexes into the symbol table of the dynamic load command
are now invalid because the number of symbol table entries
(nsyms) is now zero. Which can be seen with the existing
llvm-obdump:
% llvm-objdump -private-headers macho-invalid-bad-symbol-index
…
Load command 4
cmd LC_SYMTAB
cmdsize 24
symoff 4216
nsyms 0
stroff 4392
strsize 144
Load command 5
cmd LC_DYSYMTAB
cmdsize 80
ilocalsym 0
nlocalsym 8 (past the end of the symbol table)
iextdefsym 8 (greater than the number of symbols)
nextdefsym 2 (past the end of the symbol table)
iundefsym 10 (greater than the number of symbols)
nundefsym 1 (past the end of the symbol table)
...
And the native darwin tools generates an error for this file:
% nm macho-invalid-bad-symbol-index
nm: object: macho-invalid-bad-symbol-index truncated or malformed object (ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table)
I added new checks for the indexes and sizes for these in the
constructor of MachOObjectFile. And added comments for what
would be a proper diagnostic messages.
And changed the test case using macho-invalid-bad-symbol-index
to test for the new error now produced.
Also added a test with a valid Mach-O file with a symbol table
load command where the number of symbols is zero that shows
the report_fatal_error() is not called.
llvm-svn: 258576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An upcoming commit will add an optimization to insert() that avoids
unnecessary mallocs when we can safely extract the key type. This
commit shares code between emplace() and insert():
- if emplace() is given a single argument, and
- value_type is constructible from that argument
so that we have a single code path for the two.
I also updated the debug version of emplace_hint() to defer to
emplace(), like the non-debug version does.
In both cases, there should be NFC here.
llvm-svn: 258575
|
|
|
|
|
|
| |
Patch by Jonathan Coe.
llvm-svn: 258573
|
|
|
|
|
|
|
|
| |
This patch adds a small utility to match function calls. This utility abstracts away the mutable keywords and the lazy initialization and caching logic of identifiers from the checkers. The SimpleStreamChecker is ported over this utility within this patch to show the reduction of code and to test this change.
Differential Revision: http://reviews.llvm.org/D15921
llvm-svn: 258572
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix the issue with the most recently discovered unit receiving much less attention.
Note: this is the second attempt (prev: r258473). Now, libc++ build is fixed.
Reviewers: aizatsky, kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16487
llvm-svn: 258571
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The testing for returnBB was flipped which may cause ARM ld/st opt pass uses callee saved regs in returnBB when shrink-wrap is used.
Reviewers: t.p.northover, apazos, MatzeB
Subscribers: mcrosier, zzheng, aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D16434
llvm-svn: 258569
|
|
|
|
| |
llvm-svn: 258568
|
|
|
|
| |
llvm-svn: 258567
|
|
|
|
|
|
|
|
|
|
|
| |
When we build LLVM with externalized debug info, all debugging and
symbolication related data is extracted into dSYM files prior to
stripping. As such, there is no need to preserve local symbols in LLVM
binaries after dSYM creation.
This shrinks libLLVM.dylib from 58MB to 55MB on my system.
llvm-svn: 258566
|
|
|
|
|
|
|
|
|
|
| |
Primarily a trial test for me to try out the
git clang-format integration. Works like a charm!
This change adds a gtest fixture for the EditlineTest
common setup and teardown code.
llvm-svn: 258565
|
|
|
|
| |
llvm-svn: 258564
|
|
|
|
| |
llvm-svn: 258563
|
|
|
|
|
|
|
|
|
|
|
| |
check.
Handle decayed types, ignore qualifiers and accessibility when considering a
method as a possible overload.
Differential Revision: http://reviews.llvm.org/D16179
llvm-svn: 258562
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16429
llvm-svn: 258561
|
|
|
|
|
|
|
|
|
| |
Keep the ones still used by libclc around for now.
Emit the new amdgcn intrinsic name if not targeting r600,
in which case the old AMDGPU name is still used.
llvm-svn: 258560
|
|
|
|
|
|
|
|
| |
If the intrinsic is overloaded and works on multiple types,
it cannot resolve to a single corresponding builtin and requires
handling in clang. This just causes crashes now.
llvm-svn: 258559
|
|
|
|
| |
llvm-svn: 258558
|
|
|
|
|
|
|
|
|
|
|
| |
The intrinsic target prefix should match the target name
as it appears in the triple.
This is not yet complete, but gets most of the important ones.
llvm.AMDGPU.* intrinsics used by mesa and libclc are still handled
for compatability for now.
llvm-svn: 258557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
all the attributes from the base object.
Summary:
Make sure that any new and optimized objects created during GlobalOPT copy all the attributes from the base object.
A good example of improper behavior in the current implementation is section information associated with the GlobalObject. If a section was set for it, and GlobalOpt is creating/modifying a new object based on this one (often copying the original name), without this change new object will be placed in a default section, resulting in inappropriate properties of the new variable.
The argument here is that if customer specified a section for a variable, any changes to it that compiler does should not cause it to change that section allocation.
Moreover, any other properties worth representation in copyAttributesFrom() should also be propagated.
Reviewers: jmolloy, joker-eph, joker.eph
Subscribers: slarin, joker.eph, rafael, tobiasvk, llvm-commits
Differential Revision: http://reviews.llvm.org/D16074
llvm-svn: 258556
|
|
|
|
|
|
|
|
|
| |
emitted into a precompiled header to mirror the debug info emitted for
object files importing the PCH.
rdar://problem/24290667
llvm-svn: 258555
|
|
|
|
|
|
|
|
|
|
|
| |
This option matches the behaviour of ld64, that is it prevents globals
from being dead stripped in executables and dylibs.
Reviewed by Lang Hames
Differential Revision: http://reviews.llvm.org/D16026
llvm-svn: 258554
|
|
|
|
|
|
|
|
|
| |
\src\llvm-rw\include\llvm/Support/AlignOf.h(254) :
error C2872: 'detail' : ambiguous symbol
could be 'llvm::detail'
or 'llvm::support::detail'
llvm-svn: 258553
|
|
|
|
| |
llvm-svn: 258552
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change adds a `-spp-no-statepoints` flag to PlaceSafepoints that
bypasses the code that wraps newly introduced polls and existing calls
in gc.statepoint. With `-spp-no-statepoints` enabled, PlaceSafepoints
effectively becomes a safpeoint **poll** insertion pass.
The eventual goal is to "constant fold" this option, along with
`-rs4gc-use-deopt-bundles` to `true`, once clients using gc.statepoint
are okay doing so.
Reviewers: pgavlin, reames, JosephTremoulet
Subscribers: sanjoy, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D16439
llvm-svn: 258551
|
|
|
|
| |
llvm-svn: 258550
|
|
|
|
|
|
|
|
|
| |
This is a rather unhelpful warning indicating that the ternary operator return
types are mismatched, returning an integer and an enumeral type. Since the
integeral type is shorter to type, cast the enumeral type to `int`. Silences
the -Wextra warning from GCC.
llvm-svn: 258548
|
|
|
|
|
|
|
| |
We were unnecessarily stripping the const qualifier on the temporary variable.
Restore the constness to avoid the warning. NFC.
llvm-svn: 258547
|
|
|
|
|
|
|
|
| |
Address a couple of instances of -Wreturn-type warning from GCC. The switches
are covered, add an llvm_unreachable to the end of the functions to silence the
warning. NFC.
llvm-svn: 258546
|