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

[Ian MacLarty]

On Tue, May 25, 2010 at 2:39 PM, Julien Fischer
<juliensf at csse.unimelb.edu.au> wrote:
>
> 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.)
> +

It might be worth mentioning that the mercury-bugs list gets a lot of
spam, so it's possible that reports sent to that list may be
overlooked and that the preferred way to report bugs is via mantis.

> +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

...Mercury *on* specific...

Looks fine otherwise.

Ian.

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------