The alias to the array element is read-only and a primitive type (pointer),
therefore use the value directly instead of a reference to it.

llvm-svn: 281311

Step around a gcc pre-processor defect which causes it to fail to
parse the __has_include macro check.

llvm-svn: 281310

llvm-svn: 281309

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

llvm-svn: 281308

This patch extends readability-container-size-empty check allowing it to produce
warnings not only for STL containers, but also for containers, which provide two
functions matching following signatures:

* `size_type size() const;`
* `bool empty() const;`

Where `size_type` can be any kind of integer type.

This functionality was proposed in https://llvm.org/bugs/show_bug.cgi?id=26823
by Eugene Zelenko.

Approval: alexfh

Reviewers: alexfh, aaron.ballman, Eugene.Zelenko

Subscribers: etienneb, Prazek, hokein, xazax.hun, cfe-commits

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

llvm-svn: 281307

hwloop regression tests. These tests pass locally; will be investigating
where these differences come from.

llvm-svn: 281306

llvm-svn: 281305

descriptions now tag add instructions, and the Hexagon backend is using this to
identify loop induction statements.

Patch by Sam Parker and Sjoerd Meijer.

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

llvm-svn: 281304

This prevents a compiler crash.

llvm-svn: 281303

Optimized (truncate (assertzext x) to i1) and anyext i1 to i8/16/32.
Optimization of this patterns is a one more step towards i1 optimization on AVX-512.

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

llvm-svn: 281302

We currently return 4 for stackmaps and patchpoints, which is very optimistic
and can in rare cases cause the branch relaxation pass to fail to relax certain
branches.

This patch causes getInstSizeInBytes to return a pessimistic estimate of the
size as the number of bytes requested in the stackmap/patchpoint. In the future,
we could provide a more accurate estimate by sharing some of the logic in
AArch64::LowerSTACKMAP/PATCHPOINT.

Fixes part of https://llvm.org/bugs/show_bug.cgi?id=28750

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

llvm-svn: 281301

[X86] Remove masked shufpd/shufps intrinsics and autoupgrade to native vector shuffles. They were removed from clang previously but accidentally left in the backend.

llvm-svn: 281300

llvm-svn: 281299

llvm-svn: 281298

Patch by:	Alfred Perlstein <alfred@FreeBSD.org>

llvm-svn: 281297

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

llvm-svn: 281296

llvm-svn: 281295

Summary: This change adds "java" to the list of known extensions that clang-format supports.

Patch by Luis Hector Chavez

Reviewers: djasper

Subscribers: srhines, cfe-commits

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

llvm-svn: 281294

Original commit message:

Add -fdiagnostics-show-hotness

Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region.  This uses PGO and allows
filtering of the optimization remarks by relevance.  The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334

The general goal is to produce a YAML file with the remarks.  Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.

That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)

For the record, Hal has already expressed support for the idea of this
patch on IRC.

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

llvm-svn: 281293

This reverts r281290, as it breaks unit tests.
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/303

llvm-svn: 281292

the expectedFlakeyDarwin annotation.

I've been running this test in isolation on my macOS Sierra system
and haven't seen a failure in 20-30 runs.  The number of simultaneous
debug sessions that it spins up could be a problem when the testbots
are running under load, so I'm reducing this from 20 simultaneous
debug sessions to see if we can get enough stability to leave this
enabled.

llvm-svn: 281291

This should allow users of the library to get a range to iterate through
all the subcommands that are registered to the global parser. This
allows users to define subcommands in libraries that self-register to
have dispatch done at a different stage (like main). It allows for
writing code like the following:

    for (auto *S : cl::getRegisteredSubcommands()) {
      if (*S) {
	// Dispatch on S->getName().
      }
    }

This change also contains tests that show this usage pattern.

Reviewers: zturner, dblaikie, echristo

Subscribers: llvm-commits, mehdi_amini

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

llvm-svn: 281290

lld will use this to get the datalayout string and emit a
diagnostic if empty.

llvm-svn: 281289

in places where they help prevent leaks.

llvm-svn: 281288

