Run interprocedural const prop before global optimizer

Exposes more constant globals that can be removed by
the global optimizer. A specific example is the removal
of the static global block address array in
clang/test/CodeGen/indirect-goto.c. This change impacts only
lower optimization levels. With LTO interprocedural
const prop runs already before global opt.

llvm-svn: 212284

fix configure+make build

llvm-svn: 212283

Add support for inline asm symbols to IRObjectFile.

This also enables it in llvm-nm so that it can be tested.

llvm-svn: 212282

The RTTI fallback is no more. Remove outdated diagnostic.

llvm-svn: 212281

Add the -U flag to llvm-nm as an alias to -defined-only
as darwin’s nm(1) uses -U for this functionality.

llvm-svn: 212280

fixed typo in comment

llvm-svn: 212279

IR: cleanup Module::dropReferences

This replaces some old-style loops with range-based for.

llvm-svn: 212278

[ARM] Implement ISB memory barrier intrinsic

Adds support for __builtin_arm_isb. Also corrects DSB and ISB instructions
modelling by adding has-side-effects property.

llvm-svn: 212277

[ARM] Implement ISB memory barrier intrinsic

Adds support for __builtin_arm_isb. Also corrects DSB and ISB instructions
modelling by adding has-side-effects property.

llvm-svn: 212276

bug fix for PR20020: anti-dependency-breaker causes miscompilation

This patch sets the 'KeepReg' bit for any tied and live registers during the PrescanInstruction() phase of the dependency breaking algorithm. It then checks those 'KeepReg' bits during the ScanInstruction() phase to avoid changing any tied registers. For more details, please see comments in:
http://llvm.org/bugs/show_bug.cgi?id=20020

I added two FIXME comments for code that I think can be removed by using register iterators that include self. I don't want to include those code changes with this patch, however, to keep things as small as possible.

The test case is larger than I'd like, but I don't know how to reduce it further and still produce the failing asm.

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

llvm-svn: 212275

Fix ppcf128 component access on little-endian systems

The PowerPC 128-bit long double data type (ppcf128 in LLVM) is in fact a
pair of two doubles, where one is considered the "high" or
more-significant part, and the other is considered the "low" or
less-significant part.  When a ppcf128 value is stored in memory or a
register pair, the high part always comes first, i.e. at the lower
memory address or in the lower-numbered register, and the low part
always comes second.  This is true both on big-endian and little-endian
PowerPC systems.  (Similar to how with a complex number, the real part
always comes first and the imaginary part second, no matter the byte
order of the system.)

This was implemented incorrectly for little-endian systems in LLVM.
This commit fixes three related issues:

- When printing an immediate ppcf128 constant to assembler output
  in emitGlobalConstantFP, emit the high part first on both big-
  and little-endian systems.

- When lowering a ppcf128 type to a pair of f64 types in SelectionDAG
  (which is used e.g. when generating code to load an argument into a
  register pair), use correct low/high part ordering on little-endian
  systems.

- In a related issue, because lowering ppcf128 into a pair of f64 must
  operate differently from lowering an int128 into a pair of i64,
  bitcasts between ppcf128 and int128 must not be optimized away by the
  DAG combiner on little-endian systems, but must effect a word-swap.

Reviewed by Hal Finkel.

llvm-svn: 212274

[asan] i686-linux-android support.

Large part of this change is required due to
  https://code.google.com/p/android/issues/detail?id=61799
dlsym() crashes when symbol resolution fails, which means
we have to limit the interceptor list instead of relying on
runtime detection.

There are minor differencies in system headers, too.

llvm-svn: 212273

[asan] Fix unused variable warning.

llvm-svn: 212272

clang-tidy: Instantiate llvm::Registry<clang::tidy::ClangTidyModule>.

llvm-svn: 212271

clang-modernize: Instantiate llvm::Registry<TransformFactory>.

llvm-svn: 212270

[mach-o]: remove dylib install-name test with a.out

Unfortunately, the creation of (the default) output file, a.out races with all
the other tests in this directory. When the wrong one is read by macho-dump,
the test fails.

llvm-svn: 212269

[msan] Stop propagating shadow in blacklisted functions.

With this change all values passed through blacklisted functions
become fully initialized. Previous behavior was to initialize all
loads in blacklisted functions, but apply normal shadow propagation
logic for all other operation.

