I am hoping the bot failures are addressed by using cc1 for the ThinLTO
backend invocations as well.

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

Also, while at it, s/IsCpp/isCpp/ so that it follows LLVM style.

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

With the release of Visual Studio 2017, we need to at the very least
claim support for it in the current manifest file. With the changes
introducted in this patch we can install the extension again, but a
warning message will be shown stating that it's not supported
(https://twitter.com/parsley72/status/846558416751411200).

To get the rid of the warning more work is necessary, as VS 2017 changed
some things about extensions, see more here:
https://docs.microsoft.com/en-us/visualstudio/extensibility/how-to-migrate-extensibility-projects-to-visual-studio-2017.
While working on those changes, it has been suggested in the
mail list that this first patch is integrated in the meantime.

Patch by Hugo Puhlmann!

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

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

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

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

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

Summary:
"kernel_arg_type_qual" metadata should contain const/volatile/restrict
tags only for pointer types to match the corresponding requirement of
the OpenCL specification.

OpenCL 2.0 spec 5.9.3 Kernel Object Queries:

CL_KERNEL_ARG_TYPE_VOLATILE is returned if the argument is a pointer
and the referenced type is declared with the volatile qualifier.
[...]
Similarly, CL_KERNEL_ARG_TYPE_CONST is returned if the argument is a
pointer and the referenced type is declared with the restrict or const
qualifier.
[...]
CL_KERNEL_ARG_TYPE_RESTRICT will be returned if the pointer type is
marked restrict.

Reviewers: Anastasia, cfe-commits

Reviewed By: Anastasia

Subscribers: bader, yaxunl

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

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

Since r299174 use after scope checking is on by default. Even though
msan doesn't check for use after scope it gets confused by the lifetime
markers emitted for it, making unit tests fail. This is covered by
ninja check-msan.

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

Removing the test until I can figure out how to get the ThinLTO backend
invocation of clang to use the correct target.

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

Sigh, another follow-on fix needed for test in r299152 causing bot
failures. We also need the target-cpu for the ThinLTO BE clang
invocation.

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

Third and hopefully final fix to test for r299152 that is causing bot
failures: make sure the target triple specified for the ThinLTO backend
clang invocations as well.

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

AddressSanitizer has an optional compile-time flag, -fsanitize-address-use-after-scope, which enables detection of use-after-scope bugs. We'd like to have this feature on by default, because it is already very well tested, it's used in several projects already (LLVM automatically enables it when using -DLLVM_USE_SANITIZER=Address), it's low overhead and there are no known issues or incompatibilities.

This patch enables use-after-scope by default via the Clang driver, where we set true as the default value for AsanUseAfterScope. This also causes the lifetime markers to be generated whenever fsanitize=address is used. This has some nice consequences, e.g. we now have line numbers for all local variables.

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



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

My previous attempt to fix bot failures from r299152 didn't add the
necessary option to get bitcode out of the cc1 step.

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

Attempt to fix bot errors from r299152 by using clang_cc1 and specifying
target triple to compile step.

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

Summary:
This involved refactoring out pieces of
EmitAssemblyHelper::CreateTargetMachine for use in runThinLTOBackend.

Subsumes D31114.

Reviewers: mehdi_amini, pcc

Subscribers: Prazek, cfe-commits

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

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

seems to be down.

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

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

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

Summary:
The refactoring introduced a regression in the flag processing for
-fxray-instruction-threshold which causes it to not get passed properly.
This change should restore the previous behaviour.

Reviewers: rnk, pelikan

Subscribers: cfe-commits

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

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

GCC has the alloc_align attribute, which is similar to assume_aligned, except the attribute's parameter is the index of the integer parameter that needs aligning to.

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


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

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

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

an ObjC object pointer

When ARC is enabled in Objective-C++, comparisons between a pointer and
Objective-C object pointer typically result in errors like this:
"invalid operands to a binary expression". This error message can be quite
confusing as it doesn't provide a solution to the problem, unlike the non-C++
diagnostic: "implicit conversion of Objective-C pointer type 'id' to C pointer
type 'void *' requires a bridged cast" (it also provides fix-its). This commit
forces comparisons between pointers and Objective-C object pointers in ARC to
use the Objective-C semantic rules to ensure that a better diagnostic is
reported.

rdar://31103857

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


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

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

warning for methods that resemble the setters of readonly properties

rdar://30415679


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

Reviewers: ioeric

Reviewed By: ioeric

Subscribers: alexshap, klimek, cfe-commits

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

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

Turns out integerPartWidth only explicitly defines the width of the tc functions in the APInt class. Functions that aren't used by APInt implementation itself. Many places in the code base already assume APInt is made up of 64-bit pieces. Explicitly assuming 64-bit here doesn't make that situation much worse. A full audit would need to be done if it ever changes.

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

Fixes this clang warning on Windows:

warning: implicit truncation from 'clang::LangOptions::FPContractModeKind' to bit-field changes value from 2 to -2 [-Wbitfield-constant-conversion]
    fp_contract = LangOptions::FPC_Fast;
                ^ ~~~~~~~~~~~~~~~~~~~~~



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

This should unbreak some bots.

Follow-up on D30388.

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

Summary:
The -fxray-always-instrument= and -fxray-never-instrument= flags take
filenames that are used to imbue the XRay instrumentation attributes
using a whitelist mechanism (similar to the sanitizer special cases
list). We use the same syntax and semantics as the sanitizer blacklists
files in the implementation.

As implemented, we respect the attributes that are already defined in
the source file (i.e. those that have the
[[clang::xray_{always,never}_instrument]] attributes) before applying
the always/never instrument lists.

Reviewers: rsmith, chandlerc

Subscribers: jfb, mgorny, cfe-commits

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

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

Patch by Zhizhou Yang

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

FPContractModeKind is the codegen option flag which is already ternary (off,
on, fast).  This makes it universally the type for the contractable info
across the front-end:

* In FPOptions (i.e. in the Sema + in the expression nodes).
* In LangOpts::DefaultFPContractMode which is the option that initializes
FPOptions in the Sema.

Another way to look at this change is that before fp-contractable on/off were
the only states handled to the front-end:
 * For "on", FMA folding was performed by  the front-end
 * For "fast", we simply forwarded the flag to TargetOptions to handle it in
 LLVM

Now off/on/fast are all exposed because for fast we will generate
fast-math-flags during CodeGen.

This is toward moving fp-contraction=fast from an LLVM TargetOption to a
FastMathFlag in order to fix PR25721.

---
This is a recommit of r299027 with an adjustment to the test
CodeGenCUDA/fp-contract.cu.  The test assumed that even
though -ffp-contract=on is passed FE-based folding of FMA won't happen.

This is obviously wrong since the user is asking for this explicitly with the
option.  CUDA is different that -ffp-contract=fast is on by default.

The test used to "work" because contract=fast and contract=on were maintained
separately and we didn't fold in the FE because contract=fast was on due to
the target-default.  This patch consolidates the contract=on/fast/off state
into a ternary state hence the change in behavior.
---

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

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

This reverts commit r299027.

It's causing a test failure in clang's CodeGenCUDE/fp-contract.cu

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

FPContractModeKind is the codegen option flag which is already ternary (off,
on, fast).  This makes it universally the type for the contractable info
across the front-end:

* In FPOptions (i.e. in the Sema + in the expression nodes).
* In LangOpts::DefaultFPContractMode which is the option that initializes
FPOptions in the Sema.

Another way to look at this change is that before fp-contractable on/off were
the only states handled to the front-end:
 * For "on", FMA folding was performed by  the front-end
 * For "fast", we simply forwarded the flag to TargetOptions to handle it in
 LLVM

Now off/on/fast are all exposed because for fast we will generate
fast-math-flags during CodeGen.

This is toward moving fp-contraction=fast from an LLVM TargetOption to a
FastMathFlag in order to fix PR25721.

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

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

Summary: After examining the remaining uses of LangOptions.ObjCAutoRefCount, found a some additional places to also check for ObjCWeak not covered by previous test cases. Added a test file to verify all the code paths that were changed.

Reviewers: rsmith, doug.gregor, rjmccall

Reviewed By: rjmccall

Subscribers: cfe-commits

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

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

Summary: clang should produce the same errors Objective-C classes that cannot be assigned to weak pointers under both -fobjc-arc and -fobjc-weak. Check for ObjCWeak along with ObjCAutoRefCount when analyzing pointer conversions. Add an -fobjc-weak pass to the existing arc-unavailable-for-weakref test cases to verify the behavior is the same.

Reviewers: rsmith, doug.gregor, rjmccall

Reviewed By: rjmccall

Subscribers: cfe-commits

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

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

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

Summary: -Warc-repeated-use-of-weak should produce the same warnings with -fobjc-weak as it does with -objc-arc. Also check for ObjCWeak along with ObjCAutoRefCount when recording the use of an evaluated weak variable. Add a -fobjc-weak run to the existing arc-repeated-weak test case and adapt it slightly to work in both modes.

Reviewers: rsmith, doug.gregor, jordan_rose, rjmccall

Reviewed By: rjmccall

Subscribers: arphaman, rjmccall, cfe-commits

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

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

Summary: Similar to ARC, in ObjCWeak Objective-C object pointers qualified with a weak lifetime are not POD or trivial types. Update the type trait code to reflect this. Copy and adapt the arc-type-traits.mm test case to verify correctness.

Reviewers: rsmith, doug.gregor, rjmccall

Reviewed By: rjmccall

Subscribers: cfe-commits

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

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

Summary:
When a PCH is included via -include-pch, clang should treat the
current TU as dependent on the sourcefile that the PCH was generated from.

This is currently _partly_ accomplished by InitializePreprocessor calling
AddImplicitIncludePCH to synthesize an implicit #include of the sourcefile,
into the preprocessor's Predefines buffer.

For FrontendActions such as PreprocessOnlyAction (which is, curiously, what the
driver winds up running one of in response to a plain clang -M) this is
sufficient: the preprocessor cranks over its Predefines and emits a dependency
reference to the initial sourcefile.

For other FrontendActions (for example -emit-obj or -fsyntax-only) the
Predefines buffer is reset to the suggested predefines buffer from the PCH, so
the dependency edge is lost. The result is that clang emits a .d file in those
cases that lacks a reference to the .h file responsible for the input (and in
Swift's case, our .swiftdeps file winds up not including a reference to the
source file for a PCH bridging header.)

This patch fixes the problem by taking a different tack: ignoring the
Predefines buffer (which seems a bit like a hack anyways) and directly
attaching the CompilerInstance's DependencyCollectors (and legacy
DependencyFileGenerator) to the ASTReader for the external AST.

This approach is similar to the one chosen in earlier consultation with Bruno
and Ben, and I think it's the least-bad solution, given several options.

Reviewers: bruno, benlangmuir, doug.gregor

Reviewed By: bruno, doug.gregor

Subscribers: cfe-commits

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

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