git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318530 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
The ArgumentsAdjuster returned from `getClangStripDependencyFileAdjuster` will
skip dependency flags, and also their associated values for those flags that
take an argument. This change corrects the handling of the `-MD` and `-MMD`
flags, which do not take an argument.

Reviewers: saugustine, klimek, alexshap

Reviewed By: alexshap

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318529 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: Adds text proto filename detection.

Reviewers: klimek

Reviewed By: klimek

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318525 91177308-0d34-0410-b5e6-96231b3b80d8

For each line that we break in a protruding token, compute whether the
penalty of breaking is actually larger than the penalty of the excess
characters. Only break if that is the case.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318515 91177308-0d34-0410-b5e6-96231b3b80d8

To fix standalone builds broken by r318411 (config.h is private to llvm).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318514 91177308-0d34-0410-b5e6-96231b3b80d8

Since SVN r318510, the MinGW/ARM configuration defaults to
dwarf exception handling.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318511 91177308-0d34-0410-b5e6-96231b3b80d8

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/13565

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318507 91177308-0d34-0410-b5e6-96231b3b80d8

When mixing PCH and Implicit Modules, missing a header search path
can lead to the implicit built PCM to complaint about not finding its
matching module map.

Instead of adding more magic to implicit modules engine, add a note to
help the user add the appropriate path.

rdar://problem/33388847

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318503 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
__builtin_nexttoward lowers to a libcall, e.g. nexttowardf(), that CUDA
does not have.

Rather than try to implement it, we simply remove these functions --
nvcc doesn't support them either, and nextafter, which does work, does
essentially the same thing on GPUs, because GPUs don't have long double.

Reviewers: tra

Subscribers: cfe-commits, sanjoy

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318494 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318491 91177308-0d34-0410-b5e6-96231b3b80d8

This is still broken because it causes certain tests to be
run twice with slightly different configurations, which is
wrong in some cases.

You can observe this by running:

  ninja -nv check-all | grep debuginfo-tests

And seeing that it passes clang/test and clang/test/debuginfo-tests
to lit, which causes it to run debuginfo-tests twice.  The fix is
going to involve either:

  a) figuring out that we're running in this "deprecated" configuration,
     and then deleting the clang/test/debuginfo-tests path, which should
     cause it to behave identically to before, or:
  b) make lit smart enough that it doesn't descend into a sub-suite if
     that sub-suite already has a lit.cfg file.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318486 91177308-0d34-0410-b5e6-96231b3b80d8

explicitly instantiated, still emit it with each use.

We don't emit a definition of the member with an explicit instantiation
definition (and indeed it appears that we're not allowed to, since an explicit
instantiation definition does not constitute an odr-use and only odr-use
permits definition for defaulted special members). So we still need to emit a
weak definition with each use.

This also makes defaulted-in-class declarations behave more like
implicitly-declared special members, which matches their design intent.
And it matches the way this problem was solved in GCC.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318474 91177308-0d34-0410-b5e6-96231b3b80d8

This looks like it was just an oversight.

Fixes http://llvm.org/pr35319

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318456 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
In https://reviews.llvm.org/D39572 , I added support for specifying
`Type` when invoking `InMemoryFileSystem::addFile()`.

However, I didn't account for the fact that when `Type` is
`directory_file`, we need to construct an `InMemoryDirectory`, not an
`InMemoryFile`, or else clients cannot create files inside that
directory.

This diff fixes the bug and adds a test.

Test Plan: New test added. Ran test with:

  % make -j12 check-clang-tools

Reviewers: bkramer, hokein

Reviewed By: bkramer

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318445 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
The MS ABI convention is that the 'this' pointer on entry is the address
of the vfptr that was used to make the virtual method call. In other
words, the pointer on entry always points to the base subobject that
introduced the virtual method. Consider this hierarchy:

  struct A { virtual void f() = 0; };
  struct B { virtual void g() = 0; };
  struct C : A, B {
    void f() override;
    void g() override;
  };

On entry to C::g, [ER]CX will contain the address of C's B subobject,
and C::g will have to subtract sizeof(A) to recover a pointer to C.

Before this change, we applied this adjustment in the prologue and
stored the new value into the "this" local variable alloca used for
debug info. However, MSVC does not do this, presumably because it is
often profitable to fold the adjustment into later field accesses. This
creates a problem, because the debugger expects the variable to be
unadjusted. Unfortunately, CodeView doesn't have anything like DWARF
expressions for computing variables that aren't in the program anymore,
so we have to declare 'this' to be the unadjusted value if we want the
debugger to see the right value.

This has the side benefit that, in optimized builds, the 'this' pointer
will usually be available on function entry because it doesn't require
any adjustment.

Reviewers: hans

Subscribers: aprantl, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318440 91177308-0d34-0410-b5e6-96231b3b80d8

This was reverted due to some failures on specific darwin buildbots,
the issue being that the new lit configuration was not setting the
SDKROOT environment variable.  We've tested a fix locally and confirmed
that it works, so this patch resubmits everything with the fix
applied.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318435 91177308-0d34-0410-b5e6-96231b3b80d8

directive.

Added missed support for cancelling of target parallel for construct.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318434 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318414 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
These preambles are built by ASTUnit and clangd. Previously, preambles
were always stored on disk.

In-memory preambles are routed back to the compiler as virtual files in
a custom VFS.

