Allow the full form of FLUID-LET with ACCESS.

FLUID-LET of ACCESS broke.

(Yes, I know it's legacy, but I need it for another test at the
moment.)

Tickled a bug in connectivity analysis with arity error.

Compiler chokes on a variable named |#[continuation]|.

Open-code some flonum predicates on amd64.

- flonum-is-equal?
- flonum-is-finite?
- flonum-is-infinite?
- flonum-is-nan?
- flonum-is-normal?
- flonum-is-zero?

Teach sf about flo:safe-zero? and flo:safe=.

Speed this up a little at the expense of coverage.

Add some more spot checks.  Zero is not exact here, for sign.

Test some more edge cases and exception flags.

Teach Scheme about the floating-point subnormal-operand exception.

Make flo:clear-exceptions! register interest in fp env.

Not sure why I made it conditional before.  Makes sense for
flo:raise-exceptions! for functions whose callers might or might not
want them, but usually you do flo:clear-exceptions! only if you are
actually going to use them afterward.

Earlier change to flo:clear-exceptions! is busted.

In particular, the pattern

(flo:preserving-environment
 (lambda ()
   (flo:clear-exceptions! (flo:supported-exceptions))
   ...))

ought to give you an environment where the exceptions are cleared,
but it doesn't.

Teach the compiler about more boolean and function primitives.

Recursively integrate after substitution.

The declarations in this context may have changed.  This way, you can
get a lot of straight-line floating-point arithmetic like so:

(define (flo:sinh-taylor19 x)
  (declare (no-type-checks))
  (let* ((x^2 (flo:* x x))
         (t8 (flo:/ 1. 121645100408832000.))
         (t7 (flo:+ (flo:/ 1. 355687428096000.) (flo:* x^2 t8)))
         (t6 (flo:+ (flo:/ 1. 1307674368000.) (flo:* x^2 t7)))
         (t5 (flo:+ (flo:/ 1. 6227020800.) (flo:* x^2 t6)))
         (t4 (flo:+ (flo:/ 1. 39916800.) (flo:* x^2 t5)))
         (t3 (flo:+ (flo:/ 1. 362880.) (flo:* x^2 t4)))
         (t2 (flo:+ (flo:/ 1. 5040.) (flo:* x^2 t3)))
         (t1 (flo:+ (flo:/ 1. 120.) (flo:* x^2 t2)))
         (t0 (flo:+ (flo:/ 1. 6.) (flo:* x^2 t1))))
    (declare (integrate t0 t1 t2 t3 t4 t5 t6 t7 t8 x^2))
    (flo:* x (flo:+ 1. (flo:* x^2 t0)))))

Previously, the number of variables in this sequence that would be
integrated depended on the number of surrounding integrated calls in
the body of the let (!).

Restore parallel compilation of compiler.

Fix thinko.

Use real:abs, real:copysign.

These aren't guaranteed to be flonums here.

Mixed-exactness complex numbers are pretty silly.

Sqrt is busted on sone mixed-infinite/exact cases.

Make ieee754-binary-hex-string follow IEEE 754-2008.

New procedure (flo:logb x) gives the integer exponent of x.

Implement and fix fenceposts in inf and NaN encoding.

Use ieee754-binary-parameters to reduce magic constants.

Fix broken hexadecimal floating-point printing.

What was I thinking.  This is all wrong if the top bit is not 1.

Note copysign procedure.

Remove bogus note about flo:compare and flo:safe-compare.

Never actually committed these; decided a four-way comparison wasn't
worth it without a motivating application.  Won't work for anything
that expects a three-way -1/0/+1 compare.

Open-code flo:copysign on amd64.

Add a copysign test case that bit me in a state I can't reproduce.

Don't futz with floenv if not in use.

Makes flo:raise-exceptions! kosher to use anywhere without incurring
cost in threads that don't care.

Clear exceptions so residual crud doesn't trap.

Tidy up some negative tests.  No functional change intended.

Rename flo:safe-negative? -> flo:sign-negative?.

It was confusing that (flo:safe< x 0.) was not the same as
(flo:safe-negative? x) -- they disagree on -0 and NaN values with
negative sign bits.

Fix some things that I was mistakenly testing with an old compiler.

sqrt should not trap on qNaN, which requires some care with
comparisons.  Further, since sqrt(-0) is supposed to be -0, we can't
just use flo:safe-negative? (which returns true for -0.); we must
instead use (flo:safe< x 0.) (which returns false for -0.).

Define and expose flo:precision.

This is the same as flo:significand-digits-base-2, but its name
doesn't imply base 2 -- it refers to whatever the floating-point
radix is.  Not that we're likely to do decimal floating-point ever,
but maybe you might want to write code that could be used in another
environment that does.

Simplify and test some more exception cases.

Test NaN preservation of sqrt.

Handle more sqrt edge cases.

Enable traps here to confirm they don't happen.

Raise the appropriate exceptions in exact->exact.

- inexact-result if result is changed by rounding
- overflow if result is infinite.

Test exceptions in exact->inexact.

Teach exact->inexact to return infinity rather than crash.

Test exact->inexact near integer edge cases.

Use exact-integer-sqrt in sqrt for exact integers and rationals.

Deduplicate test cases.

Fix sqrt along negative real axis with inexact zero imaginary part.

Sqrt shouldn't discard an inexact zero imaginary component.

Test sqrt along the negative real line with/without inexact imaginary part.

Test (sqrt -0.) = -0., per IEEE 754-2008.

More sqrt edge cases, some working and some busted.

Couple more sqrt edge cases.

For +/-2i x, compute sqrt by sqrt(x) +/- i sqrt(x).

Strike off some expected failures.

