Triple class constructor. Only valid triples should now be used
inside LLVM - front-ends are now responsable for rejecting or
correcting invalid target triples. The Triple::normalize method
can be used to straighten out funky triples provided by users.
Give this a whirl through the buildbots to see if I caught all
places where triples enter LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112470 91177308-0d34-0410-b5e6-96231b3b80d8
- Cache used characters in a bitset to reduce memory overhead to just 32 bytes.
- On my core2 this code is faster except when the checked string was very short
(smaller than the list of delimiters).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111817 91177308-0d34-0410-b5e6-96231b3b80d8
functionality that most command-line tools need: ensuring that the
output file gets deleted if the tool is interrupted or encounters an
error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111595 91177308-0d34-0410-b5e6-96231b3b80d8
constructed with an output filename of "-". In particular, allow the
file descriptor to be closed, and close the file descriptor in the
destructor if it hasn't been explicitly closed already, to ensure
that any write errors are detected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111436 91177308-0d34-0410-b5e6-96231b3b80d8
(e.g. errs()) fails in close() due to (e.g.) a broken pipe. As
previously written, the had_error() flag would get set and then
the raw_ostream dtor would report a fatal error. There is nothing
the client can do about this and we have no way to report the error,
so just eat it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111321 91177308-0d34-0410-b5e6-96231b3b80d8
into report_fatal_error. Just blast the string to stderr with write(2)
and hope for the best! Part of rdar://8318441
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111320 91177308-0d34-0410-b5e6-96231b3b80d8
implementations of equality comparison and hash computation. This
can be used to optimize node lookup by avoiding creating lots of
temporary ID values just for hashing and comparison purposes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111130 91177308-0d34-0410-b5e6-96231b3b80d8
target triple and straightens it out. This does less than gcc's script
config.sub, for example it turns i386-mingw32 into i386--mingw32 not
i386-pc-mingw32, but it does a decent job of turning funky triples into
something that the rest of the Triple class can understand. The plan
is to use this to canonicalize triple's when they are first provided
by users, and have the rest of LLVM only deal with canonical triples.
Once this is done the special case workarounds in the Triple constructor
can be removed, making the class more regular and easier to use. The
comments and unittests for the Triple class are already adjusted in this
patch appropriately for this brave new world of increased uniformity.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110909 91177308-0d34-0410-b5e6-96231b3b80d8
- remove ashr which never worked.
- fix lshr and shl and add tests.
- remove dead function "intersect1Wrapped".
- add a new sub method to subtract ranges, with test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110861 91177308-0d34-0410-b5e6-96231b3b80d8
- This works, but won't handle crashes on stack overflow, or signals delivered
to a thread other than the one that crashed. The latter is particular annoying
on Darwin, because SIGABRT tends to go to the main thread.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109717 91177308-0d34-0410-b5e6-96231b3b80d8
- Designed as a simple wrapper to allow clients to attempt to catch crashes
(memory errors, assertion violations, etc.) and do some kind of recovery.
- Currently doesn't actually attempt to catch crashes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109586 91177308-0d34-0410-b5e6-96231b3b80d8
replaced by a bigger array in SmallPtrSet (by overridding it), instead just use a
pointer to the start of the storage, and have SmallPtrSet pass in the value to use.
This has the disadvantage that SmallPtrSet becomes bigger by one pointer. It has
the advantage that it no longer uses tricky C++ rules, and is clearly correct while
I'm not sure the previous version was. This was inspired by g++-4.6 pointing out
that SmallPtrSetImpl was writing off the end of SmallArray, which it was. Since
SmallArray is replaced with a bigger array in SmallPtrSet, the write was still to
valid memory. But it was writing off the end of the declared array type - sounds
kind of dubious to me, like it sounded dubious to g++-4.6. Maybe g++-4.6 is wrong
and this construct is perfectly valid and correctly compiled by all compilers, but
I think it is better to avoid the whole can of worms by avoiding this construct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107285 91177308-0d34-0410-b5e6-96231b3b80d8
buffer in the same chunk of memory.
2 less mallocs for every uninitialized MemoryBuffer and 1 less malloc for every
MemoryBuffer pointing to a memory range translate into 20% less mallocs on
clang -cc1 -Eonly Cocoa_h.m.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106839 91177308-0d34-0410-b5e6-96231b3b80d8
