Shadow uses need to be analyzed together, since each individual shadow
will only have a partial reaching def. All shadows together may cover
a given register ref, while each individual shadow may not.

llvm-svn: 280855

Summary:
Make sure that windows libraries contain the suffixes expected by clang.
This is expecially important when compiling the windows builtins with
clang, as cmake will use .a as the suffix by default.

Reviewers: beanz, compnerd

Subscribers: llvm-commits, dberris

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

llvm-svn: 280854

llvm-svn: 280853

llvm-svn: 280852

llvm-svn: 280851

llvm-svn: 280850

CUDA is an extension to C++ -- there is no such thing as "CUDA C".  But
also, the language is much more commonly called "CUDA" than "CUDA C++".

llvm-svn: 280849

llvm-svn: 280848

r280553 introduced an issue where we'd emit ambiguity errors for code
like:

```
void foo(int *, int);
void foo(unsigned int *, unsigned int);

void callFoo() {
  unsigned int i;
  foo(&i, 0); // ambiguous: int->unsigned int is worse than int->int,
              // but unsigned int*->unsigned int* is better than
              // int*->int*.
}
```

This patch fixes this issue by changing how we handle ill-formed (but
valid) implicit conversions. Candidates with said conversions now always
rank worse than candidates without them, and two candidates are
considered to be equally bad if they both have these conversions for
the same argument.

Additionally, this fixes a case in C++11 where we'd complain about an
ambiguity in a case like:

```
void f(char *, int);
void f(const char *, unsigned);
void g() { f("abc", 0); }
```

...Since conversion to char* from a string literal is considered
ill-formed in C++11 (and deprecated in C++03), but we accept it as an
extension.

llvm-svn: 280847

Previous patch added a #if which caused a variable and function
to be unused.

llvm-svn: 280846

- Should diag on a function (clang-cl warns; it's an error in cl)
- Test the attribute on nested classes (clang-cl is more permissive and more
  self-consistent than cl here)

llvm-svn: 280845

Over-zealous cleanup of using statements removed some that were
actually needed.  Also cleaned up a few warnings.

llvm-svn: 280844

Add PR number and comment in pr30298.ll to explain what is testing.

llvm-svn: 280843

There is a bug causing pch to be validated even though -fno-validate-pch is set. This patch fixes it.

ASTReader relies on ASTReaderListener to initialize SuggestedPredefines, which is required for compilations using PCH. Before this change, PCHValidator is the default ASTReaderListener. After this change, when -fno-validate-pch is set, PCHValidator is disabled, but we need a replacement ASTReaderListener to initialize SuggestedPredefines. Class SimpleASTReaderListener is implemented for this purpose.

This change only affects -fno-validate-pch. There is no functional change if -fno-validate-pch is not set.

If -fno-validate-pch is not set, conflicts in predefined macros between pch and current compiler instance causes error.

If -fno-validate-pch is set, predefine macros in current compiler override those in pch so that compilation can continue.

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

llvm-svn: 280842

llvm-svn: 280841

For now this only adds the UI necessary to configure clang-tidy
settings graphically, and it enables reading in and saving out
of .clang-tidy files.  It does not actually run clang-tidy on
any source files yet.

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

llvm-svn: 280840

This was originally reverted because the patch on the clang
tooling side was reverted.  That patch is being resubmitted,
so this patch is resubmitted as well.

llvm-svn: 280839

Summary:
C++1z 6.4.1/p2:
 If the if statement is of the form if constexpr, the value of the
 condition shall be a contextually converted constant expression of type
 bool [...]
C++1z 5.20/p4:
 [...] A contextually converted constant expression of type bool is an
 expression, contextually converted to bool (Clause4), where the
 converted expression is a constant expression and the conversion
 sequence contains only the conversions above. [...]

Contextually converting result of an expression `e` to a Boolean value
requires `bool t(e)` to be well-formed.

An explicit conversion function is only considered as a user-defined
conversion for direct-initialization, which is essentially what
//contextually converted to bool// requires.

Also, fixes PR28470.

Reviewers: rsmith

Subscribers: cfe-commits

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

llvm-svn: 280838

The patch is to fix PR30298, which is caused by rL272694. The solution is to
bail out if the target has no SSE2.

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

llvm-svn: 280837

Move the logic for doing this from the ABI argument lowering into
EmitParmDecl, which runs for all parameters. Our codegen is slightly
suboptimal in this case, as we may leave behind a dead store after
optimization, but it's 32-bit inalloca, and this fixes the bug in a
robust way.

Fixes PR30293

llvm-svn: 280836

llvm-svn: 280835

llvm-svn: 280834

The original commit was too aggressive about marking LibCalls as AAPCS.  The
libcalls contain libc/libm/libunwind calls which are not AAPCS, but C.

llvm-svn: 280833

When branching to a block that immediately tail calls, it is possible to fold
the call directly into the branch if the call is direct and there is no stack
adjustment, saving one byte.

Example:

  define void @f(i32 %x, i32 %y) {
  entry:
    %p = icmp eq i32 %x, %y
    br i1 %p, label %bb1, label %bb2
  bb1:
    tail call void @foo()
    ret void
  bb2:
    tail call void @bar()
    ret void
  }

before:

  f:
          movl    4(%esp), %eax
          cmpl    8(%esp), %eax
          jne     .LBB0_2
          jmp     foo
  .LBB0_2:
          jmp     bar

after:

  f:
          movl    4(%esp), %eax
          cmpl    8(%esp), %eax
          jne     bar
  .LBB0_1:
          jmp     foo

I don't expect any significant size savings from this (on a Clang bootstrap I
saw 288 bytes), but it does make the code a little tighter.

