From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260657

Replace 'third' with 'fourth' in the description of the fourth argument.

llvm-svn: 260656

llvm-svn: 260655

llvm-svn: 260654

before I update it to be friendly with the new pass manager.

llvm-svn: 260653

[ADT] Introduce ‘OptionSet’ in llvm/ADT headers, which is a utility class that makes it convenient to work with enumerators representing bit options.

llvm-svn: 260652

Introduce a subtarget feature for this, and leave the default with
the current behavior which assumes up to 16-byte loads/stores can
be used. The field also seems to have the ability to be set to 2 bytes,
but I'm not sure what that would be used for.

llvm-svn: 260651

llvm-svn: 260649

namespace for arguments.

llvm-svn: 260647

I don't think this was causing any real problems, so I'm not sure
how to test for this.

llvm-svn: 260646

llvm-svn: 260645

llvm-svn: 260644

Patch by Jack Howarth.

When linking to libLLVM, don't also link to the component
libraries that constitute libLLVM.

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

llvm-svn: 260641

Patch by Jorge Teixeira!

llvm-svn: 260639

llvm-svn: 260637

Previously, if both A and B are ".ctors", both compCtors(A, B) and
compCtors(B, A) are true, which is a violation of the strict weak
ordering because such function is not antisymmetric.

llvm-svn: 260633

MSan adds a constructor to each translation unit that calls
__msan_init, and does nothing else. The idea is to run __msan_init
before any instrumented code. This results in multiple constructors
and multiple .init_array entries in the final binary, one per
translation unit. This is absolutely unnecessary; one would be
enough.

This change moves the constructors to a comdat group in order to drop
the extra ones.

llvm-svn: 260632

llvm-svn: 260631

Documentation change for: http://reviews.llvm.org/D17169

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

llvm-svn: 260630

Updating sancov invocation on html_cov_dump.

sancov change: http://reviews.llvm.org/D17169

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

llvm-svn: 260629

Multi-dso programs result in multiple coverage files dumped of the form
'<module_name>.<pid>.sancov'. When analyzing these coverage files it is
important to use correct corresponding object file.

This change removes the "-obj" sancov flag and lets user specify object
file names alongside coverage files. Sancov tool would match them using
<module_name> part of coverage file and short file name of the object
file.

Corresponding changes:
- compiler-rt: http://reviews.llvm.org/D17171
- docs: http://reviews.llvm.org/D17175

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

llvm-svn: 260628

This patches teaches LVI to recognize clamp idioms (e.g. select(a > 5, a, 5) will always produce something greater than 5.

The tests end up being somewhat simplistic because trying to exercise the case I actually care about (a loop with a range check on a clamped secondary induction variable) ends up tripping across a couple of other imprecisions in the analysis. Ah, the joys of LVI...

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

llvm-svn: 260627

Don't crash if we have a DIE that has a DW_AT_ranges attribute and yet the SymbolFileDWARF doesn't have a DebugRanges. If this happens print a nice error message to prompt the user to file a bug and attach the offending DWARF file so we can get the correct compiler fixed.

<rdar://problem/24458016>

llvm-svn: 260626

Summary: Also, some cosmetic fixes.

Reviewers: arsenm, tstellarAMD

Subscribers: qcolombet, llvm-commits

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

llvm-svn: 260625

clearing the map ended up calling back into the TypeSystemMap to do lookups.  
Not a good idea, and in this case it would cause a deadlock.

You would only see this when replacing the target contents after an exec, and only if you 
had stopped before the exec, evaluated an expression, then continued
on to the point where you did the exec.  

Fixed this by making sure the TypeSystemMap::Clear tears down the TypeSystems in the map before clearing the map.
I also add an expression before exec to the TestExec.py so that we'll catch this
issue if it crops up again in the future.

<rdar://problem/24554920>

llvm-svn: 260624

llvm-svn: 260623

functions, ask it whether it did provide them after the fact. Some versions of
glibc fail to compile if you make this request and don't also claim to be at
least GCC 4.3.

llvm-svn: 260622

Also actually test the default CPU from those triples.

llvm-svn: 260621

As I noted in the comment, the sorting order of .[cd]tors are
different from .{init,fini}_array's.

http://reviews.llvm.org/D17120

llvm-svn: 260620

It makes it easier to correlate with assembly dumps, which are typically
given with hex offsets.

llvm-svn: 260619

assert(((SymbolFileDWARF*)m_ast.GetSymbolFile())->UserIDMatches(die.GetDIERef().GetUID()) &&
       "Adding incorrect type to forward declaration map");

The problem is that "m_ast.GetSymbolFile()" can return a SymbolFileDWARFDebugMap. The code is doing the right thing if the assertion is ignored.

<rdar://problem/24437972>

llvm-svn: 260618

release made this obsolete.

llvm-svn: 260617

linking defaults as other NetBSD targets, i.e. compiler_rt-in-libc and
libc++ as STL.

llvm-svn: 260616

When a target task finishes and it tries to access the th_task_team from the
threads in the team where it was created, th_task_team can be NULL or point to
a different place when that thread started a nested region that is still
running. Finding the exact task_team that the threads were using is difficult
as it would require to unwind the task_state_memo_stack. So a new field was added
in the taskdata structure to point to the active task_team when the task was
created.

llvm-svn: 260615

llvm-svn: 260614

llvm-svn: 260613

Original commit message:
[InstCombine] Fold IntToPtr and PtrToInt into preceding loads.

Currently we only fold a BitCast into a Load when the BitCast is its
only user.

Do the same for any no-op cast.

Patch by Philip Pfaffe!

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

llvm-svn: 260612

Summary:
Reasons to remove are twofold:
 - we don't really need coverage=1 for libfuzzer operation
 - makes controlling coverage for fuzzer processes non-trivial.

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

llvm-svn: 260611

normalized exponents. That's not true for double versus double double.

llvm-svn: 260610

Let DAG.getConstant() handle the splatting; there's no need
to repeat that logic here.

See also:
http://reviews.llvm.org/rL258833
http://reviews.llvm.org/rL260582

llvm-svn: 260609