- take->release: LLVM has moved to C++11.  MockWrapper became an instance of unique_ptr.

   - method symbol_iterator::increment disappeared recently, in this revision:

     r200442 | rafael | 2014-01-29 20:49:50 -0600 (Wed, 29 Jan 2014) | 9 lines

Simplify the handling of iterators in ObjectFile.

None of the object file formats reported error on iterator increment. In
retrospect, that is not too surprising: no object format stores symbols or
sections in a linked list or other structure that requires chasing pointers.
As a consequence, all error checking can be done on begin() and end().

This reduces the text segment of bin/llvm-readobj in my machine from 521233 to
518526 bytes.

My change mimics the change that the revision made to lib/DebugInfo/DWARFContext.cpp .

    - const_cast: Shut up a warning from gcc.

I ran unittests/ExecutionEngine/JIT/Debug+Asserts/JITTests to make sure it worked.

- Arch

llvm-svn: 205689

It affected callee's stack pop in x86. It is one of devergences between cygwin and mingw since mingw-gcc-4.6.

Added testcases to llvm/test/CodeGen/X86/win32_sret.ll for cygwin.

llvm-svn: 205688

be used for indexing not only section's names.

No functional changes.

llvm-svn: 205687

Apparently that's how DWARF4 suggests they be emitted. So let's do that.

llvm-svn: 205686

DebugInfo: Support namespace aliases as DW_TAG_imported_declaration instead of DW_TAG_imported_module

I really should read the spec more often (and test GCC more often too).
I just assumed that namespace aliases would be the same as using
directives, except with a name. But apparently that's not how the DWARF
standards suggests they be implemented. DWARF4 provides an example and
other non-normative text suggesting that namespace aliases be
implemented by named imported declarations intsead of named imported
modules.

So be it.

llvm-svn: 205685

llvm-svn: 205684

llvm-svn: 205683

Also update a few null pointers in this function to be consistent with
new null pointers being added.

Patch by Robert Matusewicz!

Differential Revision: http://reviews.llvm.org/D3123

llvm-svn: 205682

This adds a warning when linker_private or linker_private_weak is provided and
we handle it in a compatible manner.

Suggested by Chris Lattner!

llvm-svn: 205681

Makes iteration over implicit and explicit machine operands more
explicit (har har). Insipired by code review discussion for r205565.

llvm-svn: 205680

Member functions defined within a class definition are implicitly
'inline' for linkage purposes. Compilers might slightly favor inlining
functions explicitly marked 'inline', but LLVM doesn't make a stylistic
habit of doing this generally.

llvm-svn: 205679

This consolidates the duplicated MachO checks in the directive parsing for
various directives that are unsupported for Mach-O.  The error message change is
unimportant as this restores the behaviour to that prior to the addition of the
new directive handling.  Furthermore, use a more direct check for MachO
targeting rather than an indirect feature check of the assembler.

Also simplify the test execution command to avoid temporary files.  Further more,
perform the check in both object and assembly emission.

Whether all non-applicable directives are handled is another question.  .fnstart
is marked as being unsupported, however, the complementary .fnend is not.  The
additional unwinding directives are also still honoured.  This change does not
change that, though, it would be good to validate and mark them as being
unsupported if they are unsupported for the MachO emission.

llvm-svn: 205678

This is the other half of r205676.

llvm-svn: 205677

This avoids an extra copy during decompression and avoids the use of
MemoryBuffer which is a weirdly esoteric device that includes unrelated
concepts like "file name" (its rather generic name is a bit misleading).

Similar refactoring of zlib::compress coming up.

llvm-svn: 205676

This restores the linker_private and linker_private_weak lexemes to permit
translation of the deprecated lexmes.  The behaviour is identical to the bitcode
handling: linker_private and linker_private_weak are handled as if private had
been specified.  This enables compatibility with IR generated by LLVM 3.4.

Reported on IRC by ki9a!

llvm-svn: 205675

Differential Revision: http://reviews.llvm.org/D3154

llvm-svn: 205674

Differential Revision: http://reviews.llvm.org/D3237

llvm-svn: 205673

llvm-svn: 205672

This was reverted in 205664 and seems to be fixed by 205668... though
that may be more by accident than anything well founded.

