This is the requirement for all functions in the public API,
to eliminate weak symbol definitions.

llvm-svn: 299020

This should work on all platforms now that r299006 has landed.  Tested locally
on Windows and Linux.

This moves exe symbol-specific method implementations out of NativeRawSymbol
into a concrete subclass. Also adds implementations for hasCTypes and
hasPrivateSymbols and a simple test to ensure the native reader can access the
summary information for the executable from the PDB.

Original Differential Revision: https://reviews.llvm.org/D31059

llvm-svn: 299019

Do that by creating a global_values, which is similar to
global_objects, but also iterates over aliases and ifuncs.

llvm-svn: 299018

Some of the GEP combines (e.g., descaling) can't handle vector GEPs. We have an
existing check that attempts to bail out if given a vector GEP. However, the
check only tests the GEP's pointer operand. A GEP results in a vector of
pointers if at least one of its operands is vector-typed (e.g., its pointer
operand could be a scalar, but its index could be a vector). We should just
check the type of the GEP itself. This should fix PR32414.

Reference: https://bugs.llvm.org/show_bug.cgi?id=32414
Differential Revision: https://reviews.llvm.org/D31470

llvm-svn: 299017

Add allocator_frees_and_returns_null_on_realloc_zero=false flag for compatibility with allocators which allow a realloc(p, 0) and don't free the pointer.

Summary:
I know of two implementations that do this (ASan is not protecting against accessing the returned memory for now, just like malloc(0)):
SIE libc on the PS4
dlmalloc has a flag for this

This allows us to properly support this behaviour.

Reviewers: vsk, kcc

Subscribers: llvm-commits, kubamracek

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

llvm-svn: 299016

Summary: After examining the remaining uses of LangOptions.ObjCAutoRefCount, found a some additional places to also check for ObjCWeak not covered by previous test cases. Added a test file to verify all the code paths that were changed.

Reviewers: rsmith, doug.gregor, rjmccall

Reviewed By: rjmccall

Subscribers: cfe-commits

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

llvm-svn: 299015

Summary: clang should produce the same errors Objective-C classes that cannot be assigned to weak pointers under both -fobjc-arc and -fobjc-weak. Check for ObjCWeak along with ObjCAutoRefCount when analyzing pointer conversions. Add an -fobjc-weak pass to the existing arc-unavailable-for-weakref test cases to verify the behavior is the same.

Reviewers: rsmith, doug.gregor, rjmccall

Reviewed By: rjmccall

Subscribers: cfe-commits

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

llvm-svn: 299014

We had a mix of type checks and usage that wasn't very clear.

llvm-svn: 299013

llvm-svn: 299012

Summary: -Warc-repeated-use-of-weak should produce the same warnings with -fobjc-weak as it does with -objc-arc. Also check for ObjCWeak along with ObjCAutoRefCount when recording the use of an evaluated weak variable. Add a -fobjc-weak run to the existing arc-repeated-weak test case and adapt it slightly to work in both modes.

Reviewers: rsmith, doug.gregor, jordan_rose, rjmccall

Reviewed By: rjmccall

Subscribers: arphaman, rjmccall, cfe-commits

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

llvm-svn: 299011

Summary: Similar to ARC, in ObjCWeak Objective-C object pointers qualified with a weak lifetime are not POD or trivial types. Update the type trait code to reflect this. Copy and adapt the arc-type-traits.mm test case to verify correctness.

Reviewers: rsmith, doug.gregor, rjmccall

Reviewed By: rjmccall

Subscribers: cfe-commits

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

llvm-svn: 299010

Summary:
When a PCH is included via -include-pch, clang should treat the
current TU as dependent on the sourcefile that the PCH was generated from.

This is currently _partly_ accomplished by InitializePreprocessor calling
AddImplicitIncludePCH to synthesize an implicit #include of the sourcefile,
into the preprocessor's Predefines buffer.

For FrontendActions such as PreprocessOnlyAction (which is, curiously, what the
driver winds up running one of in response to a plain clang -M) this is
sufficient: the preprocessor cranks over its Predefines and emits a dependency
reference to the initial sourcefile.

For other FrontendActions (for example -emit-obj or -fsyntax-only) the
Predefines buffer is reset to the suggested predefines buffer from the PCH, so
the dependency edge is lost. The result is that clang emits a .d file in those
cases that lacks a reference to the .h file responsible for the input (and in
Swift's case, our .swiftdeps file winds up not including a reference to the
source file for a PCH bridging header.)

This patch fixes the problem by taking a different tack: ignoring the
Predefines buffer (which seems a bit like a hack anyways) and directly
attaching the CompilerInstance's DependencyCollectors (and legacy
DependencyFileGenerator) to the ASTReader for the external AST.

This approach is similar to the one chosen in earlier consultation with Bruno
and Ben, and I think it's the least-bad solution, given several options.

Reviewers: bruno, benlangmuir, doug.gregor

Reviewed By: bruno, doug.gregor

Subscribers: cfe-commits

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

llvm-svn: 299009

