PR32848: There isn't necessarily a FileChanged or FileSkipped for every InclusionDirective callback.

In particular, you don't get one if the inclusion directive encountered an
error. Don't assert in that case.


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

It already specifies the triples, so the intention was to test x86 for
now (or then).

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

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

This should placate GCC's -Wparentheses.

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

Summary: This patch teaches clang to use and propagate new PM in ThinLTO.

Reviewers: davide, chandlerc, tejohnson

Subscribers: mehdi_amini, Prazek, inglorion, cfe-commits

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

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

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

I'm not sure why, but on some bots, the order of two instructions are
swapped (as compared to the output on my machine). Loosen up the
CHECK-NEXT directives to deal with this.

Failing bot: http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/3097

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

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

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

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

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

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

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

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

`GenerateVarArgsThunk` in `CGVTables` clones a function before the frontend
is done emitting the compilation unit. Because of the way that DIBuilder
works, this means that the attached subprogram had incomplete (temporary)
metadata. Cloning such metadata is semantically disallowed, but happened
to work anyway due to bugs in the cloning logic. rL304226 attempted to fix
up that logic, but in the process exposed the incorrect API use here and
had to be reverted. To be able to fix this, I added a new method to
DIBuilder in rL304467, to allow finalizing a subprogram independently
of the entire compilation unit. Use that here, in preparation of re-applying
rL304226.

Reviewers: aprantl, dblaikie
Differential Revision: https://reviews.llvm.org/D33705

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

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

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

This patch makes it an error to have a mismatch between the enabled
sanitizers in a CU, and in any module being imported into the CU. Only
mismatches between non-modular sanitizers are treated as errors.

This patch also includes non-modular sanitizers in module hashes, in
order to ensure module rebuilds occur when -fsanitize=X is toggled on
and off for non-modular sanitizers, and to cut down on module rebuilds
when the option is toggled for modular sanitizers.

This fixes a longstanding issue with implicit modules and sanitizers,
which Duncan originally diagnosed.

When building with implicit modules it's possible to hit a scenario
where modules are built without -fsanitize=address, and are subsequently
imported into CUs with -fsanitize=address enabled. This causes strange
failures at runtime. The case Duncan found affects libcxx, since its
vector implementation behaves differently when ASan is enabled.

Implicit module builds should "just work" when -fsanitize=X is toggled
on and off across multiple compiler invocations, which is what this
patch does.

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

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

Check pointer arithmetic for overflow.

For some more background on this check, see:

  https://wdtz.org/catching-pointer-overflow-bugs.html
  https://reviews.llvm.org/D20322

Patch by Will Dietz and John Regehr!

This version of the patch is different from the original in a few ways:

  - It introduces the EmitCheckedInBoundsGEP utility which inserts
    checks when the pointer overflow check is enabled.

  - It does some constant-folding to reduce instrumentation overhead.

  - It does not check some GEPs in CGExprCXX. I'm not sure that
    inserting checks here, or in CGClass, would catch many bugs.

Possible future directions for this check:

  - Introduce CGF.EmitCheckedStructGEP, to detect overflows when
    accessing structures.

Testing: Apart from the added lit test, I ran check-llvm and check-clang
with a stage2, ubsan-instrumented clang. Will and John have also done
extensive testing on numerous open source projects.

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

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

GCC uses -Wno-cpp for this, so seems reasonable to add an alias to
match.

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

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

Summary:
This hooks up the detailed diagnostics of why constant initialization was
not possible if require_constant_initialization reports an error.
I have updated the test to account for the new notes.

Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24371

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

The assertion fails because EmitValueForIvarAtOffset doesn't get the
correct type of the ivar when the class the ivar belongs to is
parameterized. This commit fixes the function to compute the ivar's type
based on the type argument provided to the parameterized class.

rdar://problem/32461723

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

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

Summary:
We need to emit barrier if the union field
is CXXRecordDecl because it might have vptrs. The testcode
was wrongly devirtualized. It also proves that having different
groups for different dynamic types is not sufficient.

Reviewers: rjmccall, rsmith, mehdi_amini

Subscribers: amharc, cfe-commits

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

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

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

IgnoreNarrowingConversion should never return nullptr, but I've added an assert just in case.

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

300 was reached in r304190, 400 should be enough for a while.



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

Make the test less restrictive to allow directory layout used in our test setup.

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

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

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

Summary:
We can emit vtable definition having inline function
if they are all emitted.

Reviewers: rjmccall, rsmith

Subscribers: cfe-commits

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

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

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

Rationale: OpenCL kernels are called via an explicit runtime API
with arguments set with clSetKernelArg(), not as normal sub-functions.
Return SPIR_KERNEL by default as the kernel calling convention to ensure
the fingerprint is fixed such way that each OpenCL argument gets one
matching argument in the produced kernel function argument list to enable
feasible implementation of clSetKernelArg() with aggregates etc. In case
we would use the default C calling conv here, clSetKernelArg() might
break depending on the target-specific conventions; different targets
might split structs passed as values to multiple function arguments etc.

https://reviews.llvm.org/D33639



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

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

Summary:
Coroutine related test that used to trigger broken IR prior to r304335.

```
%x = alloca i32, align 4
store i32* %x, i32** %tmp.exprcleanup, align 4 ; <===== HERE
%ref.tmp3 = alloca %struct.A, align 1
%agg.tmp5 = alloca %"struct.std::experimental::coroutines_v1::coroutine_handle.0", align 4
%tmp.exprcleanup = alloca i32*, align 4
%allocapt = bitcast i32 undef to i32
store i32 %0, i32* %.addr, align 4
```

Fixed with r304335

Subscribers: cfe-commits

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

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

Unlike the GCC-compatible __has_trivial_destructor trait, this one computes the
right answer rather than performing the quirky set of checks described in GCC's
documentation (https://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html).

MSVC also has a __has_trivial_destructor trait which is the same as its (and
now Clang's) __is_trivially_destructible trait; we might want to consider
changing the behavior of __has_trivial_destructor if we're targeting an MSVC
platform, but I'm not doing so for now.

While implementing this I found that we were incorrectly rejecting
__is_destructible queries on arrays of unknown bound of incomplete types; that
too is fixed, and I've added similar tests for other traits for good measure.


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

Summary:
@rsmith Does this correctly address the issues mentioned in https://reviews.llvm.org/D33625#inline-292971 ?



Reviewers: rsmith, EricWF

Reviewed By: EricWF

Subscribers: cfe-commits, rsmith

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

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

to the original module map.

Also use the path and name of the original module map when emitting that
information into the .pcm file. The upshot of this is that the produced .pcm
file will track information for headers in their original locations (where the
module was preprocessed), not relative to whatever directory the preprocessed
module map was in when it was built.


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

These are already wired up to work in the MSVC toolchain header search
code. However, they were unreachable from clang-cl. A user attempted to
use them in https://bugs.llvm.org/show_bug.cgi?id=33205, so let's expose
them.

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

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

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