llvm-svn: 303911

llvm-svn: 303910

llvm-svn: 303909

This reverts commit r303861, the LLVM intrinsic was reverted.

llvm-svn: 303908

lldb: libedit produces garbled, unusable input on Linux

Apply patch from Christos Zoulas, upstream libedit developer.
It has been tested on NetBSD/amd64.

New code supports combination of wide libedit and disabled
LLDB_EDITLINE_USE_WCHAR, which was the popular case on Linux
systems.

llvm-svn: 303907

llvm-svn: 303906

llvm-svn: 303905

PPC::GETtlsADDR is lowered to a branch and a nop, by the assembly
printer. Its size was incorrectly marked as 4, correct it to 8. The
incorrect size can cause incorrect branch relaxation in
PPCBranchSelector under the right conditions.

llvm-svn: 303904

This tests optimized code where a variable is allocated on the
stack for some part of the function.

llvm-svn: 303903

llvm-svn: 303902

Summary:
This is used in the Linux kernel, and effectively just means "print an
address". This brings back r193593.

Reviewed by: Renato Golin

Reviewers: t.p.northover, rengolin, richard.barton.arm, kristof.beyls

Subscribers: aemerson, javed.absar, llvm-commits, eraman

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

llvm-svn: 303901

Thanks to Casey Carter for pointing out the out-of-date tests and
implementation.

llvm-svn: 303900

llvm-svn: 303899

llvm-svn: 303898

This fixes an oversight in r300522, which changed alloca
dbg.values to no longer emit a DW_OP_deref.

The array.ll testcase was regenerated from source.

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

llvm-svn: 303897

llvm-svn: 303896

This patch updates the promise() member to match the current spec.
Specifically it removes the non-const overload and make the return
type of the const overload non-const.

This patch also makes the ASSERT_NOT_NOEXCEPT tests libc++ specific,
since other implementations may be free to strengthen the specification.

llvm-svn: 303895

DebugInfo: Produce debug_{gnu_}pub{names,types} entries when explicitly requested, even in -gmlt or when empty

Turns out gold doesn't use the DW_AT_GNU_pubnames to decide whether to
parse the rest of the DIEs when building gdb-index. This causes gold to
trip over LLVM's output when there are DW_FORM_ref_addr present.

Gold does use the presence of a debug_gnu_pub{names,types} entry for the
CU to skip parsing the debug_info portion, so make sure that's included
even when empty (technically, when empty there couldn't be any ref_addr
anyway - it only came up when gmlt didn't produce any (even non-empty)
pubnames - but given what that reveals about gold's implementation, this
seems like a good thing to do for consistency).

llvm-svn: 303894

llvm-svn: 303893

Reviewers: eugenis

Subscribers: llvm-commits, kubamracek

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

llvm-svn: 303892

Summary:
Previously, the yaml2pdb subcommand of llvm-pdbdump only
included object file names in module info if a module info stream was
present. This change makes it so that we include the object file name
even if there is no module info stream for the module. As a result,
running
llvm-pdbdump pdb2yaml -dbi-module-info original.pdb > original.yaml &&
llvm-pdbdump yaml2pdb -pdb=new.pdb original.yaml && llvm-pdbdump
pdb2yaml -dbi-module-info new.pdb > new.yaml now produces identical
original.yaml and new.yaml files.

Reviewers: amccarth, zturner

Reviewed By: zturner

Subscribers: fhahn, llvm-commits

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

llvm-svn: 303891

If you pass /delayload:<dllname> to the COFF linker, it creates thunks
so that DLLs are loaded when they are used for the first time instead of
load-time.

