llvm-svn: 184527

llvm-svn: 184526

DebugInfo: When asm printing include a '[def]' tag for tag decls that are definitions (& rename the 'fwd' tag to 'decl' for clarity)

This change is version locked with a change in Clang, so expect some
transient buildbot fallout.

llvm-svn: 184525

DebugInfo: handle the DI asm printing change to reword '[fwd]' as '[decl]' and add '[def]' for non-decl tag types

This is to make test cases looking for definitions more legible by
making the definition explicit rather than just the absence of '[fwd]'.
This allowed the debug-info-record tests to be rephrased - and in the
interests of reducing the number of individual test cases/invocations we
have, I merged them into one file, separated them with namespaces (&
then moved them to C++ because namespaces are great). If they need to
remain 'C' only tests, they can be moved back. (I didn't group them with
'debug-info-class.cpp' because these tests only apply to
-fno-limit-debug-info)

I removed the pieces of code that would cause these tests to pass under
-flimit-debug-info to ensure the tests remain relevant to their fixes
should we ever improve -flimit-debug-info to catch that kind of code.

This commit is version locked with the corresponding change to
DebugInfo.h in LLVM. Except some transient buildbot fallout.

llvm-svn: 184524

llvm-svn: 184522

llvm-svn: 184521

llvm-svn: 184520

llvm-svn: 184519

llvm-svn: 184518

llvm-svn: 184517

llvm-svn: 184516

llvm-svn: 184515

llvm-svn: 184514

Previously we unconditionally enforced that section references in
symbols in the YAML had a name that was a section name present in the
object, and linked the references to that section. Now, permit empty
section names (already the default, if the `Section` key is not
provided) to indicate SHN_UNDEF.

llvm-svn: 184513

llvm-svn: 184512

Certain expressions can cause a constructor invocation to zero-initialize
its object even if the constructor itself does no initialization. The
analyzer now handles that before evaluating the call to the constructor,
using the same "default binding" mechanism that calloc() uses, rather
than simply ignoring the zero-initialization flag.

As a bonus, trivial default constructors are now no longer inlined; they
are instead processed explicitly by ExprEngine. This has a (positive)
effect on the generated path edges: they no longer stop at a default
constructor call unless there's a user-provided implementation.

<rdar://problem/14212563>

llvm-svn: 184511

No functionality change.

llvm-svn: 184510

This just seems a bit tidier/more principled. Based on a patch provided
by Adrian - with the only minor tweak that it needed to use
"getTypeOrNull" rather than "getCompletedTypeOrNull" since we don't
store declarations in the CompletedTypes cache.

No intended functionality change.

llvm-svn: 184509

llvm-svn: 184508

'\n' was displaying as 'n'

llvm-svn: 184507

Instead, just have 3 sub-lists, one for each of
{STB_LOCAL,STB_GLOBAL,STB_WEAK}.

This allows us to be a lot more explicit w.r.t. the symbol ordering in
the object file, because if we allowed explicitly setting the STB_*
`Binding` key for the symbol, then we might have ended up having to
shuffle STB_LOCAL symbols to the front of the list, which is likely to
cause confusion and potential for error.

Also, this new approach is simpler ;)

llvm-svn: 184506

llvm-svn: 184505

As an optimization, we only kept declared methods with distinct
signatures in the global method pool, to keep the method lists
small. Under modules, however, one could have two different methods
with the same signature that occur in different (sub)modules. If only
the later submodule is important, message sends to 'id' with that
selector would fail because the first method (the only one that got
into the method pool) was hidden. When building a module, keep *all*
of the declared methods.

I did a quick check of both module build time and uses of modules, and
found no performance regression despite this causing us to keep more
methods in the global method pool. Fixes <rdar://problem/14148896>.

llvm-svn: 184504

llvm-svn: 184503

- %N = show the name of the variable
- %> = show the expression path of the variable

llvm-svn: 184502

llvm-svn: 184501

In thread and frame format strings, it is now allowed to use Python functions to generate part or all of the output text
Specifically, the ${target ${process ${thread and ${frame specifiers have been extended to allow a subkeyword .script:<fctName> (e.g. ${frame.script:FooFunction})
The functions are prototyped as

def FooFunction(Object,unused)

where object is of the respective SB-type (SBTarget for target.script, ... and so on)

This has not been implemented for ${var because it would be akin to a Python summary which is already well-defined in LLDB

llvm-svn: 184500

directory for programs used by the driver is actually the standard
behavior we want to be compatible with GCC cross compilers -- it isn't
specific to SUSE or any other distro.

Also start fleshing out testing of the different cross compilation
patterns, both with a new very bare-bones tree of cross compilers and by
extending the multilib trees. Currently, we don't correctly model doing
a cross compile using the non-triple target of a bi-arch GCC install,
but I'll add support for that (and tests) next.

llvm-svn: 184499

llvm-svn: 184498

This will enable users in security critical applications to perform
checked-arithmetic in a fast safe manner that is amenable to c.

Tests/an update to Language Extensions is included as well.

rdar://13421498.

llvm-svn: 184497

llvm-svn: 184496

llvm-svn: 184495

llvm-svn: 184494

llvm-svn: 184493

it at the moment.
This allows to form more paired loads even when stack coloring pass destroys the
memoryoperand's value.

<rdar://problem/13978317>

llvm-svn: 184492

[PowerPC] Clean up VK_PPC_TOC... names

This is another minor cleanup; to bring enum names in line
with the corresponding @modifier names, this renames:

  VK_PPC_TOC -> VK_PPC_TOCBASE
  VK_PPC_TOC_ENTRY -> VK_PPC_TOC16

No code change intended.

llvm-svn: 184491

This is a bit tricky as the xacquire and xrelease hints use the same bytes,
0xf2 and 0xf3, as the repne and rep prefixes.

Fortunately llvm has different llvm MCInst Opcode enums for rep/xrelease
and repne/xacquire. So to make this work a boolean was added the
InternalInstruction struct as part of the Prefix state which is set with the
added logic in readPrefixes() when decoding an instruction to determine
if these prefix bytes are to be disassembled as xacquire or xrelease.  Then
we let the matcher pick the normal prefix instructionID and we change the
Opcode after that when it is set into the MCInst being created.

rdar://11019859

llvm-svn: 184490

operations in the case where evaluating a subexpression fails. No functionality
change, but test/Sema/many-logical-ops.c gets ~100x faster with this change.

llvm-svn: 184489

llvm-svn: 184488

llvm-svn: 184487