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

llvm-svn: 353588

oth strlcat and strlcpy cut off their safe bound for the argument value
at sizeof(destination). There's no need to subtract 1 in only one
of these cases.

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

rdar://problem/47873212

llvm-svn: 353583

When a module name is specified as -fmodule-name, that module gets a
clang::Module object, but it won't actually be built or imported; it
will be textual. CGDebugInfo wouldn't detect this and them emit a
DICompileUnit that had a hash but no name and that confused both
dsymutil, LLDB, and myself.

rdar://problem/47926508

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

llvm-svn: 353578

When we are calling `__builtin_constant_p` with ObjC objects of
different classes, we hit the assertion

> Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file include/llvm/Support/Casting.h, line 254.

It happens because LLVM types for `ObjCInterfaceType` are opaque and
have no name (see `CodeGenTypes::ConvertType`). As the result, for
different ObjC classes we have different `is_constant` intrinsics with
the same name `llvm.is.constant.p0s_s`. When we try to reuse an
intrinsic with the same name, we fail because of type mismatch.

Fix by bitcasting `ObjCObjectPointerType` to `id` prior to passing as an
argument to `__builtin_constant_p`. This results in using intrinsic
`llvm.is.constant.p0i8` and correct types.

rdar://problem/47499250

Reviewers: rjmccall, ahatanak, void

Reviewed By: void, ahatanak

Subscribers: ddunbar, jkorous, hans, dexonsmith, cfe-commits

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

llvm-svn: 353577

llvm-svn: 353571

This allows substantially simplifying the expression evaluation code,
because we don't have to special-case lvalues which are actually string
literal initialization.

This currently throws away an optimization where we would avoid creating
an array APValue for string literal initialization.  If we really want
to optimize this case, we should fix APValue so it can store simple
arrays more efficiently, like llvm::ConstantDataArray.  This shouldn't
affect the memory usage for other string literals.  (Not sure if this is
a blocker; I don't think string literal init is common enough for this
to be a serious issue, but I could be wrong.)

The change to test/CodeGenObjC/encode-test.m is a weird side-effect of
these changes: we currently don't constant-evaluate arrays in C, so the
strlen call shouldn't be folded, but lvalue string init managed to get
around that check.  I this this is fine.

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

llvm-svn: 353569

llvm-svn: 353568

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

llvm-svn: 353566

of the array type itself.

This fixes a bug found by inspection that was introduced in r353459. I
don't have a test case for this since we don't yet have types that would
make the containing C struct non-trivial to copy/move but wouldn't make
it non-trivial to default-initialize or destruct.

llvm-svn: 353556

[X86] Add explicit alignment to __m128/__m128i/__m128d/etc. to allow matching of MSVC behavior with #pragma pack.

Summary:
With MSVC, #pragma pack is ignored when there is explicit alignment. This differs from gcc. Clang emulates this difference when compiling for Windows.

It appears that MSVC and its headers consider the __m128/__m128i/__m128d/etc. types to be explicitly aligned and ignores #pragma pack for them. Since we don't have explicit alignment on them in our headers, we don't match the MSVC behavior here.

This patch adds explicit alignment to match this behavior. I'm hoping this won't cause any problems when we're not emulating MSVC. But if someone knows of something that would be different we can swith to conditionally adding the alignment based on _MSC_VER.

I had to add explicitly unaligned types as well so we could use them in the loadu/storeu intrinsics which use __attribute__(__packed__). Using the now explicitly aligned types wouldn't produce align 1 accesses when targeting Windows.

Reviewers: rnk, erichkeane, spatel, RKSimon

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 353555

Fixed diagnostic emission for the exceptions support in case of the
compilation of OpenMP code for the devices. From now on, it uses delayed
diagnostics mechanism, previously used for CUDA only. It allow to
diagnose not allowed used of exceptions only in functions that are going
to be codegen'ed.

llvm-svn: 353542

This reverts commit r353540. Erroneously committed, need to fix the
message and description.

llvm-svn: 353541

It is important to delay the emission of the diagnostic messages for the
functions unless it is proved that the function is going to be used on
the device side. It is required to support compilation with some of the
target-specific system headers.

llvm-svn: 353540

Specifically:

* fixes the comments on `hasObjectExpression`,
* clarifies comments on `thisPointerType` and `on`,
* adds comments to `onImplicitObjectArgument`.

It also updates associated reference docs (using the doc tool).

Reviewers: alexfh, steveire, aaron.ballman

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

llvm-svn: 353532

Summary:
Currently, `UnwrappedLineParser` thinks an arrow token after
an ObjC method expression is a C++ lambda arrow, so it formats:

```
[foo bar]->baz
```

as:

```
[foo bar] -> baz
```

Because `UnwrappedLineParser` runs before `TokenAnnotator`, it can't
know if the arrow token is after an ObjC method expression or not.

This diff makes `TokenAnnotator` remove the TT_LambdaArrow on
the arrow token if it follows an ObjC method expression.

Test Plan: New test added. Ran test with:
  % ninja FormatTests && ./tools/clang/unittests/Format/FormatTests
  Confirmed test failed before diff and passed after diff.

Reviewers: krasimir, djasper, sammccall

Reviewed By: sammccall

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 353531

Some of these functions take some extraneous arguments, e.g. EltSize,
Offset, which are computable from the Type and DataLayout.

Add some asserts to ensure that the computed values are consistent
with the passed-in values, in preparation for eliminating the
extraneous arguments. This also asserts that the Type is an Array for
the calls named "Array" and a Struct for the calls named "Struct".

Then, correct a couple of errors:

1. Using CreateStructGEP on an array type. (this causes the majority
   of the test differences, as struct GEPs are created with i32
   indices, while array GEPs are created with i64 indices)

