specialize location information and diagnostics for this entity.

llvm-svn: 150588

llvm-svn: 150587

llvm-svn: 150586

llvm-svn: 150585

return statements within a lambda; this diagnostic previously referred
to blocks.

llvm-svn: 150584

llvm-svn: 150583

For ELF, also call fixSymbolsInTLSFixups() on expressions passed to EmitValue (literal values). Previously only called on expressions in instructions. New test cases added to tls.s, tls-i386.s. Resolves PR11981.

llvm-svn: 150582

Remove reference from common_type definition.  It looks like a recent clang decltype implementation got fixed/improved and exposed this.  Fixes http://llvm.org/bugs/show_bug.cgi?id=12007.

llvm-svn: 150581

world on Solaris 11 for both x86 and x86-64 using the built-in assembler and
Solaris (not GNU) ld, however it currently relies on a hard-coded GCC location
to find crtbegin.o and crtend.o, as well as libgcc and libgcc_eh.  

llvm-svn: 150580

in test/SemaCXX/nullptr.cpp to static_assert

llvm-svn: 150579

This commit makes PrintfSpecifier::fixType() and ScanfSpecifier::fixType()
only fix a conversion specification enough that Clang wouldn't warn about it,
as opposed to always changing it to use the "canonical" conversion specifier.
(PR11975)

This preserves the user's choice of conversion specifier in cases like:

printf("%a", (long double)1);
where we previously suggested "%Lf", we now suggest "%La"

printf("%x", (long)1);
where we previously suggested "%ld", we now suggest "%lx".

llvm-svn: 150578

Problem reported by: Ryan Taylor <ryta1203@gmail.com>

llvm-svn: 150577

llvm-svn: 150576

llvm-svn: 150575

llvm-svn: 150574

llvm-svn: 150573

The c'tor list is stored as a list of 'void ()*'s, so all of the functions are
bitcast to that. However, the dyn_cast doesn't automagically look through
bitcasts. Do that for it.
<rdar://problem/10813350>

llvm-svn: 150572

used to incrementally update a created node without needing a
temporary node and RAUW.

llvm-svn: 150571

llvm-svn: 150569

I'll put MachineLICM back before PEI. All my arm/x86 benchmarks look good, but buildbots don't like it.

llvm-svn: 150568

llvm-svn: 150567

llvm-svn: 150566

llvm-svn: 150565

llvm-svn: 150564

The llc command line options for enabling/disabling passes are local to CodeGen/Passes.cpp. This patch associates those options with standard pass IDs so they work regardless of how the target configures the passes.

A target has two ways of overriding standard passes:
1) Redefine the pass pipeline (override TargetPassConfig::add%Stage)
2) Replace or suppress individiual passes with TargetPassConfig::substitutePass.

In both cases, the command line options associated with the pass override the target default.

For example, say a target wants to disable machine instruction scheduling by default:

- The target calls disablePass(MachineSchedulerID) but otherwise does not override any TargetPassConfig methods.

- Without any llc options, no scheduler is run.

- With -enable-misched, the standard machine scheduler is run and honors the -misched=... flag to select the scheduler variant, which may be used for performance evaluation or testing.

Sorry overridePass is ugly. I haven't thought of a better way without replacing the cl::opt framework. I hope to do that one day...

I haven't figured out why CodeGen uses char& for pass IDs. AnalysisID is much easier to use and less bug prone. I'm using it wherever I can for internal implementation. Maybe later we can change the global pass ID definitions as well.

llvm-svn: 150563

Added TargetPassConfig::disablePass/substitutePass as a general mechanism to override specific passes.

llvm-svn: 150562

llvm-svn: 150561

expression is referenced, defined, then referenced again, make sure we
instantiate it the second time it's referenced. This is the static data member
analogue of r150518.

llvm-svn: 150560

llvm-svn: 150559

New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association.
This provides SB classes for each of the main object types involved in providing formatter support:
 SBTypeCategory
 SBTypeFilter
 SBTypeFormat
 SBTypeSummary
 SBTypeSynthetic
plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions
For naming consistency, this patch also renames a lot of formatters-related classes.
Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side.
The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer.
An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes.
Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories.

llvm-svn: 150558

to be core constant expressions (including pointers and references to
temporaries), and makes constexpr calculations Turing-complete. A Turing machine
simulator is included as a testcase.

This opens up the possibilty of removing CCValue entirely, and removing some
copies from the constant evaluator in the process, but that cleanup is not part
of this change.

llvm-svn: 150557

llvm-svn: 150556

llvm-svn: 150555

JIT when printing the values of registers (e.g.,
"expr $pc").  Now the expression parser can do this
in the IR interpreter without running code in the
inferior process.

llvm-svn: 150554

llvm-svn: 150553

llvm-svn: 150552

is general goodness because representations of member pointers are
not always equivalent across member pointer types on all ABIs
(even though this isn't really standard-endorsed).

Take advantage of the new information to teach IR-generation how
to do these reinterprets in constant initializers.  Make sure this
works when intermingled with hierarchy conversions (although
this is not part of our motivating use case).  Doing this in the
constant-evaluator would probably have been better, but that would
require a *lot* of extra structure in the representation of
constant member pointers:  you'd really have to track an arbitrary
chain of hierarchy conversions and reinterpretations in order to
get this right.  Ultimately, this seems less complex.  I also
wasn't quite sure how to extend the constant evaluator to handle
foldings that we don't actually want to treat as extended
constant expressions.

llvm-svn: 150551

llvm-svn: 150550

well as improving the RecursiveASTVisitor's walk of lambda
expressions.

llvm-svn: 150549

meta-data.

llvm-svn: 150548