From Alexander Esilevich.

llvm-svn: 231972

llvm-svn: 231971

time. The target independent code was passing in one all the
time and targets weren't checking validity before using. Update
a few calls to pass in a MachineFunction where necessary.

llvm-svn: 231970

llvm-svn: 231969

the spec required by std::sort and friends.

Ordering things this way also dramatically simplifies the code as
short-circuit ensures we can skip all of the negative tests.

I've left one FIXME where we're establishing a fairly arbitrary
ordering. Previously, the function compared all types as equal except
for the ones it explicitly handled, but it didn't delegate correctly to
the atomflags when doing so, and so it would fail to be a SWO. The two
possible fixes are to stop comparing the atom flags entirely, or to
establish some arbitrary ordering of the types.

Since it was pure luck which ordering of unequal types we ended up with
previously (the caller was std::sort, not std::stable_sort) I chose to
make the ordering explicit and guaranteed. This seems like the best
conservative approach as I suspect we would want to switch to
stable_sort otherwise in order to have deterministic output.

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

llvm-svn: 231968

This reverts commit r231957.

IntervalMap currently doesn't support keys more aligned than host pointers
and I've been using it with uint64_t keys. This asserts on some 32bits
systems.

Revert while I work on an IntervalMap generalization.

llvm-svn: 231967

This was previously initialized by ProcessGDBRemote::Initialize but lldb-server does not contain ProcessGDBRemote anymore so this needs to be initialized directly.

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

llvm-svn: 231966

80bit Intel/PPC long double is excluded due to lacking support
for the abstraction. Consistently provide saturation logic.
Extend to long double on 128bit IEEE extended platforms.

Initial patch with test cases from GuanHong Liu.
Reviewed by Steve Canon.

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

llvm-svn: 231965

In http://reviews.llvm.org/D7880 the initialization for LLGS was separated out so that LLGS could initialize only the components it needs to. This further reduces the set of components initialized for LLGS.

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

llvm-svn: 231964

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

llvm-svn: 231963

llvm-svn: 231962

If a function is going in an unique section (because of -ffunction-sections
for example), putting a jump table in .rodata will keep .rodata alive and
that will keep alive any other function that also has a jump table.

Instead, put the jump table in a unique section that is associated with the
function.

llvm-svn: 231961

Support for the QPX vector instruction set, used on the IBM BG/Q supercomputer,
has recently been added to the LLVM PowerPC backend. This vector instruction
set requires some ABI modifications because the ABI on the BG/Q expects
<4 x double> vectors to be provided with 32-byte stack alignment, and to be
handled as native vector types (similar to how Altivec vectors are handled on
mainline PPC systems). I've named this ABI variant elfv1-qpx, have made this
the default ABI when QPX is supported, and have updated the ABI handling code
to provide QPX vectors with the correct stack alignment and associated
register-assignment logic.

llvm-svn: 231960

The main issue being fixed here is that APCS targets handling a "byval align N"
parameter with N > 4 were miscounting what objects were where on the stack,
leading to FrameLowering setting the frame pointer incorrectly and clobbering
the stack.

But byval handling had grown over many years, and had multiple layers of cruft
trying to compensate for each other and calculate padding correctly. This only
really needs to be done once, in the HandleByVal function. Elsewhere should
just do what it's told by that call.

I also stripped out unnecessary APCS/AAPCS distinctions (now that Clang emits
byvals with the correct C ABI alignment), which simplified HandleByVal.

rdar://20095672

llvm-svn: 231959

No build failure, found by code inspection.

llvm-svn: 231958

Gather the function ranges [low_pc, high_pc) during DIE selection and
store them along with the offset to apply to them to get the linked
addresses.

This is just the data collection part, it comes with no tests. That
information will be used in multiple followup commits to perform the
relocation of line tables and range sections among other things, and
these commits will add tests.

llvm-svn: 231957

llvm-svn: 231956

DW_AT_low_pc on functions is taken care of by the relocation processing, but
DW_AT_high_pc and DW_AT_low_pc on other lexical scopes need special handling.

llvm-svn: 231955

classes.

llvm-svn: 231954

llvm-svn: 231953

This adds support for copy-constructor closures.  These are generated
when the C++ runtime has to call a copy-constructor with a particular
calling convention or with default arguments substituted in to the call.

Because the runtime has no mechanism to call the function with a
different calling convention or know-how to evaluate the default
arguments at run-time, we create a thunk which will do all the
appropriate work and package it in a way the runtime can use.

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

llvm-svn: 231952

we can inspect the subtarget and function when computing values.

llvm-svn: 231951

definition, be sure to update the definition data on all declarations, not just
the canonical one, since the pattern might not be in the list of pending
definitions (if it used to be canonical itself).

One-line fix by me; reduced testcase by Daniel Jasper!

llvm-svn: 231950

http://reviews.llvm.org/D8239

llvm-svn: 231949

This fixes a bug reported here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150309/265341.html

llvm-svn: 231948

[ASan/Win] Fix a CHECK failure when an exception is thrown from a callback passed to QueueUserWorkItem

llvm-svn: 231947

llvm-svn: 231946

This is a follow-up to r231182. This adds the "vbroadcasti128" instruction
back, but without the intrinsic mapping. Also add a test to check the
instriction encoding.

This is related to rdar://problem/18742778.

llvm-svn: 231945

(caused undesirable update of -std flag to use _Atomic)  

llvm-svn: 231942

Reviewed by: Alexander Kornienko

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

llvm-svn: 231941

This basically reverts the revert in r216508, and fixes a few more cases while
I'm at it. Reading my commit message on that commit again, I think it's bupkis.

http://reviews.llvm.org/D8237

llvm-svn: 231940

several projects. rdar://20120666.

llvm-svn: 231939

llvm-svn: 231938

On a new platform that I am working on
(https://github.com/NuxiNL/cloudlibc) I am not implementing the
cat{open,close,gets}() API, just like Android, Newlib, etc.

Instead of adding yet another operating system name to the #ifs,
introduce _LIBCPP_HAS_CATOPEN in include/__config. Also adjust the code
to only pull in nl_types.h when _LIBCPP_HAS_CATOPEN is set. We only
needed this header for the cat*() API.

Differential Revision:	http://reviews.llvm.org/D8163
Reviewed by:	marshall

llvm-svn: 231937

llvm-svn: 231936

Added restictions for atomic type usage from OpenCL C Spec Section 6.13.11.8

llvm-svn: 231935

Summary:
The generic ELF TargetObjectFile defaults to .ctors, but Linux's
defaults to .init_array by calling InitializeELF with the value of
UseInitArray from TargetMachine. Make NaCl's behavior match.

Reviewers: jvoung
Differential Revision: http://reviews.llvm.org/D8240

llvm-svn: 231934

llvm-svn: 231933

OpenCL C Spec v2.0 Section 6.13.11

- Made c11 _Atomic being accepted only for c11 compilations

- Implemented CL2.0 atomics by aliasing them to the corresponding c11 atomic types using implicit typedef

- Added diagnostics for atomics Khronos extension enabling

llvm-svn: 231932

These are the Clang-related changes for the instructions added to LLVM in http://reviews.llvm.org/D7959.

Phabricator review: http://reviews.llvm.org/D8041

llvm-svn: 231931