/ALTERNATENAME is a rarely-used, undocumented command line option that is
needed to link LLD for release build. It seems that the option is for defining
an weak alias; /alternatename:foo=bar defines weak symbol "foo" for "bar".
If "foo" is defined in an input file, it'll be linked normally and the command
line option will have no effect. If it's not defined, "foo" will be handled
as an alias for "bar".

This patch implements the parser for the option. The actual weak alias handling
will be implemented in a separate patch.

llvm-svn: 196743

Use the same LaunchProcessPosixSpawn as on FreeBSD and Linux.

llvm-svn: 196742

llvm-svn: 196741

llvm-svn: 196740

VerifyDiagnosticConsumer is long-lived so the two additional members shouldn't
have any impact on release builds.

The clang headers are now free of NDEBUG conditionals. Let's keep it that way!

Note that they're not yet structurally stable, pending a few fixes in the LLVM
core headers.

llvm-svn: 196739

This should get it up and running on win and other builders without system
headers.

llvm-svn: 196738

Add -verify and update the test directives to match current expectations.

Also add a FIXME to an ObjC test that has expected-* directives but no -verify.

llvm-svn: 196737

Going by PR6913 it looks like this one can no longer reach CodeGen so remove
the redundant -emit-llvm case and treat it as an ordinary Sema test.

llvm-svn: 196736

  This fixes PR18150.

llvm-svn: 196735

LLVM r196044 should make it pass.

llvm-svn: 196734

There's no evidence that a 'DISABLE' directive ever existed.

Let's see if anything breaks..

llvm-svn: 196733

llvm-svn: 196732

in the td file.

llvm-svn: 196731

These were being substituted into approximately the following:

  clang -cc1 -internal-isystem ../lib/clang/3.5/include_only

llvm-svn: 196730

Due to a missing -verify, 2007-10-01-BuildArrayRef.c was a no-op.

The message was changed 5 years ago so also update the test to reflect the new wording.

llvm-svn: 196729

llvm-svn: 196728

llvm-svn: 196727

here is to make save/restore into variable number of argument instructions.

llvm-svn: 196726

When trying to eliminate an "sub sp, sp, #N" instruction by folding
it into an existing push/pop using dummy registers, we need to account
for the fact that this might affect precisely how "fp" gets set in the
prologue.

We were attempting this, but assuming that *whenever* we performed a
fold it would make a difference. This is false, for example, in:
    push {r4, r7, lr}
    add fp, sp, #4
    vpush {d8}
    sub sp, sp, #8

we can fold the "sub" into the "vpush", forming "vpush {d7, d8}".
However, in that case the "add fp" instruction mustn't change, which
we were getting wrong before.

Should fix PR18160.

llvm-svn: 196725

We already support using "r" on 64-bit values (a GPRPair is
allocated), but Sema doesn't know this yet so issues a warning. This
should fix it.

llvm-svn: 196724

llvm-svn: 196723

argh!

llvm-svn: 196722

Add back the test that was triggering the assertion (which I removed mistakenly thinking it was triggering just a warning and not an assertion).  My error was brought to my attention by Rafael (Thanks!).

llvm-svn: 196721

architecture and PIC flag.

llvm-svn: 196720

llvm-svn: 196719

llvm-svn: 196718

llvm-svn: 196716

Because compare() and its heper functions no longer have to be members of
LayoutPass class, we can remove it from the class. No functionality change.

llvm-svn: 196715

The comparator used in the layout pass has many calls of map::find(). Because
std::sort runs the comparator N*log2(N) times, the maps are looked up with the
same key again and again. The map lookup is not a very fast operation. It made
the pass slow.

This patch eliminates the duplicate map lookups using decorate-sort-undecorate
idiom. The pass used to take 1.1 seconds when linking LLD with LLD on Windows,
but it now takes only 0.3 seconds. Overall performance gain in that case is from
6.1 seconds to 5.2 seconds.

Differential Revision: http://llvm-reviews.chandlerc.com/D2358

llvm-svn: 196714

No functionality change.  Changing comments to match code.

llvm-svn: 196713

Clang outputs LLVM one top level decl at a time. This combined with the
visibility computation code looking for the newest NamespaceDecl would cause
it to produce different results for nested namespaces.

The two options for producing consistent results are
* Delay codegen of anything inside a namespace until the end of the file.
* Don't look for the newest NamespaceDecl.

This patch implements the second option.
This matches the gcc behavior too.

llvm-svn: 196712

This fixes PR17872.  This bug can lead to C++ destructors not being
called when they should be, when an exception is thrown.

llvm-svn: 196711

Before this change, inlining one "invoke" into an outer "invoke" call
site can lead to the outer landingpad's catch/filter clauses being
copied multiple times into the resulting landingpad.  This happens:

 * when the inlined function contains multiple "resume" instructions,
   because forwardResume() copies the clauses but is called multiple
   times;

 * when the inlined function contains a "resume" and a "call", because
   HandleCallsInBlockInlinedThroughInvoke() copies the clauses but is
   redundant with forwardResume().

Fix this by deduplicating the code.

This problem doesn't lead to any incorrect execution; it's only
untidy.

This change will make fixing PR17872 a little easier.

llvm-svn: 196710

llvm-svn: 196669

overall time of LLVM compilation by ~1%.

llvm-svn: 196667

llvm-svn: 196664

Employed the following refactorings:
  - Renamed some functions
  - Introduced explaining variables
  - Cleaned up & added comments
  - Used Optional<unsigned> for return value instead of an out parameter
  - Added assertions
  - Constified a few member functions
  
No functionality change.
All regressions pass.  

llvm-svn: 196662

They were out of place since the introduction of arbitrary precision integer
types.

This also synchronizes the documentation to Types.h, so it refers to first class
types and single value types.

llvm-svn: 196661

Add LLVM_OVERRIDE to make this a hard error in the future.

llvm-svn: 196659

This can happen when we're trying to emit a thunk with available_externally
linkage with optimization enabled but bail because it doesn't make sense
for vararg functions.

PR18098.

llvm-svn: 196658