This makes blacklist applicable in a wider range of situations.

It also makes code for blacklisted functions a lot shorter, which
works as yet another workaround for PR17409.

llvm-svn: 212268

[msan] Add missing attributes in MemorySanitizer tests.

llvm-svn: 212267

Revert of r212265.

llvm-svn: 212266

[msan] Stop propagating shadow in blacklisted functions.

With this change all values passed through blacklisted functions
become fully initialized. Previous behavior was to initialize all
loads in blacklisted functions, but apply normal shadow propagation
logic for all other operation.

This makes blacklist applicable in a wider range of situations.

It also makes code for blacklisted functions a lot shorter, which
works as yet another workaround for PR17409.

llvm-svn: 212265

Add the __qdbl intrinsic to the arm_acle.h header

Patch by: Moritz Roth

llvm-svn: 212264

Move the calling of emitTargetMD() later.

Summary:
Because a global created by GetOrCreateLLVMGlobal() is not finalised until later viz:
  extern char a[];
  char f(){ return a[5];}
  char a[10];

Change MangledDeclNames to use a MapVector rather than a DenseMap so that the
Metadata is output in order of original declaration, so to make deterministic
and improve human readablity.

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

llvm-svn: 212263

refactor for-loop as range-loop before making changes.

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

llvm-svn: 212262

ARMEB: Fix function result return for composite types

Reviewed at http://reviews.llvm.org/D4364

llvm-svn: 212261

[Driver][Mips] Check MIPS CPU name provided to the Clang driver.

llvm-svn: 212260

Minor stylistic fix in SimplifyCFG (test commit)

llvm-svn: 212259

Let llvm/test/CodeGen/X86/lower-bitcast.ll tolerant of win32 calling convention.

llvm-svn: 212258

[x86] Fix the completely broken vector widening legalization of bswap.

This operation was classified as a binary operation in the widening
logic for some reason (clearly, untested). It is in fact a unary
operation. Add a RUN line to a test to exercise this for x86.

Note that again the vector widening strategy doesn't regress anything
and in one case removes a totally unecessary instruction that we
couldn't avoid when promoting the element type.

llvm-svn: 212257

MS ABI: Get linkage of RTTI data correct

The Itanium rules are not appropriate for the MS ABI.  RTTI data is
_never_ imported and thus is never available_externally.  It is either
internal (if the type's linkage is internal) or linkonce_odr.

This also means that classes which inherit from dllimport'd bases force
their translation unit to duplicate the entirety of the RTTI data of
that base.

Interestingly, the complete object locator can never be referenced by
translation units which import the class.

This fixes PR20106.

llvm-svn: 212256

Fix compilation errors introduced by host Pipe abstraction
on Windows.

llvm-svn: 212255

[x86] Fix crashes in lowering bitcast instructions with the widening
mode.

This also runs the test in that mode which would reproduce the crash.
What I love is that *every single FIXME* in the test is addressed by
switching to widening.

llvm-svn: 212254

ARM: rename ARM builtins to use __builtin_arm prefix

This corrects SVN r212196's naming change to use the proper prefix of
`__builtin_arm_` instead of `__builtin_`.

Thanks to Yi Kong for pointing out the incorrect naming!

llvm-svn: 212253

[aarch64] Add a test that should have been in r212242 but I forgot to
add it. Sorry about that.

llvm-svn: 212251

Add new lines to debugging information.

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

llvm-svn: 212250

[x86] Based on a long conversation between myself, Jim Grosbach, Hal
Finkel, Eric Christopher, and a bunch of other people I'm probably
forgetting (sorry), add an option to the x86 backend to widen vectors
during type legalization rather than promote them.

This still would promote vNi1 vectors to get the masks right, but would
widen other vectors. A lot of experiments are piling up right now
showing that widening should probably be the default legalization
strategy outside of vNi1 cases, but it is very hard to test the
rammifications of that and fix bugs in widening-based legalization
without an option that enables it. I'll be checking in tests shortly
that use this option to exercise cases where widening doesn't work well
and hopefully we'll be able to switch fully to this soon.

llvm-svn: 212249

Invert the MC -> Object dependency.

Now that we have a lib/MC/MCAnalysis, the dependency was there just because
of two helper classes. Move the two over to MC.

This will allow IRObjectFile to parse inline assembly.

llvm-svn: 212248

[mach-o] add x86 test case to build hello world.  Fix bugs it uncovered.

llvm-svn: 212247

Add enumerations for additional languages from DWARF spec updates.

llvm-svn: 212246

Make these preprocessor directives match all of the others in the port.

llvm-svn: 212245

Remove dead code.

llvm-svn: 212244

Address review feedback for r212238.

Also, forgot to say in the commit message of r212238: Library authors will
see a warning about this issue if they build with -Wsystem-headers.

llvm-svn: 212243

[codegen,aarch64] Add a target hook to the code generator to control
vector type legalization strategies in a more fine grained manner, and
change the legalization of several v1iN types and v1f32 to be widening
rather than scalarization on AArch64.

This fixes an assertion failure caused by scalarizing nodes like "v1i32
trunc v1i64". As v1i64 is legal it will fail to scalarize v1i32.

This also provides a foundation for other targets to have more granular
control over how vector types are legalized.

Patch by Hao Liu, reviewed by Tim Northover. I'm committing it to allow
some work to start taking place on top of this patch as it adds some
really important hooks to the backend that I'd like to immediately start
using. =]

