[Sema][X86] Update immediate check for gather/scatter prefetch instructions to match the _MM_HINT_T0/T1 constant definitions

Our _MM_HINT_T0/T1 constant values are 3/2 which matches gcc, but not icc or Intel documentation. Interestingly gcc had this same bug on their implementation of the gather/scatter builtins at one point too.

Fixes PR32411.



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

Reasoning behind this change was allowing the function to accept all values
from range [-128, 255] since all of them can be encoded in an 8bit wide
value.
This differs from the prior state where only range [-128, 127] was accepted,
where values were assumed to be signed, whereas now the actual
interpretation of the immediate is deferred to the consumer as required.

Patch by Stefan Maksimovic.

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


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

This patch serializes the state of #pragma pack. It preserves the state of the
pragma from a PCH/from modules in a file that uses that PCH/those modules.

rdar://21359084

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


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

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