Bug reports should be sent to mercury-bugs@cs.mu.oz.au. If you're reporting more than one bug, please use separate emails for each bug. Please include all the relevant information, including which version of Mercury you're using, what operating system you're using, and a complete source file that demonstrates the problem. (If it's something that only shows up in multi-module programs, send a shar archive or uuencoded tar archive containing your source files.) Please try to ensure that bug reports contain all the information that we need to be able to reproduce the problem. Make sure that all bug reports are fully self-contained. Below is a list of the known outstanding bugs. We'll try to record any other bugs that are discovered on our WWW page . See also the LIMITATIONS file. Note: please do not be alarmed by the fact that this software has some bugs. ALL useful software has bugs. During the development of the Mercury implementation we have found bugs in gcc, as, ld, the dynamic loader, and even the OS kernel. We hope that by listing the known outstanding bugs here we are doing our users a service. It would be disappointing if anyone were to infer the wrong thing from it. ----------------------------------------------------------------------------- Subject: bug report - Inf and NaN Date: Wed, 4 Oct 1995 02:48:19 +1000 (EST) The following module causes an "undefined variable Inf" error in the generated C code, because 1E400 == Infinity, which gets printed as `Inf'. :- module hello. :- interface. :- import_module io. :- pred main(io__state::di, io__state::uo) is det. :- implementation. main --> io__write_float(1E400), io__write_string("\n"). ----------------------------------------------------------------------------- Subject: map__lookup failed in profiler Date: Tue, 7 May 1996 11:58:08 +1000 (EST) When profiling programs that have been compiled on the Alpha using shared libraries, the profiler will abort with a "Software Error: map__lookup failed" message. The work-around is to link with `--static'. This is actually due to a bug in the Alpha shared library mechanism, which does not conform to the ANSI C standard. There is not much we can do about this one. ----------------------------------------------------------------------------- Subject: nit in error msg Date: Thu, 16 May 1996 10:25:42 +1000 (EST) Here's another small error in an error message. If you comment out the [] clause for the functions car/1 or cdr/1, you get this message: fntest.m:023: In `car(in) = out': fntest.m:023: Error: determinism declaration not satisfied. fntest.m:023: Declared `det', inferred `semidet'. fntest.m:023: in argument 1 of clause head: fntest.m:023: unification of `HeadVar__1' and `[X | V_4]' can fail. It says Declared `det', inferred `semidet', but I never declared it at all. It's a bit misleading. Certainly not a major problem, and the later part of the message makes it quite clear what the problem is, but I thought I'd point it out to you before I forgot it. ----------------------------------------------------------------------------- Subject: missed mode error Date: Tue, 28 May 1996 02:27:34 +1000 (EST) Another one for the bug report file: The goal `some [X, Y] X \= Y' should be a mode error, but the current mode checker doesn't report an error. Instead, the compiler goes on to generate code which gives the wrong answer. For example, the following program prints out `no'. The same problem also occurs with `some [X, Y] (X = Y -> fail ; true)'. :- module bug. :- interface. :- import_module io. :- pred main(io__state::di, io__state::uo) is det. :- implementation. main --> ( { p } -> io__write_string("yes\n") ; io__write_string("no\n") ). :- pred p is semidet. p :- some [X, Y] X \= Y. The bug occurs only when the variables being unified inside a negated context are not live, i.e. when it is the last occurrence of those variables. ----------------------------------------------------------------------------- Subject: bug with PC values on Alpha Date: Wed, 12 Jun 1996 15:45:59 +1000 On the alpha, if the Mercury runtime catches a signal, it sometimes prints out the wrong value for the PC. ----------------------------------------------------------------------------- Subject: bug with polymorphic abstract exported equivalence types Date: Tue, 27 May 1997 20:42:43 +1000 (EST) The compiler generates incorrect code for the following program. The problem is that at the call to f/1 in module bar, f/1 has type `func(foo(T)) = int', and so it passes the type_info in r1 and the foo(T) (== int) in r2. But in the definition it has type `func(int) = int', so it just passes the int in r1. Similarly for the call to c/0. :- module foo. :- interface. :- func f(foo(T)) = int. :- type foo(T). :- func c = foo(int). :- implementation. :- import_module int. :- type foo(T) == int. f(X) = X + 1. c = 42. :- module bar. :- interface. :- import_module io. :- pred main(io__state::di, io__state::uo) is det. :- implementation. :- import_module foo. main --> write(f(c)), nl. ----------------------------------------------------------------------------- Subject: inter-module optimization and abstract exported equivalence types. Date: Thu, 19 February 1998 In some cases the compiler reports spurious ambiguity errors when compiling with `--intermodule-optimization'. This is due to the definition of abstract exported equivalence types being made visible by inter-module optimization. In this example, with `--intermodule-optimization' the compiler sees the declaration `:- type var == int' from term.m and then cannot determine whether `Elem' has type `int' or `pair(int)'. The work-around is to add an explicit type qualification. :- module foo. :- interface. :- import_module list, term. :- pred test(list(var)::in) is det. :- implementation. :- import_module int, std_util. test(Args0) :- MakeIndex = lambda([Elem0::in, Elem::out, Index0::in, Index::out] is det, ( Elem = Elem0 - Index0, Index is Index0 + 1 )), list__map_foldl(MakeIndex, Args0, _, 0, _). -----------------------------------------------------------------------------