http://reviews.llvm.org/D4322

llvm-svn: 212242

[mach-o] Fix warning on enumeration cases not handled

llvm-svn: 212241

Move subtarget dependent features into the subtarget from the target
machine. Includes a fix for a subtarget initialization for
hard floating point on mips16.

llvm-svn: 212240

[mach-o] add parsing of x86 relocations

llvm-svn: 212239

Enable clang to continue to parse libstdc++4.6 and stlport after r210091.

r210091 made initialization checking more strict in c++11 mode. LWG2193 is
about changing standard libraries to still be valid under these new rules,
but older libstdc++ (e.g. libstdc++4.6 in -D_GLIBCXX_DEBUG=1 mode, or stlport)
do not implement that yet.  So fall back to the C++03 semantics for container
classes in system headers below the std namespace.

llvm-svn: 212238

Update the MSVC compatibilty document for class template parsing

llvm-svn: 212237

So that we can include frame lowering in the subtarget, remove include
circular dependency with the subtarget by inlining accessor methods and
outlining a routine.

llvm-svn: 212236

Add the -reverse-sort flag (aka -r) to llvm-nm
which exists in other Unix nm(1)’s.

llvm-svn: 212235

So that we can include target lowering in the subtarget, remove include
circular dependency with the subtarget by inlining accessor methods and
outlining a routine.

llvm-svn: 212234

Fix linkage bug that miscompiled variable templates instantiated from similarly named local types. In essence, this bug ensures that the x<Foo> specialization in function foo() defined as follows differs between two distinct translation units.
    static int &foo() {
       struct Foo { };
       return x<Foo>;
    }

llvm-svn: 212233

Fix a warning about undeclared call to abort().

llvm-svn: 212232

Update comment and include guard.

I missed these when moving the files.

llvm-svn: 212231

[OCaml] Documentation improvements.

Patch by Julien Sagot

llvm-svn: 212230

More editorial issues in MSVCCompatibility.rst

Make the status text for lambdas green.

llvm-svn: 212229

Fix typos.

llvm-svn: 212228

Fix Typo in MSVCCompatibility.rst
Also removed a sentance that was no longer relevant.

llvm-svn: 212227

Revert "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself."

This reverts commit r212205.

Reverting this again, still seeing crashes when building compiler-rt...
Sorry for the continued noise, not sure why I'm failing to reproduce
this locally.

llvm-svn: 212226

lldb - problem with some PTRACE_* constants in NativeProcessLinux.cpp file

See http://reviews.llvm.org/D4366 for details.

Change by Paul Paul Osmialowski

Today this is the only problem that I'm facing trying to cross-compile lldb for AArch64 using Linaro's toolchain.

