| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This code path is entirely untested and not really maintained. The
expected use here is with libc++ only.
llvm-svn: 313954
|
|
|
|
| |
llvm-svn: 313953
|
|
|
|
| |
llvm-svn: 313952
|
|
|
|
| |
llvm-svn: 313951
|
|
|
|
|
|
|
|
| |
The script updates reference results from the previous run, and stages them.
Differential Revision: https://reviews.llvm.org/D38157
llvm-svn: 313950
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Exporting needed function for future reuse.
- Idiomatic python: using with `file as f` instead of `try/finally`.
- Fixing some indentation issues.
- No need to reinvent python `multiprocessing.getCPUCount()`
- Removing a function parameter which is always the same under all invocations.
- Adding some docstrings.
Differential Revision: https://reviews.llvm.org/D38156
llvm-svn: 313949
|
|
|
|
|
|
|
|
|
|
| |
I've been unable to find any cases whose behavior is actually changed by this,
but only because an implicitly deleted destructor also results in it being
impossible to have a trivial (non-deleted) copy constructor, which the place
where this really matters (choosing whether to pass a class in registers)
happens to also check.
llvm-svn: 313948
|
|
|
|
|
|
| |
[-Wunused-function]
llvm-svn: 313947
|
|
|
|
| |
llvm-svn: 313946
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The attribute informs the compiler that the annotated pointer parameter
of a function cannot escape and enables IRGen to attach attribute
'nocapture' to parameters that are annotated with the attribute. That is
the only optimization that currently takes advantage of 'noescape', but
there are other optimizations that will be added later that improves
IRGen for ObjC blocks.
This recommits r313722, which was reverted in r313725 because clang
couldn't build compiler-rt. It failed to build because there were
function declarations that were missing 'noescape'. That has been fixed
in r313929.
rdar://problem/19886775
Differential Revision: https://reviews.llvm.org/D32210
llvm-svn: 313945
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D37910
llvm-svn: 313944
|
|
|
|
| |
llvm-svn: 313943
|
|
|
|
|
|
|
| |
Move function call into debug macro to suppress unused variable warning
in non-debug builds.
llvm-svn: 313942
|
|
|
|
|
|
| |
You Use warnings; other minor fixes (NFC).
llvm-svn: 313941
|
|
|
|
| |
llvm-svn: 313940
|
|
|
|
| |
llvm-svn: 313939
|
|
|
|
| |
llvm-svn: 313938
|
|
|
|
|
|
| |
This found one place in lld that was not checking the error.
llvm-svn: 313937
|
|
|
|
| |
llvm-svn: 313936
|
|
|
|
| |
llvm-svn: 313935
|
|
|
|
|
|
|
|
|
| |
changes going
in today and don't want the two changes to confuse the situation with the build bots.
I'll commit tomorrow once they're known good.
llvm-svn: 313934
|
|
|
|
| |
llvm-svn: 313933
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
devices.
Normal customer devices won't be able to run these devices, we're hoping to get
a public facing bot set up at some point.
There will be some smaller follow-on patches. The changes to tools/lldb-server are
verbose and I'm not thrilled with having to skip all of these tests manually.
There are a few places where I'm making the assumption that "armv7", "armv7k", "arm64"
means it's an ios device, and I need to review & clean these up with an OS check
as well. (Android will show up as "arm" and "aarch64" so by pure luck they shouldn't
cause problems, but it's not an assumption I want to rely on).
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 313932
|
|
|
|
|
|
|
|
|
|
| |
HexagonVectorLoopCarriedReuse pass"
This reverts commit r313926.
It was failing in some bots.
llvm-svn: 313931
|
|
|
|
| |
llvm-svn: 313930
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit annotates the block parameters of the following functions
declared in compiler-rt with 'noescape':
- dispatch_sync
- dispatch_barrier_sync
- dispatch_once
- dispatch_apply
This is needed to commit the patch that adds support for 'noescape' in
clang (see https://reviews.llvm.org/D32210) since these functions are
annotated with 'noescape' in the SDK header files.
Differential Revision: https://reviews.llvm.org/D32210
llvm-svn: 313929
|
|
|
|
|
|
|
|
| |
There were two issues, one Python 3 specific related to Unicode,
and another which is that the tool substitution for lld no longer
rejected matches where a / preceded the tool name.
llvm-svn: 313928
|
|
|
|
|
|
|
|
|
| |
This change is required to easily test the given checkout of the analyzer,
rather than the one bundled with a system compiler.
Differential Revision: https://reviews.llvm.org/D38155
llvm-svn: 313927
|
|
|
|
|
|
| |
added HexagonVectorLoopCarriedReuse pass
llvm-svn: 313926
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a pass that removes the computation of provably redundant
expressions that have been computed earlier in a previous iteration. It
relies on the use of PHIs to identify loop carried dependences.
This is scalar replacement for vector types.
llvm-svn: 313925
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38003
llvm-svn: 313924
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38003
llvm-svn: 313923
|
|
|
|
|
|
|
|
| |
This is breaking several bots. I have enough information to
investigate, so I'm reverting to green until I get it figured
out.
llvm-svn: 313922
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the second slice of a Mach-O universal file.
The code in llvm-objdump in in DisassembleMachO() was getting the default
CPU then incorrectly setting into the global variable used for the -mcpu option
if that was not set. This caused a second call to DisassembleMachO() to use
the wrong default CPU when disassembling the next slice in a Mach-O universal
file. And would result in bad disassembly and an error message about an
recognized processor for the target:
% llvm-objdump -d -m -arch all fat.macho-armv7s-arm64
fat.macho-armv7s-arm64 (architecture armv7s):
(__TEXT,__text) section
armv7:
0: 60 47 bx r12
fat.macho-armv7s-arm64 (architecture arm64):
'cortex-a7' is not a recognized processor for this target (ignoring processor)
'cortex-a7' is not a recognized processor for this target (ignoring processor)
(__TEXT,__text) section
___multc3:
0: .long 0x1e620810
rdar://34439149
llvm-svn: 313921
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The changes in r297174 moved the #include of <link.h> on FreeBSD (and
probably other systems) inside of the open 'libunwind' namespace
causing various system-provided types such as pid_t to be declared in
this namespace rather than the global namespace. Fix this by moving
the relevant declarations before the 'libunwind' namespace is opened,
but still using the cleaned up declarations from r297174.
Reviewed By: ed, compnerd
Differential Revision: https://reviews.llvm.org/D38108
llvm-svn: 313920
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
debuginfo-tests has need to reuse a lot of common configuration
from clang and lld, and in general it seems like all of the
projects which are tightly coupled (e.g. lld, clang, llvm, lldb,
etc) can benefit from knowing about one other. For example,
lldb needs to know various things about how to run clang in its
test suite. Since there's a lot of common substitutions and
operations that need to be shared among projects, sinking this
up into LLVM makes sense.
In addition, this patch introduces a function add_tool_substitution
which handles all the dirty intricacies of matching tool names
which was previously copied around the various config files. This
is now a simple straightforward interface which is hard to mess
up.
Differential Revision: https://reviews.llvm.org/D37944
llvm-svn: 313919
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has gone back and forth, but it seems this is necessary
after all. realpath is not sufficient because if you have a
file named 'C:\foo.txt', then both realpath('c:\foo.txt') and
realpath(C:\foo.txt') return the string that was passed to them
exactly as is, meaning the case of the drive-letter won't match.
The problem before was not that we were normalizing the case of
items going into the config map, but rather that we were
normalizing the case of something we needed to print. The value
that is used to key on the config map should never be printed.
llvm-svn: 313918
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Avoid using XZR/WZR directly as operands to split stores of zero
vectors. Doing so can lead to the XZR/WZR being used by an instruction
that doesn't allow it (e.g. add).
Fixes bug 34674.
Reviewers: t.p.northover, efriedma, MatzeB
Subscribers: aemerson, rengolin, javed.absar, mcrosier, eraman, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D38146
llvm-svn: 313916
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For ARM thunks, the `movt` half of the relocation was using an incorrect
offset (it was off by 4 bytes). The original intent seems to have been
for the offset to have been relative to the current instruction, in
which case the difference of 4 makes sense. As the code stands, however,
the offset is always calculated relative to the start of the thunk
(`P`), and so the `movw` and `movt` halves should use the same offset.
This requires a very particular offset between the thunk and its target
to be triggered, and it results in the `movt` half of the relocation
being off-by-one.
The tests here use ARM-Thumb interworking thunks, since those are the
only ARM thunks currently implemented. I actually encountered this with
a range extension thunk (having Peter's patches cherry-picked locally),
but the underlying issue is identical.
Differential Revision: https://reviews.llvm.org/D38112
llvm-svn: 313915
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously the `_tu` was not propagated to the returned cursor, leading to errors when calling any
method on that cursor (e.g. `cursor.referenced`).
Reviewers: jbcoe, rsmith
Reviewed By: jbcoe
Subscribers: cfe-commits
Tags: #clang
Patch by jklaehn (Johann Klähn)
Differential Revision: https://reviews.llvm.org/D36953
llvm-svn: 313913
|
|
|
|
|
|
|
|
|
|
|
| |
The previous version of dumper implemented UTF-16 byte swap incorrectly
on big-endian machines. This now gets fixed.
Thanks to Bill Seurer for testing the patch locally.
Differential Review: https://reviews.llvm.org/D38150
llvm-svn: 313912
|
|
|
|
| |
llvm-svn: 313911
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds dumping of line table instructions as well as the final
state at each specified pc value in verbose mode. This is essentially
the same as the default in Darwin's dwarfdump. Dumping the actual line
table opcodes can be particularly useful for something like debugging a
bad `.debug_line` section.
Differential revision: https://reviews.llvm.org/D37971
llvm-svn: 313910
|
|
|
|
| |
llvm-svn: 313909
|
|
|
|
|
|
|
|
| |
countTrailingOnes instead of getting active bits and checking if all the bits below that make a mask.
At least for the 64-bit and less case, we should be able to determine if we even have a mask without counting any bits. This also removes the need to explicitly check for 0 active bits, isMask will return false for 0.
llvm-svn: 313908
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported here: https://bugs.llvm.org/show_bug.cgi?id=34692
A non-defined enum with a backing type was always defaulting to
being treated as a signed type. IN the case where it IS defined,
the signed-ness of the actual items is used.
This patch uses the underlying type's signed-ness in the non-defined
case to test signed-comparision.
Differential Revision: https://reviews.llvm.org/D38145
llvm-svn: 313907
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sema::InstantiateClass should check only exception specs added during
class instantiation and ignore already present delayed specs. This fixes
a case where we instantiate a class before parsing member initializers,
check exceptions for a different class and fail to find a member
initializer. Which is required for comparing exception specs for
explicitly-defaulted and implicit default constructor. With the fix we
are still checking exception specs but only after member initializers
are present.
Removing errors in crash-unparsed-exception.cpp is acceptable according
to discussion in PR24000 because other compilers accept code in
crash-unparsed-exception.cpp as valid.
rdar://problem/34167492
Reviewers: davide, rsmith
Reviewed By: rsmith
Subscribers: dim, cfe-commits
Differential Revision: https://reviews.llvm.org/D37881
llvm-svn: 313906
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm.dbg.declare"
The fix is to avoid invalidating our insertion point in
replaceDbgDeclare:
Builder.insertDeclare(NewAddress, DIVar, DIExpr, Loc, InsertBefore);
+ if (DII == InsertBefore)
+ InsertBefore = &*std::next(InsertBefore->getIterator());
DII->eraseFromParent();
I had to write a unit tests for this instead of a lit test because the
use list order matters in order to trigger the bug.
The reduced C test case for this was:
void useit(int*);
static inline void inlineme() {
int x[2];
useit(x);
}
void f() {
inlineme();
inlineme();
}
llvm-svn: 313905
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The core of this change is the new CommandInterpreter::m_command_state, which
models the state transitions for interactive commands, including an
"interrupted" state transition.
In general, command interruption requires cooperation from the code executing
the command, which needs to poll for interruption requests through
CommandInterpreter::WasInterrupted().
CommandInterpreter::PrintCommandOutput() implements an optionally
interruptible printing of the command output, which for large outputs was
likely the longest blocking part. (ex. target modules dump symtab on a
complex binary could take 10+ minutes)
patch by lemo
Differential Revision: https://reviews.llvm.org/D37923
llvm-svn: 313904
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove an assertion that tests the injectivity of the
PHIRead -> PHIWrite relation. That is, allow a single PHI write to be
used by multiple PHI reads. This may happen due to some statements
containing the PHI write not having the statement instances that would
overwrite the previous incoming value due to (assumed/invalid) contexts.
This result in that PHI write is mapped to multiple targets which is not
supported. Codegen will select one one of the targets using
getAddressFunction(). However, the runtime check should protect us from
this case ever being executed.
We therefore allow injective PHI relations. Additional calculations to
detect/santitize this case would probably not be worth the compuational
effort.
This fixes llvm.org/PR34485
llvm-svn: 313902
|