[doc] [CUDA] Add sections about STL support and differences between nvcc and clang to CompileCudaWithLLVM.rst.

llvm-svn: 281573

llvm-svn: 281570

This keeps them from conflicting with other symbols names, so it's
worth their being less convenient to use for indexing.

llvm-svn: 281569

llvm-svn: 281568

'weak' doesn't behave like it does on linux.

llvm-svn: 281567

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 281566

Just use lgamma_r and ignore the value returned in the second argument

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 281565

Ported from the amd-builtins branch, which is itself based on the
Sun Microsystems implementation.

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 281564

This macro is currently unused, but I plan to use it shortly.

The previous form did casts of pointers without an address space, which
doesn't work so well for CL 1.x.

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 281563

This patch causes a couple of issues:

1) It triggers http://llvm.org/PR30341. Although the bug is not truly a libc++
bug it breaks the LLVM build using libc++. Reverting this patch is only
a temporary workaround until Clang is fixed.

2) It adds yet another ABI incompatibility when libc++.so is compiled with GCC.
Specifically GCC doesn't ignore the _LIBCPP_INLINE_VISIBILITY on the out-of-line
definition when compiling the dylib. This causes the externally instantiated
~basic_string symbol to have hidden visibility.

This patch should be recommitted after addressing (1) and (2). (2) can be fixed
by adding _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY which is defined as
__attribute__((visibility("default"), always_inline)) as opposed to
_LIBCPP_INLINE_VISIBILITY which makes the symbol hidden.

llvm-svn: 281562

The pattern matching and transforms are identical; the cmp predicate just changes.

llvm-svn: 281561

llvm-svn: 281560

llvm-svn: 281559

llvm-svn: 281558

Commit was breaking our internal tests.

llvm-svn: 281557

The `CVType` had two redundant fields which were confusing and
error-prone to fill out.  By treating member records as a distinct
type from leaf records, we are able to simplify this quite a bit.

Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D24432

llvm-svn: 281556

This completes being able to write all the interesting
values of a PDB TPI stream.

Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D24370

llvm-svn: 281555

Summary:
This fixes a dumpbin warning on objects produced by the MC assembler
when starting from text. All .debug$S sections are supposed to be marked
IMAGE_SCN_MEM_DISCARDABLE. The main, non-COMDAT .debug$S section had
this set, but any comdat ones were not being marked discardable because
there was no .section flag for it.

This change does two things:

- If the section name starts with .debug, implicitly mark the section as
  discardable. This means we do the same thing as gas on .s files with
  DWARF from GCC, which is important.

- Adds the 'D' flag to the .section directive on COFF to explicitly say
  a section is discardable. We only emit this flag if the section name
  does not start with .debug. This allows the user to explicitly tweak
  their section flags without worrying about magic section names.

The only thing you can't do in this scheme is to create a
non-discardable section with a name starting with ".debug", but
hopefully users don't need that.

Reviewers: majnemer, rafael

Subscribers: llvm-commits

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

llvm-svn: 281554

llvm-svn: 281553

lib/Tooling injects this argument without regard for what driver syntax
is in use.

llvm-svn: 281550

If TBAA is on an intrinsic and it gets upgraded, it'll delete the call
instruction that we collected in a vector. Even if we were to use
WeakVH, it'll drop the TBAA and we'll hit the assert on the upgrade
path.

r263673 gave a shot to make sure the TBAA upgrade happens before
intrinsics upgrade, but failed to account for all cases.

Instead of collecting instructions in a vector, this patch makes it
just upgrade the TBAA on the fly, because metadata are always
already loaded at this point.

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

llvm-svn: 281549

llvm-svn: 281548

[asan] add heap_profile=1 to asan to periodically print the heap profile. So far this is a very basic heap-profile functionality

llvm-svn: 281546

llvm-svn: 281545

Summary:
We need to add a bunch more "using"s, which weren't necessary with
libstdc++.

Once this is in I can check in a test to the test-suite.

Reviewers: tra

Subscribers: cfe-commits

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

llvm-svn: 281544

[CUDA] Add test checking our ability to take a function pointer to a __global__ function on the host side.

Summary: This functionality is used by Thrust.

Reviewers: tra

Subscribers: cfe-commits

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

llvm-svn: 281543

llvm-svn: 281542

Reviewers: thakis, compnerd, majnemer, rsmith, rnk

Subscribers: alexshap, cfe-commits

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

llvm-svn: 281540

llvm-svn: 281539

Previously the prevailing information was not honored, and commons
symbols could override a strong definition. This patch fixes it and
propose the following semantic for commons: the client should mark
as prevailing the commons that it expects the LTO implementation to
merge (i.e. take the maximum size and alignment).
It implies that commons are allowed to have multiple prevailing
definitions.

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

llvm-svn: 281538

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

llvm-svn: 281537

Thanks to Zachary Turner for the suggestion.  It's distasteful that the actual
type of the lambda can't be spelled out, but it should be evident from the
definition of the lambda body.

llvm-svn: 281536

llvm-svn: 281535

llvm-svn: 281534

Makes the device strangely unstable, and fails one sanitizer_common test.

llvm-svn: 281533

Summary:
It was previously not possible for tools to use solely the stackmap
information emitted to reconstruct the return addresses of callsites in
the map, which is necessary to use the information to walk a stack. This
patch adds per-function callsite counts when emitting the stackmap
section in order to resolve the problem. Note that this slightly alters
the stackmap format, so external tools parsing these maps will need to
be updated.

**Problem Details:**
Records only store their offset from the beginning of the function they
belong to. While these records and the functions are output in program
order, it is not possible to determine where the end of one function's
records are without the callsite count when processing the records to
compute return addresses.

Patch by Kavon Farvardin!

Reviewers: atrick, ributzka, sanjoy

Subscribers: nemanjai

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

llvm-svn: 281532

llvm-svn: 281531

Summary: This reverts r281527 because I messed up the attribution.

Reviewers: srhines

Subscribers: cfe-commits

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

llvm-svn: 281530

llvm-svn: 281529

Reviewers: labath, clayborg, zturner

Subscribers: lldb-commits

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

llvm-svn: 281528