llvm-svn: 205669

While the folding set would deduplicate the nodes themselves and LLVM
would handle not emitting the same global twice, it still meant creating
a long/redundant list of global variables.

llvm-svn: 205668

llvm-svn: 205667

Also, add the names of people most recently working on particular projects,
and remove "relate bugs and checkers" (thanks, Alex!).

llvm-svn: 205666

which warns on compound conditionals that always evaluate to the same value.
For instance, (x > 5 && x < 3) will always be false since no value for x can
satisfy both conditions.

This patch also changes the CFG to use these tautological values for better
branch analysis.  The test for -Wunreachable-code shows how this change catches
additional dead code.

Patch by Anders Rönnholm.

llvm-svn: 205665

This reverts commit r205655.

Breaks the compiler-rt build with an assertion failure in LLVM...
reverting while I investigate.

llvm-svn: 205664

llvm-svn: 205663

Currently LLD accepts only "-soname <string>", but all the following
options are actually valid.

  --soname=foo
  --soname foo
  -soname=foo
  -soname foo
  -h foo

This patch fixes that issue.

llvm-svn: 205662

Fixes a false positive when temporary destructors are enabled where a temporary
is destroyed after a variable is constructed but before the VarDecl itself is
processed, which occurs when the variable is in the condition of an if or while.

Patch by Alex McCarthy, with an extra test from me.

llvm-svn: 205661

Fix "error: private field 'TM' is not used [-Werror,-Wunused-private-field]"

llvm-svn: 205660

when bridged Objective-C type conforms to the protocols in CF types's
Objective-C class. // rdar://16393330

llvm-svn: 205659

This provides more realistic costs for the insert/extractelement instructions
(which are load/store pairs), accounts for the cheap unaligned Altivec load
sequence, and for unaligned VSX load/stores.

Bad news:
MultiSource/Applications/sgefa/sgefa - 35% slowdown (this will require more investigation)
SingleSource/Benchmarks/McGill/queens - 20% slowdown (we no longer vectorize this, but it was a constant store that was scalarized)
MultiSource/Benchmarks/FreeBench/pcompress2/pcompress2 - 2% slowdown

Good news:
SingleSource/Benchmarks/Shootout/ary3 - 54% speedup
SingleSource/Benchmarks/Shootout-C++/ary - 40% speedup
MultiSource/Benchmarks/Ptrdist/ks/ks - 35% speedup
MultiSource/Benchmarks/FreeBench/neural/neural - 30% speedup
MultiSource/Benchmarks/TSVC/Symbolics-flt/Symbolics-flt - 20% speedup

Unfortunately, estimating the costs of the stack-based scalarization sequences
is hard, and adjusting these costs is like a game of whac-a-mole :( I'll
revisit this again after we have better codegen for vector extloads and
truncstores and unaligned load/stores.

llvm-svn: 205658

Remove the declaration of an unimplemented function.

llvm-svn: 205657

llvm-svn: 205656

We also don't need to duplicate the name in the LinkageName field. Just
leave it empty.

llvm-svn: 205655

llvm-svn: 205654

obviously won't work. Specifically, don't suggest methods (static or
not) from unrelated classes when the expression is a method call
through a specific object.

llvm-svn: 205653

These tests started failing on FreeBSD after r205497 "Make the fail
messages"

llvm.org/pr19347

llvm-svn: 205652

See the comment for CodeGenFunction::tryEmitAsConstant that describes
how in some contexts (lambdas) we must not emit references to the
variable, but instead use the constant directly - because of this we end
up emitting a constant for the variable, as well as emitting the
variable itself.

Should we just skip putting the variable on the stack at all and omit
the debug info for the constant? It's not clear to me - what if the
address of the local is taken?

llvm-svn: 205651

This introduces the definitions needed for the Windows on ARM target.  Add
target definitions for both the MSVC environment and the MSVC + Itanium C++ ABI
environment.  The Visual Studio definitions correspond to the definitions
provided by Visual Studio 2012.

llvm-svn: 205650

This way, you can check the number of sign bits in the
operands. The depth parameter it already has is pretty useless
without this.

llvm-svn: 205649

llvm-svn: 205648