Standalone builds of projects other than llvm itself (lldb, libcxx,
etc) include HandleLLVMOptions but not the top level llvm CMakeLists,
so we need to set this variable here to ensure that it always has a
value.

This should fix the build issues some folks have been seeing.

llvm-svn: 357976

Summary:
This patch adds support for parsing STACK CFI records from breakpad
files. The expressions specifying the values of registers are not
parsed.The idea is that these will be handed off to the postfix
expression -> dwarf compiler, once it is extracted from the internals of
the NativePDB plugin.

Reviewers: clayborg, amccarth, markmentovai

Subscribers: aprantl, lldb-commits

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

llvm-svn: 357975

Summary:
The MergeValues() function would try to merge two entries if they shared
the same beginning label. Having the same beginning label means that the
former entry's range would be empty; however, after D55919 we no longer
create entries for empty ranges, so we can no longer land in a situation
where that check in MergeValues would succeed. Instead, the "merging" is
done by keeping the live values from the preceding empty ranges in
OpenRanges, and adding them to the first non-empty range.

Reviewers: aprantl, dblaikie, loladiro

Reviewed By: aprantl

Subscribers: llvm-commits

Tags: #debug-info, #llvm

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

llvm-svn: 357974

There are no instructions VEX or EVEX instructions that set this field.

llvm-svn: 357973

[X86] Have EVEX2VEX tablegenerator use HasVEX_L and HasEVEX_L2 fields instead of the composite EVEX_LL field. Remove the EVEX_LL field. NFCI

The composite existed to simplify some other tablegen code and not really in an
important way. Remove the combined field and just calculate the vector size
using two ifs.

llvm-svn: 357972

The instruction's document this as W0 for the VEX encoding. But there's a
footnote mentioning that VEX.W is ignored in 64-bit mode. And the main VEX
encoding description says the VEX.W bit is ignored for instructions that are
equivalent to a legacy SSE instruction that uses REX.W to select a GPR which
would apply here.

By making this match EVEX we can remove a special case of allowing EVEX2VEX to
turn an EVEX.WIG instruction into VEX.W0.

llvm-svn: 357971

llvm-svn: 357970

Switch part of the computeOverflowForSignedAdd() implementation to
use Range.isAllNegative() rather than KnownBits.isNegative() and
similar. They do the same thing, but using the ConstantRange methods
allows dropping the KnownBits variables more easily in D60420.

llvm-svn: 357969

Preparation for D60420.

llvm-svn: 357968

llvm-svn: 357967

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

llvm-svn: 357966

llvm-svn: 357965

Reviewers: arsenm, nhaehnle

Subscribers: kzhuravl, jvesely, wdng, yaxunl, rovka, kristof.beyls, dstuttard, tpr, t-tye, volkan, llvm-commits

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

llvm-svn: 357964

I have occasional crashes coming from SBThread::GetExtendedBacktraceThread.  The 
symptom is that we got true back from HasThreadScope - so we should have a valid
live thread, but then when we go to use the thread, it is not good anymore and we
crash.
I can't spot any obvious cause for this crash, but in looking for same I noticed
that in the current code we check that the thread is valid, THEN we take the stop 
locker.  We really should do that in the other order, and ensure that the process 
will stay stopped before we check our thread is still good.  That's what this patch does.

<rdar://problem/47478205>

llvm-svn: 357963

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

llvm-svn: 357962

as a start for the monorepo .gitignore.

llvm-svn: 357961

It's been on in Android for a while without causing problems, so it's time
to make it the default and remove the flag.

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

llvm-svn: 357960

This changes the operand type from v4f32/v2f64 to iPTR which seems more correct. But that doesn't seem to do anything other than change the comments in X86GenDAGISel.inc. Probably because we use a ComplexPattern to do the matching so there's no autogenerated code to change.

llvm-svn: 357959

This reverts commit r357944 and r357949.

