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

llvm-svn: 186123

rdar://14323230

llvm-svn: 185397

[APFloat] Added unittest for APFloat.divide that checks special cases, result categories, and result statuses.

llvm-svn: 185050

llvm-svn: 185045

[APFloat] Added unittest for APFloat.multiply that checks special cases, result categories, and result status.

llvm-svn: 185044

[APFloat] Added unittest for APFloat.subtract that checks special cases, result categories, and result status.

llvm-svn: 185043

llvm-svn: 184974

llvm-svn: 184715

[APFloat] Added a large unittest for APFloat.add that checks that special values are computed correctly.

llvm-svn: 184714

The old isNormal is already functionally replaced by the method isFiniteNonZero
in r184350 and all references to said method were replaced in LLVM/clang in
r184356/134366.

llvm-svn: 184449

llvm-svn: 184447

I forgot to to do this in r184356. The only references were in APFloatTest.cpp.

llvm-svn: 184366

This is the first patch in a series of patches to rename isNormal =>
isFiniteNonZero and isIEEENormal => isNormal. In order to prevent careless
errors on my part the overall plan is:

1. Add the isFiniteNonZero predicate with tests. I can do this in a method
independent of isNormal. (This step is this patch).
2. Convert all references to isNormal with isFiniteNonZero. My plan is to
comment out isNormal locally and continually convert isNormal references =>
isFiniteNonZero until llvm/clang compiles.
3. Remove old isNormal and rename isIEEENormal to isNormal.
4. Look through all of said references from patch 2 and see if we can simplify
them by using the new isNormal.

llvm-svn: 184350

llvm-svn: 183525

llvm-svn: 183521

Specifically the following work was done:

1. If the operation was not implemented, I implemented it.

2. If the operation was already implemented, I just moved its location
in the APFloat header into the IEEE-754R 5.7.2 section. If the name was
incorrect, I put in a comment giving the true IEEE-754R name.

Also unittests have been added for all of the functions which did not
already have a unittest.

llvm-svn: 183179

llvm-svn: 183081