Build failed in
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/27258

In lib/CodeGen/LiveDebugVariables.cpp:589, it uses std::prev(MBBI) to
get DebugValue's SlotIndex. however, the previous instruction may be
also a debug instruction.

llvm-svn: 338992

Generate DILabel metadata and call llvm.dbg.label after label
statement to associate the metadata with the label.

After fixing PR37395.

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

llvm-svn: 338989

Summary:
Optimization remark format is slightly changed by LLVM patch D49412.
Two tests are fixed with expected messages changed.
Frankly speaking I have not tested this change yet. I will test when manage to setup the project.

Reviewers: xbolva00

Reviewed By: xbolva00

Subscribers: mehdi_amini, eraman, steven_wu, dexonsmith

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

llvm-svn: 338971

When a non-extended temporary object is created in a conditional branch, the
lifetime of that temporary ends outside the conditional (at the end of the
full-expression). If we're inserting lifetime markers, this means we could end
up generating

  if (some_cond) {
    lifetime.start(&tmp);
    Tmp::Tmp(&tmp);
  }
  // ...
  if (some_cond) {
    lifetime.end(&tmp);
  }

... for a full-expression containing a subexpression of the form `some_cond ?
Tmp().x : 0`. This patch moves the lifetime start for such a temporary out of
the conditional branch so that we don't need to generate an additional basic
block to hold the lifetime end marker.

This is disabled if we want precise lifetime markers (for asan's
stack-use-after-scope checks) or of the temporary has a non-trivial destructor
(in which case we'd generate an extra basic block anyway to hold the destructor
call).

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

llvm-svn: 338945

__builtin_memmove (in non-type-punning cases).

This is intended to permit libc++ to make std::copy etc constexpr
without sacrificing the optimization that uses memcpy on
trivially-copyable types.

__builtin_strcpy and __builtin_wcscpy are not handled by this change.
They'd be straightforward to add, but we haven't encountered a need for
them just yet.

This reinstates r338455, reverted in r338602, with a fix to avoid trying
to constant-evaluate a memcpy call if either pointer operand has an
invalid designator.

llvm-svn: 338941

Just do not generate the note at all in that case.

llvm-svn: 338935

Libc++ needs to know when aligned allocation is supported by clang, but is
otherwise unavailable at link time. Otherwise, libc++ will incorrectly end up
generating calls to `__builtin_operator_new`/`__builtin_operator_delete` with
alignment arguments.

This patch implements the following changes:

* The `__cpp_aligned_new` feature test macro to no longer be defined when
  aligned allocation is otherwise enabled but unavailable.

* The Darwin driver no longer passes `-faligned-alloc-unavailable` when the
  user manually specifies `-faligned-allocation` or `-fno-aligned-allocation`.

* Instead of a warning Clang now generates a hard error when an aligned
  allocation or deallocation function is referenced but unavailable.

Patch by Eric Fiselier.

Reviewers: rsmith, vsapsai, erik.pilkington, ahatanak, dexonsmith

Reviewed By: rsmith

Subscribers: Quuxplusone, cfe-commits

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

llvm-svn: 338934

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

llvm-svn: 338931

Do not crash if a CXXRecordDecl cannot be obtained for an object.

Special thanks for the reproduction to Alexander Kornienko.

llvm-svn: 338918

Encoding offload target triples onto comdat group key for offload initialization
code guarantees that it will be executed once per each unique combination of
offload targets.

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

llvm-svn: 338916

Properly add shared locks to the initial list of locks being tracked, instead of assuming unlock functions always use exclusive locks.

Patch by Aaron Puchert.

llvm-svn: 338912

This reverts commit r338899, it was causing ASan test failures on sanitizer-x86_64-linux-fast.

llvm-svn: 338904

Ensures the statically sized alloca is not converted to DYNAMIC_STACKALLOC
later because it is not in the entry block.

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

llvm-svn: 338899

- Testcase attempts to (not) grep 'g0' in output to ensure asm symbol is
  properly renamed, but g0 is too generic and can be part of the
  module's path in LLVM IR output.
- Changed to grep '@g0', which is what the proper global symbol name
  would be if not using asm.

llvm-svn: 338895

