debug info metadata

... when generating DWARF.

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

llvm-svn: 325234

Summary:
As a consequence, all LSP operations are now handled asynchronously,
i.e. they never block the main processing thread. However, if
-run-synchronously flag is specified, clangd still runs everything on
the main thread.

Reviewers: sammccall, ioeric, hokein

Reviewed By: sammccall, ioeric

Subscribers: klimek, jkorous-apple, cfe-commits

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

llvm-svn: 325233

This is mainly a move of simplifyShuffleOperands from DAGCombiner::visitVECTOR_SHUFFLE to create a more general purpose TargetLowering::SimplifyDemandedVectorElts implementation.

Further features can be moved/added in future patches.

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

llvm-svn: 325232

This adds f16 VCMP match rules and fixes the test cases.

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

llvm-svn: 325228

It caused fails on some buildbots.

llvm-svn: 325227

llvm-svn: 325226

llvm-svn: 325225

Analysis of fails in the case of out of memory errors can be tricky on
Windows. Such error emerges at the point where memory allocation function
fails, but manifests itself when null pointer is used. These two points
may be distant from each other. Besides, next runs may not exhibit
allocation error.

Usual programming practice does not require checking result of 'operator
new' because it throws 'std::bad_alloc' in the case of allocation error.
However, LLVM is usually built with exceptions turned off, so 'new' can
return null pointer. This change installs custom new handler, which causes
fatal error in the case of out of memory. The handler is installed
automatically prior to call to 'main' during construction of a static
object defined in 'lib/Support/ErrorHandling.cpp'. If the application does
not use this file, the handler may be installed manually by a call to
'llvm::install_out_of_memory_new_handler', declared in
'include/llvm/Support/ErrorHandling.h".

There are calls to C allocation functions, malloc, calloc and realloc.
They are used for interoperability with C code, when allocated object has
variable size and when it is necessary to avoid call of constructors. In
many calls the result is not checked against null pointer. To simplify
checks, new functions are defined in the namespace 'llvm' with the
same names as these C function. These functions produce fatal error if
allocation fails. User should use 'llvm::malloc' instead of 'std::malloc'
in order to use the safe variant. This change replaces 'std::malloc'
in the cases when the result of allocation function is not checked against
null pointer.

Finally, there are plain C code, that uses malloc and similar functions. If
the result is not checked, assert statements are added.

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

llvm-svn: 325224

llvm-svn: 325223

Patch by: Kristof Umann

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

llvm-svn: 325222

Summary: Detect ObjC characteristic types when they start a line and add additional keywords.

Reviewers: benhamilton

Reviewed By: benhamilton

Subscribers: klimek, cfe-commits

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

llvm-svn: 325221

Summary:
The chrome trace viewer requires events within a thread to strictly nest.
So we need to record the lifetime of the Span objects, not the contexts.

But we still want to show the relationship between spans where a context crosses
threads, so do this with flow events (i.e. arrows).

Before: https://photos.app.goo.gl/q4Dd9u9xtelaXk1v1
After: https://photos.app.goo.gl/5RNLmAMLZR3unvY83

