This is a temporary workaround for native arm linux builds:
PR18996: Changing regalloc order breaks "lencod" on native arm linux builds.

llvm-svn: 202433

llvm-svn: 202432

1 - There were some outdated options being passed to clang
2 - There were some bad paths being passed as options
3 - The path to the main.cpp file ("/tmp/main.cpp") was wrong when the tests were being run, now we create a temp file
4 - Added a new ActionType::eNone to do nothing (no continue, step, or kill)

llvm-svn: 202431

seems unlikely to be added. It also doesn't seem like it should be part
of the build system at all (consider out-of-tree builds).

We should probably add nice, easy tool for this that works both for svn
client trees and git-svn client trees, but it probably won't be spelled
"make update".

llvm-svn: 202430

llvm-svn: 202429

This change fixes up issues with specifying the size of the i386
register infos for FPU registers.  The bug was that for the i386
register context, the size of the FPU registers were still being
computed based on the x86_64 FXSAVE structure.

This change permits the FPR_SIZE macro to optionally be defined
outside of RegisterInfos_i386.h, which RegisterContextLinux_i386.cpp
does properly. It redefines the FPR_i386 structure with all the
accessible parts that RegisterInfos_i386.h wants to see, which we had
not done before when we made the overall size of the structure
properly sized a recently.

This change also modifies POSIXThread to create a
RegisterContextLinux_i386 only when the host is 32-bit; otherwise, it
uses the RegisterContextLinux_x86_64, which works properly for 32-bit
and 64-bit inferiors on a 64-bit host.

I tested this debugging a Linux x86 exe on an x86 host (Ubuntu 13.10
x86), and debugging a Linux x86 exe and a Linux x86-64 exe on an
x86-64 host (Ubuntu 12.04 LTS).  Those cases all worked.

Thanks to Matthew Gardiner who discoverd may key insights into
tracking down the issue. The motivation for this change and some of
the code originates from him via this thread:

http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140224/010554.html

llvm-svn: 202428

or virtual functions, but permit that error to be downgraded to
a warning (with -Wno-error=incompatible-ms-struct), and officially
support this kind of dual, ABI-mixing layout.

The basic problem here is that projects which use ms_struct are often
not very circumspect about what types they annotate; for example,
some projects enable the pragma in a prefix header and then only
selectively disable it around system header inclusions.  They may
only care about binary compatibility with MSVC for a subset of
those structs, but that doesn't mean they have no binary
compatibility concerns at all for the rest; thus we are essentially
forced into supporting this hybrid ABI.  But it's reasonable for
us to at least point out the places where we're not making
any guarantees.

The original diagnostic was for dynamic classes, i.e. those with
virtual functions or virtual bases; I've extended it to include
all classes with bases, because we are not actually making any
attempt to duplicate MSVC's base subobject layout in ms_struct
(and it is indeed quite different from Itanium, even for
non-virtual bases).

rdar://16178895

llvm-svn: 202427

<rdar://problem/16140277>

llvm-svn: 202426

Summary:
This merges VFPtrInfo and VBTableInfo into VPtrInfo, since they hold
almost the same information.  With that change, the vbtable mangling
code can easily be applied to vftable data and we magically get the
correct, unambiguous vftable names.

Fixes PR17748.

Reviewers: timurrrr, majnemer

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2893

llvm-svn: 202425

Changed all "localhost" to "127.0.0.1" to prevent potentially long name lookups.

<rdar://problem/16154630>

llvm-svn: 202424

llvm-svn: 202423

expensive libcall. Also, Qp_neg is not implemented on at least
FreeBSD. This is also what gcc is doing.

llvm-svn: 202422

This reverts commit r202420, which broke the build.

llvm-svn: 202421

This cleans up some constructors that would not be safe once FileEntry
owns the storage for its name. These were already suspect, since they
wouldn't work if the FileEntry had an open file descriptor. The only
user for these constructors was in UniqueFileContainer, which wasn't a
very useful abstraction anyway. So it and UniqueDirContainer have been
replaced with std::map<UniqueID, *>.

This change should not affect anything outside the FileManager.

llvm-svn: 202420

In llvm the only semantic difference between internal and private is that llvm
tries to hide private globals my mangling them with a private prefix. Since
the globals changed by this patch already had the magic don't mangle marker,
there should be no change in the generated assembly.

A followup patch should then be able to drop the \01L and \01l prefixes and let
llvm mangle as appropriate.

llvm-svn: 202419

Some MC components like Target Streamers or Assembly Parsers
may need to access the relocation model in order to expand
some directives and/or assembly macros.

llvm-svn: 202418

making the cache mutable.

llvm-svn: 202417

scan the register file for sub- and super-registers.
No functionality change intended.

(Tests are updated because the comments in the assembler output are
different.)

llvm-svn: 202416

llvm-svn: 202415

If a function returns a large struct by value return the first 4 words
in registers and the rest on the stack in a location reserved by the
caller. This is needed to support the xC language which supports
functions returning an arbitrary number of return values. This is
r202397 reapplied with a fix to avoid an uninitialized read of a member.

llvm-svn: 202414

No functionality change. This is r202396 reapplied with no changes.

llvm-svn: 202413

This is a small bit of refactoring in preparation for FileEntry owning
the storage for its own name.

llvm-svn: 202412

This change converts points to clang::ExternalASTSource from llvm::OwningPtr<> to
llvm::IntrusiveRefCntPtr<>.

llvm-svn: 202411

llvm-svn: 202410

No functionality change. This is just an intermediate patch for changing those
global variables to use private linkage.

llvm-svn: 202409

We moved MCJIT to use native object formats a long time ago and R600
now uses ELF, so it was dead.

llvm-svn: 202408

More LWG issues. Mark #2182, #2323 and #2213 as complete. Add a test for #2339, and mark that as complete. No actual changes to the libc++ code; all of these were already in place.

llvm-svn: 202407

clang_Type_getTemplateArgument

Note that these functions don't handle variadic templates -- see tests.

Patch by Matthieu Nottale and Philippe Daouadi.

llvm-svn: 202406

llvm-svn: 202405

Re-apply r200853, which should not crash after Clang plugins were converted to loadable modules in r201256.

llvm-svn: 202404

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

llvm-svn: 202403

llvm-svn: 202402

[sanitizer] do not acquire a global mutex in deadlock detector when dealing with Unlock (it is essentially a thread-local operation)

llvm-svn: 202401

this fixes obscure false positives
see the comments and the test for details

llvm-svn: 202400

Reviewers: klimek

Reviewed By: klimek

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2895

llvm-svn: 202399

These are causing test failures, revert for now.

llvm-svn: 202398

Summary:
If a function returns a large struct by value return the first 4 words
in registers and the rest on the stack in a location reserved by the
caller. This is needed to support the xC language which supports
functions returning an arbitrary number of return values.

Reviewers: robertlytton

Reviewed By: robertlytton

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2889

llvm-svn: 202397

No functionality change.

llvm-svn: 202396

Summary:
If the src, dst and size of a memcpy are known to be 4 byte aligned we
can call __memcpy_4() instead of memcpy().

Reviewers: robertlytton

Reviewed By: robertlytton

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2871

llvm-svn: 202395

These instructions ignore the high bits of one of their input operands -
try and use this to simplify the code.

llvm-svn: 202394