Summary:
This adds support to libclang for reading the flag_enum attribute.

This also bumps CINDEX_VERSION_MINOR for this patch series.

Reviewers: yvvan, jbcoe

Reviewed By: yvvan

Subscribers: cfe-commits

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

llvm-svn: 338820

Summary: This allows libclang to access the actual names of property setters and getters without needing to go through the indexer API. Usually default names are used, but the property can specify a different name.

Reviewers: yvvan, jbcoe

Reviewed By: yvvan

Subscribers: cfe-commits

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

llvm-svn: 338816

Summary:
Having access to implicit attributes is sometimes useful so users of libclang don't have to duplicate some of the logic in sema.

This depends on D49081 since it also adds a CXTranslationUnit flag.

Reviewers: yvvan, jbcoe

Reviewed By: yvvan

Subscribers: cfe-commits

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

llvm-svn: 338815

Summary:
This adds support to libclang for identifying ObjC related attributes that don't take arguments.

All attributes but NSObject and NSConsumed are tested.

Reviewers: yvvan, jbcoe

Reviewed By: yvvan

Subscribers: cfe-commits

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

llvm-svn: 338813

Summary:
Emit !llvm.mem.parallel_loop_access metadata for memory accesses even if the parallel loop is not the top on the loop stack.

Fixes llvm.org/PR37558.

Reviewers: ABataev, hfinkel, amusman, tyler.nowicki

Reviewed By: hfinkel

Subscribers: Meinersbur, hfinkel, cfe-commits

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

llvm-svn: 338810

Summary:
This patch adds a clang-c API for querying the nullability of an AttributedType.

The test here also tests D49081

Reviewers: yvvan, jbcoe

Reviewed By: yvvan

Subscribers: cfe-commits

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

llvm-svn: 338809

Summary:
This patch adds support to the libclang API for identifying ObjCTypeParams in CXTypes.

This patch depends on D49063 since both patches add new values to CXTypeKind.

Reviewers: yvvan, jbcoe

Reviewed By: yvvan

Subscribers: cfe-commits

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

llvm-svn: 338807

Explicit cast of a void pointer to a pointer type in different address space is
incorrectly classified as bitcast, which causes invalid bitcast in codegen.

The patch fixes that by checking the address space of the source and destination
type and set the correct cast kind.

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

llvm-svn: 338805

Summary: This patch adds support to the clang-c API for identifying ObjCObjects in CXTypes, enumerating type args and protocols on ObjCObjectTypes, and retrieving the base type of ObjCObjectTypes. Currently only ObjCInterfaceTypes are exposed, which do not have type args or protocols.

Reviewers: yvvan, jbcoe

Reviewed By: yvvan

Subscribers: cfe-commits

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

llvm-svn: 338804

Recommit of r335084 after revert in r335516.

... instead of prepending it at the beginning (the original behavior
since implemented in r122535 2010-12-23). This builds up an
AttributeList in the the order in which the attributes appear in the
source.

The reverse order caused nodes for attributes in the AST (e.g. LoopHint)
to be in the reverse order, and therefore printed in the wrong order in
-ast-dump. Some TODO comments mention this. The order was explicitly
reversed for enable_if attribute overload resolution and name mangling,
which is not necessary anymore with this patch.

The change unfortunately has some secondary effect, especially on
diagnostic output. In the simplest cases, the CHECK lines or expected
diagnostic were changed to the the new output. If the kind of
error/warning changed, the attributes' order was changed instead.

This unfortunately causes some 'previous occurrence here' hints to be
textually after the main marker. This typically happens when attributes
are merged, but are incompatible to each other. Interchanging the role
of the the main and note SourceLocation will also cause the case where
two different declaration's attributes (in contrast to multiple
attributes of the same declaration) are merged to be reverse. There is
no easy fix because sometimes previous attributes are merged into a new
declaration's attribute list, sometimes new attributes are added to a
previous declaration's attribute list. Since 'previous occurrence here'
pointing to locations after the main marker is not rare, I left the
markers as-is; it is only relevant when the attributes are declared in
the same declaration anyway.

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

llvm-svn: 338800

We can't read a deduced return type until we are sure that the types referred
to by it are not in the middle of being loaded. So defer all reading of such
deduced return types until the end of the recursive deserialization step.