This patch only does 32-bit, but 64-bit would work similarly.

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

llvm-svn: 280832

After r280733 we use LLVM's demangler in lld. As a result we no longer
have a discrepancy between f() and f(void) on FreeBSD (due to an issue
with FreeBSD's system demangler).

Restore a test case for a void arg function.

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

llvm-svn: 280831

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

llvm-svn: 280830

OpenCL kernels have hidden kernel arguments for global offset and printf buffer. For consistency, these hidden argument should be included in the runtime metadata. Also updated kernel argument kind metadata.

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

llvm-svn: 280829

[clang-offload-bundler] Fix some Clang-tidy modernize-use-override and Include What You Use warnings; other minor fixes.

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

llvm-svn: 280828

llvm-svn: 280827

Summary: There was no definition for __nop function - added inline
assembly.

Patch by Albert Gutowski!

Reviewers: rnk, thakis

Subscribers: cfe-commits

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

llvm-svn: 280826

Parse pragma intrinsic, display warning if the function isn't a builtin
function in clang and suggest including intrin.h.

Patch by Albert Gutowski!

Reviewers: aaron.ballman, rnk

Subscribers: aaron.ballman, cfe-commits

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

llvm-svn: 280825

Summary:
* Add a `query-symbol` option to query symbol without parsing the source file.
* Update Vim & Emacs integration scripts.

Reviewers: bkramer, massberg

Subscribers: cfe-commits

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

llvm-svn: 280824

Since r279664 this test causes frequent failures of test runs for ppc64le and
occasional failures for ppc64be which makes buildbot results unreliable.  If
the underlying problem is fixed it can be re-enabled.

llvm-svn: 280823

Summary:
Previously we were trying to represent this with the "contains" list of
the .cv_inline_linetable directive, which was not enough information.
Now we directly represent the chain of inlined call sites, so we know
what location to emit when we encounter a .cv_loc directive of an inner
inlined call site while emitting the line table of an outer function or
inlined call site. Fixes PR29146.

Also fixes PR29147, where we would crash when .cv_loc directives crossed
sections. Now we write down the section of the first .cv_loc directive,
and emit an error if any other .cv_loc directive for that function is in
a different section.

Also fixes issues with discontiguous inlined source locations, like in
this example:

  volatile int unlikely_cond = 0;
  extern void __declspec(noreturn) abort();
  __forceinline void f() {
    if (!unlikely_cond) abort();
  }
  int main() {
    unlikely_cond = 0;
    f();
    unlikely_cond = 0;
  }

Previously our tables gave bad location information for the 'abort'
call, and the debugger wouldn't snow the inlined stack frame for 'f'.
It is important to emit good line tables for this code pattern, because
it comes up whenever an asan bug occurs in an inlined function. The
__asan_report* stubs are generally placed after the normal function
epilogue, leading to discontiguous regions of inlined code.

Reviewers: majnemer, amccarth

Subscribers: llvm-commits

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

llvm-svn: 280822

LLVM now has a copy of libcxxabi demangler, so lldb doesn't need to
keep one too.

llvm-svn: 280821

llvm-svn: 280820

llvm-svn: 280819

Summary:
LSV replaces multiple adjacent loads with one vectorized load and a
bunch of extractelement instructions.  This patch makes the
extractelement instructions' names match those of the original loads,
for (hopefully) improved readability.

Reviewers: asbirlea, tstellarAMD

Subscribers: arsenm, mzolotukhin

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

llvm-svn: 280818

There are missing folds here and possibly folds that could be made generic.

llvm-svn: 280817

llvm-svn: 280816