------------------------------------------------------------------------
r312509 | dannyb | 2017-09-04 19:17:42 -0700 (Mon, 04 Sep 2017) | 1 line

NewGVN: Fix PR 34452 by passing instruction all the way down when we do aggregate value simplification
------------------------------------------------------------------------

llvm-svn: 319952

------------------------------------------------------------------------
r314733 | rsmith | 2017-10-02 15:43:36 -0700 (Mon, 02 Oct 2017) | 5 lines

PR33839: Fix -Wunused handling for structured binding declarations.

We warn about a structured binding declaration being unused only if none of its
bindings are used.

------------------------------------------------------------------------

llvm-svn: 319847

------------------------------------------------------------------------
r314107 | sylvestre | 2017-09-25 07:08:35 -0700 (Mon, 25 Sep 2017) | 9 lines

Fix clangd when built with LLVM_LINK_LLVM_DYLIB=ON

Reviewers: malaperle, malaperle-ericsson, bkramer

Reviewed By: bkramer

Subscribers: bkramer, mgorny, ilya-biryukov, cfe-commits

Differential Revision: https://reviews.llvm.org/D38228
------------------------------------------------------------------------

llvm-svn: 319846

------------------------------------------------------------------------
r311734 | ruiu | 2017-08-24 16:51:40 -0700 (Thu, 24 Aug 2017) | 44 lines

[MACH-O] Fix the ASM code generated for __stub_helpers section

Patch by Patricio Villalobos.

I discovered that lld for darwin is generating the wrong code for lazy
bindings in the __stub_helper section (at least for osx 10.12). This is
the way i can reproduce this problem, using this program:

  #include <stdio.h>

  int main(int argc, char **argv) {
      printf("C: printf!\n");
      puts("C: puts!\n");
      return 0;
  }

Then I link it using i have tested it in 3.9, 4.0 and 4.1 versions:

  $ clang -c hello.c
  $ lld -flavor darwin hello.o -o h1  -lc

When i execute the binary h1 the system gives me the following error:

  C: printf!
  dyld: lazy symbol binding failed:
  BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB
  has segment 4 which is too large (0..3)
  dyld: BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB has segment 4 which is too
  large (0..3)
  Trace/BPT trap: 5

Investigating the code, it seems that the problem is that the asm code
generated in the file StubPass.cpp, specifically in the line 323,when it
adds, what it seems an arbitrary number (12) to the offset into the lazy
bind opcodes section, but it should be calculated depending on the
MachONormalizedFileBinaryWrite::lazyBindingInfo result.

I confirmed this bug by patching the code manually in the binary and
writing the right offset in the asm code (__stub_helper).

This patch fixes the content of the atom that contains the assembly code
when the offset is known.

Differential Revision: https://reviews.llvm.org/D35387
------------------------------------------------------------------------

llvm-svn: 319825

We came across an llvm bug when compiling some testcases that 64-bit
immediates are silently truncated into 32-bit and then packed into
BPF_JMP | BPF_K encoding.  This caused comparison with wrong value.

This bug looks to be introduced by r308080 (llvm 5.0). The Select_Ri pattern is
supposed to be lowered into J*_Ri while the latter only support 32-bit
immediate encoding, therefore Select_Ri should have similar immediate
predicate check as what J*_Ri are doing.

The bug is fixed by
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315889

 91177308-0d34-0410-b5e6-96231b3b80d8
in llvm 6.0.

This patch is largely the same as the fix in llvm 6.0 except
one minor adjustment for the test case.

Reported-by: John Fastabend <john.fastabend@gmail.com>
Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
Reviewed-by: Yonghong Song <yhs@fb.com>
llvm-svn: 319633

------------------------------------------------------------------------
r316035 | tnorthover | 2017-10-17 14:43:52 -0700 (Tue, 17 Oct 2017) | 6 lines

AArch64: account for possible frame index operand in compares.

If the address of a local is used in a comparison, AArch64 can fold the
address-calculation into the comparison via "adds". Unfortunately, a couple of
places (both hit in this one test) are not ready to deal with that yet and just
assume the first source operand is a register.
------------------------------------------------------------------------

llvm-svn: 319231

------------------------------------------------------------------------
r319130 | matze | 2017-11-27 17:17:52 -0800 (Mon, 27 Nov 2017) | 7 lines

ARM: Fix PR32578

https://llvm.org/PR32578

I simplified and converted the reproducer into a lit test.

