order based on order of insertion.
This should cause both our warnings about these and the modules
serialization to be deterministic as a consequence.
Found by inspection.
llvm-svn: 233343
Change `getNonCompileUnitScope()` to return `MDScope` and
`getConstantAsMetadata()` to return `ConstantAsMetadata`. This will
make it easier to start requiring more type safety in the debug info
hierarchy.
llvm-svn: 233340
DeclIDs so that in addition to be grouped by file, the order of these
groups is stable.
Found by inspection, no test case. Not sure this can be observed without
a randomized seed for the hash table, but we shouldn't be relying on the
hash table layout under any circumstances.
llvm-svn: 233339
Move all the `MDNode` field helper methods into a new class,
`MDFieldPrinter`, and add helpers for integers, bools, and `DW_*`
symbolic constants. This reduces a ton of code duplication, and makes
it more mechanical to update `AsmWriter` to print broken code in the
context of stricter accessors (like in r233322).
llvm-svn: 233337
Summary:
This is similar to the change introduced for variable DIEs in r233098. If the
linkage names of functions are missing in the DWARF, then their fully qualified
names (similar to the name that would be got by demangling their linkage name)
is generated using the decl context.
This change fixes TestNamespace when the test case is compiled with GCC, hence
it is enabled for GCC. The test and the test case are also enhanced to cover
variadic functions.
Test Plan: dotest.py -C <clang|gcc> -p TestNamespace
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8623
llvm-svn: 233336
rewritten decls for Objective-C modules.
Found by inspection and completely obvious, so no test case. Many of the
remaining determinism fixes won't have precise test cases at this point,
but these are the kinds of things we wouldn't ask for a specific test of
during code review but ask authors to fix. The functionality isn't
changing, and should (he he!) already be tested.
llvm-svn: 233333
traversing the identifier table.
No easy test case as this table is somewhere between hard and impossible
to observe as non-deterministically ordered. The table is a hash table
but we hash the string contents and never remove entries from the table
so the growth pattern, etc, is all completely fixed. However, relying on
the hash function being deterministic is specifically against the
long-term direction of LLVM's hashing datastructures, which are intended
to provide *no* ordering guarantees. As such, this defends against these
things by sorting the identifiers. Sorting identifiers right before we
emit them to a serialized form seems a low cost for predictability here.
llvm-svn: 233332
logic removed.
This logic was both inserting all builtins into the identifier table and
ensuring they would get serialized. The first happens unconditionally
now, and we always write out the entire identifier table. This code can
simply go away.
llvm-svn: 233331
We used to mark a bunch of libm nodes as Expand for f16. There are no
libcalls we can use for those, so we eventually just hit an unhelpful
llvm_unreachable in ExpandFPLibCall.
Instead, just ignore them altogether. If nothing else changes, we'll
then get the more descriptive and pleasant "Cannot select" fatal error.
There's an argument to be made for consistency, but f16 is already
special in all the good ways, and as long as there's no f16 support in
the ops expander (this patch), as well as the Soften/Expand float
legalizers (which, when hit, will currently segfault), I think there's
no point in even pretending we can legalize any of this.
This shouldn't affect anything that's not already broken.
llvm-svn: 233328
constructors in the current lexical context even though name lookup
found them via some other context merged into the redecl chain.
This can only happen for implicit constructors which can only have the
name of the type of the current context, so we can fix this by simply
*always* merging those names first. This also has the advantage of
removing the walk of the current lexical context from the common case
when this is the only constructor name we need to deal with (implicit or
otherwise).
I've enhanced the tests to cover this case (and uncovered an unrelated
bug which I fixed in r233325).
llvm-svn: 233327
deserializing an inherited constructor.
This is the exact same logic we use when deserializing method overrides
for the same reason: the canonical decl may end up pinned to a different
decl when we are improting modules, we need to re-pin to the canonical
one during reading.
My test case for this will come in a subsequent commit. I was trying to
test a more tricky bug fix and the test case happened to tickle this bug
as well.
llvm-svn: 233325
Summary:
The ARM backend can use a loop to implement copying byval parameters before
a call. In non-thumb2 mode it uses a constant pool load to materialize the
trip count. For targets that need movt instead (e.g. Native Client), use
the same code as in thumb2 mode to materialize the trip count.
Reviewers: jfb, t.p.northover
Differential Revision: http://reviews.llvm.org/D8442
llvm-svn: 233324
Check accessors of `MDLocation`, and change them to `cast<>` down to the
right types. Also add type-safe factory functions.
All the callers that handle broken code need to use the new versions of
the accessors (`getRawScope()` instead of `getScope()`) that still
return `Metadata*`. This is also necessary for things like
`MDNodeKeyImpl<MDLocation>` (in LLVMContextImpl.h) that need to unique
the nodes when their operands might still be forward references of the
wrong type.
In the `Value` hierarchy, consumers that handle broken code use
`getOperand()` directly. However, debug info nodes have a ton of
operands, and their order (even their existence) isn't stable yet. It's
safer and more maintainable to add an explicit "raw" accessor on the
class itself.
llvm-svn: 233322
Summary:
When the arch is given as "arm" clang uses the default target CPU from
LLVM to determine what the real arch should be (i.e. "arm" becomes
"armv4t" because LLVM's getARMCPUForArch falls back to "arm7tdmi").
Default to "cortex-a8" so that we end up with "armv7" in clang.
the nacl-direct.c test in clang also covers this case.
Differential Revision: http://reviews.llvm.org/D8589
llvm-svn: 233321
There is something in link.exe that requires a relocation to use a
global symbol. Not doing so breaks the chrome build on windows.
This patch sets isWeak for that to work. To compensate,
we then need to look past those symbols when not creating relocations.
This patch includes an ELF test that matches GNU as behaviour.
I am still reducing the chrome build issue and will add a test
once that is done.
llvm-svn: 233318
When no hijack listener is set up, the global event listener will
try to pull events off the queue, racing with the event thread.
By always forcing a hijack listener, even when one was not given,
we guarantee that the listener always gets all events.
This was causing problems in synchronous mode with the process
stop event sometimes never being picked up and causing the debugger
to hang while processing a .lldbinit file.
Reviewed by: Jim Ingham
Differential Revision: http://reviews.llvm.org/D8562
llvm-svn: 233315
Eric Christopher pointed out that we have a check for assembly code
generation in a clang test, which isn't cool. We already have Driver
and back-end CodeGen tests for the .abiversion handling, so this
testing is unnecessary anyway. Make it go away.
llvm-svn: 233314
APInt uses Knuth's D algorithm for long division. In rare cases the
implementation applied a transformation that was not needed.
Added unit tests for long division. KnuthDiv() procedure is fully covered.
There is a case in APInt::divide() that I believe is never used (marked with
a comment) as all users of divide() handle trivial cases earlier.
Patch by Pawel Bylica!
http://reviews.llvm.org/D8448
llvm-svn: 233312
Most expected OS failures or skipped tests are about the target platform on
which the test binary is being run, not the host platform launching the tests.
This changes expectedFailureOS and skipIfPlatform to check against the remote
platform when running remote tests.
Test Plan:
Run ./do_sep.py test suite against a remote target on a different platform and
verify that tests which should be excluded on the remote platform are excluded.
Differential Revision: http://reviews.llvm.org/D8611
llvm-svn: 233311
Summary:
This patch is an attempt at making `DenseMapIterator`s "fail-fast".
Fail-fast iterators that have been invalidated due to insertion into
the host `DenseMap` deterministically trip an assert (in debug mode)
on access, instead of non-deterministically hitting memory corruption
issues.
Enabling fail-fast iterators breaks the LLVM C++ ABI, so they are
predicated on `LLVM_ENABLE_ABI_BREAKING_CHECKS`.
`LLVM_ENABLE_ABI_BREAKING_CHECKS` by default flips with
`LLVM_ENABLE_ASSERTS`, but can be clamped to ON or OFF using the CMake /
autoconf build system.
Reviewers: chandlerc, dexonsmith, rnk, zturner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8351
llvm-svn: 233310
The "|&" operator isn't POSIX, so it can fail depending on the host's
default shell. Avoid it.
There were also a couple of places that did "2>1", but this creates a
file called "1". They clearly meant "2>&1".
llvm-svn: 233309
Previously we were using teardown hooks in these two instances to
shutdown processes. TestBase already deletes all targets in its
own teardown, which will kill processes, so these steps weren't
necessary.
llvm-svn: 233308
tear down hooks run as part of Base.tearDown(). Some of these
hooks rely on accessing the debugger instance. So although it
looks awkward, we need to call "del self.dbg" after calling
Base.tearDown().
llvm-svn: 233306
This reverts commit r233254, effectively reapplying r233164 (and its
successors), with an additional testcase for when subprograms match
exactly. This fixes PR22792 (again).
I'm using the same approach, but I've moved up the call to
`stripReplacedSubprograms()`. The function pointers need to be dropped
before mapping any metadata from the source module, or else this can
drop the function from new subprograms that have merged (via Metadata
uniquing) with the old ones. Dropping the pointers first prevents them
from merging.
**** The original commit message follows. ****
Linker: Drop function pointers for overridden subprograms
Instead of dropping subprograms that have been overridden, just set
their function pointers to `nullptr`. This is a minor adjustment to the
stop-gap fix for PR21910 committed in r224487, and fixes the crasher
from PR22792.
The problem that r224487 put a band-aid on: how do we find the canonical
subprogram for a `Function`? Since the backend currently relies on
`DebugInfoFinder` (which does a naive in-order traversal of compile
units and picks the first subprogram) for this, r224487 tried dropping
non-canonical subprograms.
Dropping subprograms fails because the backend *also* builds up a map
from subprogram to compile unit (`DwarfDebug::SPMap`) based on the
subprogram lists. A missing subprogram causes segfaults later when an
inlined reference (such as in this testcase) is created.
Instead, just drop the `Function` pointer to `nullptr`, which nicely
mirrors what happens when an already-inlined `Function` is optimized
out. We can't really be sure that it's the same definition anyway, as
the testcase demonstrates.
This still isn't completely satisfactory. Two flaws at least that I can
think of:
- I still haven't found a straightforward way to make this symmetric
in the IR. (Interestingly, the DWARF output is already symmetric,
and I've tested for that to be sure we don't regress.)
- Using `DebugInfoFinder` to find the canonical subprogram for a
function is kind of crazy. We should just attach metadata to the
function, like this:
define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) {
llvm-svn: 233302
Third element is to be added soon to "struct AArch64NamedImmMapper::Mapping". So its instances are renamed from ...Pairs to ...Mappings
Reviewers: jmolloy
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8582
llvm-svn: 233300
Unlike most of the other platforms supported by Clang, CloudABI only
supports static linkage, for the reason that global filesystem access is
prohibited. Functions provided by dlfcn.h are not present. As we know
that applications will not try to do any symbol lookups at run-time, we
can garbage collect unused code quite aggressively. Because of this, it
makes sense to enable -ffunction-sections and -fdata-sections by
default.
Object files will be a bit larger than usual, but the resulting binary
will not be affected, as the sections are merged again. However, when
--gc-sections is used, the linker is able to remove unused code far more
more aggressively. It also has the advantage that transitive library
dependencies only need to be provided to the linker in case that
functionality is actually used.
Differential Revision: http://reviews.llvm.org/D8635
Reviewed by: echristo
llvm-svn: 233299
Summary:
This should always be true but sometimes is not, during platform bring
up. As recommended by Jim Ingham, an assertion should be enough here to
help.
This addresses post commit comments in http://reviews.llvm.org/D8554.
Test Plan: Run unit tests.
Reviewers: jasonmolenda, emaste, jingham, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8574
llvm-svn: 233298
class AArch64NamedImmMapper is to become dependent of SubTargetFeatures, while class AArch64Operand don't have access to the latter.
So, AArch64NamedImmMapper constructor invocations are refactored away from methods of AArch64Operand.
Reviewers: jmolloy
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8579
llvm-svn: 233297
Ahmed Bougacha