mirror of
https://github.com/Mercury-Language/mercury.git
synced 2026-04-16 18:03:36 +00:00
Estimated hours taken: 0.1 BUGS Added an entry for spurious ambiguity errors due to abstract exported equivalence types being made visible by --intermodule-optimization.
173 lines
6.0 KiB
Plaintext
173 lines
6.0 KiB
Plaintext
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>.
|
|
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, _).
|
|
|
|
-----------------------------------------------------------------------------
|