mercury/BUGS

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 <http://www.cs.mu.oz.au/mercury>.
In addition to the bugs mentioned here, some bugs related
to the implementation of particular languages features
(existential types, nested modules, tabling)
are also mentioned in the language reference manual, and some
problems related to using Mercury on specific operating systems
are described in the README.* files.
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: GCC internal error
Date: Tue, 26 June 2001
   
    random.c: In function `random_module6':
    random.c:412: fixed or forbidden register 3 (bx) was spilled for class
    GENERAL_REGS.
    This may be due to a compiler bug or to impossible asm
    statements or clauses.

    mercury_trace_alias.c:98: Unable to find a register to spill in class
    `SIREG'.

This problem occurs with several different combinations of GCC version
and C source file.

This seems to be a bug in GCC's handling of global register variables.
The bug seems to be finally fixed in GCC 3.3 or 3.4.

If this problem occurs when compiling the source distribution, install
from the binary distribution instead.
   
If a similar problem occurs when compiling your program, there are a
few possible work-arounds:
* Use a lower level of C compiler optimization for the affected C
  files (add `CFLAGS-foo = -O1' or `CFLAGS-foo = -O0' to your
  Mmakefile for each affected C file).
* Use a high-level C code compilation grade (add `GRADE = hlc.gc' to
  your Mmakefile). These grades do not use the GCC extensions which
  trigger this problem. Unfortunately, mdb does not yet work with
  the high-level C back-end.
* Use `asm_jump.*' compilation grades instead of `asm_fast.*'
  grades. Note that `asm_jump.*' grades are not usually installed.
* Try a newer version of GCC.  Avoid GCC version 2.96 (distributed by
  Red Hat) and 3.0.

-----------------------------------------------------------------------------
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: NaN behaviour
Date: Mon, 21 Oct 2002 21:02:00 +1000

The mercury standard library tends to avoid producing NaN (e.g. throwing
an exception in many places where libc would return NaN), but it's still
possible from arithmetic functions (e.g. 0.0*Inf, Inf - Inf, Inf + -Inf,
Inf / Inf), sin,cos,tan when passed infinity, and perhaps other things (I
haven't done a full search).  Presumably it can also arise from using the
foreign language interface.

When NaN does arise, we have a problem that `=' (and unification) aren't
reflexive.  From a logical point of view, this is a fairly serious problem.

A lesser problem is that `<' doesn't induce a total order on floats.

-----------------------------------------------------------------------------
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: 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: 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, _).

-----------------------------------------------------------------------------

Date: Wed, 1 Dec 1999 22:52:57 +1100
Subject: compiler infinite loop for cyclic type classes

According to the language reference manual:

|  Typeclass constraints on type class declarations gives rise to a
|  superclass relation.  This relation must be acyclic.  That is, it is an
|  error if a type class is its own (direct or indirect) superclass.

But if you try to compile modules containing cyclic typeclasses,
the compiler goes into an infinite loop and eventually gets a
stack overflow, rather than reporting a proper error message.

-----------------------------------------------------------------------------