Patch by Vedant Kumar!
------------------------------------------------------------------------

llvm-svn: 319181

------------------------------------------------------------------------
r311456 | krasimir | 2017-08-22 07:28:01 -0700 (Tue, 22 Aug 2017) | 13 lines

[clang-format] Fix lines regression in clang-format.py

Summary:
This patch fixes a regression after https://reviews.llvm.org/rL305665,
which updates the structure of the `lines` variable.

Reviewers: djasper

Reviewed By: djasper

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D37011
------------------------------------------------------------------------

llvm-svn: 319179

------------------------------------------------------------------------
r318848 | hahnfeld | 2017-11-22 09:15:20 -0800 (Wed, 22 Nov 2017) | 7 lines

Fix for OMP doacross implementation on Power

Power has a weak consistency model so we need memory barriers to
make writes (both from runtime and from user code) available for
all threads.

Differential Revision: https://reviews.llvm.org/D40175
------------------------------------------------------------------------

llvm-svn: 319057

------------------------------------------------------------------------
r318658 | achurbanov | 2017-11-20 08:00:42 -0800 (Mon, 20 Nov 2017) | 4 lines

Fixed OMP doacross implementation on 32-bit platforms.

Differential Revision: https://reviews.llvm.org/D40171

------------------------------------------------------------------------

llvm-svn: 319053

------------------------------------------------------------------------
r316106 | labath | 2017-10-18 11:52:16 -0700 (Wed, 18 Oct 2017) | 4 lines

lldb-server tests: Fix undefined behavior

We were creating a StringRef pointing to a temporary string. Problem manifested
itself when running the test on osx.
------------------------------------------------------------------------

llvm-svn: 319035

------------------------------------------------------------------------
r316181 | jvesely | 2017-10-19 13:40:13 -0700 (Thu, 19 Oct 2017) | 4 lines

AMDGPU: Parse r600 CPU name early and expose FMAF capability

Improve amdgcn macro test
Differential Revision: https://reviews.llvm.org/D38667
------------------------------------------------------------------------

llvm-svn: 319032

------------------------------------------------------------------------
r313182 | sylvestre | 2017-09-13 13:03:29 -0700 (Wed, 13 Sep 2017) | 13 lines

SplitEmptyFunction should be true in the Mozilla coding style

Summary:
As defined here: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Classes
See for the downstream bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1399359

Reviewers: Typz, djasper

Reviewed By: Typz

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D37795
------------------------------------------------------------------------

llvm-svn: 318858

------------------------------------------------------------------------
r318788 | mcrosier | 2017-11-21 10:08:34 -0800 (Tue, 21 Nov 2017) | 16 lines

[AArch64] Mark mrs of TPIDR_EL0 (thread pointer) as *having* side effects.

This partially reverts r298851.  The the underlying issue is that we don't
currently model the dependency between mrs (read system register) and
msr (write system register) instructions.

Something like the below should never be reordered:

 msr TPIDR_EL0, x0  ;; set thread pointer
 mrs x8, TPIDR_EL0  ;; read thread pointer

but was being reordered after r298851.  The functional part of the patch
that wasn't reverted needed to remain in place in order to not break
r299462.

PR35317
------------------------------------------------------------------------

llvm-svn: 318854

------------------------------------------------------------------------
r315086 | compnerd | 2017-10-06 11:06:59 -0700 (Fri, 06 Oct 2017) | 8 lines

Bitcode: add an auto-upgrade for LTO section name

The bitcode reader looks specifically for `__DATA, __objc_catlist` as a
section name.  However, SVN r304661 removed the spaces (the two names
are functionally equivalent but do not compare equally
lexicographically).  This causes compatibility issues.  Add an
auto-upgrade path for removing the spaces as well as use the new name in
the LTO plugin.
------------------------------------------------------------------------

llvm-svn: 318851

------------------------------------------------------------------------
r313398 | steven_wu | 2017-09-15 14:12:14 -0700 (Fri, 15 Sep 2017) | 19 lines

[AutoUpgrade] Fix a compatibility issue with module flag

Summary:
After r304661, module flag to record objective-c image info section is
encoded without whitespaces after comma. The new name is equivalent to
the old one, except that when LTO a module built by old compiler and a
module built by a new compiler, it will fail with conflicting values.

Fix the issue by removing whitespaces in bitcode upgrade path.

rdar://problem/34416934

Reviewers: compnerd

Reviewed By: compnerd

Subscribers: mehdi_amini, hans, llvm-commits