2. Passing the wrong Offset to CreateStructGEP in TargetInfo.cpp on
   x86-64 NACL (which uses 32-bit pointers).

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

llvm-svn: 353529

Summary:
This is to check that operators are handled properly in
`ASTImporterSpecificLookup`.  Note, this lookup table is not used in LLDB, only
in CTU.

Reviewers: a_sidorin, shafik, a.sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

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

llvm-svn: 353505

Summary: Operators kind was not checked, so we reported e.g. op- to be equal with op+

Reviewers: shafik, a_sidorin, aaron.ballman

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

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

llvm-svn: 353504

Summary:
Automatic initialization [1] of __block variables was trampling over the block's
headers after they'd been initialized, which caused self-init usage to crash,
such as here:

  typedef struct XYZ { void (^block)(); } *xyz_t;
  __attribute__((noinline))
  xyz_t create(void (^block)()) {
    xyz_t myself = malloc(sizeof(struct XYZ));
    myself->block = block;
    return myself;
  }
  int main() {
    __block xyz_t captured = create(^(){ (void)captured; });
  }

This type of code shouldn't be broken by variable auto-init, even if it's
sketchy.

[1] With -ftrivial-auto-var-init=pattern

<rdar://problem/47798396>

Reviewers: rjmccall, pcc, kcc

Subscribers: jkorous, dexonsmith, cfe-commits

Tags: #clang

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

llvm-svn: 353495

r344765 added those intrinsics, but used the wrong types.

Patch by Mike Hommey

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

llvm-svn: 353493

As suggested by @rjmccall in D57797.

llvm-svn: 353490

This patch simply teach BPF driver about the new CPU "v3" introduced in
LLVM backend.

Acked-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
llvm-svn: 353479

This patch fixes a bug where clang doesn’t reject union fields of
non-trivial C struct types. For example:

```
// This struct is non-trivial under ARC.
struct S0 {
  id x;
};

union U0 {
  struct S0 s0; // clang should reject this.
  struct S0 s1; // clang should reject this.
};

void test(union U0 a) {
  // Previously, both 'a.s0.x' and 'a.s1.x' were released in this
  // function.
}
```

rdar://problem/46677858

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

llvm-svn: 353459

Summary:
Deferred diagnostic interface is going to be used for OpenMP device
compilation. Generalized previously existed deferred diagnostic
interface for CUDA to be used with OpenMP and, possibly, other models.

Reviewers: rjmccall, tra

Subscribers: caomhin, cfe-commits, kkwli0

Tags: #clang

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

llvm-svn: 353456

Valid OpenCL C code should still compile in C++ mode.

This change enables extensions and OpenCL types.

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

llvm-svn: 353431

Summary:
Currently `TestImportBase` is derived from `ParameterizedTestsFixture`
which explicitly states that the gtest parameter can be only an
`ArgVector`. This is a limitation when we want to create tests which may
have different parameters.
E.g. we would like to create tests where we can combine different test
parameters. So, for example we'd like gtest to be able to provide
parameters of `<std::tuple<ArgVector, const char *>` instead of a simple
`ArgVector`.

Reviewers: a_sidorin, shafik, a.sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

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

llvm-svn: 353425

The patch in r350643 incorrectly sets the COFF emission based on bits
instead of bytes. This patch converts the 32 via CharUnits to bits to
compare the correct values.

Change-Id: Icf38a16470ad5ae3531374969c033557ddb0d323
llvm-svn: 353411

MSVC supports /Oy- on aarch64, so clang-cl should too.

Patch by Nathan Froyd!

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

llvm-svn: 353402

llvm-svn: 353393

Moved everything SMT-related to LLVM and updated the cmake scripts.

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

llvm-svn: 353373

There is no advantage in having them in separate files, I doubt some will ever use them separately.

This also makes it easier to move the API to LLVM.

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

llvm-svn: 353372

Now, instead of passing the reference to a shared_ptr, we pass the shared_ptr instead.

I've also removed the check if Z3 is present in CreateZ3ConstraintManager as this function already calls CreateZ3Solver that performs the exactly same check.

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

llvm-svn: 353371

This patch moves the ConstraintSMT definition to the SMTConstraintManager header to make it easier to move the Z3 backend around.

We achieve this by not using shared_ptr  anymore, as llvm::ImmutableSet doesn't seem to like it.

The solver specific exprs and sorts are cached in the Z3Solver object now and we move pointers to those objects around.

As a nice side-effect, SMTConstraintManager doesn't have to be a template anymore. Yay!

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

llvm-svn: 353370

CreateCall/Invoke.

Also, remove the getFunctionType() function from CGCallee, since it
accesses the pointee type of the value. The only use was in EmitCall,
so just inline it into the debug assertion.

This is the last of the changes for Call and Invoke in clang.

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

llvm-svn: 353356

initialization and global destructor calls.

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

llvm-svn: 353355

Memory region that correspond to a variable is identified by the variable's
declaration and, in case of local variables, the stack frame it belongs to.

The declaration needs to be canonical, otherwise we'd have two different
memory regions that correspond to the same variable.

Fix such bug for global variables with forward declarations and assert
that no other problems of this kind happen.

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

llvm-svn: 353353

This reverts commit r341722.

The "postponed" mechanism turns out to be necessary in order to handle
situations when a symbolic region is only kept alive by implicit bindings
in the Store. Otherwise the region is never scanned by the Store's worklist
and the binding gets dropped despite being live, as demonstrated
by the newly added tests.

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

llvm-svn: 353350

The MSDN document was also updated to reflect this, but it probably will take a few days to show in below link.

https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail

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

llvm-svn: 353337

llvm-svn: 353320

Reviewers: cfe-commits, lhames

Reviewed By: lhames

Subscribers: hintonda, klimek, pirama

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

llvm-svn: 353318