Fix branch cuts of some test cases -- no more xfail!

Annotate where these tests rely on type and range checks.

Define (copysign m s) = magnitude of m, sign of s.

Add some more edge cases for sqrt.

Test exceptions in sqrt too.

Test flo:negate.

Add some more sqrt edge cases.

Fix mistranscription of opcode for UNPCKLF.

Add some more copysign tests.

Floating-point total ordering.

- (flo:total< x y) is true if x < y in the total ordering on
  floating-point values defined in IEEE 754-2008 Sec. 5.10, i.e. this
  is the totalOrder function of IEEE 754-2008 Sec. 5.7.2.
- (flo:total-order x y) is -1 if x < y, 0 if x = y, +1 if x > y in the
  total ordering -- the three-way comparison version of total<.
- (flo:total-mag< x y) = (flo:total< (flo:abs x) (flo:abs y))
- (flo:total-order-mag x y)
  = (flo:total-order (flo:abs x) (flo:abs y))

While here, tweak release notes on flonum stuff.

sqrt is busted on infinities.

Move a bunch of flonum tests to test-flonum.scm.

Let's keep test-arith.scm for higher-level numerical computations.

Make the signature of define-enumerated-test match everyone else.

Not sure why I used vectors here in the first place.

Note string and symbol escape printing bug.

Note local optional parameter bug.

Note magnitude overflow bug.

Note flo:min/max IEEE 754-2008 conformance.

Test more edge cases of rounding operations.

Include the rounding->exact operations too.

Update some release notes on floating-point stuff.

Use fabs(3) for C implementation of FLONUM-ABS.

A conditional based on < doesn't handle NaN correctly.

Our C implementation of flo:abs is busted.

Pass multiple arguments here.  No functional change.

New NaN-related and min/max flonum procedures and fixes.

- (flo:qnan) returns a quiet NaN: arithmetic on it quietly returns
  another qNaN (usually the same one, unless there are multiple to
  choose from) without raising any exception.

- (flo:snan) returns a signalling NaN: arithmetic on it returns
  another sNaN (usually the same) and raises an exception, which will
  trap if you ask.

- (flo:qnan? f) = (and (flo:nan? f) (flo:nan-quiet? f))

- (flo:snan? f) = (and (flo:nan? f) (not (flo:nan-quiet? f)))

- (flo:min x y) and (flo:max x y) now raise an exception only if at
  least one input is a signalling NaN, and traps only if you ask.
  These now implement minNum and maxNum of IEEE 754-2008.

- (flo:min-mag x y) and (flo:max-mag x y) return whichever of the
  inputs has the smaller magnitude, as in minNumMag and maxNumMag in
  IEEE 754-2008.

New primitives for creating and examining NaNs.

- (flo:make-nan negative? quiet? payload)
- (flo:nan-quiet? nan)
- (flo:nan-payload nan)

New CTASSERT macro for compile-time assertions.

Implement flo:safe-zero? and flo:safe=.

Merge these cases again now that the xfails are fixed.

Implement binary-hash-by-X; some hair to guarantee fixnum result.

Not nearly as fast as the underlying unary hash, but for now that's OK.  If need
be we can make it faster.

Simplify spar-push-body.

Eliminate unnecessary copy of map-in-order.

Teach LIAR/x86-64 to open-code flo:safe-negative?.

Correctly commute flo:safe>= to flo:safe<=, not to safe:>=.

Until LIAR's RTL code compression was taught to search through
object->float, this code path appears to have been impossible to
exercise.

Teach RTL compression to search through object->float too.

This way it can fold (object->float (constant #x1p+0)) in both

(assign (register #x22) (object->float (constant #x1p+0))
(assign (register #x23) (offset (register 4) (machine-constant 0)))
(assign (register #x24) (object->float (register #x23)))
(jumpc (flonum-pred-2-args flonum-is-greater? (register #x22) (register #x24)) label-3)

and

(assign (register #x21) (offset (register 4) (machine-constant 0)))
(assign (register #x22) (object->float (register #x21)))
(assign (register #x24) (object->float (constant #x1p+0)))
(jumpc (flonum-pred-2-args flonum-is-greater? (register #x22) (register #x24)) label-3)

where previously it could handle only the second one because the
reference appeared in the immediately subsequent instruction.

This exposes a latent bug in the x86-64 code generator, to be fixed
in a subsequent commit.

fixup! aa477cf3a28ded82f8cbcda5e8ee317cf9490d2f

Delete a rewriting rule that could not possibly have ever matched.

It would have required (object->float (object->float ...)) to appear
in the input, which makes no sense.

Test literal operands to flonum comparators.

This is a failed attempt to trigger a compiler bug that I noticed by
code inspection.

Make thie test actually check something by calling both.

Re-enable invalid-operation traps here and fix the one broken test.

Should maybe add a flo:safe-zero?, or decide that flo:zero? is the
quiet version and (flo:= x 0.) is the signalling one.

Factor out unary->binary predicate conversion.

Add flo:<>, as (or flo:< flo:>) for now.

Test flo:unordered? both ways too.

Test compilation of flonum comparisons both ways.

Run the flonum tests both compiled and interpreted.

These tests now pass on x86-64.

Need to teach i386, svm, and C about this now.

Test compiling in-line calls to the flonum comparators too.

Teach LIAR/x86-64 about ordered vs unordered comparisons.

- Fix miscompilation of ordered comparisons: now the standard
  comparison operators raise exceptions, which trap if you ask.

- Open-code the unordered comparisons flo:safe< &c.

Factor out unary->binary predicate conversion.

Explain what commute-flonum-predicate is doing.

Teach rtlgen to open-code flo:safe-negative? too.

Disabled on all machines for now.