Summary:
Given the following test program:

```
class C {
public:
  int A(int a, int& b);
};

int C::A(const int a, int b) {
  return a * b;
}
```

Clang would produce an error message that correctly diagnosed the
redeclaration of `C::A` to not match the original declaration (the
parameters to the two declarations do not match -- the original takes an
`int &` as its 2nd parameter, but the redeclaration takes an `int`). However,
it also produced a note diagnostic that inaccurately pointed to the
first parameter, claiming that `const int` in the redeclaration did not
match the unqualified `int` in the original. The diagnostic is
misleading because it has nothing to do with why the program does not
compile.

The logic for checking for a function overload, in
`Sema::FunctionParamTypesAreEqual`, discards cv-qualifiers before
checking whether the types are equal. Do the same when producing the
overload diagnostic.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cpplearner, cfe-commits

Tags: #clang

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

llvm-svn: 352831

Who knew...they're not built by default or as part of the tests.

llvm-svn: 352830

Summary:
UBSan wants to detect when unreachable code is actually reached, so it
adds instrumentation before every unreachable instruction. However, the
optimizer will remove code after calls to functions marked with
noreturn. To avoid this UBSan removes noreturn from both the call
instruction as well as from the function itself. Unfortunately, ASan
relies on this annotation to unpoison the stack by inserting calls to
_asan_handle_no_return before noreturn functions. This is important for
functions that do not return but access the the stack memory, e.g.,
unwinder functions *like* longjmp (longjmp itself is actually
"double-proofed" via its interceptor). The result is that when ASan and
UBSan are combined, the noreturn attributes are missing and ASan cannot
unpoison the stack, so it has false positives when stack unwinding is
used.

Changes:
Clang-CodeGen now directly insert calls to `__asan_handle_no_return`
when a call to a noreturn function is encountered and both
UBsan-unreachable and ASan are enabled. This allows UBSan to continue
removing the noreturn attribute from functions without any changes to
the ASan pass.

Previously generated code:
```
  call void @longjmp
  call void @__asan_handle_no_return
  call void @__ubsan_handle_builtin_unreachable
```

Generated code (for now):
```
  call void @__asan_handle_no_return
  call void @longjmp
  call void @__asan_handle_no_return
  call void @__ubsan_handle_builtin_unreachable
```

rdar://problem/40723397

Reviewers: delcypher, eugenis, vsk

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

> llvm-svn: 352690

llvm-svn: 352829

Fixes: https://bugs.llvm.org/show_bug.cgi?id=37168

This is only a first pass at supporting these custom import
modules.  In the long run we most likely want to treat these
kinds of symbols very differently.  For example, it should not
be possible to resolve such as symbol at static link type.

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

llvm-svn: 352828

Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.

Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.

Then:
- update the CallInst/InvokeInst instruction creation functions to
  take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.

One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.

However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)

Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.

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

llvm-svn: 352827

Summary:
In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking
an executable. This patch implements a check to error on undefined
symbols in a shared object, if all of its DT_NEEDED entries are seen.

Our approach resembles the one used in gold, achieves a good balance to
be useful but not too smart (ld.bfd traces all DSOs and emulates the
behavior of a dynamic linker to catch more cases).

The error is issued based on the symbol table, different from undefined
reference errors issued for relocations. It is most effective when there
are DSOs that were not linked with -z defs (e.g. when static sanitizers
runtime is used).

gold has a comment that some system libraries on GNU/Linux may have
spurious undefined references and thus system libraries should be
excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The
story may have changed now but we make --allow-shlib-undefined the
default for now. Its interaction with -shared can be discussed in the
future.

Reviewers: ruiu, grimar, pcc, espindola

Reviewed By: ruiu

Subscribers: joerg, emaste, arichardson, llvm-commits

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

llvm-svn: 352826

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

llvm-svn: 352825

Having an incorrect type for a cast causes the checker to incorrectly
dismiss the operation under ARC, leading to a false positive
use-after-release on the test.

rdar://47709885

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

llvm-svn: 352824

Should fix non-lld links.

llvm-svn: 352823

This reverts commit r350920 as it is not clear whether we should force a
class to be returned in registers when copy and move constructors are
both deleted.

For more background, see the following discussion:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190128/259907.html

llvm-svn: 352822

If we're optimizing for size, that overrides the subtarget
feature, so we would always produce 'inc' if we matched
this pattern.

llvm-svn: 352821

Another pattern exposed in D57516.

llvm-svn: 352820

llvm-svn: 352819

[sanitizer-coverage] prune trace-cmp instrumentation for CMP isntructions that feed into the backedge branch. Instrumenting these CMP instructions is almost always useless (and harmful) for fuzzing

llvm-svn: 352818

It should probably just be mandatory for getTgtMemIntrinsic to return
the alignment.

llvm-svn: 352817

This function initializes enough of the runtime to be able to run
instrumented code in a statically linked executable. It replaces
__hwasan_shadow_init() which wasn't doing enough initialization for
instrumented code that uses either TLS or IFUNC to work.

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

llvm-svn: 352816

Summary:
Temporarily disable value-profile-cmp2.test on Win.
https://reviews.llvm.org/D57465 causes the test to fail on Win.
However, it seems that the behavior of libFuzzer on Win was broken
before that patch. It crashes in the exit handler when not used with
ASAN. Prior to the patch, the crash handler would run, tricking the
test into thinking libFuzzer on Win had exited properly.

