Now to copy a string into a BumpPtrAllocator and get a StringRef to the copy:

   StringRef myCopy = myStr.copy(myAllocator);
   

llvm-svn: 200885

llvm-svn: 200579

There are a couple of interesting things here that we want to check over
(particularly the expecting asserts in StringRef) and get right for general use
in ADT so hold back on this one. For clang we have a workable templated
solution to use in the meanwhile.

This reverts commit r200187.

llvm-svn: 200194

(1) Add llvm_expect(), an asserting macro that can be evaluated as a constexpr
    expression as well as a runtime assert or compiler hint in release builds. This
    technique can be used to construct functions that are both unevaluated and
    compiled depending on usage.

(2) Update StringRef using llvm_expect() to preserve runtime assertions while
    extending the same checks to static asserts in C++11 builds that support the
    feature.

(3) Introduce ConstStringRef, a strong subclass of StringRef that references
    compile-time constant strings. It's convertible to, but not from, ordinary
    StringRef and thus can be used to add compile-time safety to various interfaces
    in LLVM and clang that only accept fixed inputs such as diagnostic format
    strings that tend to get misused.

llvm-svn: 200187

[APInt] Fix nearestLogBase2 to return correct answers for very large APInt and APInt with a bitwidth of 1.

I also improved the comments, added some more tests, etc.

llvm-svn: 199610

This was due to arithmetic overflow in the getNumBits() computation. Now we
cast BitWidth to a uint64_t so that does not occur during the computation. After
the computation is complete, the uint64_t is truncated when the function
returns.

I know that this is not something that is likely to happen, but it *IS* a valid
input and we should not blow up.

llvm-svn: 199609

subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.

Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.

llvm-svn: 198685

llvm-svn: 198379

This functionality was enabled by r198374. Here's a test to ensure it
works and we don't regress it.

Based on a patch by Maciej Piechotka.

llvm-svn: 198377

It was never specialized so let's just remove that unused
configurability and always do the default.

llvm-svn: 198374

llvm-svn: 197647

Remove APInt::extractBit since it is already implemented via operator[]. Change tests for extractBit to test operator[].

llvm-svn: 197277

llvm-svn: 197272

llvm-svn: 197271

Defaulting to iOS 3.0 when LLVM has to guess the version is no longer a useful
option and can give surprising results (like tail calls being disabled).

5.0 seems like a reasonable compromise as a platform that's still interesting
to some people.

rdar://problem/15567348

llvm-svn: 196912

Enhance the tests to actually require moves in C++11 mode, in addition
to testing the moved-from state. Further enhance the tests to cover
copy-assignment into a moved-from object and moving a large-state
object. (Note that we can't really test small-state vs. large-state as
that isn't an observable property of the API really.) This should finish
addressing review on r195239.

llvm-svn: 195261

r195239, as well as a comment about the fact that assigning over
a moved-from object was in fact tested. Addresses some of the review
feedback on r195239.

llvm-svn: 195260

Somehow, this ADT got missed which is moderately terrifying considering
the efficiency of move for it.

The code to implement move semantics for it is pretty horrible
currently but was written to reasonably closely match the rest of the
code. Unittests that cover both copying and moving (at a basic level)
added.

llvm-svn: 195239

This patch places class definitions in implementation files into anonymous
namespaces to prevent weak vtables. This eliminates the need of providing an
out-of-line definition to pin the vtable explicitly to the file.

llvm-svn: 195092

This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file. The memory leaks in this version have been fixed. Thanks
Alexey for pointing them out.

Differential Revision: http://llvm-reviews.chandlerc.com/D2068

Reviewed by Andy

llvm-svn: 195064

This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
  Base *foo = new Child();
  delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.

llvm-svn: 194997

This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file.

Differential Revision: http://llvm-reviews.chandlerc.com/D2068

Reviewed by Andy

llvm-svn: 194865

This bug only bit the C++98 build bots because all of the actual uses
really do move. ;] But not *quite* ready to do the whole C++11 switch
yet, so clean it up. Also add a unit test that catches this immediately.

llvm-svn: 194548

a derived type and this makes it *much* easier to write this code.

llvm-svn: 194321

llvm-svn: 194320

r-value references. I still want to test that when we have them,
llvm_move is actually a move.

Have I mentioned that I really want to move to C++11? ;]

llvm-svn: 194318

Clang managed to never instantiate the copy constructor. Added tests to
ensure this path is tested.

We could still use tests for the polymorphic nature. Those coming up
next.

llvm-svn: 194317

to fix C++98 builds.

llvm-svn: 194316

unique ownership smart pointer which is *deep* copyable by assuming it
can call a T::clone() method to allocate a copy of the owned data.

This is mostly useful with containers or other collections of uniquely
owned data in C++98 where they *might* copy. With C++11 we can likely
remove this in favor of move-only types and containers wrapped around
those types.

llvm-svn: 194315

startswith_lower is ocassionally useful and I think worth adding.
endwith_lower is added for completeness.

Differential Revision: http://llvm-reviews.chandlerc.com/D2041

llvm-svn: 193706

llvm-svn: 193550

separator between each two elements.

llvm-svn: 189846

This is a re-commit of r189442; I'll follow up with clang changes.

The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in.  The larger default is much
less confusing.

I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which).  I have a WIP patch if anyone is interested.

llvm-svn: 189624

This is breaking numerous Clang tests on the buildbot.

llvm-svn: 189447

The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in.  The larger default is much
less confusing.

I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which).  I have a WIP patch if anyone is interested.

llvm-svn: 189442

llvm-svn: 188933

IEEE-754R 1.4 Exclusions states that IEEE-754R does not specify the
interpretation of the sign of NaNs. In order to remove an irrelevant
variable that most floating point implementations do not use,
standardize add, sub, mul, div, mod so that operating anything with
NaN always yields a positive NaN.

In a later commit I am going to update the APIs for creating NaNs so
that one can not even create a negative NaN.

llvm-svn: 187314

This reverts commit r187248. It broke many bots.

llvm-svn: 187254

Both GCC and LLVM will implicitly define __ppc__ and __powerpc__ for
all PowerPC targets, whether 32- or 64-bit.  They will both implicitly
define __ppc64__ and __powerpc64__ for 64-bit PowerPC targets, and not
for 32-bit targets.  We cannot be sure that all other possible
compilers used to compile Clang/LLVM define both __ppc__ and
__powerpc__, for example, so it is best to check for both when relying
on either inside the Clang/LLVM code base.

This patch makes sure we always check for both variants.  In addition,
it fixes one unnecessary check in lib/Target/PowerPC/PPCJITInfo.cpp.
(At least one of __ppc__ and __powerpc__ should always be defined when
compiling for a PowerPC target, no matter which compiler is used, so
testing for them is unnecessary.)

There are some places in the compiler that check for other variants,
like __POWERPC__ and _POWER, and I have left those in place.  There is
no need to add them elsewhere.  This seems to be in Apple-specific
code, and I won't take a chance on breaking it.

There is no intended change in behavior; thus, no test cases are
added.

llvm-svn: 187248

There were a couple of different loops that were not handling
'.' correctly in APFloat::convertFromHexadecimalString; these mistakes
could lead to assertion failures and incorrect rounding for overlong
hex float literals.

Fixes PR16643.

llvm-svn: 186539