PTRACE_GETREGS, PTRACE_SETREGS, PTRACE_GETFPREGS, PTRACE_SETFPREGS are not defined for AArch64
These things can be defined different ways for other architectures, e.g. for x86_64 Linux, asm/ptrace-abi.h defines them as preprocessor constants while sys/ptrace.h defines them in enum along with corresponding PT_* preprocessor constants
NativeProcessLinux.cpp includes sys/ptrace.h
To avoid accidental redefinition of enums with preprocessor constants, I'm proposing this patch which first checks for PT_* preprocessor constants then checks for PTRACE_* constants then when it still can not find them, it defines preprocessor constants.
Similar approach was already used for PTRACE_GETREGSET and PTRACE_SETREGSET constants; in this case however it was easier, since enum values in sys/ptrace.h and preprocessor constants shared all exactly the same names (e.g. there's no additional PT_GETREGSET name defined).

llvm-svn: 212225

Move the data layout and selection dag info from the mips target machine
down to the subtarget.

llvm-svn: 212224

[X86] AVX512: Allow writemask argument in vpermt* intrinsics

llvm-svn: 212223

[X86] AVX512: Generate Pat<>'s for the vpermt2* intrinsics via multiclass

This new multiclass, avx512_perm_table_3src derives from the current one and
provides the Pat<>.  The next patch will add another Pat<> that uses the
writemask.

Note that I dropped the type annotation from the intrinsic call, i.e.: (v16f32
VR512:$src1) -> R512:$src1.  I think that this should be fine (at least many
intrinsic calls don't provide them) and it greatly reduces the number of
template arguments.

llvm-svn: 212222

[X86] AVX512: Add writemask variants for vperm*2*

This includes assembler and codegen support (see the new tests in
avx512-encodings.s and avx512-shuffle.ll).

<rdar://problem/17492620>

llvm-svn: 212221

Add host layer support for pipes.

Windows does support pipes, but they do so in a slightly different way. Added a Host layer which abstracts the use of pipes into a new Pipe class that everyone can use.

Windows benefits include:
- Being able to interrupt running processes when IO is directly hooked up
- being able to interrupt long running python scripts
- being able to interrupt anything based on ConnectionFileDescriptor

llvm-svn: 212220

Fixup typo in MSVCCompatibility.rst

llvm-svn: 212219

R600: Add a comment that llvm.AMDGPU.trunc is a legacy intrinsic

llvm-svn: 212218

R600/SI: Use a ComplexPattern for ADDR64 addressing of MUBUF loads

llvm-svn: 212217

R600: Promote i64 loads to v2i32

llvm-svn: 212216

R600/SI: Adjsut SGPR live ranges before register allocation

SGPRs are written by instructions that sometimes will ignore control flow,
which means if you have code like:

if (VGPR0) {
  SGPR0 = S_MOV_B32 0
} else {
  SGPR0 = S_MOV_B32 1
}

The value of SGPR0 will 1 no matter what the condition is.

In order to deal with this situation correctly, we need to view the
program as if it were a single basic block when we calculate the
live ranges for the SGPRs.  They way we actually update the live
range is by iterating over all of the segments in each LiveRange
object and setting the end of each segment equal to the start of
the next segment.  So a live range like:

[3888r,9312r:0)[10032B,10384B:0)  0@3888r

will become:

[3888r,10032B:0)[10032B,10384B:0)  0@3888r

This change will allow us to use SALU instructions within branches.

llvm-svn: 212215

R600/SI: Add verifier check for immediates in register operands.

llvm-svn: 212214

Make LLDB.framework link again on Yosemite.

llvm-svn: 212213

Remove non-static field initializer to appease MSVC

llvm-svn: 212212

XFAIL test on Android (this is a known issue)

llvm-svn: 212211

Fix configure+make build.

llvm-svn: 212210

Move CFG building code to a new lib/MC/MCAnalysis library.

The new library is 150KB on a Release+Asserts build, so it is quiet a bit of
code that regular users of MC don't need to link with now.

llvm-svn: 212209

Removing Carbon dependency by removing obsolete code.
The only part using Carbon is a function in Host.mm used to open a file in Xcode.
That code is broken and it is no longer useful as Xcode supports LLDB natively.

llvm-svn: 212208

If a breakpoint gets deleted, any SBBreakpoints representing that
breakpoint should return false from IsValid.

llvm-svn: 212206

DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself.

Originally committed in r211723, reverted in r211724 due to failure
cases found and fixed (ArgumentPromotion: r211872, Inlining: r212065),
committed again in r212085 and reverted again in r212089 after fixing
some other cases, such as debug info subprogram lists not keeping track
of the function they represent (r212128) and then short-circuiting
things like LiveDebugVariables that build LexicalScopes for functions
that might not have full debug info.

And again, I believe the invariant actually holds for some reasonable
amount of code (but I'll keep an eye on the buildbots and see what
happens... ).

Original commit message:

PR20038: DebugInfo: Inlined call sites where the caller has debug info
but the call itself has no debug location.

This situation does bad things when inlined, so I've fixed Clang not to
produce inlinable call sites without locations when the caller has debug
info (in the one case where I could find that this occurred). This
updates the PR20038 test case to be what clang now produces, and readds
the assertion that had to be removed due to this bug.

I've also beefed up the debug info verifier to help diagnose these
issues in the future, and I hope to add checks to the inliner to just
assert-fail if it encounters this situation. If, in the future, we
decide we have to cope with this situation, the right thing to do is
probably to just remove all the DebugLocs from the inlined instructions.

llvm-svn: 212205

[RegAllocGreedy] Provide a subtarget hook to disable the local reassignment
heuristic.
By default, no functionality change.
This is a follow-up of r212099.

This hook provides a finer grain to control the optimization.

<rdar://problem/17444599>

llvm-svn: 212204

Don't try to construct debug LexicalScopes hierarchy for functions that do not have top level debug information.

If a function isn't actually in a CU's subprogram list in the debug info
metadata, ignore all the DebugLocs and don't try to build scopes, track
variables, etc.

While this is possibly a minor optimization, it's also a correctness fix
for an incoming patch that will add assertions to LexicalScopes and the
debug info verifier to ensure that all scope chains lead to debug info
for the current function.

Fix up a few test cases that had broken/incomplete debug info that could
violate this constraint.

Add a test case where this occurs by design (inlining a
debug-info-having function in an attribute nodebug function - we want
this to work because /if/ the nodebug function is then inlined into a
debug-info-having function, it should be fine (and will work fine - we
just stitch the scopes up as usual), but should the inlining not happen
we need to not assert fail either).

llvm-svn: 212203

Constify the Function pointers in the result of makeSubprogramMap

These don't need to be mutable and callers being added soon in CodeGen
won't have access to non-const Module&.

llvm-svn: 212202

AArch64: Re-enable AArch64AddressTypePromotion

This reverts commits r212189 and r212190.

While this pass was accidentally disabled (until r212073), r205437
slipped in a use of `auto` that should have been `auto&`.

This fixes PR20188.

llvm-svn: 212201

Add missing dependency to macho-dump.

r212094 added a few tests that use macho-dump.

llvm-svn: 212200

AArch64: Remove unnecessary parens

llvm-svn: 212199

Derive run-time conditions for delinearization

As our delinearization works optimistically, we need in some cases run-time
checks that verify our optimistic assumptions. A simple example is the
following code:

void foo(long n, long m, long o, double A[n][m][o]) {

  for (long i = 0; i < 100; i++)
    for (long j = 0; j < 150; j++)
      for (long k = 0; k < 200; k++)
        A[i][j][k] = 1.0;
}

After clang linearized the access to A and we delinearized it again to
A[i][j][k] we need to ensure that we do not access the delinearized array
out of bounds (this information is not available in LLVM-IR). Hence, we
need to verify the following constraints at run-time:

CHECK:   Assumed Context:
CHECK:   [o, m] -> {  : m >= 150 and o >= 200 }
llvm-svn: 212198

R600: Fix crashes when an illegal type load or store is not handled.

I don't think anything hits this now, but will be exposed in future
patches.

llvm-svn: 212197

CodeGen: make target builtins support languages

This extends the target builtin support to allow language specific annotations
(i.e. LANGBUILTIN).  This is to allow MSVC compatibility whilst retaining the
ability to have EABI targets use a __builtin_ prefix.  This is merely to allow
uniformity in the EABI case where the unprefixed name is provided as an alias in
the header.

llvm-svn: 212196

Just adding a getHalfTy method to IRBuilder for completeness.

llvm-svn: 212195

AArch64: Merge isa with dyn_cast

llvm-svn: 212194

Update the MSVC Compatibility document

It hasn't been updated to reflect the progress we've made.  We've fuzz
tested VFTables, VBTables, layout, and RTTI data.  We support lambdas
that are compatible with their scheme.

llvm-svn: 212193

Start converting usages of off_t to other types.

off_t is a type which is used for file offsets.  Even more
specifically, it is only used by a limited number of C APIs that
deal with files.  Any usage of off_t where the variable is not
intended to be used with one of these APIs is a bug, by definition.

This patch corrects some easy mis-uses of off_t, generally by
converting them to lldb::offset_t, but sometimes by using other
types such as size_t, when appropriate.

The use of off_t to represent these offsets has worked fine in
practice on linux-y platforms, since we used _FILE_OFFSET_64 to
guarantee that off_t was a uint64.  On Windows, however,
_FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit.
So the usage of off_t on Windows actually leads to legitimate bugs.

Reviewed by: Greg Clayton

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

llvm-svn: 212192

ARCMigrate: simplify diagnostic handling

Recent enhancements in the diagnostics engine mean that
TransformActions::report() no longer needs to duplicate this suppression logic.

That's great because the old code was flawed and would have attached notes to
the wrong primary diagnostic in non-trivial use.

With these changes it becomes safe to use reportNote() freely in the migration
tool.

llvm-svn: 212191

XFAIL the test to go with r202189

llvm-svn: 212190

AArch64: Temporarily disable AArch64AddressTypePromotion

Temporarily disable AArch64AddressTypePromotion, which was effectively
re-enabled in r212073 and r212075, while I look into PR20188.

llvm-svn: 212189

[ASan] Print exact source location of global variables in error reports.

See https://code.google.com/p/address-sanitizer/issues/detail?id=299 for the
original feature request.

Introduce llvm.asan.globals metadata, which Clang (or any other frontend)
may use to report extra information about global variables to ASan
instrumentation pass in the backend. This metadata replaces
llvm.asan.dynamically_initialized_globals that was used to detect init-order
bugs. llvm.asan.globals contains the following data for each global:
  1) source location (file/line/column info);
  2) whether it is dynamically initialized;
  3) whether it is blacklisted (shouldn't be instrumented).

Source location data is then emitted in the binary and can be picked up
by ASan runtime in case it needs to print error report involving some global.
For example:

  0x... is located 4 bytes to the right of global variable 'C::array' defined in '/path/to/file:17:8' (0x...) of size 40

These source locations are printed even if the binary doesn't have any
debug info.

This is an ABI-breaking change. ASan initialization is renamed to
__asan_init_v4(). Pre-built libraries compiled with older Clang will not work
with the fresh runtime.

llvm-svn: 212188

Revert "Revert "MachineScheduler: better book-keeping for asserts.""

This reverts commit r212109, which reverted r212088.

However, disable the assert as it's not necessary for correctness.  There are
several corner cases that the assert needed to handle better for in-order
scheduling, but none of them are incorrect scheduler behavior. The assert is
mainly there to collect good unit tests like this and ensure that the
target-independent scheduler is working as expected with the various machine
models.

llvm-svn: 212187

Use arguments of user statements to perform induction variable substitution

To translate the old induction variables as they exist before Polly to new
new induction variables introduced during AST code generation we need to
generate code that computes the new values from the old ones. We can do this
by just looking at the arguments isl generates in each scheduled statement.

Example:

  // Old
  for i
    S(i)

  // New
  for c0
    for c1
      S(c0 + c1)

To get the value of i, we need to compute 'c0 + c1'. This expression is readily
available in the user statements generated by isl and just needs to be
translated to LLVM-IR.

This replaces an old confusing construct that constructed during ast generation
an isl multi affine expression that described this relation and which was then
again ast generated for each statement and argument when translating the isl ast
to LLVM-IR. This approach was difficult to understand and the additional ast
generation calls where entirely redundant as isl provides the relevant
expressions as arguments of the generated user statements.

llvm-svn: 212186

Minor cleanup for string_view; mostly from suggestions by Richard Smith. Also, make the tests pass under c++03

llvm-svn: 212185

Also document the 'arc commit' commands in the 'Committing a change' section of the Phabricator doc

llvm-svn: 212184

Added standard macro guard. In case __GNUC_VA_LIST was not
defined or defined identically before there will not be any
change in functionality.

MinGW-w64 defines __GNUC_VA_LIST as

  #define __GNUC_VA_LIST

which is different than the definition here, causing
a warning without the guard.

llvm-svn: 212183