Interface of ASTUnit does not allow to use in-memory preambles, as
ASTUnit::CodeComplete receives FileManager as a parameter, so we can't
change VFS used by the compiler inside the CodeComplete method.

A follow-up commit will update clangd in clang-tools-extra to use
in-memory preambles.

Reviewers: klimek, sammccall, bkramer

Reviewed By: klimek

Subscribers: ioeric, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318411 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318371 91177308-0d34-0410-b5e6-96231b3b80d8

Patch by Nikolai Kosjar!

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318367 91177308-0d34-0410-b5e6-96231b3b80d8

Patch by Nikolai Kosjar!

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318365 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318347 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318345 91177308-0d34-0410-b5e6-96231b3b80d8

A first step toward removing the repetition of
features/CPU info in the x86 target info, this
patch pulls all the processor information out into
its own .def file.

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



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318343 91177308-0d34-0410-b5e6-96231b3b80d8

[AST, Sema] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318341 91177308-0d34-0410-b5e6-96231b3b80d8

The number of 'built-in candidate' notes now varies since __float128 may
or may not be a candidate depending on the target.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318314 91177308-0d34-0410-b5e6-96231b3b80d8

In the PR, Clang ended up in a situation where it tried to mangle the
__float128 type, which isn't supported when targetingt MSVC, because
Clang instantiated a variable template with that type when searching for
a conversion to use in an arithmetic expression.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318309 91177308-0d34-0410-b5e6-96231b3b80d8

Internal linkage variables ODR referenced from inline functions create
ODR violations (the same inline function ends up having different
definitions in each TU, since it references different variables - rather
than one definition).

This also happens to break modular code generation - so this is the last
fix to allow clang to compile with modular code generation.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318304 91177308-0d34-0410-b5e6-96231b3b80d8

Fixes PR33745.

Patch by Nikolai Kosjar!

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318292 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Constant samplers are handled as static variables and clang's code generation
library, which leads to llvm::unreachable. We bypass emitting sampler variable
as static since it's translated to a function call later.

Reviewers: yaxunl, Anastasia

Reviewed By: yaxunl, Anastasia

Subscribers: cfe-commits

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318290 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318286 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318274 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318258 91177308-0d34-0410-b5e6-96231b3b80d8

When we merge together class definitions, we can end up with the canonical
declaration of a field not being the one that was lexically within the
canonical definition of the class. Additionally, when we merge class
definitions via update records (eg, for a template specialization whose
declaration is instantiated in one module and whose definition is instantiated
in multiple others), we can end up with the list of lexical contents for the
class not including a particular declaration of a field whose lexical parent is
that class definition. In the worst case, we have a field whose canonical
declaration's lexical parent has no fields, and in that case this attempt to
number the fields by walking the fields in the declaration of the class that
contained one of the canonical fields will fail.

Instead, when numbering fields in a class, do the obvious thing: walk the
fields in the definition.

I'm still trying to reduce a testcase; the setup that leads to the above
scenario seems to be quite fragile.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318245 91177308-0d34-0410-b5e6-96231b3b80d8

LLVM exposes a file in the backend (X86TargetParser.def) that
contains information about the correct list of CpuIs values.

This patch removes 2 of the copied and pasted versions of this
list from clang and instead includes the data from the .def file.

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318234 91177308-0d34-0410-b5e6-96231b3b80d8

Lifting from Bob Wilson's notes: The hash value that we compute and
store in PGO profile data to detect out-of-date profiles does not
include enough information. This means that many significant changes to
the source will not cause compiler warnings about the profile being out
of date, and worse, we may continue to use the outdated profile data to
make bad optimization decisions.  There is some tension here because
some source changes won't affect PGO and we don't want to invalidate the
profile unnecessarily.

This patch adds a new hashing scheme which is more sensitive to loop
nesting, conditions, and out-of-order control flow. Here are examples
which show snippets which get the same hash under the current scheme,
and different hashes under the new scheme:

Loop Nesting Example
--------------------

  // Snippet 1
  while (foo()) {
    while (bar()) {}
  }

  // Snippet 2
  while (foo()) {}
  while (bar()) {}

Condition Example
-----------------

  // Snippet 1
  if (foo())
    bar();
  baz();

  // Snippet 2
  if (foo())
    bar();
  else
    baz();

Out-of-order Control Flow Example
---------------------------------

  // Snippet 1
  while (foo()) {
    if (bar()) {}
    baz();
  }

  // Snippet 2
  while (foo()) {
    if (bar())
      continue;
    baz();
  }

In each of these cases, it's useful to differentiate between the
snippets because swapping their profiles gives bad optimization hints.

The new hashing scheme considers some logical operators in an effort to
detect more changes in conditions. This isn't a perfect scheme. E.g, it
does not produce the same hash for these equivalent snippets:

  // Snippet 1
  bool c = !a || b;
  if (d && e) {}

  // Snippet 2
  bool f = d && e;
  bool c = !a || b;
  if (f) {}

This would require an expensive data flow analysis. Short of that, the
new hashing scheme looks reasonably complete, based on a scan over the
statements we place counters on.

Profiles which use the old version of the PGO hash remain valid and can
be used without issue (there are tests in tree which check this).

rdar://17068282

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318229 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318221 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318216 91177308-0d34-0410-b5e6-96231b3b80d8

We would like to extract the full call when just the callee function is
selected


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318215 91177308-0d34-0410-b5e6-96231b3b80d8