this is the last of them in my build of LLVM. Haven't tried Clang yet.

Found via UBSan.

llvm-svn: 243934

It's already in SysRegMappings, no need to also have it in MSRMappings:
the latter is only used if we didn't find a match in the former.

llvm-svn: 243933

This too was found by UBSan. Down to 35 failures for me.

llvm-svn: 243932

llvm-svn: 243931

llvm-svn: 243930

llvm-svn: 243929

This happens to work, but is not guaranteed to work. Indeed, most memcpy
interfaces in Linux-land annotate these arguments as nonnull, and GCC
and LLVM both can and do optimized based upon that. When they do so,
they might legitimately have miscompiled code calling this routine with
two valid iterators, 'nullptr' and 'nullptr'. There was even code doing
precisely this because StringRef().begin() and StringRef().end() both
produce null pointers.

This was found by UBSan.

llvm-svn: 243927

There's a bunch of code in LowerFCOPYSIGN that does smart lowering, and
is actually already vector-aware; let's use it instead of scalarizing!

The only interesting change is that for v2f32, we previously always used
use v4i32 as the integer vector type.
Use v2i32 instead, and mark FCOPYSIGN as Custom.

llvm-svn: 243926

We used to legalize it like it's any other binary operations.  It's not,
because it accepts mismatched operand types.  Because of that, we used
to hit various asserts and miscompiles.

Specialize vector legalizations to, in the worst case, unroll, or, when
possible, to just legalize the operand that needs legalization.

Scalarization isn't covered, because I can't think of a target where
some but not all of the 1-element vector types are to be scalarized.

llvm-svn: 243924

llvm-svn: 243923

llvm-svn: 243922

llvm-svn: 243921

The previous commits moved this functionality into the client.

Also remove the now unused member variable.

llvm-svn: 243920

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 243918

From: Erik de Castro Lopo <erikd@qti.qualcomm.com>
llvm-svn: 243917

From: Erik de Castro Lopo <erikd@qti.qualcomm.com>
llvm-svn: 243916

Reviewers: Duncan P. N. Exon Smith
llvm-svn: 243915

llvm-svn: 243914

Summary: Simple test case to verify that an instance of a derived class with virtual base is properly poisoned

Reviewers: eugenis, kcc

Subscribers: cfe-commits

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

modified test to be more concise, and check the local pointer to the destroyed object

revised test to not examine padding- only explicit object members

llvm-svn: 243913

Summary: In addition to checking compiler flags, the front-end also examines the attributes of the destructor definition to ensure that the SanitizeMemory attribute is attached.

Reviewers: eugenis, kcc

Subscribers: cfe-commits

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

refactored test into new file, revised how function attribute examined

modified test to examine default dtor with and without attribute

removed attribute check

llvm-svn: 243912

It's better to pass libLTO to ld64 via the command line flag than rely
on setting DYLD_LIBRARY_PATH.

llvm-svn: 243911

llvm-svn: 243910

Various value handles needed to be copy constructible and copy
assignable (mostly for their use in DenseMap). But to avoid an API that
might allow accidental slicing, make these members protected in the base
class and make derived classes final (the special members become
implicitly public there - but disallowing further derived classes that
might be sliced to the intermediate type).

Might be worth having a warning a bit like -Wnon-virtual-dtor that
catches public move/copy assign/ctors in classes with virtual functions.
(suppressable in the same way - by making them protected in the base,
and making the derived classes final) Could be fancier and only diagnose
them when they're actually called, potentially.

Also allow a few default implementations where custom implementations
(especially with non-standard return types) were implemented.

llvm-svn: 243909

This adds the required target feature names to x86 builtins that need
particular features. Most have exactly one ("avx", "aes", etc), but some
of the avx512 features have multiple requirements, eg "avx512vl,avx512bw".

llvm-svn: 243908

llvm-svn: 243907

"this namespace alias decl is unused" -> "namespace alias decl '...' is unused"

llvm-svn: 243906

llvm-svn: 243905

Fixes obvious memory leak in test
TestForEofAfterReadFailureOnDataStreamer.  Also removes constexpr use
from same test.

Patch by Karl Schimpf.

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

llvm-svn: 243904

llvm-svn: 243903

llvm-svn: 243902

(Because, hey, who wouldn't?)

llvm-svn: 243901

through PHI nodes across iterations.

This patch teaches the new advanced loop unrolling heuristics to propagate
constants into the loop from the preheader and around the backedge after
simulating each iteration. This lets us brute force solve simple recurrances
that aren't modeled effectively by SCEV. It also makes it more clear why we
need to process the loop in-order rather than bottom-up which might otherwise
make much more sense (for example, for DCE).

This came out of an attempt I'm making to develop a principled way to account
for dead code in the unroll estimation. When I implemented
a forward-propagating version of that it produced incorrect results due to
failing to propagate *cost* between loop iterations through the PHI nodes, and
it occured to me we really should at least propagate simplifications across
those edges, and it is quite easy thanks to the loop being in canonical and
LCSSA form.

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

llvm-svn: 243900

llvm-svn: 243899

While checking for the existence of the clang-tools-extra directory,
the script was not checking for its destination name, "extra", and
the script was failing when re-running without checking out new
sources.

llvm-svn: 243898

Some functions return concrete ByteStreamers by value - explicitly
support that in the base class. (dtor can be virtual, no one seems to be
polymorphically owning/destroying them)

llvm-svn: 243897

Recommit r243824: -Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are deprecated in C++11

This reverts commit r243888, recommitting r243824.

This broke the Windows build due to a difference in the C++ standard
library implementation. Using emplace/forward_as_tuple should ensure
there's no need to copy ValIDs.

llvm-svn: 243896

Summary:
This is consistent with binutils and ASan behavior on other platforms,
and makes it easier to use llvm-symbolizer with WinASan. The
--relative-address flag to llvm-symbolizer is also no longer needed.

An RVA is a "relative virtual address", meaning it is the address of
something inside the image minus the base of the mapping at runtime.

A VA in this context is an RVA plus the "preferred base" of the module,
and not a real runtime address. The real runtime address of a symbol
will equal the VA iff the module is loaded at its preferred base at
runtime.

On Windows, the preferred base is stored in the ImageBase field of one
of the PE file header, and this change adds the necessary code to
extract it. On Linux, this offset is typically included in program and
section headers of executables.

ELF shared objects typically use a preferred base of zero, meaning the
smallest p_vaddr field in the program headers is zero. This makes it so
that PIC and PIE module offsets come out looking like RVAs, but they're
actually VAs. The difference between them simply happens to be zero.

Reviewers: samsonov, majnemer

Subscribers: llvm-commits

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

llvm-svn: 243895

Also converted a cast<> to dyn_cast while i was working on the same
line of code.

llvm-svn: 243894

llvm-svn: 243893

Thanks to Aaron Ballman for spotting this.

llvm-svn: 243891