These changes failed to account for the fact that
the guard object is under aligned for atomic operations
on 32 bit platforms (It's aligned to 4 bytes but we require 8).

llvm-svn: 357958

Fixes PR38686

> llvm-svn: 52527

llvm-svn: 357957

cxa_guard_abort should still broadcast on exit.

llvm-svn: 357956

Add a flag to control whether the ModulesDidLoad notification is
called when a module is added.  If the notifications are disabled,
the caller must call ModulesDidLoad after adding all the new modules,
but postponing this notification until they're all batched up can
allow for better efficiency than notifying one-by-one.

Change the name of the ModuleList notifier functions that a subclass
can implement to start with 'Notify' to make it clear what they are.
Add a NotifyModulesRemoved.

Add header documentation for the changed/updated methods.

Added defaulted-value 'notify' argument to ModuleList Append,
AppendIfNeeded, and Remove because callers working with a local
ModuleList don't have an obvious idea of what notify means in this
context.  When the ModuleList is a part of the Target class, the
notify behavior matters.

DynamicLoaderDarwin has been updated so that libraries being
added/removed are correctly batched up before notifications are
sent.  Added the TestModuleLoadedNotifys.py test to run on 
Darwin to test this.

<rdar://problem/48293064> 

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

llvm-svn: 357955

This is a follow-up to r357829 (https://reviews.llvm.org/D60340) to
see whether increasing the packet timeout for non-asan builds could
also positively affect the stability of non-asan bots.

llvm-svn: 357954

PR41425:
https://bugs.llvm.org/show_bug.cgi?id=41425

llvm-svn: 357953

This reverts commit e7bd735b.
Reverting because of buildbot failure.

llvm-svn: 357952

Summary:
The previous logging infrastructure had several problems:

* Debugging output was emitted to standard output which is also where
  the symbolized output would go. Interleaving these two separate
  bits of information makes inspecting the output difficult and could
  potentially break tests.

* Enabling debugging output requires modifying the script which is
  not very conveninent.

* When debugging it isn't immediately obvious where the output is
  coming from.

This patch uses the Python standard library logging infrastructure
which fixes all of the above problems. Logging is controlled using
two new options.

* `--log-level` - Sets the logging level, default is
`info`.
* `--log-dest` - Set the logging destination, default
is standard error.

Some simple test cases for the feature are included.

rdar://problem/49476995

Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka

Subscribers: #sanitizers, llvm-commits

Tags: #llvm, #sanitizers

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

llvm-svn: 357951

llvm-svn: 357950

The INIT_COMPLETE write now writes to the entire guard object
instead of just one byte.

llvm-svn: 357949

llvm::StringRef host_and_port is not guaranteed to be null-terminated.
Generally, it is not safe at all to convert a StringRef into a char *
by calling data() on it.

<rdar://problem/49698580>

llvm-svn: 357948

This will allow RuntimeDyldChecker (and rtdyld-check tests) to test a new JIT
linker: JITLink (https://reviews.llvm.org/D58704).

llvm-svn: 357947

CMake already specifies those, and we never actually want those to be
used. In fact, r357811 re-ordered those flags in a way that the
explicitly-provided install_name was overriding the CMake-provided
install_name (instead of the other way around). This caused the dylib
to be considered a system dylib, and hence the explicitly provided rpath
to be ignored. This, in turn, caused some unit tests to start linking
against the system libc++.dylib instead of the freshly-built one.
Specifically, the unit tests that started linking against the system
dylib are those that didn't specify a DYLD_LIBRARY_PATH, such as
last_write_time.sh.cpp.

llvm-svn: 357946

The new value is taken from <mach/machine.h> in the MacOSX10.14 SDK from
Xcode 10.1. Update llvm-objdump and llvm-readobj accordingly.

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

llvm-svn: 357945

The read of the guard variable by the caller is atomic,
and doesn't happen under a mutex.

Our internal reads and writes were non-atomic, because they happened
under a mutex.

The writes should always be atomic since they can be observed outside
of the lock.

Making the reads atomic is not strictly necessary under the current
global mutex approach, but will be under implementations that use a
futex (which I plan to land shortly). However, they should add little
additional cost.

llvm-svn: 357944

A more general canonicalization between fdiv and fmul would not
handle this case because that would have to be limited by uses
to prevent 2 values from becoming 3 values:
(x/y) * (x/y) --> (x*x) / (y*y)

(But we probably should still have that limited -- but more general --
canonicalization independently of this change.)

llvm-svn: 357943

Be more selective in the SimplifyDemandedBits -> SimplifyDemandedVectorElts bitcast call based on the demanded elts.

llvm-svn: 357942

Summary:
These all had somewhat custom file headers with different text from the
ones I searched for previously, and so I missed them. Thanks to Hal and
Kristina and others who prompted me to fix this, and sorry it took so
long.

Reviewers: hfinkel

Subscribers: mcrosier, javed.absar, cfe-commits

Tags: #clang

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

llvm-svn: 357941

[ASTImporter] Call to HandleNameConflict in VisitEnumDecl mistakeningly using Name instead of SearchName

Summary:
https://reviews.llvm.org/D51633 added error handling to the ASTNodeImporter::VisitEnumDecl(...) for the conflicting names case. This could lead to erroneous return of an error in that case since we should have been using SearchName. Name may be empty in the case where we find the name via getTypedefNameForAnonDecl(...).

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

llvm-svn: 357940

llvm-svn: 357939

Overflow conditions for sadd.sat and ssub.sat which can be determined
based on constant ranges, but not necessarily known bits.

llvm-svn: 357938

Summary:
- `@property(attr, attr2)` instead of `@property ( attr,attr2 )`.
- Change priority of attributes (see code/comments inline).
- Support for printing weak and unsafe_unretained attributes.

Subscribers: arphaman, jfb, cfe-commits

Tags: #clang

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

llvm-svn: 357937