This mechanism do not work for data symbols as there's no way to trap
acccesses to data imported from DLLs. (Technically, I think if we do not
initially map dllimport tables in memory, we could actually trap accesses
and delay-load data symbols, but that's not what Windows do.)

This patch is to report an error when you try to delay-load data symbols.

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

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

llvm-svn: 303890

VSO#391542 "Types can't be convertible to nullptr_t"

Also put internal bug numbers on the workarounds in test_workarounds.h for correlation.

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

llvm-svn: 303889

VSO#109062 "Explicit template argument specification with empty template parameter pack expansion does not imply further empty pack expansion"

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

llvm-svn: 303888

Summary:
This required for any users who call exit() after creating
thread-specific data, as tls destructors are only called when
pthread_exit() or pthread_cancel() are used. This should also
match tls behavior on linux.

Getting the base address of the tls section is straightforward,
as it's stored as a section offset in %gs. The size is a bit trickier
to work out, as there doesn't appear to be any official documentation
or source code referring to it. The size used in this patch was determined
by taking the difference between the base address and the address of the
subsequent memory region returned by vm_region_recurse_64, which was
1024 * sizeof(uptr) on all threads except the main thread, where it was
larger. Since the section must be the same size on all of the threads,
1024 * sizeof(uptr) seemed to be a reasonable size to use, barring
a more programtic way to get the size.

1024 seems like a reasonable number, given that PTHREAD_KEYS_MAX
is 512 on darwin, so pthread keys will fit inside the region while
leaving space for other tls data. A larger size would overflow the
memory region returned by vm_region_recurse_64, and a smaller size
wouldn't leave room for all the pthread keys. In addition, the
stress test added here passes, which means that we are scanning at
least the full set of possible pthread keys, and probably
the full tls section.

Reviewers: alekseyshl, kubamracek

Subscribers: krytarowski, llvm-commits

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

llvm-svn: 303887

The existing implementation ran CHECKs to assert that the thread state
was stored inside the tls. However, the mac implementation of tsan doesn't
store the thread state in tls, so these checks fail once darwin tls support
is added to the sanitizers. Only run these checks on platforms where
the thread state is expected to be contained in the tls.

llvm-svn: 303886

llvm-svn: 303885

llvm-svn: 303884

Summary:
Apparently Windows's `UnmapOrDie` doesn't support partial unmapping. Which
makes the new region allocation technique not Windows compliant.

Reviewers: alekseyshl, dvyukov

Reviewed By: alekseyshl

Subscribers: llvm-commits, kubamracek

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

llvm-svn: 303883

llvm-svn: 303882

is also being reverted.

llvm-svn: 303881

When lld isn't built, the tests as they were previously, were too picky about
the path to the linker.

llvm-svn: 303880

Summary:
Currently, AllocateRegion has a tendency to fragment memory: it allocates
`2*kRegionSize`, and if the memory is aligned, will unmap `kRegionSize` bytes,
thus creating a hole, which can't itself be reused for another region. This
is exacerbated by the fact that if 2 regions get allocated one after another
without any `mmap` in between, the second will be aligned due to mappings 
generally being contiguous.

An idea, suggested by @alekseyshl, to prevent such a behavior is to have a
stash of regions: if the `2*kRegionSize` allocation is properly aligned, split
it in two, and stash the second part to be returned next time a region is
requested.

At this point, I thought about a couple of ways to implement this:
 - either an `IntrusiveList` of regions candidates, storing `next` at the
   begining of the region;
 - a small array of regions candidates existing in the Primary.

While the second option is more constrained in terms of size, it offers several
advantages:
 - security wise, a pointer in a region candidate could be overflowed into, and
   abused when popping an element;
 - we do not dirty the first page of the region by storing something in it;
 - unless several threads request regions simultaneously from different size
   classes, the stash rarely goes above 1 entry.

I am not certain about the Windows impact of this change, as `sanitizer_win.cc`
has its own version of MmapAlignedOrDie, maybe someone could chime in on this.

MmapAlignedOrDie is effectively unused after this change and could be removed
at a later point. I didn't notice any sizeable performance gain, even though we
are saving a few `mmap`/`munmap` syscalls.

Reviewers: alekseyshl, kcc, dvyukov

Reviewed By: alekseyshl

Subscribers: llvm-commits, kubamracek

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

llvm-svn: 303879

llvm-svn: 303878

llvm-svn: 303877

Mark LWG#2900 as complete - we already do this, and I checked the tests in a couple days ago (r303268 & r303824)

llvm-svn: 303876

Fix PR33120 and others by eliminating self-cycles a different way.

llvm-svn: 303875

Fixes PR27566.

Differential revision: https://reviews.llvm.org/D30837

llvm-svn: 303874

Also comes with a cmake cache for building the runtime bits:

 $ cmake <normal cmake flags> \
   -DBAREMETAL_ARMV6M_SYSROOT=/path/to/sysroot \
   -DBAREMETAL_ARMV7M_SYSROOT=/path/to/sysroot \
   -DBAREMETAL_ARMV7EM_SYSROOT=/path/to/sysroot \
   -C /path/to/clang/cmake/caches/BaremetalARM.cmake \
   /path/to/llvm

https://reviews.llvm.org/D33259

llvm-svn: 303873

MSVC doesn't support C++ operator names (using 'or' instead of ||, 
'not' instead of '!', etc), so this was disabled in MSVC mode in r303798.
This fixes the regression noticed on the buildbots.

llvm-svn: 303872