and commit a1853e834c65751f92521f7481b15cf0365e796b.

They broke arm and aarch64

llvm-svn: 353590

After r353586, we won't fail on the AMDGPU floor pattern that was killing the
importer before.

llvm-svn: 353589

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

llvm-svn: 353588

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

llvm-svn: 353587

If we run into a pattern that looks like this:

add
  (complex $x, $y)
  (complex $x, $z)

We should skip the pattern instead of asserting/doing something unpredictable.

This makes us return an Error in that case, and adds a testcase for skipped
patterns.

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

llvm-svn: 353586

llvm-svn: 353585

[libFuzzer] more refactoring; change some of the exit codes (timeout, OOM, interrupt) so that the parent process can distinguish those

llvm-svn: 353584

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

Reviewers: vsk, fhahn, davidxl

Reviewed By: vsk

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 353582

we get a pointer to the c-string rep and then the temporary object
is destructed and we still refer to the c-string after that.

llvm-svn: 353581

llvm-svn: 353580

With a fix after r353563 that adds some more opcodes.

llvm-svn: 353579

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

This reverts commit r353553.

This breaks CodeGen/AArch64/GlobalISel/legalize-ext-csedebug-output.mir:

http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/57963/console

llvm-svn: 353575

llvm-svn: 353573

Summary:
The message "could not get the buffer for the member defining symbol"
now also contains the name of the archive and the name of the archive
member that we tried to open.

Reviewers: ruiu

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 353572

llvm-svn: 353571

[libFuzzer] introduce an experimental mode -fork=1, where fuzzing happens in a subprocess (still running multiple inputs per process), thus making the fuzzing more resilient to timeouts and OOMs. This is just a skeleton of the code, and some associated refactoring, not a fully working feature yet. 

llvm-svn: 353570

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

llvm-svn: 353567

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

llvm-svn: 353566

These instructions can generate a stack overflow exception so technically they read the stack overflow exception mask bit.

llvm-svn: 353564

This patch accompanies the RFC posted here:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html

This patch adds a new CallBr IR instruction to support asm-goto
inline assembly like gcc as used by the linux kernel. This
instruction is both a call instruction and a terminator
instruction with multiple successors. Only inline assembly
usage is supported today.

This also adds a new INLINEASM_BR opcode to SelectionDAG and
MachineIR to represent an INLINEASM block that is also
considered a terminator instruction.

There will likely be more bug fixes and optimizations to follow
this, but we felt it had reached a point where we would like to
switch to an incremental development model.

Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii

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

llvm-svn: 353563

When CodeExtractor saves the result of InvokeInst at the first insertion
point of the 'normal destination' basic block, this block can be omitted
in the outlined region, so store is placed outside of the function. The
suggested solution is to process saving outputs after creating exit
stubs for new function, and stores will be placed in that blocks before
return in this case.

Patch by Sergei Kachkov!

Fixes llvm.org/PR40455.

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

llvm-svn: 353562

Summary:
Scoped interceptor should not be used when calling real pthread_exit().
On macOS C++ destructors are not called by pthread_exit(), and later check for empty thread ignore set fails.

Patch by Yuri Per.

Reviewers: dvyukov, vitalybuka

Reviewed By: vitalybuka

Subscribers: vitalybuka, thegameg, kubamracek, jfb, llvm-commits, #sanitizers

Tags: #sanitizers, #llvm

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

llvm-svn: 353561

The macros were changed but not updated in the Darwin version.

Fail here: http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/53739/

rdar://47925820

llvm-svn: 353560

llvm-svn: 353559

Inline compatability is determined from the individual feature
bits. These are just sets of the separate features, but will always be
treated as incompatible unless they are specifically ignored.

Defining the ISA version number here in tablegen would be nice, but it
turns out this wasn't actually used.

llvm-svn: 353558

The sqrt case is faster and we already do this for the case where
the exponent is 0.25. This adds the 0.75 case which is also not
sensitive to signed zeros.

Patch by Whitney Tsang (Whitney)

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

llvm-svn: 353557

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

Summary:
The modernize-use-default-member-init check crashes when trying to
create an assignment value for a value-initialized enum because it isn't a
BuiltinType.
An enum cannot be initialized by assigning 0 to it unless a cast is added.
It could be initialized with an enumerator with the value 0, but there might not
be one.
Avoid these issues by ignoring the UseAssignment setting for value-initialized
enums.

Fixes PR35050.

Reviewers: aaron.ballman, alexfh, JonasToth

Reviewed By: JonasToth

Subscribers: xazax.hun, cfe-commits

Tags: #clang

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

llvm-svn: 353554

https://reviews.llvm.org/D57932

Add some logging + tests to make sure CSEInfo prints debug output.

reviewed by: arsenm

llvm-svn: 353553

llvm-svn: 353552

Summary:
Document that libFuzzer supports Windows, how to get it,
and its limitations.

Reviewers: kcc, morehouse, rnk, metzman

Reviewed By: kcc, rnk, metzman

Subscribers: hans, rnk

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

llvm-svn: 353551

Add LLVM_USE_NEWPM to build LLVM using the experimental new pass manager.

Differential Revision: http://reviews.llvm.org/D57068

llvm-svn: 353550

type in lldb and polly.

llvm-svn: 353549