llvm-svn: 25046

llvm-svn: 25045

drop it on the floor.

llvm-svn: 25044

llvm-svn: 25043

1. Don't mix C++ and C standard I/O, convert to C++ iostreams
2. Wrap long lines
3. use the std namespace to simplify/shorten the code

llvm-svn: 25042

llvm-svn: 25041

let us get some do what I meant not what I said stuff checked in.  You would think the alpha backend would be 64bit clean

llvm-svn: 25040

llvm-svn: 25039

llvm-svn: 25038

llvm-svn: 25037

llvm-svn: 25036

llvm-svn: 25035

llvm-svn: 25034

llvm-svn: 25033

llvm-svn: 25032

llvm-svn: 25031

llvm-svn: 25030

llvm-svn: 25029

llvm-svn: 25028

args >8 put into the wrong place

llvm-svn: 25027

llvm-svn: 25026

llvm-svn: 25025

llvm-svn: 25024

llvm-svn: 25023

llvm-svn: 25022

llvm-svn: 25021

and unordered_map to make it into the standard)

Hurry up, JTC1 SC22 WG21 Library Working Group!

llvm-svn: 25020

llvm-svn: 25019

llvm-svn: 25018

Currently tblgen cannot tell which operands in the operand list are results so
it assumes the first one is a result. This is bad. Ideally we would fix this
by separating results from inputs, e.g. (res R32:$dst),
(ops R32:$src1, R32:$src2). But that's a more distruptive change. Adding
'let noResults = 1' is the workaround to tell tblgen that the instruction does
not produces a result. It works for now since tblgen does not support
instructions which produce multiple results.

llvm-svn: 25017

llvm-svn: 25016

llvm-svn: 25015

llvm-svn: 25014

the bzip2 homepage, only ancient (gcc 2.7.x ?) versions of GCC
require this? It certainly isn't needed for the current bzip2
sources.

llvm-svn: 25013

to try building LLVM on HP-UX! (the Right Way seems to be to tear out
the ancient STL that HP ship and use http://incubator.apache.org/stdcxx/ )

llvm-svn: 25012

llvm-svn: 25011

llvm-svn: 25010

llvm-svn: 25009

llvm-svn: 25008

llvm-svn: 25007