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

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

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

llvm-svn: 353566

[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

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:
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

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

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

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

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

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

llvm-svn: 353373

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

Reviewers: tlively

Subscribers: dschuff, sbc100, jgravelle-google, sunfish, jfb, cfe-commits

Tags: #clang

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

llvm-svn: 353260

The assert added to EmitCall there was triggering in Windows Chromium
builds, due to a mismatch of the return type.

The MSVC constructor call extension (`this->Foo::Foo()`) was emitting
the constructor call from 'EmitCXXMemberOrOperatorMemberCallExpr' via
calling 'EmitCXXMemberOrOperatorCall', instead of
'EmitCXXConstructorCall'. On targets where HasThisReturn is true, that
was failing to set the proper return type in the call info.

Switching to calling EmitCXXConstructorCall also allowed removing some
code e.g. the trivial copy/move support, which is already handled in
EmitCXXConstructorCall.

Ref: https://bugs.chromium.org/p/chromium/issues/detail?id=928861
Differential Revision: https://reviews.llvm.org/D57794

llvm-svn: 353246

For global variables with unordered initialization that are instantiated
within a module, we previously did not emit the global (or its
initializer) at all unless it was used in the importing translation unit
(and sometimes not even then!), leading to misbehavior and link errors.

We now emit the initializer for an instantiated global variable with
unordered initialization with side-effects in a module into every
translation unit that imports the module. This is unfortunate, but
mostly matches the behavior of a non-modular compilation and seems to be
the best that we can reasonably do.

llvm-svn: 353240

When a framework with the same name is available at multiple framework
search paths, we use the first matching location. If a framework at this
location doesn't have all the headers, it can be confusing for
developers because they see only an error `'Foo/Foo.h' file not found`,
can find the complete framework with required header, and don't know the
incomplete framework was used instead.

Add a note explaining a framework without required header was found.
Also mention framework directory path to make it easier to find the
incomplete framework.

rdar://problem/39246514

Reviewers: arphaman, erik.pilkington, jkorous

Reviewed By: jkorous

Subscribers: jkorous, dexonsmith, cfe-commits

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

llvm-svn: 353231

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

llvm-svn: 353227

This is suggested by 3.3.9 of MSP430 EABI document.
We do allow user to manually enable frame pointer. GCC toolchain uses the same behavior.

Patch by Dmitry Mikushev!

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

llvm-svn: 353212

Summary:
Added ability to generate correct debug info data about the variable
address class. Currently, for all the locals and globals the default
values are used, ADDR_local_space(6) for locals and ADDR_global_space(5)
for globals. The values are taken from the table in
  https://docs.nvidia.com/cuda/archive/10.0/ptx-writers-guide-to-interoperability/index.html#cuda-specific-dwarf.
  We need to emit correct data for address classes of, at least, shared
  and constant globals. Currently, all these variables are treated by
  the cuda-gdb debugger as the variables in the global address space
  and, thus, it require manual data type casting.

Reviewers: echristo, probinson

Subscribers: jholewinski, aprantl, cfe-commits

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

llvm-svn: 353204

The fix is to issue error messages if there are more than one 
teams construct inside a target constructs.

#pragma omp target
{
  #pragma omp teams
  {  ...  }

  #pragma omp teams
  { ... }
}

llvm-svn: 353186

edge cases.

Currently, EmitCall emits a call instruction with a function type
derived from the pointee-type of the callee. This *should* be the same
as the type created from the CallInfo parameter, but in some cases an
incorrect CallInfo was being passed.

All of these fixes were discovered by the addition of the assert in
EmitCall which verifies that the passed-in CallInfo matches the
Callee's function type.

As far as I know, these issues caused no bugs at the moment, as the
correct types were ultimately being emitted. But, some would become
problematic when pointee types are removed.

List of fixes:

* arrangeCXXConstructorCall was passing an incorrect value for the
  number of Required args, when calling an inheriting constructor
  where the inherited constructor is variadic. (The inheriting
  constructor doesn't actually get passed any of the user's args, but
  the code was calculating it as if it did).

* arrangeFreeFunctionLikeCall was not including the count of the
  pass_object_size arguments in the count of required args.

* OpenCL uses other address spaces for the "this" pointer. However,
  commonEmitCXXMemberOrOperatorCall was not annotating the address
  space on the "this" argument of the call.

* Destructor calls were being created with EmitCXXMemberOrOperatorCall
  instead of EmitCXXDestructorCall in a few places. This was a problem
  because the calling convention sometimes has destructors returning
  "this" rather than void, and the latter function knows about that,
  and sets up the types properly (through calling
  arrangeCXXStructorDeclaration), while the former does not.

* generateObjCGetterBody: the 'objc_getProperty' function returns type
  'id', but was being called as if it returned the particular
  property's type. (That is of course the *dynamic* return type, and
  there's a downcast immediately after.)

* OpenMP user-defined reduction functions (#pragma omp declare
  reduction) can be called with a subclass of the declared type. In
  such case, the call was being setup as if the function had been
  actually declared to take the subtype, rather than the base type.

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

llvm-svn: 353181

When Clang/LLVM is built with the CLANG_DEFAULT_STD_CXX CMake macro that sets
the default standard to something other than C++14, there are a number of lit
tests that fail as they rely on the C++14 default.
This patch just adds the language standard option explicitly to such test cases.

Differential revision: https://reviews.llvm.org/D57581

llvm-svn: 353163

When we attempt to add an addr space qual to a type already
qualified by an addr space ICE is triggered. Before creating
a type with new address space, remove the old addr space.

Fixing PR38614!

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

llvm-svn: 353160

Summary:
This is a follow up for https://reviews.llvm.org/D57278. The previous
revision should have also included Kernel ASan.

rdar://problem/40723397

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 353120

A non-lazy class will be initialized eagerly when the Objective-C runtime is
loaded. This is required for certain system classes which have instances allocated in
non-standard ways, such as the classes for blocks and constant strings.
Adding this attribute is essentially equivalent to providing a trivial
+load method but avoids the (fairly small) load-time overheads associated
with defining and calling such a method.

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

llvm-svn: 353116

rdar://47713266

Differential revision: https://reviews.llvm.org/D57712

llvm-svn: 353115

Changes suggested by Eli Friedman <efriedma@quicinc.com>

llvm-svn: 353088

Summary: this commit adds support to a new dependence type introduced in OpenMP
5.0. The LLVM OpenMP RTL already supports this feature, so we  only need to
modify CLANG to take advantage of them.


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

llvm-svn: 353018

There is currently no way to distinguish implicit from explicit
CXXThisExpr in the AST dump output.

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

Reviewed By: steveire

llvm-svn: 353003

Different Unix "errno" values are returned for the following scenarios:

$ echo test > /tmp/existingFile/impossibleDir/impossibleFile
"Not a directory"
$ echo test > /tmp/nonexistentDir/impossibleFile
"No such file or directory"

This fixes the regression introduced by r352971 / D57592.

llvm-svn: 352996