by default, rather than whether they may be built at all.

llvm-svn: 149037

around, in the process cleaning up the various gcc/msvc compiler
workarounds.

llvm-svn: 149036

llvm-svn: 149035

llvm-svn: 149034

llvm-svn: 149033

llvm-svn: 149032

Refactor to share code for handling return statements between lambda expressions and block literals.  As it turns out, almost all the logic can be shared.

llvm-svn: 149031

When this is imported into your lldb using the "command script import /path/to/gdbremote.py"
these new commands are available within LLDB. 'start_gdb_log' will enable logging with 
timestamps for GDB remote packets, and 'stop_gdb_log' will then dump the details and
also a lot of packet timing data. This allows us to accurately track what packets are
taking up the most time when debugging (when using the ProcessGDBRemote debugging plug-in).

Also udpated the comments at the top of the cmdtemplate.py to show how to correctly import
the module from within LLDB.

llvm-svn: 149030

llvm-svn: 149029

more robust) ways to do what it was doing now.  Also, add static methods
for decoding a ShuffleVector mask.

llvm-svn: 149028

-fixit-recompile
	applies fixits and recompiles the result
-fixit-to-temporary
	applies fixits to temporary files
-fix-only-warnings">,
    applies fixits for warnings only, not errors

Combining "-fixit-recompile -fixit-to-temporary" allows testing the result of fixits
without touching the original sources.

llvm-svn: 149027

be no functional change (the offsets in AT_data_member_location are still
correct). If the gdb testsuite itself needs changing then I'll revert this
and the clang patch.

llvm-svn: 149026

when asking for a ConstantStruct with all undef elements.

llvm-svn: 149025

new methods recently added to (sometimes greatly!) simplify code.

llvm-svn: 149024

ConstantVector.  Fix some outright bugs in the implementation of
ConstantArray and Constant struct, which would cause us to not make
one big UndefValue when asking for an array/struct with all undef
elements.  Enhance Constant::isAllOnesValue to work with
ConstantDataVector.

llvm-svn: 149021

llvm-svn: 149016

llvm-svn: 149015

Now the lexer just produces a token and the parser is the one responsible for
activating it.
This fixes problem like the one pr11797 where the lexer and the parser were not
in sync. This also let us be more strict on where in the file we accept
these pragmas.

llvm-svn: 149014

llvm-svn: 149013

llvm-svn: 149012

both actually tests what it wants to, doesn't have bogus and broken
assertions in it, and is also formatted much more cleanly and
consistently. Probably still some more that can be improved here, but
its much better.

Original commit message:
----
Try to unbreak the FreeBSD toolchain's detection of 32-bit targets
inside a 64-bit freebsd machine with the 32-bit compatibility layer
installed. The FreeBSD image always has the /usr/lib32 directory, so
test for the more concrete existence of crt1.o. Also enhance the tests
for freebsd to clarify what these trees look like and exercise the new
code.

Thanks to all the FreeBSD folks for helping me understand what caused
the failure and how we might fix it. =] That helps a lot. Also, yay
build bots.

llvm-svn: 149011

mode does not form part of the path.

llvm-svn: 149010

llvm-svn: 149009

using CFArrayCreate & family.

Specifically, CFArrayCreate's input should be:
'A C array of the pointer-sized values to be in the new array.'

(radar://10717339)

llvm-svn: 149008

they show up as argument types of two block pointers.
// rdar://10734265

llvm-svn: 149007

llvm-svn: 149006

llvm-svn: 149005

llvm-svn: 149004

llvm-svn: 149003

llvm-svn: 149002

unused yet.

llvm-svn: 149001

llvm-svn: 149000

to reduce the number of cast<>'s we have.  This allows someone to use
things like Ty->getVectorNumElements() instead of 
cast<VectorType>(Ty)->getNumElements() when you know that a type is a
vector.

It would be a great general cleanup to move the codebase to use these,
I will do so in the code I'm touching.

llvm-svn: 148999

"isValidOperands" and "getMaskValue" methods to allow 
ConstantDataSequential.

llvm-svn: 148998

Rework flushing of diagnostics to PathDiagnosticConsumer.  Now all the reports are batched up before being flushed
to the underlying consumer implementation.  This allows us to unique reports across analyses to multiple functions (which
shows up with inlining).

llvm-svn: 148997

This boils down to using MachineOperand::readsReg() more.

This fixes PR11829 where a use ended up after the first def when
lowering REG_SEQUENCE instructions involving IMPLICIT_DEFs.

llvm-svn: 148996

Don't stack-allocate an IntegerLiteral which can be referred to after the current method returns.  PR11744, part 2.

llvm-svn: 148995

llvm-svn: 148994

Original log:

Author: chandlerc <chandlerc@91177308-0d34-0410-b5e6-96231b3b80d8>
Date:   Wed Jan 25 21:32:31 2012 +0000

    Try to unbreak the FreeBSD toolchain's detection of 32-bit targets
    inside a 64-bit freebsd machine with the 32-bit compatibility layer
    installed. The FreeBSD image always has the /usr/lib32 directory, so
    test for the more concrete existence of crt1.o. Also enhance the tests
    for freebsd to clarify what these trees look like and exercise the new
    code.

    Thanks to all the FreeBSD folks for helping me understand what caused
    the failure and how we might fix it. =] That helps a lot. Also, yay
    build bots.

llvm-svn: 148993

Add some ABI tweaks for i386-pc-win32 triple so that we return structs in an MSVC-compatible way.  Patch by Joe Groff.

llvm-svn: 148992