Differential Revision: https://reviews.llvm.org/D37909
------------------------------------------------------------------------

llvm-svn: 318850

------------------------------------------------------------------------
r318039 | labath | 2017-11-13 06:03:17 -0800 (Mon, 13 Nov 2017) | 37 lines

Revert "[lldb] Use OrcMCJITReplacement rather than MCJIT as the underlying JIT for LLDB"

This commit really did not introduce any functional changes (for most
people) but it turns out it's not for the reason we thought it was.

The reason wasn't that Orc is a perfect drop-in replacement for MCJIT,
but it was because we were never using Orc in the first place, as it was
not initialized.

Orc's initialization relies on a global constructor in the LLVMOrcJIT.a.
Since this archive does not expose any symbols referenced from other
object files, it does not get linked into liblldb when linking against
llvm components statically. However, in an LLVM_LINK_LLVM_DYLIB=On
build, LLVMOrcJit.a is linked into libLLVM.so using --whole-archive, so
the global constructor does end up firing.

The result of using Orc jit is pr34194, where lldb fails to evaluate
even very simple expressions. This bug can be reproduced in
non-LLVM_LINK_LLVM_DYLIB builds by making sure Orc jit is linked into
liblldb, for example by #including
llvm/ExecutionEngine/OrcMCJITReplacement.h in IRExecutionUnit.cpp (and
adding OrcJIT as a dependency to the relevant CMakeLists.txt file). The
bug reproduces (at least) on linux and osx.

The root cause of the bug seems to be related to relocation processing.
It seems Orc processes relocations earlier than the system it is
replacing. This means the relocation processing happens before we have
had a chance to remap section load addresses to reflect their address in
the target process memory, so they end up pointing to locations in the
lldb's address space instead.

I am not sure whether this is a bug in Orc jit, or in how we are using
it from lldb, but in any case it is preventing us from using Orc right
now. Reverting this fixes LLVM_LINK_LLVM_DYLIB build, and makes it clear
that we are in fact *not* using Orc, and we never really were.

This reverts commit r279327.
------------------------------------------------------------------------

llvm-svn: 318845

------------------------------------------------------------------------
r315994 | ericwf | 2017-10-17 06:03:17 -0700 (Tue, 17 Oct 2017) | 18 lines

[libc++] Fix PR34898 - vector iterator constructors and assign method perform push_back instead of emplace_back.

Summary:
The constructors `vector(Iter, Iter, Alloc = Alloc{})` and `assign(Iter, Iter)` don't correctly perform EmplaceConstruction from the result of dereferencing the iterator. This results in them performing an additional and unneeded copy.

This patch addresses the issue by correctly using `emplace_back` in C++11 and newer.

There are also some bugs in our `insert` implementation, but those will be handled separately.

@mclow.lists We should probably merge this into 5.1, agreed?

Reviewers: mclow.lists, dlj, EricWF

Reviewed By: mclow.lists, EricWF

Subscribers: cfe-commits, mclow.lists

Differential Revision: https://reviews.llvm.org/D38757
------------------------------------------------------------------------

llvm-svn: 318837

------------------------------------------------------------------------
r312892 | ericwf | 2017-09-10 16:41:20 -0700 (Sun, 10 Sep 2017) | 10 lines

Fix PR34298 - Allow std::function with an incomplete return type.

This patch fixes llvm.org/PR34298. Previously libc++ incorrectly evaluated
the __invokable trait via the converting constructor `function(Tp)` [with Tp = std::function]
whenever the copy constructor or copy assignment operator
was required. This patch further constrains that constructor to short
circut before evaluating the troublesome SFINAE when `Tp` matches
std::function.

The original patch is from Alex Lorenz.
------------------------------------------------------------------------

llvm-svn: 318835

------------------------------------------------------------------------
r318289 | jdevlieghere | 2017-11-15 02:57:05 -0800 (Wed, 15 Nov 2017) | 14 lines

[DebugInfo] Fix potential CU mismatch for SubprogramScopeDIEs.

In constructAbstractSubprogramScopeDIE there can be a potential mismatch
between `this` and the CU of ContextDIE when a scope is shared between
two DISubprograms belonging to a different CU. In that case, `this` is
the CU that was specified in the IR, but the CU of ContextDIE is that of
the first subprogram that was emitted. This patch fixes the mismatch by
looking up the CU of ContextDIE, and switching to use that.

