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

For functions whose callers don't check that enough input is present,
add checks at the start of the function that enough input is there and
set Error otherwise.

For functions that return AST objects, return nullptr instead of
incomplete AST objects with nullptr fields if an error occurred during
the function.

Introduce a new function demangleDeclarator() for the sequence
demangleFullyQualifiedSymbolName(); demangleEncodedSymbol() and
use it in the two places that had this sequence. Let this new function
check that ConversionOperatorIdentifiers have a valid TargetType.

Some of the bad inputs found by oss-fuzz, others by inspection.

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

llvm-svn: 357936

[X86] Fix a couple lowering functions that called ReplaceAllUsesOfValueWith for the newly created code and then return SDValue(). Use MERGE_VALUES instead.

Returning SDValue() makes the caller think custom lowering was unsuccessful and then it will fall back to trying to expand the original node. This expanded code will end up with no users and end up being pruned later. But it was useless unnecessary work to create it.

Instead return a MERGE_VALUES with all the results so the caller knows something changed. The caller can handle the replacements.

For one of the cases I had to use UNDEF has a dummy value for a result we know is unused. This should get pruned later.

llvm-svn: 357935

    COMMON blocks are a feature of Fortran that has no direct analog in C languages, but they are similar to data sections in assembly language programming. A COMMON block is a named area of memory that holds a collection of variables. Fortran subprograms may map the COMMON block memory area to their own, possibly distinct, non-empty list of variables. A Fortran COMMON block might look like the following example.

    COMMON /ALPHA/ I, J

    For this construct, the compiler generates a new scope-like DI construct (!DICommonBlock) into which variables (see I, J above) can be placed. As the common block implies a range of storage with global lifetime, the !DICommonBlock refers to a !DIGlobalVariable. The Fortran variable that comprise the COMMON block are also linked via metadata to offsets within the global variable that stands for the entire common block.

    @alpha_ = common global %alphabytes_ zeroinitializer, align 64, !dbg !27, !dbg !30, !dbg !33
    !14 = distinct !DISubprogram(…)
    !20 = distinct !DICommonBlock(scope: !14, declaration: !25, name: "alpha")
    !25 = distinct !DIGlobalVariable(scope: !20, name: "common alpha", type: !24)
    !27 = !DIGlobalVariableExpression(var: !25, expr: !DIExpression())
    !29 = distinct !DIGlobalVariable(scope: !20, name: "i", file: !3, type: !28)
    !30 = !DIGlobalVariableExpression(var: !29, expr: !DIExpression())
    !31 = distinct !DIGlobalVariable(scope: !20, name: "j", file: !3, type: !28)
    !32 = !DIExpression(DW_OP_plus_uconst, 4)
    !33 = !DIGlobalVariableExpression(var: !31, expr: !32)

    The DWARF generated for this is as follows.

    DW_TAG_common_block:
    DW_AT_name: alpha
    DW_AT_location: @alpha_+0
    DW_TAG_variable:
    DW_AT_name: common alpha
    DW_AT_type: array of 8 bytes
    DW_AT_location: @alpha_+0
    DW_TAG_variable:
    DW_AT_name: i
    DW_AT_type: integer*4
    DW_AT_location: @Alpha+0
    DW_TAG_variable:
    DW_AT_name: j
    DW_AT_type: integer*4
    DW_AT_location: @Alpha+4

Patch by Eric Schweitz!

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

llvm-svn: 357934

Functions __kmpc_alloc/__kmpc_free are updated with the new interfaces.
Patch synchronizes the compiler with the runtime.

llvm-svn: 357933

This reverts r357931 (git commit 8b70a5c1)

llvm-svn: 357932

Summary:
ThinLTOCodeGenerator currently does not preserve llvm.used symbols and
it can internalize them. In order to pass the necessary information to the
legacy ThinLTOCodeGenerator, the input to the code generator is
rewritten to be based on lto::InputFile.

This fixes: PR41236
rdar://problem/49293439

Reviewers: tejohnson, pcc, dexonsmith

Reviewed By: tejohnson

Subscribers: mehdi_amini, inglorion, eraman, hiraditya, jkorous, dang, llvm-commits

Tags: #llvm

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

llvm-svn: 357931

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

There is potential for miscompiled code emitted from JumpThreading when
analyzing a block with one or more indirectbr or callbr predecessors. The
ProcessThreadableEdges() function incorrectly folds conditional branches
into an unconditional branch.

This patch prevents incorrect branch folding without fully pessimizing
other potential threading opportunities through the same basic block.

This IR shape was manually fed in via opt and is unclear if clang and the
full pass pipeline will ever emit similar code shapes.

Thanks to Matthias Liedtke for the bug report and simplified IR example.

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

llvm-svn: 357930

* Replace HBWMALLOC API with more general MEMKIND API, new functions
  and variables added.
* Have libmemkind.so loaded when accessible.
* Redirect memspaces to default one except for high bandwidth which
  is processed separately.
* Ignore some allocator traits e.g., sync_hint, access, pinned, while
  others are processed normally e.g., alignment, pool_size, fallback,
  fb_data, partition.
* Add tests for memory management

Patch by Andrey Churbanov

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

llvm-svn: 357929

Summary:
Emit !heapallocsite in the metadata for calls to functions marked with
__declspec(allocator). Eventually this will be emitted as S_HEAPALLOCSITE debug
info in codeview.

Reviewers: rnk

Subscribers: jfb, cfe-commits

Tags: #clang

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

llvm-svn: 357928

This patch cleans up the bookkeeping code for the load balancing dynamic mode.

When a thread is moved to or from the thread pool, the th_active_in_pool flag
and the __kmp_thread_pool_active_nth global counter are both updated. This
removes the need for the corrective code in the main wait loop. Another global
counter, __kmp_thread_pool_nth, was removed completely, as it was only used for
debugging, but was not under KMP_DEBUG.

Patch by Terry Wilmarth

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

llvm-svn: 357927

For partitions I intend to use the same set of version indexes in
each partition for simplicity. Since each partition will need its own
VersionNeedSection this will require moving the verneed tracking out of
VersionNeedSection. The way I've done this is to move most of the tracking
into SharedFile. What will eventually become the per-partition tracking
still lives in VersionNeedSection.

As a bonus the code gets a little simpler and more consistent with how we
handle verdef.

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

llvm-svn: 357926

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

llvm-svn: 357925

[X86] Add some fp to integer conversion intrinsics to Sema::CheckX86BuiltinRoundingOrSAE so their rounding controls will be checked.

If we don't check this in the frontend we'll get an isel error in the backend later. This is far less friendly to users.

llvm-svn: 357924

Added special processing of the memory management directives/clauses for
NVPTX target. For private locals, omp_default_mem_alloc and
omp_thread_mem_alloc result in allocation in local memory.
omp_const_mem_alloc allocates const memory, omp_teams_mem_alloc
allocates shared memory, and omp_cgroup_mem_alloc and
omp_large_cap_mem_alloc allocate global memory.

llvm-svn: 357923

llvm-svn: 357922