llvm-svn: 281287

In c++1z, static_assert is not required to have a StringLiteral message, where
previously it was required.  Update the AST Reader to be able to handle a
null StringLiteral.

llvm-svn: 281286

Differential Revision: http://reviews.llvm.org/D20415

llvm-svn: 281285

This patch reverses the edge from DIGlobalVariable to GlobalVariable.
This will allow us to more easily preserve debug info metadata when
manipulating global variables.

Fixes PR30362. A program for upgrading test cases is attached to that
bug.

Differential Revision: http://reviews.llvm.org/D20147

llvm-svn: 281284

This should make it easier to add cases that we currently don't cover,
like supporting more kinds of type mismatches and more than 2 input vectors.

llvm-svn: 281283

Fix an issue where LLDB was not masking enough bits off of objc classes data() pointers, effectively rendering us unable to generate descriptors for some classes

Fixes rdar://27758358

llvm-svn: 281282

That confuses e.g. machine basic block placement, which then doesn't
realize that control can fall through a block that ends with a conditional
tail call. Instead, isBranch=1 should be set.

Also, mark EFLAGS as used by these instructions.

llvm-svn: 281281

Temporarily Revert "[MC] Defer asm errors to post-statement failure" as it's causing errors on the sanitizer bots.

This reverts commit r281249.

llvm-svn: 281280

This reverts commit r281276.

Many bots are failing.

llvm-svn: 281279

We should be doing the same checks when a type is completed as we do
when a complete type is used during emission. Previously, we duplicated
the logic, and it got out of sync. This could be observed with
dllimported classes.

Also reduce a test case for this slightly.

Implementing review feedback from David Blaikie on r281057.

llvm-svn: 281278

This patch makes us act more conservatively when trying to determine
the objectsize for an array at the end of an object. This is in
response to code like the following:

```
struct sockaddr {
  /* snip */
  char sa_data[14];
};

void foo(const char *s) {
  size_t slen = strlen(s) + 1;
  size_t added_len = slen <= 14 ? 0 : slen - 14;
  struct sockaddr *sa = malloc(sizeof(struct sockaddr) + added_len);
  strcpy(sa->sa_data, s);
  // ...
}
```

`__builtin_object_size(sa->sa_data, 1)` would return 14, when there
could be more than 14 bytes at `sa->sa_data`.

Code like this is apparently not uncommon. FreeBSD's manual even
explicitly mentions this pattern:
https://www.freebsd.org/doc/en/books/developers-handbook/sockets-essential-functions.html
(section 7.5.1.1.2).

In light of this, we now just give up on any array at the end of an
object if we can't find the object's initial allocation.

I lack numbers for how much more conservative we actually become as a
result of this change, so I chose the fix that would make us as
compatible with GCC as possible. If we want to be more aggressive, I'm
happy to consider some kind of whitelist or something instead.

llvm-svn: 281277

Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region.  This uses PGO and allows
filtering of the optimization remarks by relevance.  The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334

The general goal is to produce a YAML file with the remarks.  Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.

That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)

For the record, Hal has already expressed support for the idea of this
patch on IRC.

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

llvm-svn: 281276

llvm-svn: 281275

llvm-svn: 281274

Still to come:
1) SB API's
2) Testcases
3) Loose ends:
   a) serialize Thread options
   b) serialize Exception resolvers
4) "break list --file" should list breakpoints contained in a file and
   "break read -f 1 3 5" should then read in only those breakpoints.

<rdar://problem/12611863>

llvm-svn: 281273

Convert the previous introduced is-a relationship between the LVICache and LVIImple clases into a has-a relationship and hide all the implementation details of the cache from the lazy query layer.

The only slightly concerning change here is removing the addition of a queried block into the SeenBlock set in LVIImpl::getBlockValue.  As far as I can tell, this was effectively dead code.  I think it *used* to be the case that getCachedValueInfo wasn't const and might end up inserting elements in the cache during lookup.  That's no longer true and hasn't been for a while.  I did fixup the const usage to make that more obvious.

llvm-svn: 281272