This change allow cmucl to fold identity operations as in

(defun foo (x)
  (declare (float x))
  (* x 1))

Previously, cmucl wouldn't change (* x 1) to just x. because the
declaration of x is represented internally as a union type.

srctran.lisp::
 * The optional convert-type arg is always true, so remove it and
   update the local functions to convert always.
 * Clean up some comments as well.

float-tran.lisp::
 * Fix up one place where we were supplying a value for the optional
   convert-type arg.

accordingly.

The reader conditionals in {{{NOT-MORE-CONTAGIOUS}}} were incorrrectly
handling the case when the second type was a double-float. It was
always returning T in that case, but this is wrong if the first type
is a double-double-float.

entries with just the file path, removing the revision number, date,
author and state.  The actual information is now computed during
compilation and stored in the fasl itself.  (See ticket:48.)

suggested by Helmut Eller on cmucl-imp, 2011-01-08.

may get confused with source locations if the reader macros are
installed.

boot-2010-02-1 as the bootstrap file.  You should probably also use
the new -P option for build.sh to generate and update the po files
while building.

unicode-utf16-extfmt-2009-06-11.

o Remove the %ldb change in rev 1.164 to workaround in ticket #20.
o Delay the logand optimizer so that it runs later.  This allows type
  propagation a chance to converge before we run the logand
  optimizer.  This fixes ticket #20 and #21.  This may increase
  compilation time since the IR1 optimizations will run more often due
  to logand changes.

general-info/release-19f.txt:
o Update for modular arith fixes
o Update ticket #15 since we have SSE2 now.

args was (integer 0 0).  Move the case for zero length args up to
handle this case, before we get to the bounded/unbounded case.

  (defun foo (x)
    (declare (type unsigned-byte x))
    (logand x #xff))

  It was returning unsigned-byte when the result should have a bounded
  type like (unsigned-byte 8).

o Small optimization for %ldb deftransform:  If the byte positiion is
  known to be 0, don't transform to (ash int 0), but just replace it
  with int.

in a fixnum.  Consider the case where x and y are fixnums in

    (logand (* x y) 255)

The compiler knows the result must be 8 bits long, but we need to do
modular arithmetic because the (* x y) can be longer than 32 bits.

Thus, only skip the modular arithmetic stuff if both args are known to
be fixnums.

modular arithmetic and is basically implemented in vm-tran.lisp.

o Adjust deftransform for %ldb to precompute the shift and/or mask if
  they are known to be constants.  This works around the problem
  mentioned in ticket #20.
o Change LOGAND-DEFOPT-HELPER to do modular arith stuff only if the
  derived result type won't fit in a fixnum.  This gives the fixnum
  vops a chance to work, speeding some things up.
  - This appears to fix the issues tickets #18 and #19.
  - Some simple benchmarks indicates this change can produce a 10%-15%
    speedup.
  - Not 100% sure this is correct, but it should be ok.

compiler/sparc/arith.lisp:
o Change cost of FAST-LOGAND-C/SIGNED-UNSIGNED=>UNSIGNED to 2 to give
  the equivalent fixnum VOP a chance.

The defoptimizer for SIGNUM was not handling DOUBLE-DOUBLE-FLOAT
numbers at all.

The merge is from the tag "double-double-irrat-end".  The
double-double branch is now obsolete.

The code should build without double-double support (tested on sparc)
as well as build with double-double support (tested also on sparc).

with [0.0, 0.0] to produce [-0.0,-0.0].  The correct answer is
[-0.0,0.0].  This bug was reported by Mika Pihlajamaki, cmucl-imp, Dec
28, 2005.

A simple test case is

(defun foo2b ()
  (* 0
     (+ (if (< 1 1)
	    1
	    1)
	3.14)))

whether the compiler will do modular arithmetic optimizations when
compiling code.

This allows a workaround for a bug noted by Martin Cracauer on
cmucl-imp, 2005/07/20.  Also works around an old bug on cmucl-help,
2004/11/03.

constant-argument's of type number instead of t.  This fixes ansi-test
misc.149a, misc.149, and misc.108.

We should probably examine other deftransforms to make sure they only
get called on other constant-argument's of the appropriate type.

NIL, which means unbounded.  Fixes ansi-test misc.89b, which was
calling coerce on an integer that was too big to fit in a
single-float.

result if -0.0 could be returned.  This causes the misc.558 ansi-test
to fail.

We should do something better than this fix.

Delight.

Fixes 6 misc tests from ansi-tests where type derivation for LOGAND
was broken.

o Remove some unused variables

type of (logior positive-integer 0) to (integer 0 0).  Same problem
with logxor.

non-negative when one arg was negative but the other was not.

Should fix the segfault for the misc.306 ansi test.

left shift of 1 because deftransforms were not checking for the case
of a 0 arg.

bounds.

Currently only for (unsigned-byte 32) and subtypes thereof.

before checking if they're numeric-type-p.  So %dpb-derive-type-aux
was never computing anything useful.

because when width is 0, (unsigned-byte 0) is invalid and we really
wanted (integer 0 0) anyway.

Happens when deriving the type of (logand x 0).

during interval arithmetic and returns a doubly unbounded INTERVAL.  Use this
in the INTERVAL-* routines.

This is intended to fix the ansi-test failure misc.89.  The approach is
rather heavy-handed, and a better solution is desirable.

consistent in which argument is selected.  Previously, they were
inconsistent which causes problems when the argument types are equal,
but of different types.

(Based on a patch Alexey Dejneka did for SBCL for the same issue.)

  (that we backed out) so (abs (the (double-float 0d0) x)) produces
  the correct result.
o Add a kludge to INTERVAL-RANGE-INFO to handle the case of an
  interval -0.0 to 0.0 specially.  INTERVAL-RANGE-INFO should return
  NIL instead of '- for this.
o The fixes to INTERVAL-RANGE-INFO tickle a bug in INTERVAL-SPLIT
  where we weren't correctly splitting the the interval [-0.0, 0d0]
  into 2 intervals correctly.  This was causing the compiler to loop
  forever deriving things.

This is all a bit kludgy.  Dealing with signed-zeroes is a pain.

the stack:

(defun foo (x)
  (declare (type (member 0d0 -0d0) x))
  (/ 46666 x))

  This shows up in deriving the type of (abs (the (double-float
  0d0))), which was (double-float 0d0), but should have been (or
  (member 0d0) (double-float (0d0)).

o In TWO-ARG-DERIVE-TYPE, use our own same-leaf-ref-p in place of the
  real same-leaf-ref-p.  We don't care if the leaf is not constant,
  only that they are the same leaf.  This shows up in Eric Marsden's
  cl-bench where CMUCL was not able to deduce that z^2 is positive in
  mandelbrot/dfloat.