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

Improve the error message slightly for files that aren't using the expected UTF-8 encoding.  Patch by Seth Cantrell.

llvm-svn: 148991

and let linker handle the rest.

This finally fixes PR5329

llvm-svn: 148990

llvm-svn: 148989

llvm-svn: 148988

llvm-svn: 148987

function. They don't appear to be used, and are inconsistent with handling of
other physreg intervals (i.e. intervals that are not live-in) where ranges are
not inserted for aliases.

llvm-svn: 148986

LLVM isn't an acronym anymore.

llvm-svn: 148985

Always break upon finding a vreg operand (in Release as well as +Asserts). Remove assertion which can no longer trigger.

llvm-svn: 148984

If timestamps are enabled when logging GDB remote packets ("log enable -T -f /tmp/packets.log gdb-remote logs") then get the amount of time spent executing each packet and summarize at the end of a dump. Sample timing output looks like:

----------------------------------------------------------------------
Packet timing summary:
----------------------------------------------------------------------
Packet                 Time       %
---------------------- -------- ------
       qThreadStopInfo 0.363844  35.35
                     m 0.281967  27.39
                     s 0.147160  14.30
          qfThreadInfo 0.070865   6.88
          qsThreadInfo 0.061608   5.99
                     z 0.036796   3.57
                     Z 0.036271   3.52
                     c 0.018410   1.79
                     H 0.012418   1.21
---------------------- -------- ------
                 Total 1.029339 100.00

llvm-svn: 148983

llvm-svn: 148982

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: 148981

This suppresses typo correction for auto-generated call expressions such
as to 'begin' or 'end' within a C++0x for-range statement.

llvm-svn: 148979