(This could stand some further improvement, in particular I think we want a
container span whenever we schedule work on a thread. But that's another patch)

Reviewers: ioeric

Subscribers: klimek, ilya-biryukov, jkorous-apple, cfe-commits

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

llvm-svn: 325220

GlobalISel doesn't yet implement blockaddress and falls back to
SelectionDAG. This results in additional branch instruction to
the next basic block which breaks the OMPT tests.
Disable GlobalISel for now when compiling the tests because fixing
them is not easily possible. See http://llvm.org/PR36313 for full
discussion history.

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

llvm-svn: 325218

llvm-svn: 325217

llvm-svn: 325216

llvm-svn: 325215

There is a more powerful but still simple function `isKnownViaSimpleReasoning ` that
does constant range check and few more additional checks. We use it some places (e.g.
when proving implications) and in some other places we only check constant ranges.

Currently, indvar simplifier fails to remove the check in following loop:

  int inc = ...;
  for (int i = inc, j = inc - 1; i < 200; ++i, ++j)
    if (i > j) { ... }

This patch replaces all usages of `isKnownPredicateViaConstantRanges` with
`isKnownViaSimpleReasoning` to have smarter proofs. In particular, it fixes the
case above.

Reviewed-By: sanjoy
Differential Revision: https://reviews.llvm.org/D43175

llvm-svn: 325214

This also makes the behavior close to GNU ld's.

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

llvm-svn: 325213

Summary:
Introduce handling of 1200 NetBSD specific ioctl(2) calls.
Over 100 operations are disabled as unavailable or conflicting
with the existing ones (the same operation number).

Add a script that generates the rules to detect ioctls on NetBSD.
The generate_netbsd_ioctls.awk script has been written
in NetBSD awk(1) (patched nawk) and is compatible with gawk.

Generate lib/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc
with the awk(1) script.

Update sanitizer_platform_limits_netbsd accordingly to add the needed
definitions.

Sponsored by <The NetBSD Foundation>

Reviewers: joerg, vitalybuka, eugenis, dvyukov

Reviewed By: vitalybuka

Subscribers: kubamracek, llvm-commits, mgorny, fedor.sergeev, #sanitizers

Tags: #sanitizers

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

llvm-svn: 325212

Since r325210, in cfg-temporary-dtors mode, we can rely on the CFG to tell us
that we're indeed constructing a temporary, so we can trivially construct a
temporary region and inline the constructor.

Much like r325202, this is only done under the off-by-default
cfg-temporary-dtors flag because the temporary destructor, even if available,
will not be inlined and won't have the correct object value (target region).
Unless this is fixed, it is quite unsafe to inline the constructor.

If the temporary is lifetime-extended, the destructor would be an automatic
destructor, which would be evaluated with a "correct" target region - modulo
the series of incorrect relocations performed during the lifetime extension.
It means that at least, values within the object are guaranteed to be properly
escaped or invalidated.

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

llvm-svn: 325211

Constructors of C++ temporary objects that have destructors now can be queried
to discover that they're indeed constructing temporary objects.

The respective CXXBindTemporaryExpr, which is also repsonsible for destroying
the temporary at the end of full-expression, is now available at the
construction site in the CFG. This is all the context we need to provide for
temporary objects that are not lifetime extended. For lifetime-extended
temporaries, more context is necessary.

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

llvm-svn: 325210

EvalCallOptions were introduced in r324018 for allowing various parts of
ExprEngine to notify the inlining mechanism, while preparing for evaluating a
function call, of possible difficulties with evaluating the call that they
foresee. Then mayInlineCall() would still be a single place for making the
decision.

Use that mechanism for destructors as well - pass the necessary flags from the
CFG-element-specific destructor handlers.

Part of this patch accidentally leaked into r324018, which led into a change in
tests; this change is reverted now, because even though the change looked
correct, the underlying behavior wasn't. Both of these commits were not intended
to introduce any function changes otherwise.

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

llvm-svn: 325209

Summary:
This corrects intercepting this call on NetBSD without false positives.

Sponsored by <The NetBSD Foundation>

Reviewers: joerg, eugenis, vitalybuka

Reviewed By: vitalybuka

Subscribers: llvm-commits, #sanitizers

Tags: #sanitizers

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

llvm-svn: 325208

Summary:
This corrects intercepting this call on NetBSD without false positives.

Sponsored by <The NetBSD Foundation>

Reviewers: joerg, eugenis, vitalybuka

Reviewed By: vitalybuka

Subscribers: llvm-commits, #sanitizers

Tags: #sanitizers

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

llvm-svn: 325207

Summary:
Implement the skeleton of NetBSD syscall hooks for use with sanitizers.

Add a script that generates the rules to handle syscalls
on NetBSD: generate_netbsd_syscalls.awk. It has been written
in NetBSD awk(1) (patched nawk) and is compatible with gawk.

Generate lib/sanitizer_common/sanitizer_platform_limits_netbsd.h
that is a public header for applications, and included as:
<sanitizer_common/sanitizer_platform_limits_netbsd.h>.

Generate sanitizer_syscalls_netbsd.inc that defines all the
syscall rules for NetBSD. This file is modeled after the Linux
specific file: sanitizer_common_syscalls.inc.

Start recognizing NetBSD syscalls with existing sanitizers:
ASan, ESan, HWASan, TSan, MSan.

Sponsored by <The NetBSD Foundation>

Reviewers: joerg, vitalybuka, kcc, dvyukov, eugenis

Reviewed By: vitalybuka

Subscribers: hintonda, kubamracek, mgorny, llvm-commits, #sanitizers

Tags: #sanitizers

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

llvm-svn: 325206

llvm-svn: 325205

When we are emitting a relocatable output, we should keep the original
symbol name including "@" part. Previously, we drop that part unconditionally
which resulted in dropping versions from symbols.

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

llvm-svn: 325204

llvm-svn: 325203

This only affects the cfg-temporary-dtors mode - in this mode we begin inlining
constructors that are constructing function return values. These constructors
have a correct construction context since r324952.

Because temporary destructors are not only never inlined, but also don't have
the correct target region yet, this change is not entirely safe. But this
will be fixed in the subsequent commits, while this stays off behind the
cfg-temporary-dtors flag.

Lifetime extension for return values is still not modeled correctly.

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

llvm-svn: 325202

In CFG, every DeclStmt has exactly one decl, which is always a variable.

It is also pointless to check that the initializer is the constructor because
that's how construction contexts work now.

llvm-svn: 325201

llvm-svn: 325200

Summary:
lstat - get file status

Use it on NetBSD.

Sponsored by <The NetBSD Foundation>

Reviewers: joerg, vitalybuka, eugenis

Reviewed By: vitalybuka

Subscribers: kubamracek, llvm-commits, #sanitizers

Tags: #sanitizers

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

llvm-svn: 325199

These must have not been printing the last time the test was re-generated.

llvm-svn: 325198

This matches the Intel and AMD documentation and is consistent with the LAR instruction.

llvm-svn: 325197

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

llvm-svn: 325196

llvm-svn: 325195

Seems tests fails if link already exists.
Also removed duplicated part of tests.

llvm-svn: 325194

- Insert __AMD__ macro
- Insert __AMDGPU__ macro
- Insert __devicename__ macro
- Add missing tests for arch macros

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

llvm-svn: 325193

The match would be ambiguous, but at&t asm parsing doesn't support ambiguous matches and will just return the first.

llvm-svn: 325192

llvm-svn: 325191