Note: the phrase 'Found in CG n.m' should not be taken to imply that the
problem concerned does not exist in earlier versions of the compiler.


Bug 1:	Found in CG 2.10			   Fixed in CG 2.11

In some circumstances, a construct of the form	a := b; b := c	can be
effectively compiled in the wrong order, so that afterwards a = b = c.

New feature						 in CG 2.11

There is now some degree of checking for integer operands used with floating
point operators, and vice versa.  This cannot be complete, but at any rate
if you write  x#+1  you will get a warning.  The code compiled for such an
expression is the same as before (no coercion is done).

Bug 2:	Found in CG 2.11			   Fixed in CG 2.12

A procedure which ends by calling another with five arguments, and which
otherwise contains no procedure call (and which is sufficiently small) may
wrongly be compiled as needing no stackframe, meaning that the value of
argument 5 in the called procedure will be wrong.

Bug 3:	Found in CG 2.12			   Fixed in CG 2.13

An expression of the form  (p+k)!(n*q),  where k is a constant and n is even
may be compiled as if it were  p!(n*q)	(if there was a previous  p!...  so
that a shifted version of p is still present in a register).

Feature: in CG 2.12 and all earlier		   Fixed in CG 2.13

The code generated for floating-point operations uses the first version of the
floating-point instruction set.  Floating point is thus not available under
Arthur, for which only an emulator for the second version of the instruction
set is available.

Feature: in CG 2.12 and all earlier

When handling  GET "filename", the compiler looks first for a file named
filename, and then for :0.alib.filename (and it is an error if neither exists).
This isn't too appropriate for Arthur now, where :0 is the floppy.  I believe
that the search path should be user-suppliable, and that the default path
should have $.alib in place of :0.alib.  Currently, the path is fixed but it
is possible to specify where particular header files live by something like
  -HDR "LibHdr=a.b.c.LibHdr"
on the command line.

Bug 4:	Found in CG 2.12			   Fixed in CG 2.13

Where a sufficiently simple procedure (containing no calls is a necessary but
not sufficient constraint) returns as result the value of a static variable,
it may not load the pointer to the static variable area first, so that the
procedure acts correctly if called from within the same compilation unit, but
not if called externally.

Bug 5:	Found in CG 2.13 (also exists in all earlier versions)
						   Fixed in CG 2.14

VCAR (x+k) := floating point value  gets the offset k 4 times too large (not
shifting it down, since the instructions shift it up).

Bug 6:	Found in CG 2.13			   Fixed in CG 2.14

FIX always reads from FP reg 0, not the one the operand happens to be in.
(At places like just after procedure calls, this will in fact be right).

Bug 7: Found in CG 2.13 			   Fixed in CG 2.14

The fix to cure bug 4 above is wrong for procedures near the end of a compiled
section (starting within the last 512 words).  And whereas in the previous
state all that happened was that the wrong value was returned, now there may be
a data abort or address exception.

New feature					   in front end 2.2

It is now possible to switch off the special (for Cambridge Lisp) reserved
words NIL, LGE, LLE, LGT and LGR.  The L option controls their admissibility;
it is on by default (switched off by ... -opt -l).

Bug 8: Found in CG 2.13 			   Fixed in CG 2.14

The result of a/2, where a is negative, is (-a)/2.

Bug 9: Found in CG 2.14 			   Fixed in CG 2.14

Where a section has a very large number of (any combination of) STATIC
variables, TABLE elements and numeric constants too large to fit into a DP
instruction, the compiler may generate an internal error of the form:
      Resolve reference: offset ... at	....

Bug 10: Found in CG 2.14			   Fixed in CG 2.15

Further to 9, if a procedure is large and contains no use of STATIC variables,
TABLEs or strings, but does use large constants, the same internal error may
occur.

Bug 11: Found in CG 2.14			   Fixed in CG 2.15

The following sort of construct

   LET x = ...;
   LET y = ...;
   IF ...<#x1234 THEN {
      LET z = ...;
      LET zz = ...;

may (in circumstances easy to explain only in terms of the generated code)
cause the values for z and zz to be written to completely the wrong place in
store.	The important thing here is a comparison against a constant breakable
into two 8 bit chunks; the latter two declarations could equally well be a
FOR loop with variable upper bound; or both sets of declarations could be
assignments to adjacent variables declared previously.	Insertion of a
procedure call before the IF will certainly remove the problem; so may many
other small perturbations.

Bug 12: Found in CG 2.14			   Fixed in CG 2.15

In code like

   LET a = ...
   LET b = field OF @a

it is possible for the code to extract the field to precede that loading the
value for a.

Bug 13: Found in CG 2.11			   Fixed in CG 2.15

Code like
   x!3 := .....
   .... := x!3
(where there may be a sizeable gap between the two statements) may use
the old value of x!3 in the second statement.

Bug 14: Found in CG 2.15			   Fixed in CG 2.16

The N option does not as it should control inclusion of procedure name strings
in compiled code.

Bug 15: Found in CG 2.16

A procedure such as  LET f(a, b) BE a(b) is miscompiled.  Adding a dummy
procedure call will fix it.
