[m-rev.] for review: BUGS file rewrite

[Julien Fischer]

Branches: 10.04, main

Rewrite the BUGS file -- the (old) bugs that used to be listed here
have been shifted into the bug database, or have been deleted.

BUGS:
 	Mention the bug database -- mention that the list of current
 	bugs is located there.

 	Delete entries for bugs that are now in the bug database.

 	Mention that bug reports should include the name and version
 	of the C/Java/Erlang compiler involved and the command line
 	options used with mmc.

Index: BUGS
===================================================================
RCS file: /home/mercury/mercury1/repository/mercury/BUGS,v
retrieving revision 1.26
diff -u -r1.26 BUGS
--- BUGS	2 May 2007 07:30:57 -0000	1.26
+++ BUGS	25 May 2010 04:37:49 -0000
@@ -1,160 +1,32 @@
-Bug reports should be sent to mercury-bugs at csse.unimelb.edu.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.mercury.csse.unimelb.edu.au>.
-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.
-
------------------------------------------------------------------------------
-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 =
-		(pred(Elem0::in, Elem::out, Index0::in, Index::out) is det :-
-			Elem = Elem0 - Index0,
-			Index is Index0 + 1
-	),
-	list.map_foldl(MakeIndex, Args0, _, 0, _).
-
------------------------------------------------------------------------------
-Subject: mode analysis bug
-Date: 1 December 2004
-
-The Mercury compiler sometimes aborts with the following error message:
-
-  	Uncaught Mercury exception:
-  	Software Error: inappropriate determinism inside a negation
-
-This bug is due to a limitation in the mode checker.  It has only
-been reported as occurring when inlining is enabled.  A workaround
-is to disable inlining for any affected files.  This can be done
-by using the option `--no-inlining'.
+Bugs can be reported via the Mercury bug tracking system at
+<http://bugs.mercury.csse.unimelb.edu.au>.  We use the Mantis bug tracking
+software.  You will need to login in order to access the bug tracking system.
+If you do not have an account, you can create one by clicking on the 
+``Signup for a new account'' link at the bottom of the login page and
+following the instructions.
+
+Alternatively, you may email bug reports to mercury-bugs at csse.unimelb.edu.au.
+If you are reporting more than one bug, please use separate emails for each
+bug.  (If it's something that only shows up in multi-module programs, send
+a shar archive or uuencoded tar archive including your source files.)
+
+Please include the following information in your bug report:
+
+  * the version of Mercury;
+  * the system type;
+  * a complete source file that demonstrates the problem;
+  * the command line flags with which the Mercury compiler was invoked;
+  * the name and version of the C compiler that you are using;
+
+For bugs that involve the Erlang or Java backends, include the name and version
+of the Erlang or Java implementation that you are using.
+
+Please try to ensure that bug report contains all the information that we need to
+be able to reproduce the problem.  Make sure that all bug reports are fully
+self-contained.
+
+The bug tracking system contains a current list of known outstanding bugs.
+Some other problems related to using Mercury specific operating systems are
+described in the README.* files.

+See also the LIMITATIONS file.

--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------