Fix the build on OS X 10.8.0

It seems our exception handler can be called before it's fully set up.
Handle that case without potentially leaking too many ports.

Reported by Gabriel Dos Reis on sbcl-devel.
Substitute constants with modular equivalents more safely

* Modular arithmetic sometimes lets us narrow constants down,
  especially with signed arithmetic. We now update the receiving
  LVAR's type conservatively when there are multiple uses; otherwise,
  conflicting type information results in spurious dead code
  elimination.

* Test case by Eric Marsden.

* Reported by Eric Marsden on sbcl-devel (2013-04-18).
Trivial code cleanups

 Declare a variable as ignored, and descriptors are 64 bit on
 x86-64. The latter was brought to my attention by Douglas Katzman.
sort NEWS into enhancement/bug fix/optimization order
fix formatting of most recent "changes" line in NEWS
1.1.7: will be tagged as "sbcl-1.1.7"
Handle environment initialization better.

Don't fail with mysterious errors and memory faults on startup during
initialization of *default-pathname-defaults* when the current
directory contains undecodable characters or is deleted. Similarly
catch decoding errors for things like *runtime-pathname* and
*posix-argv*.
Turn the errors into warnings, and ensure that streams are initialized
and the error messages can be printed.
Add :directory argument to sb-ext:run-program.

The implementation uses chdir(2) on Unices, the lpCurrentDirectory
argument to CreateProcessW on Windows.
Slightly adapted from the patch by Matthias Benkard.
Closes lp#791800
Fix init-var-ignoring-errors.

Actually set the variable to the default value in case of an error.

Caught by Nikodemus Siivola.
Split bitops-derive-type.lisp out of srctran.lisp.

The moved part contains DERIVE-TYPE methods for LOGAND, LOGIOR, and
friends. The split is motivated by srctran.lisp being too large and
by planned changes to these type derivers.
Improve scaling of type derivation for LOG{AND,IOR,XOR}.

If the types of the arguments of LOG{AND,IOR,XOR} are known to be ranges
of non-negative integers the compiler currently derives the range of the
result using straightforward implementations of algorithms from
"Hacker's Delight". These take quadratical time in the number of bits of
the inputs in the worst case, potentially leading to unacceptably long
compilation times. (The algorithms are based on loops over the bits of
the inputs, doing calculations during each iteration that are themselves
linear in the number of bits of their operands.)

Instead implement bit-parallel algorithms I have found that take linear
time in all cases. While their runtime therefore is limited to much
smaller values for large inputs, it is comparable to that of the current
algorithms for small inputs, too; the new deriver for LOGXOR is in fact
faster than the old one by a factor of two to ten already in the latter
case.

The (existing) test for these derivers compares their results with those
from a brute-force algorithm for all O(N^4) many pairs of input ranges
with endpoints from the set of N-bit unsigned integers. The brute-force
algorithm needs to consider O(N^2) input pairs for each pair of ranges,
making the total runtime O(N^6). Therefore the test normally runs with
N = 5. I have tested all three new derivers successfully with N = 7.

Replace LOG{AND,IOR,XOR}-DERIVE-UNSIGNED-{LOW,HIGH}-BOUND with
LOG{AND,IOR,XOR}-DERIVE-UNSIGNED-BOUNDS to make it possible to evaluate
expressions only once that the calculations for the low and the high
bound have in common. The callers always need both bounds anyway.

Adapt the test to this change. (It runs twice as fast now due to the
brute force loop calculating both bounds in one go.)

Add a test for the scaling behaviour. This needs a function to measure
runtimes over potentially large ranges; add this to test-util.lisp.

Fixes lp#1096444.
Faster ISQRT on small (about fixnum sized) numbers.

ISQRT is implemented using a recursive algorithm for arguments above 24
which is compiled using generic arithmetic only (as it must support both
fixnums and bignums).

Improve this by compiling this recursive part twice, once using generic
and once fixnum-only arithmetic, and dispatching on function entry into
the applicable part. For maximum speed, the fixnum part recurs directly
into itself, thereby avoiding further type dispatching.

This makes ISQRT run about three times as fast on fixnum inputs while
the generated code is about 40 percent larger (both measured on x86-64).
For bignums a speedup can be seen, too, as ISQRT always recurs into
fixnum territory eventually, but the relative gain obviously becomes
smaller very fast with increasing size of the argument.

I have changed the variable names in the recursive part; they no longer
have an "n-" prefix as this in SBCL by convention means "number of" and
as the argument of the recursive part is no longer visibly "n".

Slightly augment the test case.
Convert the MOVE macro on x86-64 into a function.

This is possible as the macro is used just to simulate an inline
function. Converting MOVE into a true function shrinks the core by
448 KiB and may even make the compiler run faster due to reduced
instruction cache pressure.

Some background: Only on x86-64 MOVE is used with float SCs sometimes.
It therefore needs to select different machine instructions depending on
the SC of its destination argument. This compiles to so much code that
inlining it can't be justified, especially given that MOVE is used in
several hundred VOPs.

While at it, correct the comment at the top of the file for 64-bitness.
Document the new :directory argument for run-program.
Micro-optimize integer-length on fixnums on x86-64.

INTEGER-LENGTH is implemented by using the BSR instruction, which
returns the position of the first 1-bit from the right. And that needs
to be incremented to get the width of the integer, and BSR doesn't
work on 0, so it needs a branch to handle 0.

But fixnums are tagged by being shifted left n-fixnum-tag-bits times,
untagging by shifting right n-fixnum-tag-bits-1 times (and if
n-fixnum-tag-bits = 1, no shifting is required), will make the
resulting integer one bit wider, making the increment unnecessary.
Then, to avoid calling BSR on 0, OR the result with 1. That sets the
first bit to 1, and if all other bits are 0, BSR will return 0,
which is the correct value for INTEGER-LENGTH.
backtrace-interrupted-condition-wait now passes on darwin.
ppc: Implement :stack-allocatable-fixed-objects

  * Alter SYS:SRC;COMPILER;PPC;MACROS.LISP, WITH-FIXED-ALLOCATION
to accept a parameter for requesting stack allocation instead of
heap allocation.

  * Alter SYS:SRC;COMPILER;PPC;ALLOC.LISP, VOP FIXED-ALLOC to pass
the new stack-allocation parameter.

  * And add :stack-allocatable-fixed-objects to the PPC section in
make-config.sh.
compiler/{sparc,ppc}/macros: with-pinned-objects improvements.

  * For all precise gencgc backends, with-pinned-objects uses an
explicit "pin list".  This pin list should be stack-allocated.

  * Declare the pin list to be TRULY-DYNAMIC-EXTENT, for both
backends.  This won't actually do anything unless the backend
also supports :stack-allocatable-fixed-objects or more than two
objects are to be pinned at once (one-arg LIST and two-arg LIST*
are both converted to CONS by the compiler, and CONS falls under
:stack-allocatable-fixed-objects rather than
:stack-allocatable-lists).
Add test cases for non-consing WITHOUT-GCING and WITH-PINNED-OBJECTS.

  * Neither of these two constructs should cons under normal
circumstances, but WITH-PINNED-OBJECTS is occasionally broken in
this respect on some backends.  May as well make it explicit and
official.
gencgc: Compute bytes_allocated correctly during dynamic space pickup.

  * Rather than computing bytes_allocated based on the number of
pages prior to the "alloc pointer" (really the heap high-water
mark), accumulate it based on the number of ALLOCATED pages.

  * Fixes some lossage in write_generation_stats(), which seems to
be the only place where this value is checked against reality.