home *** CD-ROM | disk | FTP | other *** search
- 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.
-