llvm-svn: 58690

llvm-svn: 58689

For some targets, it's not possible to place GVs in the same memory buffer as the MachineCodeEmitter allocated memory. Code and data has different read / write / execution privilege requirements.

This is a short term workaround. The current solution is for the JIT memory manager to manage code and data memory separately.

llvm-svn: 58688

friendlier to non-Unixes that happen to have perl. Patch from Sascha Othman!

llvm-svn: 58687

llvm-svn: 58685

llvm-svn: 58684

llvm-svn: 58683

llvm-svn: 58682

llvm-svn: 58681

llvm-svn: 58680

tools/llc/CMakeLists.txt.

llvm-svn: 58678

Linux/x86-64.

llvm-svn: 58677

llvm-svn: 58676

* The prologue is modified to read the __stack_chk_guard global and insert it
  onto the stack.

* The epilogue is modified to read the stored guard from the stack and compare
  it to the original __stack_chk_guard value. If they differ, then the
  __stack_chk_fail() function is called.

* The stack protector needs to be first on the stack (after the parameters) to
  catch any stack-smashing activities.

Front-end support will follow after a round of beta testing.

llvm-svn: 58673

llvm-svn: 58672

llvm-svn: 58671

llvm-svn: 58666

llvm-svn: 58663

llvm-svn: 58658

llvm-svn: 58657

llvm-svn: 58656

have its node id set. The new and and shift nodes are the nodes that need
the IDs. This fixes PR2982.

llvm-svn: 58655

Fix <rdar://problem/6339636> clang ObjC rewriter: Assertion failed: FileID-1 < FileIDs.size() && "Invalid FileID!", file c:\cygwin\home\Administrator\llvm\tools\clang\include\clang/Basic/SourceManager.h, line 513

llvm-svn: 58654

llvm-svn: 58653

Fix Plist output.

llvm-svn: 58652

llvm-svn: 58651

llvm-svn: 58650

llvm-svn: 58649

llvm-svn: 58647

llvm-svn: 58646

llvm-svn: 58644

llvm-svn: 58643

work correctly, and bring over a late change to ppcf128
SetCC handling.

llvm-svn: 58642

  X x(5, 7);

llvm-svn: 58641

sized integers like i129, and also reduce the number
of assumptions made about how vaarg is implemented.
This still doesn't work correctly for small integers
like (eg) i1 on x86, since x86 passes each of them
(essentially an i8) in a 4 byte stack slot, so the
pointer needs to be advanced by 4 bytes not by 1 byte
as now.  But this is no longer a LegalizeTypes problem
(it was also wrong in LT before): it is a bug in the
operation expansion in LegalizeDAG: now LegalizeTypes
turns an i1 vaarg into an i8 vaarg which would work
fine if only the i8 vaarg was turned into correct code
later.

llvm-svn: 58635

Eric C, thanks!

llvm-svn: 58634

to avoid overload ambiguities. This fixes build errors introduced
by r58623.

llvm-svn: 58632

llvm-svn: 58631

add a period at the end of the comment, ignoring the fact that the comment would be hard pressed to be considered a sentence, but if it makes Bill happy...

llvm-svn: 58630

cope with the case where a user-defined conversion is actually a copy
construction, and therefore can be compared against other standard
conversion sequences. While I called this a hack before, now I'm
convinced that it's the right way to go.

Compare overloads based on derived-to-base conversions that invoke
copy constructors. 

Suppress user-defined conversions when attempting to call a
user-defined conversion.

llvm-svn: 58629