******************** KnownBugs ******************** Last Change: Wed May 17 17:44:15 1995 The current version of Parallaxis-III on this server is a much more stable version than the one from September. But remember it is not yet the final version. There still exist bugs. Most of them are missing consistency checks and missing error messages. The general rule is: if you enter correct Parallaxis source code you should get correct running code. This file contains a summary of the bugs we know of. We're working on them at the moment. If you encounter some strange behaviour of the compiler, please first check the list below if it's already a known bug before reporting it to us. ====================================================================== [This is the start of the BUGS-list.] ---------------------------------------------------------------------- The RETURN of a function-procedure always returns. This is wrong, only the active PEs should virtually return and the procedure should return only when all PEs have virtually returned. Example: CONFIGURATION conf[1..20]; PROCEDURE f():conf OF INTEGER; BEGIN IF ID(conf)>10 THEN RETURN 1; ELSE RETURN 5; END; (* IF *) END f; This should return 10x 1 and 10x 5, but it only returns 10x 1 and 10x undefined values, because the RETURN in the THEN part causes the whole procedure to return without executing the ELSE part. You can work around this problem by collecting the result in a variable and returning at a single point. CONFIGURATION conf[1..20]; PROCEDURE f():conf OF INTEGER; VAR h: conf OF INTEGER; BEGIN IF ID(conf)>10 THEN h := 1; ELSE h := 5; END; (* IF *) RETURN h; END f; ---------------------------------------------------------------------- If you enter a string in ReadString that is longer than the array of characters given to it, the additional characters overwrite the memory behind the array. Be sure to have arrays that are large enough. ---------------------------------------------------------------------- There are problems when using AND and OR in parallel boolean expressions. Be sure to use enough parentheses, then it works ok. (=> missing error message) This problems seems to be solved now. But further testing is needed. ---------------------------------------------------------------------- Don't use identifiers that are also used in Connection computations without declaring them. (=>missing error message) E.g. MODULE bug_con; CONFIGURATION list[1..5]; CONNECTION next: list[i] -> list[i+1]; BEGIN i := 1; (* <-- not declared but no error is reported !!! *) END bug_con. ---------------------------------------------------------------------- There are lots of runtime range checks missing, and those created show the line of the C-file, not the line of the Parallaxis-file. ---------------------------------------------------------------------- If you declare variables from an open configuration, you only get an error message from the C-compiler instead of the Parallaxis-compiler. CONFIGURATION grid[*],[*]; VAR x: grid OF INTEGER; (* <--- This is not allowed *) ---------------------------------------------------------------------- ID, DIM, ... don't generate errors when called with an open configuration. ---------------------------------------------------------------------- DIM(config, x) gives no runtime error when called with x>RANK(config). ---------------------------------------------------------------------- Type checking is missing in record constants: TYPE com = RECORD re,im: REAL END; CONST i = com(0,1); ^^^ should be REALs, but no error reported ---------------------------------------------------------------------- If you have a procedure with a vector VAR-parameter, you must not call it with a field of a record as in this example: MODULE bug_record; CONFIGURATION list[1..9]; TYPE Rec = RECORD x,y: INTEGER; END; (*RECORD*) PROCEDURE f(VAR x: list OF INTEGER); END f; VAR a: list OF Rec; BEGIN f(a.x); (* wrong *) END bug_record. This creates an error in the C-compiler pass. And this is a rather severe problem, where we have no correct solution yet. The problem is that such a record field is stored together with the other fields of the record. This is different to the way a usual vector variable is stored and so no pointer can be given to the procedure. If the parameter is call-by-value (no VAR), everything works fine. ---------------------------------------------------------------------- The check whether declarations in the DEFINITION MODULE and IMPLEMENTATION MODULE match should be improved. Especially if you import an identifier that does not exist in the DEFINITION MODULE, this is not recognized. ---------------------------------------------------------------------- If you compile a pair of .pd/.pm-files with option -c, the C-compiler generates warnings: gcc: -lp3: linker input file unused since linking not done gcc: -lm: linker input file unused since linking not done These warnings shouldn't be shown. ---------------------------------------------------------------------- There may be problems if you create CASE label ranges that reach MAX(INTEGER) or MAX(CARDINAL). The compiler may hang while generating infinite case labels, slowly filling your disk. ---------------------------------------------------------------------- The evaluation of expressions uses far too much help variables. This can be improved. This is no bug, but it slows down the simulation. ---------------------------------------------------------------------- Connections should only use the kind of indexes the configuration was declared with. Here is an error message missing. CONFIGURATION conf['A'..'H'],[0..255]; CONNECTION conn: conf[i,j]->conf[i,'x']; (* wrong *) ---------------------------------------------------------------------- Arrays that are declared local to a procedure may not have a procedure parameter as a boundary. Here's also an error message missing. PROCEDURE p(x: INTEGER); VAR a: ARRAY [1..x] OF CHAR; (* wrong *) ---------------------------------------------------------------------- If you import an identifier via FROM, it should be allowed to refer to it qualified. This is not possible at the moment. FROM mod IMPORT id; ... mod.id ... (* Should be possible *) ---------------------------------------------------------------------- In an assignment the expression on the right-hand side is evaluated before any expression in the lvalue on the left-hand side. This should be the other way round to guarantee the left-to-right evaluation rule. E.g. MODULE lefttoright; VAR i: CARDINAL; a: ARRAY[0..10] OF CARDINAL; PROCEDURE f():CARDINAL; BEGIN INC(i); RETURN i; END f; BEGIN i := 0; a[f()] := f(); (* results in a[2] := 1; should be: a[1] := 2 *) END lefttoright. ---------------------------------------------------------------------- Modula-2 defines the evaluation of boolean expressions to be done in the short form, i.e. the rest of the expression is not evaluated when the result cannot change anymore. E.g. IF (a c2[i]; b: c1[i] -> c2[i DIV 2]; VAR x,y: c1 OF INTEGER; z: c2 OF INTEGER; ... z := 0; z := MOVE.a(x) + MOVE.b:#SUM (y); Despite of the initialization with 0, at the end z contains only valid values on PEs 0..4. PEs 5..9 are undefined. When transmitting data from configuration c1 to configuration c2, there's no way to determine any default value for those PEs not receiving any value. And so PE 9 receives no value from either the first (via a) or the second term (via b), so it's undefined. PEs 5..8 receive a value from the first term (via connection a), but there's no value from the second term (via connection b), so they're undefined, too. An example using numbers should make this point clear: PE: 0 1 2 3 4 5 6 7 8 in c1 --------------------------------------------------------- a: 4 2 4 1 0 4 4 3 1 b: 2 3 3 1 0 4 0 3 2 PE: 0 1 2 3 4 5 6 7 8 9 in c2 --------------------------------------------------------- z: 0 0 0 0 0 0 0 0 0 0 after z:=0 1st term: 4 2 4 1 0 4 4 3 1 ? MOVE.a(x) 2nd term: 5 4 4 3 2 ? ? ? ? ? MOVE.b:#SUM (y) z: 9 6 8 4 2 ? ? ? ? ? after addition It may seem that the values of z (all zeros) could be used as default values in both data exchange operations. This is not true. The expression on the right-hand side must be fully computable without knowing anything about the left-hand side of the assignment, because an expression can also occur in situations, where no left-hand side even exists, e.g. as a parameter to a procedure call. This problem is not exactly a bug. It is a restriction due to the language design. As a result, the current version of Parallaxis-III only guarantees to get no undefined values when exchanging data within the same configuration. Here, the source value itself can be used as default value for the target value. Please remember, that SEND has no such problems, as it is a procedure. By giving the target configuration explicitly by a variable, the default values of the target can be directly used from this variable. ---------------------------------------------------------------------- ABS() used to return CARDINAL result when called with an INTEGER. This was not conform with the Modula-2 language report, where ABS should return the type of its argument. This is now corrected. ---------------------------------------------------------------------- ====================================================================== [This is the end of the Bugs-File.] Hartmut Keller, Thomas Braunl