llvm-svn: 249803

The current implementation of `StrengthenNoWrapFlags` is agnostic to the
order of `Ops`, so this commit should not change anything semantic.  An
upcoming change will make `StrengthenNoWrapFlags` sensitive to the order
of `Ops`.

llvm-svn: 249802

llvm-svn: 249801

llvm-svn: 249800

It works on Windows now.

llvm-svn: 249799

As with <stddef.h>, skip our custom header if __need_FILE or __need___FILE is defined.

llvm-svn: 249798

Apparently system-windows was only a clang lit suite feature.

llvm-svn: 249797

This reverts commit r249794.

Apparently my checkouts are full of unexpected surprises today.

llvm-svn: 249796

llvm-svn: 249795

This reverts commit r249032.

TODO write commit msg

llvm-svn: 249794

llvm-svn: 249793

Summary:
 - Recurse from cleanupendpads to their cleanuppads, to make sure the
   cleanuppad is visited if it has a cleanupendpad but no cleanupret.
 - Check for and avoid double-processing cleanuppads, to allow for them to
   have multiple cleanuprets (plus cleanupendpads).
 - Update Cxx state numbering to visit toplevel cleanupendpads and to
   recurse from cleanupendpads to their preds, to ensure we number any
   funclets in inlined cleanups.  SEH state numbering already did this.

Reviewers: rnk

Subscribers: llvm-commits

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

llvm-svn: 249792

llvm-svn: 249791

builtins:

avx512vd -> avx512vl
rdrand -> rdrnd
avx512ff -> avx512f

no functional change.

llvm-svn: 249790

llvm-svn: 249789

PR25118: move system_header pragma before uses of include_next to avoid extension warnings for people finding libc++ headers via -I paths.

llvm-svn: 249788

Summary:
Currently when a function annotated with __attribute__((nonnull)) is called in an unevaluated context with a null argument a -Wnonnull warning is emitted. 
This warning seems like a false positive unless the call expression is potentially evaluated. Change this behavior so that the non-null warnings use DiagRuntimeBehavior so they wont emit when they won't be evaluated.

Reviewers: majnemer, rsmith

Subscribers: mclow.lists, cfe-commits

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

llvm-svn: 249787

I called the wrong MachineBasicBlock::addLiveIn() overload.

llvm-svn: 249786

llvm-svn: 249785

Summary:
Previously the relative address flag only affected PDB debug info.  Now
both DIContext implementations always expect to be passed virtual
addresses. llvm-symbolizer is now responsible for adding ImageBase to
module offsets when --relative-offset is passed.

Reviewers: zturner

Subscribers: llvm-commits

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

llvm-svn: 249784

Apparently the iterators in `clang::CFGBlock` have an auto-conversion to
`CFGBlock *`, but the dereference operator gives `const CFGBlock &`.
Until I have a moment to fix that, revert the GenericDomTree chagnes
from r249782.

llvm-svn: 249783

Stop converting implicitly between iterators and pointers/references in
lib/IR.  For convenience, I've added a `getIterator()` accessor to
`ilist_node` so that callers don't need to know how to spell the
iterator class (i.e., they can use `X.getIterator()` instead of
`Function::iterator(X)`).

I'll eventually disallow these implicit conversions entirely, but
there's a lot of code, so it doesn't make sense to do it all in one
patch.  One library or so at a time.

Why?  To root out cases of `getNextNode()` and `getPrevNode()` being
used in iterator logic.  The design of `ilist` makes that invalid when
the current node could be at the back of the list, but it happens to
"work" right now because of a bug where those functions never return
`nullptr` if you're using a half-node sentinel.  Before I can fix the
function, I have to remove uses of it that rely on it misbehaving.
(Maybe the function should just be deleted anyway?  But I don't want
deleting it -- potentially a huge project -- to block fixing
ilist/iplist.)

llvm-svn: 249782

Also added a few comments.

llvm-svn: 249781

llvm-svn: 249780

Summary:
These non-semantic changes will help make a later change adding
support for deopt operand bundles more streamlined.

Reviewers: reames, swaroop.sridhar

Subscribers: sanjoy, llvm-commits

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

llvm-svn: 249779

This is to enable me to address review for D13491 -- `Flags` is a
bitfield of `StatepointFlags`, not an individual item out of the enum,
so it should be represented as an `uint32_t`.

llvm-svn: 249778

Summary:
This will be used in a later change to RewriteStatepointsForGC.

Reviewers: reames, swaroop.sridhar

Subscribers: llvm-commits

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

llvm-svn: 249777

Summary: Use `const auto &` instead of `auto` in `makeStatepointExplicit`.

Reviewers: reames, swaroop.sridhar

Subscribers: llvm-commits

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

llvm-svn: 249776

These are enabled by default in clang-cl, because the whole idea is that
it should work like cl.exe, but I suppose it can make sense to disable
them if someone wants to compile code in a more strict mode.

llvm-svn: 249775

and expressions.  Also wired that into the OptionValue infrastructure, although
it isn't used for tab-completion yet.

llvm-svn: 249769

from malformed Mach-O files that caused a crash because of a
section header had a size that extended past the end of the file.

rdar://22983603

llvm-svn: 249768

Stop relying on ilist implicit conversions from `value_type&` to
`iterator` in YAMLParser.cpp.

I eventually want to outlaw this entirely.  It encourages
`getNextNode()` and `getPrevNode()` in iterator logic, which is
extremely fragile (and relies on them never returning `nullptr`).

FTR, there's nothing nefarious going on in this case, it was just easy
to clean up since the callers really wanted iterators to begin with.

llvm-svn: 249767

Clang supports SEH well enough that this should work out of the box.  If
it doesn't, we'll hear about it.

llvm-svn: 249766

llvm-svn: 249765

Stop using `getNextNode()` to get an insertion point (at least, in this
one place).  Instead, use iterator logic directly.

The `getNextNode()` interface isn't actually supposed to work for
creating iterators; it's supposed to return `nullptr` (not a real
iterator) if this is the last node.  It's currently broken and will
"happen" to work, but if we ever fix the function, we'll get some
strange failures in places like this.

llvm-svn: 249764

Stop using `getNextNode()` to get an iterator to a fragment (at least,
in this one place).  Instead, use iterator logic directly.

The `getNextNode()` interface isn't actually supposed to work for
creating iterators; it's supposed to return `nullptr` (not a real
iterator) if this is the last node.  It's currently broken and will
"happen" to work, but if we ever fix the function, we'll get some
strange failures in places like this.

llvm-svn: 249763

Even if we don't have it in PATH, lipo should usually exist in the same directory
as dsymutil. Keep the fallback looking up the PATH, it's very useful when
testing a non-installed executable.

llvm-svn: 249762

There are a bunch of macros (__need_size_t etc) that request just one piece of
<stddef.h>; if any one of these is defined, we just directly include the
underlying header.

Note that <stddef.h> provides a ::nullptr_t. We don't want that available to
includers of <cstddef>, so instead of following the usual pattern where <cfoo>
includes <foo.h> then pulls things from :: into std:: with using-declarations,
we implement <stddef.h> and <cstddef> separately; both include <__nullptr> for
the definition of std::nullptr_t.

llvm-svn: 249761

The required page alignment is different on different targets. On PowerPC, for
example, we need 64K pages (the loader won't set different permissions on a
finer granularity than that). I've set the existing targets to what I believe
to be the correct values, and have updated the regression tests accordingly.

llvm-svn: 249760

CMake build rules listed -I flags for two different libc++ header
locations which broke when libc++ headers started using include_next.

Also change -I to -isystem to avoid compiler warning about
include_next.

llvm-svn: 249759