Also, when we load a function type that has a deduced return type, update all
other redeclarations of the function to have that deduced return type.

llvm-svn: 338798

Objects local to a function are destroyed right after the statement returning
(part of) them is executed in the analyzer. This patch enables MallocChecker to
warn in these cases.

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

llvm-svn: 338780

The CoreEngine only gives us a ReturnStmt if the last element in the
CFGBlock is a CFGStmt, otherwise the ReturnStmt is nullptr.
This patch adds support for the case when the last element is a
CFGAutomaticObjDtor, by returning its TriggerStmt as a ReturnStmt.

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

llvm-svn: 338777

Summary:
Add support for atomic.wait / atomic.wake builtins based on the Wasm
thread proposal.

Reviewers: dschuff

Subscribers: sbc100, jgravelle-google, sunfish, cfe-commits

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

llvm-svn: 338771

llvm-svn: 338766

llvm-svn: 338756

llvm-svn: 338754

Summary:
C++11 onwards specs the non-member functions atomic_load and atomic_load_explicit as taking the atomic<T> by const (potentially volatile) pointer. C11, in its infinite wisdom, decided to drop the const, and C17 will fix this with DR459 (the current draft forgot to fix B.16, but that’s not the normative part).

clang’s lib/Headers/stdatomic.h implements these as #define to the __c11_* equivalent, which are builtins with custom typecheck. Fix the typecheck.

D47613 takes care of the libc++ side.

Discussion: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058129.html

<rdar://problem/27426936>

Reviewers: rsmith

Subscribers: cfe-commits

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

llvm-svn: 338743

The way address space declarations for builtins currently work
is nearly useless. The code assumes the address spaces used for
builtins is a confusingly named "target address space" from user
code using __attribute__((address_space(N))) that matches
the builtin declaration. There's no way to use this to declare
a builtin that returns a language specific address space.
The terminology used is highly cofusing since it has nothing
to do with the the address space selected by the target to use
for a language address space.

This feature is essentially unused as-is. AMDGPU and NVPTX
are the only in-tree targets attempting to use this. The AMDGPU
builtins certainly do not behave as intended (i.e. all of the
builtins returning pointers can never compile because the numbered
address space never matches the expected named address space).

The NVPTX builtins are missing tests for some, and the others
seem to rely on an implicit addrspacecast.

Change the used address space for builtins based on a target
hook to allow using a language address space for a builtin.
This allows the same builtin declaration to be used for multiple
languages with similarly purposed address spaces (e.g. the same
AMDGPU builtin can be used in OpenCL and CUDA even though the
constant address spaces are arbitarily different).

This breaks the possibility of using arbitrary numbered
address spaces alongside the named address spaces for builtins.
If this is an issue we probably need to introduce another builtin
declaration character to distinguish language address spaces from
so-called "target address spaces".

llvm-svn: 338707

rdar://39701823

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

llvm-svn: 338667

This is a follow-up to r338656.

llvm-svn: 338664

I forgot to commit this in r326530.

llvm-svn: 338656

As pointed out by Richard Smith in post-review of r338489.

llvm-svn: 338640

Fix %hmaptool path to refer to clang_tools_dir instead of
llvm_tools_dir, in order to fix standalone builds.  The tool is built
as part of clang, so it won't be found in installed LLVM tools.

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

llvm-svn: 338627

Summary:
Android's memory allocators also guarantee 8-byte alignment for 32-bit
architectures and 16-byte alignment for 64-bit.

Reviewers: rsmith

Subscribers: cfe-commits, srhines, enh

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

llvm-svn: 338603

Revert r338455 "[constexpr] Support for constant evaluation of __builtin_memcpy and __builtin_memmove (in non-type-punning cases)."

It caused asserts during Chromium builds, see reply on the cfe-commits thread.

> This is intended to permit libc++ to make std::copy etc constexpr
> without sacrificing the optimization that uses memcpy on
> trivially-copyable types.
>
> __builtin_strcpy and __builtin_wcscpy are not handled by this change.
> They'd be straightforward to add, but we haven't encountered a need for
> them just yet.

llvm-svn: 338602