We still have to skip a token inside SEARCH_DIR() when -nostdlib is
specified. Previuosly, we didn't skip it, so it caused a parse error.

llvm-svn: 281001

Add a missing ')' in the help output.  NFC.

llvm-svn: 281000

export-declarations. These don't yet have an effect on name visibility;
we still export everything by default.

llvm-svn: 280999

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

llvm-svn: 280998

Reviewers: thakis, Prazek, compnerd, rnk

Subscribers: majnemer, cfe-commits

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

llvm-svn: 280997

llvm-svn: 280996

Summary: The hoisted instruction is executed speculatively. It could affect the debugging experience as user would see gdb go into code that may not be expected to execute. It will also affect sample profile accuracy by assigning incorrect frequency to source within then/else branch.

Reviewers: davidxl, dblaikie, chandlerc, kcc, echristo

Subscribers: mehdi_amini, probinson, eric_niebler, andreadb, llvm-commits

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

llvm-svn: 280995

llvm-svn: 280994

llvm-svn: 280993

The test case included in r280979 wasn't checking what it was supposed to be
checking for the predicated store case. Fixing the test revealed that the
multi-use case (when a pointer is used by both vectorized and scalarized memory
accesses) wasn't being handled properly. We can't skip over
non-consecutive-like pointers since they may have looked consecutive-like with
a different memory access.

llvm-svn: 280992

llvm-svn: 280991

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

llvm-svn: 280990

lld differs from GNU ld in that it does not have a built-in default
target emulation. Emulation is always specified via the -m option, or
obtained from the object file(s) being linked. In most cases at least
one ELF object is included in the link, so the emulation is known.

When using lld's (not yet committed) -b binary support with -r, to
convert a binary file into an ELF object we do not have a known
emulation. The error message previously emitted in this case
"-m or at least a .o file required" is accurate but does not offer
much insight. Add text to the error message to give a hint why -m or an
object file is required.

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

llvm-svn: 280989

Visual Studio 2013 (CRT version 12) added support for many C99 long long and
long double functions. Visual Studio 2015 (CRT version 14) increased C99 and C11
compliance further. Since we don't support Visual Studio versions older than
2013, we can considerably clean up the support header.

Patch by Shoaib Meenai!

llvm-svn: 280988

llvm-svn: 280987

llvm-svn: 280986

llvm-svn: 280985

In C mode, if we have a visible declaration but not a visible definition, a tag
defined in the declaration should be have a visible definition. In C++ we rely
on the ODR merging, whereas in C we cannot because each declaration of a
function gets its own set of declarations in its prototype scope.

Patch developed in collaboration with Richard Smith!

llvm-svn: 280984

A trailing _fbsd is stripped from emulation names, but if the result was
still not a valid emulation the error was somewhat confusing.

For example,

% ld.lld -m elf_amd64_fbsd
unknown emulation: elf_amd64

Use the original emulation name in error messages.

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

llvm-svn: 280983

In the FreeBSD world x86_64 still has its original name, amd64. Accept
it as an alias.

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

llvm-svn: 280982

The text and html coverage views take different approaches to emitting
highlighted regions. That's because this problem is easier in the text
view: there's no need to worry about escaping text or adding tooltip
content to a highlighted snippet.

Unfortunately, the html view didn't get region highlighting quite right.

This patch fixes the situation, bringing parity between the two views.

llvm-svn: 280981

Disable the new abort-in-SIGABRT code under SANITIZER_GO.

llvm-svn: 280980

Previously, all consecutive pointers were marked uniform after vectorization.
However, if a consecutive pointer is used by a memory access that is eventually
scalarized, the pointer won't remain uniform after all. An example is
predicated stores. Even though a predicated store may be consecutive, it will
still be scalarized, making it's pointer operand non-uniform.

This patch updates the logic in collectLoopUniforms to consider the cases where
a memory access may be scalarized. If a memory access may be scalarized, its
pointer operand is not marked uniform. The determination of whether a given
memory instruction will be scalarized or not has been moved into a common
function that is used by the vectorizer, cost model, and legality analysis.

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

llvm-svn: 280979

Previously we were making new instances of YamlTypeDumperCallbacks
in order to recurse down and serialize / deserialize nested
records such as field lists.  This meant you could not pass
context from a higher operation to a lower operation because
it would be using a new instance of the visitor callback
delegate.

YAMLIO library was updated to support context-sensitive mappings,
so now we can reuse the same instance of the visitor callback
delegate even for nested operations.

llvm-svn: 280978

mapping a yaml field to an object in code has always been
a stateless operation.  You could still pass state by using the
`setContext` function of the YAMLIO object, but this represented
global state for the entire yaml input.  In order to have
context-sensitive state, it is necessary to pass this state in
at the granularity of an individual mapping.

This patch adds support for this type of context-sensitive state.
You simply pass an additional argument of type T to the
`mapRequired` or `mapOptional` functions, and provided you have
specialized a `MappingContextTraits<U, T>` class with the
appropriate mapping function, you can pass this context into
the mapping function.

Reviewed By: chandlerc
Differential Revision: https://reviews.llvm.org/D24162

llvm-svn: 280977

Previous patch added a #if which causes some unused identifier warnings.

llvm-svn: 280976

This reverts commit r280839.
It's problematic on OS X, where the '/Users/...' paths are interpreted
as '/U' options.

Investigation ongoing in http://llvm.org/PR30328.

llvm-svn: 280975

This will confuse later passes which try to look at the
immediate value and don't truncate first.

llvm-svn: 280974

Recent change exposed this issue, breaking the Hexagon buildbots.

llvm-svn: 280973

llvm-svn: 280972

Fix the .arch asm parser to use the full set of features for the architecture
and any extensions on the command line. Add and update testcases accordingly
as well as add an extension that was used but not supported.

llvm-svn: 280971

llvm-svn: 280970

This reverts commit r280890, as the related LLVM commit broke the thumb bots.

llvm-svn: 280969

This reverts commit r280889, as the original LLVM commits broke the thumb
buildbots.

llvm-svn: 280968

And associated commits, as they broke the Thumb bots.

This reverts commit r280935.
This reverts commit r280891.
This reverts commit r280888.

llvm-svn: 280967

Switch to range based for loop.
No functional change, but more readable code.

llvm-svn: 280966

MSVC did not understand my brace-initializer syntax. :/

llvm-svn: 280965

I introduced this potential bug by missing this diff in:
https://reviews.llvm.org/rL280873

...however, I'm not sure how to reach this code path with a regression test.
We may be able to remove this code and assume that the transform to a constant
is always handled by InstSimplify?

llvm-svn: 280964

llvm-svn: 280963

llvm-svn: 280962