Reviewers: morehouse, vitalybuka

Reviewed By: morehouse

Subscribers: yln

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

llvm-svn: 352815

A handful of bots are still breaking, either because I missed them in my audit,
they were offline, or something else. I'm contacting their authors, but I'll
revert for now and re-commit later.

llvm-svn: 352814

Summary:
The custom lowering introduced in rL352592 creates build_vector nodes
with negative i32 operands, but these operands did not meet the value
range constraints necessary to match build_vector nodes. This CL fixes
the issue by removing the unnecessary constraints.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish

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

llvm-svn: 352813

As was suggested when the policy originally went in.

llvm-svn: 352812

Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

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

llvm-svn: 352811

Reviewers: jgravelle-google, sbc100

Subscribers: aheejin, llvm-commits

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

llvm-svn: 352810

llvm-svn: 352809

This requires a little extra work due tothe fact i32 is not a legal type. When
call lowering happens post-legalisation (e.g. when an intrinsic was inserted
during legalisation). A bitcast from f32 to i32 can't be introduced. This is
similar to the challenges with RV32D. To handle this, we introduce
target-specific DAG nodes that perform bitcast+anyext for f32->i64 and
trunc+bitcast for i64->f32.

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

llvm-svn: 352807

Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits

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

llvm-svn: 352806

llvm-svn: 352805

Reviewers: aaron.ballman

Subscribers: cfe-commits

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

llvm-svn: 352804

- fixes the test on macOS with LLVM_ENABLE_PIC=OFF
- together with D57343, gets the test to pass on Windows
- makes it run everywhere (it seems to just pass on Linux)

The main change is to pull out the resource directory computation into a
function shared by all 3 places that do it. In CIndexer.cpp, this now works no
matter if libclang is in lib/ or bin/ or statically linked to a binary in bin/.


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

llvm-svn: 352803

llvm-svn: 352802

rC352620 caused regressions because it copied floating point format from
aux target.

floating point format decides whether extended long double is supported.
It is x86_fp80 on x86 but IEEE double on amdgcn.

Document usage of long doubel type in HIP programming guide 
https://github.com/ROCm-Developer-Tools/HIP/pull/890

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

llvm-svn: 352801

This reverts commit f47d6b38 (r352791).

Seems to run into compilation failures with GCC (but not clang, where
I tested it). Reverting while I investigate.

llvm-svn: 352800

Instead of calling CUDA runtime to arrange function arguments,
the new API constructs arguments in a local array and the kernels
are launched with __cudaLaunchKernel().

The old API has been deprecated and is expected to go away
in the next CUDA release.

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

llvm-svn: 352799

..and use it to control that parts of CUDA compilation
that depend on the specific version of CUDA SDK.

This patch has a placeholder for a 'new launch API' support
which is in a separate patch. The list will be further
extended in the upcoming patch to support CUDA-10.1.

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

llvm-svn: 352798

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: llvm-commits, mgorny, ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

llvm-svn: 352796

llvm-svn: 352795

Summary: Moving special handling to MemorySSAUpdater in D57199.

Reviewers: gberry, george.burgess.iv

Subscribers: sanjoy, jlebar, Prazek, llvm-commits

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

llvm-svn: 352794

Summary: Also clean up some preexisting target feature code.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, jfb

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

llvm-svn: 352793

This patch fixes pr39098.

For the attached test case, CombineZExtLogicopShiftLoad can optimize it to

t25: i64 = Constant<1099511627775>
t35: i64 = Constant<0>
  t0: ch = EntryToken
t57: i64,ch = load<(load 4 from `i40* undef`, align 8), zext from i32> t0, undef:i64, undef:i64
    t58: i64 = srl t57, Constant:i8<1>
  t60: i64 = and t58, Constant:i64<524287>
t29: ch = store<(store 5 into `i40* undef`, align 8), trunc to i40> t57:1, t60, undef:i64, undef:i64

But later visitANDLike transforms it to

t25: i64 = Constant<1099511627775>
t35: i64 = Constant<0>
  t0: ch = EntryToken
t57: i64,ch = load<(load 4 from `i40* undef`, align 8), zext from i32> t0, undef:i64, undef:i64
      t61: i32 = truncate t57
    t63: i32 = srl t61, Constant:i8<1>
  t64: i32 = and t63, Constant:i32<524287>
t65: i64 = zero_extend t64
    t58: i64 = srl t57, Constant:i8<1>
  t60: i64 = and t58, Constant:i64<524287>
t29: ch = store<(store 5 into `i40* undef`, align 8), trunc to i40> t57:1, t60, undef:i64, undef:i64

And it triggers CombineZExtLogicopShiftLoad again, causes a dead loop.

Both forms should generate same instructions, CombineZExtLogicopShiftLoad generated IR looks cleaner. But it looks more difficult to prevent visitANDLike to do the transform, so I prevent CombineZExtLogicopShiftLoad to do the transform if the ZExt is free.

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

llvm-svn: 352792

The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.

Then:
- update the CallInst/InvokeInst instruction creation functions to
  take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.

One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.

However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)

Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.

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

llvm-svn: 352791

CMake 3.6 introduced CMAKE_TRY_COMPILE_PLATFORM_VARIABLES, which solves
precisely the problem that necessitated init_user_prop, so we can switch
over whenever we bump our minimum CMake requirement.

llvm-svn: 352790