This fixes PR35212 (https://bugs.llvm.org/show_bug.cgi?id=35212)

Patch by Philip Craig!

Differential revision: https://reviews.llvm.org/D39981
------------------------------------------------------------------------

llvm-svn: 318542

------------------------------------------------------------------------
r318207 | sdardis | 2017-11-14 22:26:42 +0000 (Tue, 14 Nov 2017) | 18 lines

Reland "[mips][mt][6/7] Add support for mftr, mttr instructions."

This adjusts the tests to hopfully pacify the
llvm-clang-x86_64-expensive-checks-win buildbot.

Unlike many other instructions, these instructions have aliases which
take coprocessor registers, gpr register, accumulator (and dsp accumulator)
registers, floating point registers, floating point control registers and
coprocessor 2 data and control operands.

For the moment, these aliases are treated as pseudo instructions which are
expanded into the underlying instruction. As a result, disassembling these
instructions shows the underlying instruction and not the alias.

Reviewers: slthakur, atanasyan

Differential Revision: https://reviews.llvm.org/D35253

------------------------------------------------------------------------

llvm-svn: 318386

------------------------------------------------------------------------
r312748 | jroelofs | 2017-09-07 15:01:25 -0700 (Thu, 07 Sep 2017) | 10 lines

Fix validation of the -mthread-model flag in the Clang driver

The ToolChain class validates the -mthread-model flag in the constructor which
doesn't work correctly since the thread model methods are virtual methods. The
check is moved into Clang::ConstructJob() when constructing the internal
command line.

https://reviews.llvm.org/D37496

Patch by: Ian Tessier!
------------------------------------------------------------------------

llvm-svn: 318346

------------------------------------------------------------------------
r312043 | rnk | 2017-08-29 14:44:21 -0700 (Tue, 29 Aug 2017) | 25 lines

[cmake] Stop putting the revision info in LLVM_VERSION_STRING

Summary:
This reduces the number of build actions after a no-op commit from
thousands to about six, which should be acceptable. If six actions is
still too many, developers can disable the LLVM_APPEND_VC_REV cmake
option.

llvm-config.h is a widely included header that should rarely change.
Before this patch, it would change after every re-configure. Very few
users of llvm-config.h need to know the precise version, and those that
do can migrate to incorporating LLVM_REVISION as provided by
llvm/Support/VCSRevision.h.

This should bring LLVM back to the behavior that it had before r306858
from June 30 2017. Most LLVM tools will now print a version string like
"6.0.0svn" instead of "6.0.0-git-c40c2a23de4".

Fixes PR34308

Reviewers: pcc, rafael, hans

Subscribers: mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D37272
------------------------------------------------------------------------

llvm-svn: 318344

------------------------------------------------------------------------
r310475 | belleyb | 2017-08-09 06:47:01 -0700 (Wed, 09 Aug 2017) | 28 lines

[Support] PR33388 - Fix formatv_object move constructor

formatv_object currently uses the implicitly defined move constructor,
but it is buggy. In typical use-cases, the problem doesn't show-up
because all calls to the move constructor are elided. Thus, the buggy
constructors are never invoked.

The issue especially shows-up when code is compiled using the
-fno-elide-constructors compiler flag. For instance, this is useful when
attempting to collect accurate code coverage statistics.

The exact issue is the following:

The Parameters data member is correctly moved, thus making the
parameters occupy a new memory location in the target
object. Unfortunately, the default copying of the Adapters blindly
copies the vector of pointers, leaving each of these pointers
referencing the parameters in the original object instead of the copied
one. These pointers quickly become dangling when the original object is
deleted. This quickly leads to crashes.

The solution is to update the Adapters pointers when performing a move.
The copy constructor isn't useful for format objects and can thus be
deleted.

This resolves PR33388.

Differential Revision: https://reviews.llvm.org/D34463
------------------------------------------------------------------------

llvm-svn: 318333

------------------------------------------------------------------------
r315578 | abataev | 2017-10-12 06:51:32 -0700 (Thu, 12 Oct 2017) | 7 lines

[OPENMP] Fix PR34925: Fix getting thread_id lvalue for inlined regions
in C.

If we try to get the lvalue for thread_id variables in inlined regions,
we did not use the correct version of function. Fixed this bug by adding
overrided version of the function getThreadIDVariableLValue for inlined
regions.
------------------------------------------------------------------------

llvm-svn: 318315

------------------------------------------------------------------------
r313776 | marshall | 2017-09-20 10:34:11 -0700 (Wed, 20 Sep 2017) | 1 line

Fix a bit of UB in __independent_bits_engine. Fixes PR#34663
------------------------------------------------------------------------

llvm-svn: 318236

------------------------------------------------------------------------
r315464 | abataev | 2017-10-11 08:29:40 -0700 (Wed, 11 Oct 2017) | 5 lines

[OPENMP] Fix PR34916: Crash on mixing taskloop|tasks directives.

If both taskloop and task directives are used at the same time in one
program, we may ran into the situation when the particular type for task
directive is reused for taskloop directives. Patch fixes this problem.
------------------------------------------------------------------------

llvm-svn: 318233

------------------------------------------------------------------------
r310905 | rnk | 2017-08-14 18:17:47 -0700 (Mon, 14 Aug 2017) | 11 lines

Avoid PointerIntPair of constexpr EvalInfo structs

They are stack allocated, so their alignment is not to be trusted.
32-bit MSVC only guarantees 4 byte stack alignment, even though alignof
would tell you otherwise. I tried fixing this with __declspec align, but
that apparently upsets GCC. Hopefully this version will satisfy all
compilers.

See PR32018 for some info about the mingw issues.

Should supercede https://reviews.llvm.org/D34873
------------------------------------------------------------------------

------------------------------------------------------------------------
r310994 | chandlerc | 2017-08-16 00:22:49 -0700 (Wed, 16 Aug 2017) | 6 lines

Fix a UBSan failure where this boolean was copied when uninitialized.

When r310905 moved the pointer and bool out of a PointerIntPair, it made
them end up uninitialized and caused UBSan failures when copying the
uninitialized boolean. However, making the pointer be null should avoid
the reference to the boolean entirely.
------------------------------------------------------------------------

llvm-svn: 318225

------------------------------------------------------------------------
r315310 | sdardis | 2017-10-10 06:34:45 -0700 (Tue, 10 Oct 2017) | 22 lines

[mips] Partially fix PR34391

Previously, the parsing of the 'subu $reg, ($reg,) imm' relied on a parser
which also rendered the operand to the instruction. In some cases the
general parser could construct an MCExpr which was not a MCConstantExpr
which MipsAsmParser was expecting.

Address this by altering the special handling to cope with unexpected inputs
and fine-tune the handling of cases where an register name that is not
available in the current ABI is regarded as not a match for the custom parser
but also not as an outright error.

Also enforces the binutils restriction that only constants are accepted.

This partially resolves PR34391.

Thanks to Ed Maste for reporting the issue!

Reviewers: nitesh.jain, arichardson

Differential Revision: https://reviews.llvm.org/D37476

------------------------------------------------------------------------

llvm-svn: 318192

------------------------------------------------------------------------
r317204 | sdardis | 2017-11-02 05:47:22 -0700 (Thu, 02 Nov 2017) | 15 lines

[mips] Use register scavenging with MSA.

MSA stores and loads to the stack are more likely to require an
emergency GPR spill slot due to the smaller offsets available
with those instructions.

Handle this by overestimating the size of the stack by determining
the largest offset presuming that all callee save registers are
spilled and accounting of incoming arguments when determining
whether an emergency spill slot is required.

Reviewers: atanasyan

Differential Revision: https://reviews.llvm.org/D39056

------------------------------------------------------------------------

------------------------------------------------------------------------
r318172 | sdardis | 2017-11-14 11:11:45 -0800 (Tue, 14 Nov 2017) | 5 lines

[mips] Simplify test for 5.0.1 (NFC)

Simplify testing that an emergency spill slot is used when MSA
is used so that it can be included in the 5.0.1 release.

------------------------------------------------------------------------

llvm-svn: 318191

------------------------------------------------------------------------
r317470 | sdardis | 2017-11-06 02:50:04 -0800 (Mon, 06 Nov 2017) | 12 lines

[mips] Fix PR35140

Mark all symbols involved with TLS relocations as being TLS symbols.

This resolves PR35140.

Thanks to Alex Crichton for reporting the issue!

Reviewers: atanasyan

Differential Revision: https://reviews.llvm.org/D39591

------------------------------------------------------------------------

llvm-svn: 318188

------------------------------------------------------------------------
r314798 | sdardis | 2017-10-03 06:45:49 -0700 (Tue, 03 Oct 2017) | 9 lines

[mips] Enable spilling and reloading of the dsp register set.

The dsp register class is an alias of the gpr register class, so
we have to define instructions for spilling and reloading.

Reviewers: atanasyan

Differential Revision: https://reviews.llvm.org/D38038

------------------------------------------------------------------------

llvm-svn: 318183

------------------------------------------------------------------------
r310543 | pcc | 2017-08-09 18:07:44 -0700 (Wed, 09 Aug 2017) | 9 lines

Linker: Create a function declaration when moving a non-prevailing alias of function type.

We were previously creating a global variable of function type,
which is invalid IR. This issue was exposed by r304690, in which we
started asserting that global variables were of a valid type.

Fixes PR33462.

Differential Revision: https://reviews.llvm.org/D36438
------------------------------------------------------------------------

llvm-svn: 318181

------------------------------------------------------------------------
r310522 | belleyb | 2017-08-09 13:58:39 -0700 (Wed, 09 Aug 2017) | 8 lines

[Linker] PR33527 - Linker::LinkOnlyNeeded should import AppendingLinkage globals

Linker::LinkOnlyNeeded should always import globals with
AppendingLinkage.

This resolves PR33527.

Differential Revision: https://reviews.llvm.org/D34448
------------------------------------------------------------------------

llvm-svn: 318180

------------------------------------------------------------------------
r317115 | jlpeyton | 2017-11-01 12:44:42 -0700 (Wed, 01 Nov 2017) | 19 lines

[OpenMP] Fix race condition in omp_init_lock

This is a partial fix for bug 34050.

This prevents callers of omp_set_lock (which does not hold __kmp_global_lock)
from ever seeing an uninitialized version of __kmp_i_lock_table.table.

It does not solve a use-after-free race condition if omp_set_lock obtains a
pointer to __kmp_i_lock_table.table before it is updated and then attempts to
dereference afterwards. That race is far less likely and can be handled in a
separate patch.

The unit test usually segfaults on the current trunk revision. It passes with
the patch.

Patch by Adam Azarchs

Differential Revision: https://reviews.llvm.org/D39439

------------------------------------------------------------------------

llvm-svn: 318178

------------------------------------------------------------------------
r316452 | jlpeyton | 2017-10-24 09:10:09 -0700 (Tue, 24 Oct 2017) | 9 lines

Disable threadprivate data cleanup if runtime is terminating

The problem is due to the runtime's threadprivate cleanup code which tries to
access data that was already destroyed by one of the root threads.
__kmp_init_gtid is used as a checker here since it is set to false before actual
resource cleanup is done in __kmp_cleanup().

Patch by Hansang Bae

------------------------------------------------------------------------

llvm-svn: 318176

------------------------------------------------------------------------
r311269 | jlpeyton | 2017-08-19 16:53:36 -0700 (Sat, 19 Aug 2017) | 8 lines

Use va_copy instead of __va_copy to fix building libomp against musl libc

Fixes https://bugs.llvm.org/show_bug.cgi?id=34040

Patch by Peter Levine

Differential Revision: https://reviews.llvm.org/D36343

------------------------------------------------------------------------

llvm-svn: 318175

------------------------------------------------------------------------
r309875 | jlpeyton | 2017-08-02 13:06:32 -0700 (Wed, 02 Aug 2017) | 11 lines

Move lock acquire/release functions in task deque cleanup code

The original locations can be reached without initializing the lock variable
(td_deque_lock), so it is potentially unsafe.  It is guaranteed that the lock
is initialized if the deque (td_deque) is not NULL, and lock functions can be
safely called.

Patch by Hansang Bae

Differential Revision: https://reviews.llvm.org/D36017

------------------------------------------------------------------------

llvm-svn: 318171

------------------------------------------------------------------------
r313278 | prazek | 2017-09-14 10:33:08 -0700 (Thu, 14 Sep 2017) | 11 lines

Enable __declspec(selectany) on any platform

Summary:
This feature was disabled probably by mistake in rL300562
This fixes bug https://bugs.llvm.org/show_bug.cgi?id=33285

Reviewers: davide, rnk

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D33852
------------------------------------------------------------------------

llvm-svn: 318133

------------------------------------------------------------------------
r315611 | abataev | 2017-10-12 13:03:39 -0700 (Thu, 12 Oct 2017) | 5 lines

[OPENMP] Fix PR34927: Emit initializer for reduction array with declare
reduction.

If the reduction is an array or an array section and reduction operation
is declare reduction without initializer, it may lead to crash.
------------------------------------------------------------------------

llvm-svn: 318120