llvm-svn: 185128

llvm-svn: 185127

* Don't try to create parent directories in unique_file. It had two problem:
   * It violates the contract that it is atomic. If the directory creation
     success and the file creation fails, we would return an error but the
     file system was modified.
   * When creating a temporary file clang would have to first check if the
     parent directory existed or not to avoid creating one when it was not
     supposed to.

* More efficient implementations of createUniqueDirectory and the unique_file
  that produces only the file name. Now all 3 just call into a static
  function passing what they want (name, file or directory).

Clang also has to be updated, so tests might fail if a bot picks up this commit
and not the corresponding clang one.

llvm-svn: 185126

Templatize connectAtomsWithLayoutEdge() so that it can handle other types of
defined atoms.

llvm-svn: 185125

llvm-svn: 185124

llvm-svn: 185123

radar://14169017

llvm-svn: 185122

llvm-svn: 185121

llvm-svn: 185120

llvm-svn: 185119

This replaces a long list of declarations for visitor functions with
a list generated from DeclNodes.inc.  Nothing really interesting came
out of it; we had comprehensive coverage anyway
(excluding FriendTemplateDecls).

llvm-svn: 185118

initialized during aggregate initialization of the surrounding structure.

llvm-svn: 185117

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

llvm-svn: 185115

a zero-argument createNullPtrType function for creating the canonical
nullptr type.

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

llvm-svn: 185114

llvm-svn: 185113

passing arguments in the fixed style.

We have an abstraction for deciding this, but it's (1) deep in
IR-generation, (2) necessarily tied to exact argument lists, and
(3) triggered by unprototyped function types, which we can't
legitimately make in C++ mode.  So this solution, wherein Sema
rewrites the function type to an exact prototype but leaves the
variadic bit enabled so as to request x86-64-like platforms to
pass the extra variadic info, is very much a hack, but it's one
that works in practice on the platforms that LLDB will support
in the medium term --- the only place we know of where it's a
problem is instance methods in Windows, where variadic functions
are implicitly cdecl.  We may have a more abstracted base on which
to build a solution by then.

rdar://13731520

llvm-svn: 185112

Revert "Revert "[APFloat] Removed APFloat constructor which initialized to either zero/NaN but allowed you to arbitrarily set the category of the float.""

This reverts commit r185099.

Looks like both the ppc-64 and mips bots are still failing after I reverted this
change.

Since:

1. The mips bot always performs a clean build,
2. The ppc64-bot failed again after a clean build (I asked the ppc-64
maintainers to clean the bot which they did... Thanks Will!),

I think it is safe to assume that this change was not the cause of the failures
that said builders were seeing. Thus I am recomitting.

llvm-svn: 185111

This reverts commit r184817. The failure Chandler was seeing was most likely the
bug that Bob Wilson fixed in r184870 (which was a bug caught by these tests).

To be safe, I just checked again on x86-64 mac os x/linux that this test passed
(which it did).

llvm-svn: 185110

its only caller with a FIXME explaining why it's bogus.

llvm-svn: 185109

llvm-svn: 185108

Both StopReadThread and the thread being stopped set the thread id to
0 after m_read_thread_enabled was set to false. If the thread being
stopped got there first then StopReadThread called pthread_join on an
invalid thread number. This is not a Good Thing,

Should fix a fairly regular segfault when quitting on Linux.

llvm-svn: 185107

llvm-svn: 185106

llvm-svn: 185105

llvm-svn: 185104

llvm-svn: 185103

llvm-svn: 185102

llvm-svn: 185101

Under -fms-extensions, only inject a friend tag name when we didn't see a tag with that name in an enclosing scope.

r177473 made us correctly consider only those declarations in the
enclosing namespace scope when looking for a friend declaration. Under
ms-extensions mode, where we do some level of friend injection, this
meant that we were introducing a new tag type into a different scope
than what Microsoft actually does. Address this by only doing the
friend injection when we didn't see any tag with that name in any
outer scope. Fixes <rdar://problem/14250378>.

llvm-svn: 185100

Revert "[APFloat] Removed APFloat constructor which initialized to either zero/NaN but allowed you to arbitrarily set the category of the float."

This reverts commit r185095. This is causing a FileCheck failure on
the 3dnow intrinsics on at least the mips/ppc bots but not on the x86
bots.

Reverting while I figure out what is going on.

llvm-svn: 185099

llvm-svn: 185098

Otherwise, we end up with an exponential IR blowup.
Fixes PR16472.

llvm-svn: 185097

llvm-svn: 185096

[APFloat] Removed APFloat constructor which initialized to either zero/NaN but allowed you to arbitrarily set the category of the float.

The category which an APFloat belongs to should be dependent on the
actual value that the APFloat has, not be arbitrarily passed in by the
user. This will prevent inconsistency bugs where the category and the
actual value in APFloat differ.

I also fixed up all of the references to this constructor (which were
only in LLVM).

llvm-svn: 185095

algorithm when assigning EnumValues to the synthesized registers.

The current algorithm, LessRecord, uses the StringRef compare_numeric
function.  This function compares strings, while handling embedded numbers.
For example, the R600 backend registers are sorted as follows:

  T1
  T1_W
  T1_X
  T1_XYZW
  T1_Y
  T1_Z
  T2
  T2_W
  T2_X
  T2_XYZW
  T2_Y
  T2_Z

In this example, the 'scaling factor' is dEnum/dN = 6 because T0, T1, T2
have an EnumValue offset of 6 from one another.  However, in other parts
of the register bank, the scaling factors are different:

dEnum/dN = 5:
  KC0_128_W
  KC0_128_X
  KC0_128_XYZW
  KC0_128_Y
  KC0_128_Z
  KC0_129_W
  KC0_129_X
  KC0_129_XYZW
  KC0_129_Y
  KC0_129_Z

The diff lists do not work correctly because different kinds of registers have
different 'scaling factors'.  This new algorithm, LessRecordRegister, tries to
enforce a scaling factor of 1.  For example, the registers are now sorted as
follows:

  T1
  T2
  T3
  ...
  T0_W
  T1_W
  T2_W
  ...
  T0_X
  T1_X
  T2_X
  ...
  KC0_128_W
  KC0_129_W
  KC0_130_W
  ...

For the Mips and R600 I see a 19% and 6% reduction in size, respectively.  I
did see a few small regressions, but the differences were on the order of a
few bytes (e.g., AArch64 was 16 bytes).  I suspect there will be even
greater wins for targets with larger register files.

Patch reviewed by Jakob.
rdar://14006013

llvm-svn: 185094

llvm-svn: 185093

llvm-svn: 185092

* Use a single stat to find out if the file exists and if it is a regular file.
* Use early returns when possible.
* Add comments explaining why we have each check.

llvm-svn: 185091

llvm-svn: 185089

the time when the IRInterpreter ran inside
IRForTarget.

llvm-svn: 185088

Because Registry.h is using the LLVM_DELETED_FUNCTION macro.

llvm-svn: 185087