Summary: When adding an Objective-C retainable type member to a C++ class, also check the LangOpts.ObjCWeak flag and the lifetime qualifier so __weak qualified Objective-C pointer members cause the class to be a non-POD type with non-trivial special members, so the compiler always emits the necessary runtime calls for copying, moving, and destroying the weak member. Otherwise, Objective-C++ classes with weak Objective-C pointer members compiled with -fobjc-weak exhibit undefined behavior if the C++ class is classified as a POD type.

Reviewers: rsmith, benlangmuir, doug.gregor, rjmccall

Reviewed By: rjmccall

Subscribers: cfe-commits

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

llvm-svn: 299008

Remove trailing whitespace.

llvm-svn: 299007

The -output-color option was successful at suppressing color changes, but
was still allowing color resets.

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

llvm-svn: 299006

The same test fails on clang-cmake-armv7-a15-full biuld bot
but passes the clang-cmake-thumbv7-a15-full.

For now, we mark it as UNSUPPORTED for armhf target.
Bug 32457 tracks it.

llvm-svn: 299005

llvm-svn: 299004

llvm-svn: 299002

Summary:
But don't actually inspect the tree any deeper than we already do. This
change is NFC but the next one will enable full traversal of the
source/destination patterns.

Depends on D30535

Reviewers: t.p.northover, qcolombet, aditya_nandakumar, rovka, ab

Subscribers: igorb, dberris, llvm-commits, kristof.beyls

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

llvm-svn: 299001

llvm-svn: 299000

As of r298987 the argument is a value that we std::move, so it
shouldn't be const anymore.

llvm-svn: 298999

This patch changes GnuHashTableSection implementation
to avoid depend on uintX_t and other ELFT stuff, reducing amount of 
changes for following patch(es).

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

llvm-svn: 298998

It was XFAILed in r298974. However, the problem was not exposed on
the buildbot because hardfp flag was not passed during the test.

We can fix the CMAKE to pass the same flag as building the lib to the
RUN line to see if the problem is still there. For now, we remove the
XFAIL.

llvm-svn: 298997

Make the enumerators follow the coding convention and start with OW_...

llvm-svn: 298996

Patch by Wei-Ren Chen!

llvm-svn: 298995

llvm-svn: 298994

[X86][AVX2] Prevent unary interleaving patterns from calling lowerVectorShuffleAsSplitOrBlend (PR32453)

llvm-svn: 298993

llvm-svn: 298992

Based on comment in D31249.

llvm-svn: 298991

llvm-svn: 298989

No longer makes sense as the previous opcode mnemonic it was referring to is long gone.

llvm-svn: 298988

Instantiation of the MachineVerifierPass through
PassInfo::getNormalCtor would yield a segfault since the default
constructor of the MachineVerifierPass takes a reference to nullptr.

Patch by Simone Pellegrini.

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

llvm-svn: 298987

llvm-svn: 298986

llvm-svn: 298985

[AVX-512] Remove explicit KMOVWrk/KMOVWKr instructions from patterns where we can just use COPY_TO_REGCLASS instead.

This will result in a KMOVW or KMOVD being emitted during register allocation. And in at least some cases this might allow the register coalescer to remove the copy all together.

llvm-svn: 298984

Summary:
It is problematic for this reader that it expects to read data from
several threads, but the header or message format does not define
framing. Since the buffers are reused, we can't rely on skipping
zeroed out data as a synchronization method either.

There is an argument that this is not version compatible with the format
the reader expected previously. I argue that since the writer wrote garbage
past the end of buffer record, there is no currently working reader to
compromise.

The corresponding writer change is posted to D31384.

Reviewers: dberris, pelikan

Reviewed By: dberris

Subscribers: llvm-commits

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

llvm-svn: 298983

Summary:
Currently the FDR log writer, upon flushing, dumps a sequence of buffers from
its freelist to disk. A reader can read the first buffer up to an EOB record,
but then it is unclear how far ahead to scan to find the next threads traces.

There are a few ways to handle this problem.
1. The reader has externalized knowledge of the buffer size.
2. The size of buffers is in the file header or otherwise encoded in the log.
3. Only write out the portion of the buffer with records. When released, the
   buffers are marked with a size.
4. The reader looks for memory that matches a pattern and synchronizes on it.

2 and 3 seem the most flexible and 2 does not rule 3 out.

This is an implementation of 2.

In addition, the function handler for fdr more aggressively checks for
finalization and makes an attempt to release its buffer.

Reviewers: pelikan, dberris

Reviewed By: dberris

Subscribers: llvm-commits

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

llvm-svn: 298982

llvm-svn: 298978

Summary:
This change exercises the end-to-end functionality defined in the FDR
logging implementation. We also prepare for being able to run traces
generated by the FDR logging implementation from being analysed with the
llvm-xray command that comes with the LLVM distribution.

This also unblocks D31385, D31384, and D31345.

Reviewers: kpw, pelikan

Subscribers: llvm-commits, mgorny

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

llvm-svn: 298977

Reviewers: cfe-commits, Anastasia

Reviewed By: Anastasia

Subscribers: yaxunl, bader

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

llvm-svn: 298976