View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
162 [mercury] Bug minor always 2010-09-09 22:47 2022-10-11 16:43
Reporter: pbone Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: No compiler error for a mode involving an instantation state that doesn't match the argument type.
Description: In the following code I expect to receive a compiler error telling me that the instantiation state that I'm trying to use is incorrect for the type that I'm using.

If the body of the predicate is more detailed and for example uses the empty list for the head variable then the compiler complains that the empty list doesn't match the instantiation state for the some_type type.

This is reproducible on taura (Linux x86-64, Mercury version rotd-2010-08-22, gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1 with default compilation options (asm_fast.gc)
Tags:
Steps To Reproduce:
Additional Information: :- module inst_state.

:- interface.

:- import_module list.

:- type some_type
    ---> f1
    ; f2.

:- inst some_types_inst
    ---> f1.

    % Note that I forget to wrap the inst in a list(I) inst so that it matches
    % the type.
    %
:- pred some_pred(list(some_type)::out(some_types_inst)) is erroneous.

:- implementation.

:- import_module require.

some_pred(_) :-
    error("unimplemented").
Attached Files:
 
Notes
(0001205)
juliensf   
2022-10-11 16:43   
If you declare what type the inst is for you will now get such an error:

    :- inst some_types_inst for some_type/0
          ---> f1.

(Since declaring the types for insts will eventually become the default, I don't think we need to do
anything here.)




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
151 [mercury] Bug trivial always 2010-05-30 16:25 2022-10-11 16:35
Reporter: pbone Platform:  
Assigned To: juliensf OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Incorrect documentation for string.unsafe_set_char
Description: James Cussens found that the documentation for this standard library predicate and function doesn't match the implementation. The documentation says that it is a constant time operation but it involves a strcpy.

The unsafe part of the name says that there is no bounds check and that a strlen call isn't performed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
Notes
(0000265)
juliensf   
2010-05-30 16:28   
The documentation refers to the commented out mode of unsafe_set_char, which
is constant time. The problem is that the mode that is enabled isn't.
(0001204)
juliensf   
2022-10-11 16:35   
This was fixed in commit f71b5f20.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
564 [mercury] Bug minor always 2022-09-08 14:27 2022-09-08 15:35
Reporter: wangp Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: unnecessary use_module in .opt files
Description: I was trying to figure out why a seemingly small change to one module causes a project-wide recompilation when developing with intermodule module optimisation enabled.


For the attached test case, mmc --make-opt-int fib.m produces:

:- module fib.
:- use_module builtin.
:- use_module int.
:- use_module io.
:- use_module map.
:- use_module private_builtin.

:- func fib.fib(int) = int.
:- mode fib((builtin.in)) = (builtin.out) is det.

:- pragma inline(func((fib.checked_fib)/1)).
fib.checked_fib(V_3) = V_4 :-
    ( if
      V_5 = 40 : int,
      int.(V_3 >= V_5)
    then
      V_4 = -1 : int
    else
      V_4 = fib.fib(V_3)
    ).

I don't see the need for:

:- use_module io.
:- use_module map.

The io module is only used by a predicate not exported or opt-exported from fib.m.
The map module is not used at all.

Not sure about private_builtin either.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: fib.m (551 bytes) 2022-09-08 14:27
https://bugs.mercurylang.org/file_download.php?file_id=323&type=bug
 
Notes
(0001203)
zs   
2022-09-08 15:35   
Unfortunately, this is not so much a bug, as an as-yet-unimplemented feature,
because at the moment, we just generate a use_module declaration for
*every* module imported by the module whose .opt file we are creating,
*regardless* of whether it is needed or not. See the XXXs in intermod.m
starting at line 1386.

I think the reason for this non-attempt was that originally, .trans_opt
files used to be written out piecemeal; each analysis pass, after it was run,
appended its results to that file. This made it complicated to find out
up front which modules would be needed, and writing out the use_modules
at the end could have screwed up the then-rigid ordering requirements
of the make_hlds pass. Such considerations would have affected .opt files
as well, because .opt files are also written out in two pieces by two
separate algorithms, as explained by the comment starting on line 58.
However, the above is speculation, since I am not intermod.m's original
author.

As for why builtin and private_builtin are in the .opt file:
they are *always* implicitly imported and used respectively in every module,
whether needed or not, and intermod.m blindly copies them to the .opt file.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
562 [mercury] Bug minor always 2022-08-03 10:37 2022-08-18 20:01
Reporter: wangp Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: performance regression since rotd-2022-05-01
Description: The attached module compiles much slower than it used to.

I have bisected the regression to commit 911bc5ea0c6565b9ae48132b153182627b3ddbea "Convert more modules to use var_tables". The slow down occurs during the Fully expanding equivalence types step.


% time ~/local/stow/mercury-srcdist-rotd-2022-04-29/bin/mmc -C parse_tables.m
0.63s user 0.03s system 99% cpu 0.662 total

% time ~/local/stow/mercury-srcdist-rotd-2022-05-01/bin/mmc -C parse_tables.m
7.51s user 0.03s system 99% cpu 7.553 total
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: parse_tables.m (246,635 bytes) 2022-08-03 10:37
https://bugs.mercurylang.org/file_download.php?file_id=321&type=bug
 
Notes
(0001202)
zs   
2022-08-18 20:01   
Fix committed 2022 aug 18.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
559 [mercury] Bug minor always 2022-05-03 16:12 2022-08-03 19:41
Reporter: juliensf Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Stack overflow in hlc.gc Mercury 22.01.1 compiler on Windows
Description: The attached module is derived from a stress test for the Zinc compiler. Compiling this with a Mercury 22.0.1 compiler built in the hlc.gc results in a stack overflow on Windows when reading the module. (The significance of Window is that the stack size is very small, even though IIRC we bump it up a bit.)
(This is not a new problem, Mercury 20.01 also has the same problem.)
Tags:
Steps To Reproduce:
    $ mmc -C zm_hug_flat_case.m
Additional Information:
Attached Files: zm_huge_flat_case.m.gz (96,956 bytes) 2022-05-03 16:12
https://bugs.mercurylang.org/file_download.php?file_id=319&type=bug
 
Notes
(0001194)
zs   
2022-05-03 18:06   
I believe I have diagnosed the problem, though I cannot confirm it,
since I am not set up to program on Windows.

Compiling zm_huge_flat_case.m with a debug grade compiler under mdb,
the command "min_depth 10000" shows very deep mutual recursion in
parse_goal.m between parse_goal, parse_non_call_goal, and parse_goal_semicolon.
Basically, you need three stack frames for each disjunct in that big
disjunction, and the different determinisms (parse_non_call_goal is semidet,
the others are det) prevent both the MLDS and the LLDS code generator
from being able to do tail recursion.

I have an idea for a solution and will try it out tomorrow, but it may
add some overhead. Once I have an implementation ready, I will need you
to run some benchmarks to see whether it adds any overhead for run-of-the-mill,
non-extreme Mercury code, and if so, whether that overhead is significant.
(0001201)
zs   
2022-08-03 19:41   
Last part of the fix committed 2022 may 7.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
563 [mercury] Bug crash always 2022-08-03 13:04 2022-08-03 15:53
Reporter: wangp Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: type constructor for equivalence type not found
Description: The compiler throws an exception when compiling the attached test case in hlc (and probably other MLDS grades).

quirks.m defines an equivalence type in the implementation which uses a type constructor that it imports:
    :- import_module set.
    :- type quirks == set(string).

But when generating code for a module that imports quirks.m, that type constructor is not found.

% mmake GRADE=hlc.gc getprop.depend
% mmake GRADE=hlc.gc getprop.c
% cat getprop.err
Uncaught Mercury exception:
Software Error: map.lookup: key not found
        Key Type: string
        Key Value: "set"
        Value Type: tree234.tree234(parse_tree.prog_data.type_ctor, hlds.hlds_data.hlds_type_defn)
Stack dump follows:
   0 pred exception.throw/1-0 (erroneous) (exception.m:313)
   1 pred require.error/1-0 (erroneous) (require.m:172)
   2 pred require.report_lookup_error/3-0 (erroneous) (require.m:276)
   3 pred map.lookup/3-0 (det) (map.m:1272)
   4 pred hlds.hlds_data.lookup_type_ctor_defn/3-0 (det) (hlds_data.m:598)
   5 func check_hlds.type_util.classify_type_ctor/2-0 (det) (type_util.m:1038)
   6 func ml_backend.mlds.mercury_type_to_mlds_type/2-0 (det) (mlds.m:2661)
   7 pred ml_backend.ml_code_util.ml_gen_local_var_decl/6-0 (det) (ml_code_util.m:998)
   8 pred ml_backend.ml_code_gen.ml_gen_local_var_decls/6-0 (det) (ml_code_gen.m:1392)
   9 pred ml_backend.ml_code_gen.ml_gen_goal/7-0 (det) (ml_code_gen.m:611)
  10 pred ml_backend.ml_proc_gen.ml_gen_proc_body/10-0 (det) (ml_proc_gen.m:1688)
  11 pred ml_backend.ml_proc_gen.ml_gen_proc/11-0 (det) (ml_proc_gen.m:620)
  12 pred list.foldl3/8-0 (det) (list.m:3556)
  13 pred ml_backend.ml_proc_gen.ml_gen_scc_code/10-0 (det) (ml_proc_gen.m:322)
  14 pred ml_backend.ml_proc_gen.ml_gen_scc/12-0 (det) (ml_proc_gen.m:227)
  15 pred ml_backend.ml_proc_gen.ml_gen_sccs/12-0 (det) (ml_proc_gen.m:211)
  16 pred ml_backend.ml_proc_gen.ml_gen_preds/9-0 (det) (ml_proc_gen.m:121)
  17 pred ml_backend.ml_top_gen.ml_code_gen/6-0 (det) (ml_top_gen.m:84)
  18 pred top_level.mercury_compile_mlds_back_end.mlds_backend/8-0 (det) (mercury_compile_mlds_back_end.m:128)
  19 pred top_level.mercury_compile_main.after_front_end_passes/13-0 (det) (mercury_compile_main.m:1930)
  20 pred top_level.mercury_compile_main.process_augmented_module/14-0 (det) (mercury_compile_main.m:1756)
  21 pred top_level.mercury_compile_main.augment_and_process_module/15-0 (det) (mercury_compile_main.m:1646)
  22 pred list.map_foldl3/9-0 (det) (list.m:3892)
  23 pred top_level.mercury_compile_main.augment_and_process_all_submodules/15-0 (det) (mercury_compile_main.m:1588)
  24 pred top_level.mercury_compile_main.read_augment_and_process_module_ok/13-0 (det) (mercury_compile_main.m:1420)
  25 pred top_level.mercury_compile_main.read_augment_and_process_module/11-0 (det) (mercury_compile_main.m:1362)
  26 pred top_level.mercury_compile_main.do_process_compiler_arg/10-0 (det) (mercury_compile_main.m:1138)
  27 pred top_level.mercury_compile_main.setup_and_process_compiler_arg/14-0 (det) (mercury_compile_main.m:1010)
  28 pred top_level.mercury_compile_main.setup_and_process_compiler_cmd_line_args/16-0 (det) (mercury_compile_main.m:929)
  29 pred top_level.mercury_compile_main.do_op_mode_args/13-0 (det) (mercury_compile_main.m:742)
  30 pred top_level.mercury_compile_main.do_op_mode/12-0 (det) (mercury_compile_main.m:577)
  31 pred top_level.mercury_compile_main.main_after_setup/7-0 (det) (mercury_compile_main.m:532)
  32 pred top_level.mercury_compile_main.real_main_after_expansion/3-0 (det) (mercury_compile_main.m:276)
  33 pred top_level.mercury_compile_main.real_main/2-0 (det) (mercury_compile_main.m:138)
  34 pred mercury_compile.main/2-0 (det) (mercury_compile.m:32)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: eqv-type-module-import-bug.tar.gz (10,240 bytes) 2022-08-03 13:04
https://bugs.mercurylang.org/file_download.php?file_id=322&type=bug
 
Notes
(0001200)
wangp   
2022-08-03 15:47   
The regression was introduced in commit 45d6c5bde3d6df2cba786a2ab821b1ce3ebb86ff "The first step in reducing .int2 files to essentials.", which made this change to the .int2 file:

diff --git a/Mercury.good/int2s/quirks.int2 b/Mercury.bad/int2s/quirks.int2
index af739867c..2c5455d64 100644
--- a/Mercury.good/int2s/quirks.int2
+++ b/Mercury.bad/int2s/quirks.int2
@@ -2,5 +2,4 @@
 :- interface.
 :- type quirks.
 :- implementation.
-:- use_module set.
 :- type quirks == set.set(string).




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
561 [mercury] Bug minor have not tried 2022-06-22 23:46 2022-06-22 23:46
Reporter: juliensf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Segmentation fault with GCC 12 (Github issue 0000103)
Description: The attached test case is for Github issue 0000103. It causes a segmentation fault when compiled in asm_fast.gc with GCC 12.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: gh_103.m (984 bytes) 2022-06-22 23:46
https://bugs.mercurylang.org/file_download.php?file_id=320&type=bug
 
There are no notes attached to this issue.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
560 [mercury] Bug crash always 2022-05-27 17:37 2022-05-31 16:24
Reporter: wangp Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: asm_fast.gc crashes on aarch64 with gcc 10.2
Description: Configure enables asm_fast.gc by default on aarch64 but it doesn't work with newer versions of gcc:

gcc 10.2, Debian 11 - crash
gcc 8.3.0, Debian 10 - ok
gcc 6.3.0, Debian 9 - ok

reg.gc works so far on a few small programs. I have not tried a bootcheck yet (emulation is slow).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
Notes
(0001195)
juliensf   
2022-05-27 17:50   
Does the crash with the sample programs occur with GCC 10.2 occur with:

    a. --mercury-linkage shared
    b. --mercury-linkage static
    c. both

Have you tried compiling with gcc -O0?
(0001196)
wangp   
2022-05-30 12:10   
It crashes in all three cases (--mercury-linkage shared, --mercury-linkage static, compiling the standard library and hello.m with gcc -O0).
(0001197)
wangp   
2022-05-31 12:37   
Debian 11 also has a package for gcc version 9.3.0.

The sample programs also crash in asm_fast.gc using gcc 9.3.0 in all three cases (--mercury-linkage shared, --mercury-linkage static, compiling the standard library and hello.m with gcc -O0).
(0001198)
juliensf   
2022-05-31 14:18   
In the absence of an immediate fix, I suggest we disable the use of asm_fast as the LLDS base grade on aarch64 for GCC >= 9 on both the master and release branches (assuming reg.gc is ok.)
(0001199)
wangp   
2022-05-31 16:24   
It has something to do with PIC. Adding this to Mmake.params and compiling the sample programs without PIC makes them not crash:

EXTRA_CFLAGS = -fno-pic -fno-PIC -static
EXTRA_MLFLAGS = -static

(That makes me a bit suspicious that it is something similar to the PIC register issue on x86, but it might be completely unrelated.)

For now I agree we should disable asm_fast on aarch64 with GCC >= 9. I'm doing a partial bootcheck on reg.gc to make sure that works ok.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
558 [mercury] Bug major always 2022-04-21 17:42 2022-04-22 00:36
Reporter: pbone Platform: amd64  
Assigned To: juliensf OS: Linux  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: The mprof.1 manpage is currupt
Description: The mprof.1 manpage contains:

.TH 1 "2022-04-21" "Mercury Programmer's Manual"
\&../scripts/mprof: 24: exec: ../profiler/mercury_profile: not found
.SH AUTHORS
The Mercury team.
.SH COPYRIGHT
This program and its documentation are copyright by
the University of Melbourne and the Mercury team.
They may be copied only under the terms of the
GNU General Public License \-
see the file COPYING in the Mercury distribution.
.SH SEE ALSO
The Mercury User's Guide.
.PP
<http://www.mercurylang.org/information/documentation.html>
Tags:
Steps To Reproduce: Build the source distribution, don't need to install, look in doc/mprof.1
Additional Information: The script/mprof script fails to execute ../profiler/mercury_profile, it's unclear why, that executable exists.

A second problem is that the mprof script lacks the -e flag causing the error to be ignored.
Attached Files:
 
Notes
(0001191)
juliensf   
2022-04-21 18:37   
The compiler and profiler directories are missing as dependencies from the doc target in the top-level Mmakefile. (As well as any other directories containing executables that we generated manual pages for.)
(0001192)
juliensf   
2022-04-22 00:25   
Fix in commit 336215914.
(The fix is available in rotd-2022-04-21 and 22.01.2-beta-2022-04-21.)
(0001193)
pbone   
2022-04-22 00:36   
Thanks, I backported your patch for the debian package.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
557 [mercury] Bug minor always 2022-04-11 01:08 2022-04-11 13:42
Reporter: dirkz Platform: Mac  
Assigned To: zs OS: MacOS  
Priority: normal OS Version: Catalina  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ambiguous type causes compiler error without giving a useful error message for debugging
Description: Mercury-Versions: 22.01 and rotd-2022-04-07

Two discriminated union types are defined in separate modules foo.m and bar.m and share the same name `ambiguous_type`. The module foo.m defines a record type of which one field has type `ambiguous_type`. A module qualification for the type of this record field is missing.

Actual result:
The compiler aborts with error and without giving a useful error message for debugging.

Expected result:
The compiler aborts with error, complaining about the missing module qualification for the ambiguous type.
Tags:
Steps To Reproduce: Run the attached test case (foo.m and bar.m)

mmc --make foo
Additional Information:
Attached Files: test-case.tar.xz (3,584 bytes) 2022-04-11 01:08
https://bugs.mercurylang.org/file_download.php?file_id=318&type=bug
 
Notes
(0001190)
zs   
2022-04-11 13:42   
Fix committed 2022 apr 11.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
556 [mercury] Bug minor have not tried 2022-04-06 12:10 2022-04-07 12:56
Reporter: juliensf Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Stage 2 compiler does not build with --intermod-opt -O5 and rotd-2022-04-04
Description: From testing.mercurylang.org

fact_table.m:2543: error: the user defined inst
fact_table.m:2553: error: the user defined inst
fact_table.m:3400: error: the user defined inst
building of stage 2 compiler not successful

In non-truncated form it is:

fact_table.m:2543: In the second argument of predicate `get_hash_table_type'/2:
fact_table.m:2543: error: the user defined inst
fact_table.m:2543: `ll_backend.fact_table.key_char'/0
fact_table.m:2543: is declared to be applicable only to values of type
fact_table.m:2543: `char.char'/0,
fact_table.m:2543: but here it is applied to values of type
fact_table.m:2543: `character'/0.
fact_table.m:2553: In the third argument of predicate
fact_table.m:2553: `get_hash_table_type_loop'/3:
fact_table.m:2553: error: the user defined inst
fact_table.m:2553: `ll_backend.fact_table.key_char'/0
fact_table.m:2553: is declared to be applicable only to values of type
fact_table.m:2553: `char.char'/0,
fact_table.m:2553: but here it is applied to values of type
fact_table.m:2553: `character'/0.
fact_table.m:3400: In the fifth argument of predicate
fact_table.m:3400: `generate_hash_lookup_code'/7:
fact_table.m:3400: error: the user defined inst
fact_table.m:3400: `ll_backend.fact_table.key_char'/0
fact_table.m:3400: is declared to be applicable only to values of type
fact_table.m:3400: `char.char'/0,
fact_table.m:3400: but here it is applied to values of type
fact_table.m:3400: `character'/0.

It looks like equivalence types are not being expanded in insts correctly.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
Notes
(0001187)
zs   
2022-04-06 15:18   
I started fixing this by expanding type_ctors in inst definitions,
but realised that this is wrong approach. The reason is that the inst
will (in virtually all cases) contain function symbols of the named type,
and thus makes sense only if the user who wrote the inst knows the
ultimate expansion of the "for typector". If they know it, why not write it?

Therefore I propose to fix this bug in two ways.

- Replace char with character in the inst definition in fact_table.m.

- Add code that detects when the "for type_ctor" part of an inst defn
  is an equivalence type, and generates a version of the error messag
  above that mentions this fact.
  
Any objections?
(0001188)
juliensf   
2022-04-06 15:37   
I don't have any particularly strong objections. Your proposed fix does introduce a certain lack
of uniformity with respect to how equivalence types are treated by different parts of the language.
(It's probably not too bad in presence of an error message describing what is wrong.)

As to "if they know, why not write it?", I think this bug answers that question. It wasn't written because the equivalence type is the preferred name for the type in question. When deprecating a type name we quite often start by introducing an equivalence that defines the new name and then swapping them around later, before finally (after a respectable interval) deleting the original name. (That isn't quite the story with character / char, but it's close.)

Another reason a user may have used char instead of character here, is that they may have read the library documentation. It is fairly emphatic on the point:

    Originally we used `character' rather than `char' for the type name
    because `char' was used by NU-Prolog to mean something different.
    But now we use `char' and the use of `character' is discouraged.
(0001189)
zs   
2022-04-07 12:56   
Fix committed 2022 apr 7.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
555 [mercury] Feature Request minor N/A 2022-04-05 12:12 2022-04-05 12:12
Reporter: wangp Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: do not implicitly import modules imported by ancestor modules
Description: We may want to change the submodule visibility rule so that declarations from modules imported by ancestor modules are NOT automatically visible to a submodule.

E.g.
Module a declares foo, and happens to import io.
Module a.b can see foo, but it must import io itself if it wants to use io.

This change would reduce unwanted coupling between the parent module and submodule (as described in commit 92438b2ec). It would also allow the compiler to warn about unnecessary imports that currently *might* be required by a submodule.

An argument against this change is that since nested submodules are written in the same source file as the parent module, it does seem somewhat natural (in a "block scoping" way) for imports in the parent module to also affect a nested submodule. We would not want to have different visibility rules for nested or separate submodules.

May be related to Mantis bug 0000505
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
There are no notes attached to this issue.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
554 [mercury] Bug minor have not tried 2022-03-29 01:17 2022-03-29 13:55
Reporter: juliensf Platform:  
Assigned To: juliensf OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: mmake realclean does not remove .dep_err files
Description: mmake realclean deletes any .err files, but does not delete .dep_err files.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
Notes
(0001186)
juliensf   
2022-03-29 13:55   
Fixed in commit 0cbe2c6.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
553 [mercury] Feature Request minor have not tried 2022-03-23 20:07 2022-03-23 20:07
Reporter: juliensf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: mmc --make and GNU make jobserver integration
Description: It would be useful for mmc --make to be able to (optionally) use GNU make's jobserver protocol, so that the number of parallel jobs inside the Mercury compiler can be limited by the number of jobs a top-level make is invoked with.

Reference: <https://www.gnu.org/software/make/manual/html_node/Job-Slots.html#Job-Slots>
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
There are no notes attached to this issue.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
552 [mercury] Bug minor have not tried 2022-03-16 21:31 2022-03-17 15:00
Reporter: juliensf Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Compiler aborts in deep_profiler directory in Java grade with --intermod-opt
Description: Building the Mercury system with

    MCFLAGS = --intermod-opt -O0

in the Java grade causes the following abort in the deep_profiler directory

Making Mercury/javas/jmercury/dense_bitset.java
Making Mercury/javas/jmercury/display.java
Making Mercury/javas/jmercury/display_report.java
Uncaught Mercury exception:
Software Error: map.lookup: key not found
        Key Type: term.var(parse_tree.prog_data.prog_var_type)
        Key Value: var(287)
        Value Type: ml_backend.ml_gen_info.ml_ground_terma
Tags:
Steps To Reproduce:
Additional Information: Mercury: 22.01-beta-2022-03-16, rotd-2022-03-16
GCC: 4.8.5
OS: CentOS 7
Attached Files:
 
Notes
(0001182)
zs   
2022-03-16 21:42   
That is a strange pair of build flags. Do not optimize anything,
but do so across module boundaries? :-)
(0001183)
juliensf   
2022-03-16 22:00   
Yes and no. It's not something I would do by choice. The script I am using to test the release steps through all combinations of -O0 -> -O6 with and without --intermod-opt; the problem arose there. I suspect the issue may arise at other optimisation levels as well.
(0001184)
zs   
2022-03-17 09:09   
I know the cause of the problem. I am testing a fix.
(0001185)
zs   
2022-03-17 15:00   
Fix committed 2022 mar 17.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
549 [mercury] Bug minor have not tried 2022-02-18 22:50 2022-03-01 13:57
Reporter: juliensf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Segmentation fault building stage 3 dependencies with GCC 9, -O6 and debug grades
Description: Build staging 3 source file mappings or dependencies causes a segmentation fault when bootchecking
in either of the grades asm_fast.gc.debug.stseg or asm_fast.gc.decldebug.stseg. This occurs (only) when
compiling with -O6 (with and without --intermod-opt).

Mercury: 22.01-beta-2022-02-16
C compiler: GCC 9.3.1
OS: CentOS 7

The issue did not occur with same optimisation settings and GCC 4.8.5 on the same machine.
(I have GCC versions 10 and 11 installed on the same machine and will try them as well.)
Tags:
Steps To Reproduce:
Additional Information: make: Target 'dep_library' not remade because of errors.
cd mdbcomp && PATH=../scripts:../util:../mfilterjavac:../../mfilterjavac:$PATH MMAKE_VPATH=. MMAKE_DIR=../scripts DESTDIR= ../scripts/mmake mer_mdbcomp.depend
gmake[1]: Entering directory '/home/jfischer/release/mercury.git/stage3/mdbcomp'
config.status: creating MDBCOMP_FLAGS
/home/jfischer/release/betas/22.01-beta-2022-02-12/bin//mmc --grade asm_fast.gc.debug.stseg -O6 --intermod-opt --flags MDBCOMP_FLAGS -f *.m

*** Mercury runtime: caught strange segmentation violation ***
PC at signal: 28623904 (1b4c420)

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

home/jfischer/release/betas/22.01-beta-2022-02-12/bin//mmc --grade asm_fast.gc.decldebug.stseg -O6 --intermod-opt --flags GRADE_LIB_FLAGS -f *.m
Uncaught Mercury exception:
Software Error: predicate `io.record_env_var_equal_value'/3: Unexpected: No = in environment entry
Stack dump follows:
   0 pred exception.throw_impl/1-0 (erroneous) (exception.m:695)
   1 pred exception.throw/1-0 (erroneous) (exception.m:313)
   2 pred require.error/1-0 (erroneous) (require.m:172)
   3 pred require.unexpected/2-0 (erroneous) (require.m:203)
   4 pred io.record_env_var_equal_value/3-0 (det) (io.m:11818)
reached unknown label
Attached Files:
 
Notes
(0001180)
juliensf   
2022-02-27 02:19   
The issue does not occur with GCC 10.
(0001181)
juliensf   
2022-03-01 13:57   
The issue also does not occur with GCC 11.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
547 [mercury] Bug minor random 2022-02-09 12:32 2022-02-26 07:20
Reporter: juliensf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Test failure: intermittent failure of valid/foreign_import_module
Description: The test case valid/foreign_import_module intermittently fails like in the output below. This appears to be a timing related issue (a missing dependency perhaps?) as there doesn't appear to be much of pattern in the failures.


home/jfischer/release/trunk-test/mercury.git-2/stage2/scripts/mmc --make-interface --grade hlc.gc.prof -O5 --intermod-opt --flags ../TESTS_FLAGS --flags ../WS_FLAGS foreign_import_module
/home/jfischer/release/trunk-test/mercury.git-2/stage2/scripts/mmc --make-interface --grade hlc.gc.prof -O5 --intermod-opt --flags ../TESTS_FLAGS --flags ../WS_FLAGS foreign_import_module_2
/home/jfischer/release/trunk-test/mercury.git-2/stage2/scripts/mmc --make-optimization-interface --grade hlc.gc.prof -O5 --intermod-opt --flags ../TESTS_FLAGS --flags ../WS_FLAGS foreign_import_module
/home/jfischer/release/trunk-test/mercury.git-2/stage2/scripts/mmc --make-optimization-interface --grade hlc.gc.prof -O5 --intermod-opt --flags ../TESTS_FLAGS --flags ../WS_FLAGS foreign_import_module_2
/home/jfischer/release/trunk-test/mercury.git-2/stage2/scripts/mmc --compile-to-c --grade hlc.gc.prof -O5 --intermod-opt --flags ../TESTS_FLAGS --flags ../WS_FLAGS foreign_import_module > foreign_import_module.err 2>&1
/home/jfischer/release/trunk-test/mercury.git-2/stage2/scripts/mmc --compile-to-c --grade hlc.gc.prof -O5 --intermod-opt --flags ../TESTS_FLAGS --flags ../WS_FLAGS foreign_import_module_2 > foreign_import_module_2.err 2>&1
/home/jfischer/release/trunk-test/mercury.git-2/stage2/scripts/mgnuc --grade hlc.gc.prof -- -c foreign_import_module.c -o foreign_import_module.o
foreign_import_module.c:166:38: fatal error: foreign_import_module_2.mh: No such file or directory
 #include "foreign_import_module_2.mh"
                                      ^
compilation terminated.
gmake[3]: *** [foreign_import_module.o] Error 1
/home/jfischer/release/trunk-test/mercury.git-2/stage2/scripts/mgnuc --grade hlc.gc.prof -- -c foreign_import_module_2.c -o foreign_import_module_2.o
/home/jfischer/release/trunk-test/mercury.git-2/stage2/scripts/mgnuc --grade hlc.gc.prof -- -c foreign_import_module_init.c -o foreign_import_module_init.o
gmake[3]: Target `foreign_import_module.runtest' not remade because of errors.
gmake[3]: Leaving directory `/home/jfischer/release/trunk-test/mercury.git-2/tests/hard_coded'
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: DIFF.fim.d (3,540 bytes) 2022-02-26 07:20
https://bugs.mercurylang.org/file_download.php?file_id=317&type=bug
 
Notes
(0001173)
zs   
2022-02-09 20:35   
The bug description says valid/foreign_import_module, but
the test cases is in tests/hard_coded.

This test has been intermittently failing as long as I remember.
(0001179)
zs   
2022-02-26 07:20   
The attached diff shows the difference between

- the contents of the main module's .d file immediately after
  generating dependencies, and
- its contents after trying to (and failing) to build the executable.

Like Julien, I believe the issue is a missing dependency. Specifically,
I think it is the fact that the dependency of the main module's .o file
on the submodule's .mh file (foreign_import_module_2.mh) is missing
from the *initial contents of the .d file. It is there after the failed
attempt to build the executable, but by then, the test has failed.

As the comment in do_process_compiler_arg in mercury_compile_main.m says,
the root cause of the problem is that --generate-dependencies uses its
own algorithm for computing what goes into .d files, an algorithm that is
completely separate from that used to update the .d file's contents
on every subsequent compiler invocation. The algorith used by --generate
-dependencies shouldn't be fixed; it should be replaced, using the
algorithm used by all other compiler invocations as the basis.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
545 [mercury] Bug minor have not tried 2022-02-06 15:22 2022-02-22 02:50
Reporter: juliensf Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Data constructor named "event" results in invalid optimisation interface
Description: The attached program has been extracted from <https://github.com/dzyr/mercury-xml>.
It illustrates a problem where a type has a data constructor named event, which becomes
the subject of a direct_arg clause in the optimisation interface. This causes a syntax error
when reading in xml_read.opt because event is not escaped using parentheses.
Tags:
Steps To Reproduce: mmc --intermod-opt --make use_xml_read
Additional Information:
Attached Files: event_bug.tar.gz (732 bytes) 2022-02-06 15:22
https://bugs.mercurylang.org/file_download.php?file_id=316&type=bug
 
Notes
(0001178)
zs   
2022-02-22 02:50   
Fix committed 2022 feb 9.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
551 [mercury] Bug minor have not tried 2022-02-21 17:11 2022-02-21 21:03
Reporter: juliensf Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Information messages refer to non-existent pragma
Description: The compiler is emitting information messages like the following for the tests in tests/debugger when bootchecking in grade asm_fast.par.gc:

gmake[3]: Leaving directory `/home/jfischer/release/mercury.git/tests/debugger'
ERROR OUTPUT
io_tab_goto.m:029: Ignoring the
io_tab_goto.m:029: `:- pragma table_io(entry_stores_procid_inputs_outputs, alone)'
io_tab_goto.m:029: declaration for predicate `io_tab_goto.goto'/2 mode 0,
io_tab_goto.m:029: because tabling is not compatible with parallel execution.

At the source code level, there is AFAIK no such thing as a table_io pragma.

Mercury: 22.01-beta-2022-02-16
C compiler: GCC 4.8.5
OS: CentOS 7
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
Notes
(0001177)
zs   
2022-02-21 21:03   
Fix for the misleading error message committed 2022 feb 21.

(The test case may still fail due to mismatch with the expected output,
but that is a separate issue.)




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
548 [mercury] Bug minor have not tried 2022-02-09 18:21 2022-02-12 10:57
Reporter: juliensf Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Stage 2 compiler fails in hlc.gc.pregen -O4 bootcheck
Description: Bookchecking in the grade hlc.gc.pregen with -O4 fails due to an errors in the generated C code like:

transform_hlds.loop_inv.c:373:11: error: duplicate member ‘transform_hlds__loop_inv__gen_aux_proc_goal_3_p_0_env_0__Var_87’
   MR_Word transform_hlds__loop_inv__gen_aux_proc_goal_3_p_0_env_0__Var_87;
  
This occurs both with both --intermod-opt and --no-intermod-opt.
The problem does not occur with other optimisation levels.
Tags:
Steps To Reproduce:
Additional Information: Mercury: 22.01-beta-2022-02-08
GCC: 4.8.5
OS: CentOS 7
Attached Files:
 
Notes
(0001174)
zs   
2022-02-09 20:47   
The error occurs in the code generated for the gen_aux_proc_goal
predicate, and the repeated variables are part of the implementation
of the invariant_goal predicate, which is inlined into the switch arm
for generic_calls, unifies and foreign_procs indirectly through
gen_aux_proc_handle_nonrecursive_call. Some implementation methods
for switches that ml_switch_gen.m can choose from can duplicate
the code we generate for an arm, and that is what seems to have
happened here. I don't yet know why.
(0001175)
zs   
2022-02-10 00:27   
Actually, there are two separate bugs involved here.
One results in the duplication of auxiliary functions,
and one results in the duplication of fields in environment
structures.

I have a simple fix for the first problem, which I will document
and post tomorrow. The second problem is harder.
(0001176)
zs   
2022-02-12 10:57   
Fixes have been committed for both problems.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8 [mercury] Bug minor always 2007-09-27 23:55 2022-02-09 12:38
Reporter: anonymous Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: code hanging in asm_fast.gc.prof
Description: From bojar@csse.unimelb.edu.au Tue Sep 4 12:07:44 2007
Date: Tue, 04 Sep 2007 12:07:43 +1000
From: Ondrej Bojar <bojar@csse.unimelb.edu.au>
To: mercury-bugs@csse.unimelb.edu.au
Subject: [Fwd: "hang-up in C-code in asm_fast.gc.prof" - possible solution]

Hi, all.

I've received this suggestion from Krzysztof Foltman some while ago and now I
tested it. Indeed, if I use sigprocmask to block SIGPROF just before
io.call_system_return_signal and unblock it afterwards, my program does not hang
up in asm_fast.gc.prof as it would without any treatment.

I'm using rotd-2007-08-13, so I assume this issue was not fixed yet.

Could you please add the temporary blocking of SIGPROF around every system() or
fork() calls in the standard library, if compiled in profiling grade?

Thanks, Ondrej.

-------- Original Message --------
Subject: "hang-up in C-code in asm_fast.gc.prof" - possible solution
Date: Wed, 15 Aug 2007 16:36:58 +0100
From: Krzysztof Foltman <krzysztof@foltman.com>
To: bojar@csse.unimelb.edu.au

It's probably too late for this, but I think I've found the reason your
code hangs under profiler.

You need to temporarily block the SIGPROF signal with pthread_sigmask or
sigprocmask for the time of system() or fork(), otherwise the profiler
causes those functions to hang indefinitely.

Chris

--
Ondrej Bojar (mailto:obo@cuni.cz / bojar@ufal.mff.cuni.cz)
http://www.cuni.cz/~obo
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
Notes
(0001172)
juliensf   
2022-02-09 12:38   
This appears to affect stage 2 compilers when bootchecking in .prof grades.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
544 [mercury] Bug minor have not tried 2022-02-05 17:08 2022-02-07 18:10
Reporter: juliensf Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Test failure: valid/static causes compiler abort in grade hlc.gc.tr at -O5 and above
Description: valid/static is failing with a compiler abort in the grade hlc.gc.tr at -O5 and above.

Uncaught Mercury exception:
Software Error: map.lookup: key not found
        Key Type: term.var(parse_tree.prog_data.prog_var_type)
        Key Value: var(6)
        Value Type: ml_backend.ml_gen_info.ml_ground_term

Mercury: 22.01-beta-2022-02-04
OS: CentOS 7
GCC: 4.8.5
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: bug544.m (597 bytes) 2022-02-06 12:55
https://bugs.mercurylang.org/file_download.php?file_id=315&type=bug
 
Notes
(0001165)
zs   
2022-02-06 12:55   
I have diagnosed the problem on the attached cut-down test case.

The predicate that causes the problem, s, includes a cc_nondet scope
that constructs a static term, Result. In non-trailing grades, this works
just fine.

The add_trail_ops transformation replaces that cc_nondet scope with
a disjunction, whose first disjunct is the cc_nondet scope with some
trail ops around it, and whose second disjunct does some trail ops and
then fails.

The problem comes in the fact that ml_gen_ordinary_model_det_semi_disj
generates code for each disjunct by invoking ml_gen_goal_as_branch_block
on it, and this predicate discards any updates to the const_var_map
done while processing a disjunct. So that we generate an entry for
Result in the const_var_map when we process its generator unification,
but then throw away the resulting const_var_map at the end of the branch.
When the code generator reaches the code that wants to *use* Result,
just after the scope or the disjunction it turns into, its lookup
in the const_var_map fails.

The guilty party in this case is add_trail_ops.m, because it leaves
the unification that uses Result as in input marked with construct_statically,
even though its addition of the disjunction invalidated the grounds
that justified that marker. We could fix this by having add_trails_ops
marking everything that it can construct_dynamically. The next pass is
mark_static, which could turn unifications back to construct_statically
if it is safe to do so.

Another way to fix the bug is to change ml_gen_goal_as_block, and the
predicates that call it, so that at the end of each branched control
structure we end up not with the const_var_map that we entered with
(the current situation), but with the "consensus" of the const_var_maps
at the ends of the branches, *provided* the branch end is reachable.
In this case, and in all other cases where add_trail_ops introduces
disjunctions like this, there will be one reachable branch end and
one unreachable branch end, so we will end up with the const_var_map
of the first branch.

Note that both possible fixes are too drastic to add to the release
without at least a week or two of testing.

Opinions?
(0001166)
zs   
2022-02-06 13:01   
To clarify: by "consensus", I mean the intersection
of the const_var_maps at the ends of the reachable branches,
when each map is viewed as a set of key/value pairs.
We already have similar operations on other structures
in our code generators.
(0001167)
juliensf   
2022-02-06 14:55   
Having the HLDS coming out of add_trail_op pass be inconsistent is a possible source of future bugs (in addition to causing this one), for that reason I would favour the first fix. So far as merging a fix on to the release branch is concerned, the first fix has less of an impact on everything else (i.e. the non-trailing MLDS grades).

For the release, I've set up one of Opturion's larger servers to systematically bootcheck all the usual grades using -O0 to -O6, with and without --intermod-opt. We can do the same hlc grades on the master branch once a fix is available -- and for there release branch, if/when the fix is merged onto it. [Fortunately, bootchecks are reasonably fast with -j16 ;-)]
(0001168)
zs   
2022-02-06 15:13   
With the second approach, the HLDS coming out of add_trail_ops
would still be consistent, just with respect to a changed definition
of "under what circumstances is a construct unification allowed to assume
that one of the rhs variable is constant". The updated definition would
of course have to be documented somewhere, but

- the only thing that pays attention to the construct_how annotations
is the MLDS code generator, and
- we would update that in accordance with the updated definition.

About the first approach: probably the simplest way to implement it would be
to get add_trail_ops to add a marker to the disjunctions it creates, which
the following mark_static pass would look for. If it found it, then it would
replace every construct_how annotation reachable from the end of that disjunction
on forward execution with construct_dynamically (the default), and rebuild it
from its own knowledge. That way, you would avoid having to teach add trail ops
about static terms.

BTW, I would be comfortable doing the fix using the second approach,
but not the first.
(0001169)
juliensf   
2022-02-06 15:28   
Ok, not having to teach add_trail_ops about static terms is a convincing reason for the second approach.
(0001171)
zs   
2022-02-07 18:10   
Fix committed 2022 feb 7.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
546 [mercury] Feature Request minor N/A 2022-02-07 14:34 2022-02-07 16:56
Reporter: wangp Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: make io.system_error public
Description: As discussed on mercury-users (05 Feb 2022) we should give access to the system error code from an io.error value. Something like this:

    % implementation
    :- type io.error
        ---> io_error(system_error, string).

    :- func make_io_error(system_error, string) = io.error.

    :- pred get_system_error(io.error::in, system_error::out)
        is semidet.


(Assign yourself if you want to work on it.)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
Notes
(0001170)
juliensf   
2022-02-07 16:56   
A complication here is that on Windows, there are two different sets of error codes: one for the system calls and another for the library functions that report their errors via errno. Currently we don't distinguish between the two, which means any potential user of a public system_error type won't know which is which.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
510 [mercury] Bug crash always 2020-06-19 17:33 2022-01-25 22:15
Reporter: zs Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: compiler crash due to missing type definition
Description: The valid/bug510 test case (which I added and committed just now) causes a compiler crash.
It occurs when the compiler tries to look up the definition of the sparse_bitset type,
but does not find it, due to it being hidden behind module abstraction barriers.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
Notes
(0001162)
zs   
2022-01-25 03:55   
Some change in the last 18 or so months has fixed this test case,
since it does not cause a compiler crash anymore.
(0001163)
zs   
2022-01-25 22:15   
The crash is still present in MLDS grades.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
499 [mercury] Bug minor always 2020-04-06 13:08 2022-01-25 01:51
Reporter: wangp Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: unqualified type encountered assertion
Description: The compiler crashes on the attached (erroneous) source file:

% mmc --make-interface bug
Uncaught Mercury exception:
Software Error: predicate `parse_tree.comp_unit_interface.accumulate_modules_used_by_type_ctor'/3: Unexpected: unqualified type encountered
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: bug.m (91 bytes) 2020-04-06 13:08
https://bugs.mercurylang.org/file_download.php?file_id=297&type=bug
 
Notes
(0001161)
zs   
2022-01-25 01:51   
An immediate fix was committed 2020 april 8. The underlying problem,
ignoring errors by default when making .intN files, has been sortof-solved
by making --halt-at-invalid-interface the default, with the immediate fix
from 2020 preventing a compiler crash if it is ever explicitly switched off.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
530 [mercury] Feature Request minor have not tried 2021-02-26 18:03 2022-01-25 01:41
Reporter: zs Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: diagnose inapplicable insts in mode declarations
Description: This is (or was) real code from library/hash_table.m:

:- pred update_item_in_bucket(K, V, hash_bucket(K, V), hash_bucket(K, V)).
:- mode update_item_in_bucket(in(hb_two_plus), in, in, out) is semidet
:- mode update_item_in_bucket(in, in, in, out) is semidet.

The in(hb_two_plus) was intended to be applied to the third argument,
the initial hash bucket, not to the key, whose type is unknown, and is
extremely unlikely to be a hash bucket of any size :-(

The compiler should check whether the modes of arguments in mode declarations
match the types (if any) of the corresponding arguments, and generate
error messages for any mismatches.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
Notes
(0001160)
zs   
2022-01-25 01:41   
Feature implemented on 2021 dec 30.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
521 [mercury] Bug minor always 2020-09-29 17:23 2022-01-25 01:24
Reporter: dirkz Platform: Mercury 20.06  
Assigned To: zs OS: macOS Catalina  
Priority: normal OS Version: 10.15.7  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Missing error message about an 'undefined type'; misleading error message instead
Description: The compiler should clearly complain about an 'undefined type'.

Expected error message:
thing_def.m:17 error: undefined type `list'/1.

Actual error message:
main.m:033: In clause for predicate `get_wrapped_things'/1:
main.m:033: in argument 1 of functor `list_wrapper/1':
main.m:033: type error in unification of argument
main.m:033: and constant `get_things'.
main.m:033: argument has type `list.list(thing_def.thing)',
main.m:033: constant `get_things' has type `list(thing_def.thing)'.
For more information, recompile with `-E'.
Tags:
Steps To Reproduce: mmc --make main
Additional Information: Attached example:

Module thing_def.m declares this function without importing the list module:

:- func get_things = list(thing).

Not importing the list module is the actual problem. But the compiler does not complain about the missing import. Instead it issues a misleading error message.
Attached Files: example.tgz (434 bytes) 2020-09-29 17:23
https://bugs.mercurylang.org/file_download.php?file_id=307&type=bug
 
Notes
(0001108)
zs   
2020-10-08 16:10   
I just added code to compiler to complain about the missing import. It should
be in the next ROTD. You still get the misleading error message, but you
also get a non-misleading pointer to where the error is.

The error should really be diagnosed when the compiler makes the interface file
for the module with the missing import. The compiler has had an option named
--print-errors-warnings-when-generating-interface for a while now which does
exactly that, but for now, it is not turned on by default, because it is part
of a bigger set of changes that are not complete yet. However, if you are willing to live with an experimental-for-now feature, you can enable it manually.
(0001111)
dirkz   
2020-10-12 05:15   
Thank you for fixing the error message.

I just performed a successful test with rotd-2020-10-09 on MacOS High Sierra 10.13.6.
(0001159)
zs   
2022-01-25 01:24   
The compiler has been diagnosing such errors when making interface files
for some time now.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
541 [mercury] Bug minor have not tried 2021-12-22 00:39 2022-01-25 01:21
Reporter: juliensf Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Standard lib compilation aborts in asm_fast.gc.profdeep.stseg with --intermod-opt -O5
Description: Compilation of a number of stdlib modules (bit_buffer, io, rtti_implementation, store, type_desc) fails with the following:

     Uncaught Mercury exception:
     Software Error: predicate `ll_backend.code_gen.generate_goal'/7: Unexpected: semidet model in det context
     Stack dump not available in this grade.

in grade asm_fast.gc.profdeep.stseg with --intermodule-optimization -O5.
This was with rotd-2021-12-19.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
Notes
(0001158)
zs   
2022-01-25 01:21   
Fix was committed 2022 jan 3.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
542 [mercury] Bug minor have not tried 2022-01-24 17:07 2022-01-24 22:59
Reporter: juliensf Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Test failure: hard_coded/gh72 causes compiler abort at -O5
Description: Bootchecking in asm_fast.gc with -O5 causes the compiler to abort on tests/hard_coded/gh72
with the following:

    ERROR OUTPUT
    Uncaught Mercury exception:
    Software Error: predicate `hlds.instmap.merge_instmapping_delta_vars'/9: Unexpected: error merging var 5

Mercury: 22.01-beta-2022-01-24
OS: CentOS 7
GCC: 4.8.5
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
Notes
(0001157)
zs   
2022-01-24 22:59   
Fix committed 2022 jan 24.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
543 [mercury] Bug minor have not tried 2022-01-24 17:39 2022-01-24 20:47
Reporter: juliensf Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Test failures: hard_coded/backend_external -- invalid C code at -O6
Description: hard_coded/backend_external_func in grade asm_fast.gc
hard_coded/backend_external in grade asm_fast.gc
hard_coded/backend_external_pred in grade asm_fast.gc

At -O6, the above all failing when compiling the generated C code, with errors like:

backend_external.c:133:1: error: redefinition of ‘backend_external_module’
backend_external.m:84:1: note: previous definition of ‘backend_external_module’ was here

Mercury: 22.01-beta-2022-01-24
OS: CentOS 7
GCC: 4.8.5
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
Notes
(0001156)
zs   
2022-01-24 20:47   
Fix committed 2022 jan 24.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
540 [mercury] Feature Request minor have not tried 2021-11-08 17:29 2021-11-08 17:29
Reporter: zs Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: making up for not updating insts
Description: When mode analysis processes a conjunction such as A = f(B, C), B = g(D),
it updates the insts of only the variables of the primitive operation it is
looking at at each point in time. This means that when we process B = g(D),
we update the inst of B to say that it is bound to g, but we do NOT update
the insts of the variables whose terms include B. Therefore if a later part
of that conjunction passes A to a predicate whose in an argument position
that requires the inst of the argument to be f(g(ground), ground), we get
an error, because while mode analysis knows that A's inst is f(ground, ground),
it does not know that the first ground is now known to be g(ground).

Alias tracking turned out to be a bad idea when done all the time, but we could
maybe get around this by doing it "on demand". It would apply only when
all the mode errors for a procedure have the form "var A is expected to have
inst InstSpec, but its actual inst is InstGen", where InstSpec is an
instance of InstGen that differs from it by requiring a ground inst of
a specific shape (such as "g(ground)") for some part of InstGen
that is simply "ground". In such cases, we would redo the mode analysis
after making a trial modification of the procedure body for each such error.
If these modifications fix all the errors, we keep the modified body;
otherwise, we revert to the original procedure body and report the errors.

The trial modification needs as input the identity of the variable in the error,
its required inst, and the goal path of the goal with the error. (We can keep
this info in the mode_error structure.) The modification would traverse the
procedure body while keeping a set of variable it is on the lookout for.
Initially, this set would contain only the variable in the error. When we find
either a construction or deconstruction unification with a lookout variable
on the left hand side, we would (a) record in a map the right hand corresponding
to this left hand side, and (b) we would add all the variables in the right hand
side to the lookout set. This way, we could enable the reconstruction of *all*
the constructed and/or deconstructred parts of the original variable, even when
some of those unifications don't directly reference it.

The above works in the absence of branched goals. In their presence, we would
need to (a) start processing each branch with the same initial binding map,
(b) process each branch independently, and (b) take the intersection of the
final binding maps of the branches as the final map of the branched control
structure itself. This intersection operation throws away information,
and this may prevent being able to reconstruct the binding of the original
variable at the error site.

However, if we *can* reconstruct that binding, then we can add a new goal
before the error site that rebuilds the same term as the original variable,
as e.g. A' = f(B, C), and replaces all references to A with references to A'
in all the places where that reconstruction is valid. (This means all goals
for which the value of A is supplied by the unifications that we used to
construct A'; references to A outside any of their scopes must NOT be replaced.)
Given the unification sequence B = g(D), A' = f(B, C), mode analysis *will*
record the inst of A' as f(g(ground), ground), which should fix the original
mode error. This extra unification will be deleted, long after mode analysis,
by common structure elimination.

With the right housekeeping, it should be possible to (try to) fix all mode errors
of this form in a procedure body at the same time.

Of course, this is rather a lot of machinery for a relatively rare problem.
Simply adding a verbose-only component to the original error message reminding
the programmer that manually adding this redundant unification may fix
the mode error (and why) may get most of the benefit at much lower cost.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
There are no notes attached to this issue.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
539 [mercury] Bug minor always 2021-10-11 12:56 2021-10-14 13:17
Reporter: wangp Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: placing nondummy var which has no state (LCMC)
Description: The compiler aborts during code generation in low-level C grades when LCMC is enabled. (There are other similar bug reports involving debugging or parallel conjunction which may or may not be related.)


% mmc -s asm_fast.gc --optimise-constructor-last-call -C soupy
Uncaught Mercury exception:
Software Error: predicate `ll_backend.var_locn.actually_place_var'/6: Unexpected: placing nondummy var 6 which has no state
Stack dump follows:
   0 pred exception.throw/1-0 (erroneous) (exception.m:313)
   1 pred require.error/1-0 (erroneous) (require.m:172)
   2 pred require.unexpected/2-0 (erroneous) (require.m:203)
   3 pred ll_backend.var_locn.actually_place_var/6-0 (det) (var_locn.m:1807)
   4 pred ll_backend.var_locn.var_locn_place_var/5-0 (det) (var_locn.m:1706)
   5 pred ll_backend.var_locn.actually_place_vars/4-0 (det) (var_locn.m:1730)
   6 pred ll_backend.var_locn.var_locn_place_vars/4-0 (det) (var_locn.m:1722)
   7 pred ll_backend.code_loc_dep.setup_call/7-0 (det) (code_loc_dep.m:3325)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: soupy.m (2,707 bytes) 2021-10-11 12:56
https://bugs.mercurylang.org/file_download.php?file_id=314&type=bug
 
Notes
(0001152)
zs   
2021-10-12 02:14   
I have diagnosed the source of the problem, and outlined two possible
approaches to a fix, in the version of this test case I added to
the test suite as tests/valid/bug539.m.

The bug is solely in lco.m, which sets a buried mine; the code generator,
which is where the abort occurs, merely steps on it.
(0001153)
wangp   
2021-10-12 11:46   
Thanks for looking into it.

Of the two proposed solutions, I favour the second. I don't see a reason why lco.m should be replacing the non-self-recursive call to type_check/2 with the lco-optimised version in the first place.
(0001154)
zs   
2021-10-12 18:53   
The reason why lco.m replaces the call to type_check in fun_type
is that these two predicates are mutually recursive, i.e. they are
in the same SCC. If we restricted lco.m to optimize only self-recursive
tail calls, lco couldn't generate code for mutually recursive predicates
that could handle unlimited input sizes in constant stack space.

lco.m should avoid transforming that call to type_check in fun_type
NOT because the call is not SELF-recursive, but because it is not
TAIL recursive (in the lco sense, i.e. modulo constructors).
A call that is a tail call in this sense *cannot* be followed by
consumers of the original output variable, which is the cause of the
compiler abort.
(0001155)
zs   
2021-10-14 13:17   
Fix committed 2021 oct 13.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
538 [mercury] Bug minor always 2021-09-13 00:13 2021-09-13 05:34
Reporter: dirkz Platform: mercury-srcdist-rotd-2021-09-08  
Assigned To: zs OS: macOS Catalina  
Priority: low OS Version: 10.15.7  
Status: resolved Product Version:  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Compiler does not recognise a chained subtype definition
Description: Example:
========

    % Html content categories modelled as subtypes (simplified)
    % 1. All html elements belong to the base type flow_content
    % 2. Phrasing_content is a subset of flow_content
    % 3. Nesting of a-elements (hyperlinks) is invalid. Neither direct nor
    % indirect nesting is allowed.
    %
:- type flow_content
    ---> p(list(phrasing_content))
    ; div(list(flow_content))
    ; a(list(flow_content_without_a))
    ; text(string).


:- type flow_content_without_a =< flow_content
    ---> p(list(phrasing_content_without_a))
    ; div(list(flow_content_without_a))
    ; text(string).


:- type phrasing_content =< flow_content
    ---> a(list(phrasing_content_without_a))
    ; text(string).


    % 1. Explicitly declared subtype of phrasing_content
    % 2. Implicit subtype of flow_content_without_a, because both share the
    % same base type (flow_content) and the subtype only omits constructor
    % definitions
    %
:- type phrasing_content_without_a =< phrasing_content
    ---> text(string).


Expected result:
================
The module should compile without error.


Actual result:
==============
Compiler error. Mercury does not recognise the implicit (undeclared) subtype
relationship between subtype phrasing_content_without_a and its supertype
flow_content_without_a. The subtype definition is valid, because both share
the same base type (flow_content) and phrasing_content_without_a only omits
constructor definitions of flow_content_without_a.

$ mmc --make subtype
Making Mercury/int3s/subtype.int3
Making Mercury/ints/subtype.int
Making Mercury/cs/subtype.c
subtype.m:036: Error: the first argument of `a' has a type,
subtype.m:036: `list.list(subtype.phrasing_content_without_a)', which is not
subtype.m:036: a subtype of the corresponding argument type
subtype.m:036: `list.list(subtype.flow_content_without_a)' in the supertype.
** Error making `Mercury/cs/subtype.c'.
Tags:
Steps To Reproduce: Run attached Mercury module with:
mmc --make subtype
Additional Information:
Attached Files: subtype.m (1,645 bytes) 2021-09-13 00:13
https://bugs.mercurylang.org/file_download.php?file_id=313&type=bug
 
Notes
(0001151)
zs   
2021-09-13 05:34   
As you say in the bug report, the attached code gets a compiler error because
"Mercury does not recognise [an] implicit (undeclared) subtype relationship".
This is because Mercury is not *designed* to do so. It pays attention only
to *declared* subtype relationships, and there is no such relationship between
the two types involved in the error, phrasing_content_without_a and flow_content_without_a.

Letting a type have two or more supertypes, such as letting phrasing_content_without_a have both phrasing_content and flow_content_without_a as supertypes, would not be
a bug fix. It would be a new feature, and it would have to be designed as such.
It would certainly require new language rules. At the moment, when each subtype
has exactly one supertype, every subtype-to-supertype chain ends in a unique base type.
If we allowed more than supertype, there would be many possible subtype-to-supertype
chains starting at any given subtype, and we would definitely have to require that
they all end in the same base type. However, other rules may be required as well.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
537 [mercury] Feature Request feature N/A 2021-08-31 20:40 2021-08-31 20:40
Reporter: zs Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: unique file handles
Description: At the moment, once you open a file and get a file handle, you can
(try to) perform operations using that handle even after the handle
is closed.

We could add a new module to the library, called maybe uio.m,
where an open of a file gives you a *unique* file handle. Every
operation then takes a di,uo pair of the relevant kind of unique
file handle ({in,out}put, {text,binary}, and gives you back the
same handle you gave it. The exception is the close operation,
which takes a di file handle. This way, mode analysis could guarantee
the absence of operations on closed files.

The implementation would be simple, using type casts to the existing
file handle types with foreign code, followed by a call to the
equivalent predicate in io.m.

We would need some mechanism to detect the duplication of these unique
file handles during forks and fork-like operations, but that shouldn't
be too hard.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
There are no notes attached to this issue.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
536 [mercury] Bug minor always 2021-06-07 14:25 2021-06-25 16:06
Reporter: wangp Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: --track-flags unreliable when invoked quickly
Description: mmc --make fails to rebuild modules when invoked multiple times quickly with different flags, despite using --track-flags. Presumably this has something to do with the poor resolution of timestamps returned by io.file_modification_time, so is a specific case of a more general problem with mmc --make.


Script
=======
#!/bin/sh
set -x
rm -rf ./Mercury
mmc -m e --track-flags -s hlc.gc
#sleep 1
mmc -m e --track-flags -s hlc.gc -O3
#sleep 1
mmc -m e --track-flags -s hlc.gc -O4


Output
========
+ rm -rf ./Mercury
+ mmc -m e --track-flags -s hlc.gc
Making Mercury/int3s/e.int3
Making Mercury/ints/e.int
Making Mercury/cs/e.c
Making Mercury/os/e.o
Making e
+ mmc -m e --track-flags -s hlc.gc -O3
** Nothing to be done for `e'.
+ mmc -m e --track-flags -s hlc.gc -O4
** Nothing to be done for `e'.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
Notes
(0001148)
juliensf   
2021-06-25 15:22   
As starting point, I think we should decouple the notion of file timestamps from the other time related types in the standard library. (The latter are quite limited and ought to replaced, but that's a separate issue.)

I propose we introduce a new type io.file_time/0 (and whatever supporting operations are required) which maps on to whatever the highest resolution file time representation on the underlying platform is (.e.g java.nio.file.attribute.FileTime in Java, FILETIME structure on Windows etc.). We then add a new version of file_modification_time that returns that rather than a time_t.
(0001149)
zs   
2021-06-25 16:06   
That is a good idea.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
535 [mercury] Bug minor always 2021-06-05 16:13 2021-06-05 16:13
Reporter: juliensf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Abort during make install with grade hlc.gc on Windows 10
Description: During 'make install' for grade 'hlc.gc' we get:

     Uncaught Mercury exception:
    Software Error: predicate `parse_tree.write_deps_file.generate_d_file'/7: Unexpected: source file name doesn't end in `.m'

Modifying the compiler to print out the name of the "source" file that doesn't end with .m results in a file name that appears to contain rubbish:

    Uncaught Mercury exception:
    Software Error: predicate `parse_tree.write_deps_file.generate_d_file'/7: Unexpected: source file name doesn't end in `.m': it is "<80>Í^?#W"

This is occurring on:

* Windows 10, MSYS2 3.2.0-340 x86_64
* MinGW-w64 GCC 10.3.0
* Mercury commit 567704838
* Compiler built in in 'asm_fast.gc'.
* Boostrapped using rotd-202-05-01
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
There are no notes attached to this issue.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
534 [mercury] Bug crash always 2021-05-28 07:32 2021-05-28 07:32
Reporter: emacstheviking Platform: Apple  
Assigned To: OS: Catalina  
Priority: normal OS Version: 10.15.7  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Uncaught Mercury exception when using try[] on predicate optimsied away to true?
Description: Whilst trying to use try/catch, I was calling a predicate that attempted to abstract away the perceived repetition of using trace[]. I created a local predicate, atrace, which then calls a more common code ftrace, the intent was to be able to abstract out the check for an environment variable being present and then only cause output to happen of the debug level of that variable was past a given threshold.

Zoltan says all three predicates are effectively useless, which I can almost understand, but nonetheless it caused the compiler to choke on my awful code.

Thank you.
Tags:
Steps To Reproduce: This code:
on_lexer(Lx, AST) :-
    AST = astcon,
    list.filter_map(promote, lexer.tokens(Lx), ATokens),
    atrace("after promotion: %s\n\n--", [s(string(ATokens))]),
    (
        try []
            ast([], Tree, ATokens, Rest)
        then
            atrace("then block, Rest: %s\n", [s(string(Rest))])
        else
            atrace("else block\n", [])
        catch syntax_error(Pos, Why) ->
            atrace("oops: %s at %s", [s(Why), s(string(Pos))])
    ).

coupled with the following implementation of atrace and ftrace gave rise to the issue.

:- pred atrace(string::in, list(string.poly_type)::in) is det.
atrace(Format, Args) :-
    atrace(0, Format, Args).
:- pred atrace(int::in, string::in, list(string.poly_type)::in) is det.
atrace(Level, Format, Args) :-
    utils.ftrace(Level, "FELT_AST", "\n", Format, Args).

and

:- pred ftrace(
    int::in, string::in, string::in, string::in, list(string.poly_type)::in) is det.
ftrace(Level, Flag, Prefix, Format, Args) :-
    trace[io(!Dbg)] (
        utils.get_env_int(Flag, 0, N, !Dbg),
        (if N >= Level then
            io.print(Prefix, !Dbg),
            io.format(Format, Args, !Dbg)
        else true)
    ).
Additional Information: Mercury Compiler, version 20.06.1, on x86_64-apple-darwin19.6.0
Copyright (C) 1993-2012 The University of Melbourne
Copyright (C) 2013-2020 The Mercury team
Usage: mmc [<options>] <arguments>
Use `mmc --help' for more information.
Attached Files:
 
There are no notes attached to this issue.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
532 [mercury] Bug minor always 2021-05-12 15:52 2021-05-13 20:00
Reporter: wangp Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: constant_prop_2 failure in low-level C grades
Description: The hard_coded/constant_prop_2.m test case fails in low-level C grades. When --loop-invariants is enabled (e.g. with -O5) the first test is not being optimised away:

    ( if "abc" ++ "xyz" = "abcxyz" then
        io.write_string("yes", !IO), io.nl(!IO)
    else
        link_error(!IO)
    ).

I have bisected it to commit 18e222656 "Stop common_struct from interfering with mark_static_terms."

When --loop-invariants is enabled, the mark_static_terms.m pass is run, which marks the unification as construct_statically:

% constant_prop_2.hlds_dump.148-mark_static
constant_prop_2.main(STATE_VARIABLE_IO_0, STATE_VARIABLE_IO) :-
  ( if
    ( % conjunction
      V_6 = "abcxyz"
      % V_6 <= "abcxyz"
      % cell_is_unique
      % construct statically
      ,
      V_6 = "abcxyz"
      % V_6 ?= "abcxyz"
    )
  then
    ( % conjunction
      V_9 = "yes"
      % V_9 <= "yes"
      % cell_is_unique
      % construct statically
      ,
      io.write_string(V_9, STATE_VARIABLE_IO_0, STATE_VARIABLE_IO_10)
      ,
      io.nl(STATE_VARIABLE_IO_10, STATE_VARIABLE_IO)
    )
  else
    constant_prop_2.link_error(STATE_VARIABLE_IO_0, STATE_VARIABLE_IO)
  ).

But commit 18e222656 disables the optimisation unless How = construct_dynamically.

NOTE: the comment in common_optimise_unification incorrectly states that
mark_static_terms.m is only run in MLDS grades. maybe_mark_static_terms is currently located in mercury_compile_mlds_back_end.m, but it is called by maybe_loop_inv.
Tags:
Steps To Reproduce:  % mmc -s asm_fast.gc --loop-invariants constant_prop_2.m
/usr/bin/ld: constant_prop_2.o: in function `<predicate 'main'/2 mode 0>':
constant_prop_2.c:(.text+0x59): undefined reference to `<predicate 'constant_prop_2.link_error'/2 mode 0>'

Whether you actually get a link error seemingly depends on your version of gcc, linker, and phase of the moon.
Additional Information:
Attached Files:
 
Notes
(0001135)
zs   
2021-05-12 16:30   
Two things.

First, I have started on a diff to move maybe_mark_static_terms
from mercury_compile_mlds_backend.m to mark_static_terms.m, which
is already in the backend-neutral hlds package.

Second, I can see two broad approaches for the restoration of
the status-quo-ante of that bisected commit. One is to modify
loop_inv, which screws things up for the LLDS backend by getting
mark_static_terms to tinker with the construct_how fields in ways
that the LLDS backend does not expect, by making it clean up its
mess, and put the original values back into those fields. This
works only if we know what those original values are. The other
way is to set a flag in the simplify_info that specifies whether
we are targeting a backend that wants to pay attention to
construct_statically values in construct_how fields, or not.
In the latter case, we get commom_optimise_unification to accept
How = construct_statically as well as construct_dynamically.

The second is much easier to program, but imposes a (tiny) cost
on all compilations. I think that cost is too small to worry about,
so I would prefer the second approach.

Opinions?
(0001136)
wangp   
2021-05-12 18:38   
(Last edited: 2021-05-12 18:38)
The second sounds okay. There could be a danger that someone tries to make use of construct_statically in the LLDS backend when that information is no longer valid, but that will have to be clarified through comments.

Or, would it be possible to rerun mark_static_terms.m to recompute the how_to_construct fields after common.m makes a change that might invalidate those fields (for the MLDS backend only)?
(0001137)
zs   
2021-05-12 19:49   
Since the LLDS backend's code for creating static data predates
mark_static_terms.m, it should not pay any attention to construct_statically.
You are right, that should be documented as part of fixing this bug.

I don't understand your second paragraph. I am proposing that the code
in common.m that may invalidate the construct_how fields for the MLDS backend
be run ONLY when targeting the LLDS backend, so the situation assumed by
your question wouldn't arise.
(0001138)
wangp   
2021-05-13 12:10   
> I don't understand your second paragraph. I am proposing that the code
> in common.m that may invalidate the construct_how fields for the MLDS backend
> be run ONLY when targeting the LLDS backend, so the situation assumed by
> your question wouldn't arise.

Sorry, here is the context:

I am considering what if we allow common.m to optimise away
constructions marked 'construct_statically',
i.e. the situation before commit 18e222656.

That would obviously reintroduce bug 0000493 for the MLDS backend,
because a construction that is optimised away may invalidate a
'construct_statically' annotation on another construction
in the same procedure.

I think we can fix that by making common.m re-run the mark_static_terms
algorithm on a procedure if it optimises away a construction marked
'construct_statically'.
      
We would need to change mark_static_terms so that it can change
constructions from 'construct_statically' back to 'construct_dynamically'
if a variable on the RHS of the construction is NOT in the static set.
(0001139)
zs   
2021-05-13 12:27   
I think we are still talking at cross purposes. I am proposing
a change that would not affect what we do in MLDS grades at all.
(I have actually implemented it, the bootcheck is going right now.)
It affects only what we do in LLDS grades. Since LLDS grades
do not pay attention to construct_statically (treating it the same
as construct_dynamically), they do not CARE whether or not the invariants
established by mark_static_terms.m are preserved by common.m.
(0001140)
zs   
2021-05-13 20:00   
Fix committed 20201 may 13.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
526 [mercury] Bug minor always 2020-11-11 11:34 2021-04-28 11:17
Reporter: wangp Platform:  
Assigned To: wangp OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: unused imports affected by opt-imported typeclass instances
Description: Some basic investigation of why warnings/bug412.m fails when intermodule optimisation is enabled.

The `io' module is considered used because polymorphism adds a typeclass info to the constant structure database due to opt-imported typeclass instances. Then const_struct_used_modules treats every constant structure as a use:

const_struct_used_modules(_ConstNum - ConstStruct, !UsedModules) :-
    % Every const_struct in the const_struct_db was put there because
    % it is used in module. None of the uses can be in the interface.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
 
Notes
(0001124)
zs   
2020-11-12 03:13   
The obvious fix is to add a field to each entry to the const_struct_db
that says "does this entry come from the current module, or not?",
and then ignore the fields with "no" answers when it comes to computing
the set of used modules. The only nontrivial aspect I see is when
two or more const structs use a smaller const struct; the smaller
const struct should say "for this module" if any of its users also say so.

Do you see anything wrong with this approach?
(0001125)
wangp   
2020-11-30 13:35   
I think your approach should work.

(Sorry for the late response; the notification was caught by GMail's spam filter.)
(0001134)
wangp   
2021-04-28 11:17   
Fixed by zs on 2021-01-23




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
531 [mercury] Bug major always 2021-04-26 23:57 2021-04-27 00:17
Reporter: hyphz Platform: Windows  
Assigned To: OS: 10  
Priority: normal OS Version: 20H2  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: 20.06.1 will not compile in MingW32 2013072200 w/gcc 9.2.0-2: gettimeofday is deprecated
Description: Seems to be no workaround for this or way to add the -W flag to disable it?
Tags:
Steps To Reproduce: Install MSYS with latest gcc, flex and bison
Run configure and make on mercury
Additional Information:
Attached Files:
 
Notes
(0001133)
juliensf   
2021-04-27 00:06   
(Last edited: 2021-04-27 00:17)
Creating a file named Mmake.params at the top-level of the source tree that contains the following
should workaround the problem:

    EXTRA_CFLAGS=-Wno-deprecated-declarations

(or whatever the appropriate -W option is in this case.)




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
529 [mercury] Bug minor always 2021-02-20 15:47 2021-02-26 17:57
Reporter: wangp Platform:  
Assigned To: zs OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: higher order inst from existentially quantified data constructors
Description: As reported on m-users 2021-02-16, deconstructing a data constructor with existentially quantified type variables leaves a higher order argument with inst 'ground' even if higher order inst information is available from the du type definition.
Tags:
Steps To Reproduce: % mmc -e exist_cons_ho_arg.m
exist_cons_ho_arg.m:026: In clause for `main(di, uo)':
exist_cons_ho_arg.m:026: in argument 1 (i.e. the predicate term) of
exist_cons_ho_arg.m:026: higher-order predicate call:
exist_cons_ho_arg.m:026: mode error: variable `Pred' has instantiatedness
exist_cons_ho_arg.m:026: `ground',
exist_cons_ho_arg.m:026: expecting higher-order pred inst of arity 1.
Additional Information:
Attached Files: exist_cons_ho_arg.m (484 bytes) 2021-02-20 15:47
https://bugs.mercurylang.org/file_download.php?file_id=310&type=bug
 
Notes
(0001132)
zs   
2021-02-26 17:57   
Fix committed 2021 feb 24.




View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
528 [mercury] Bug minor always 2021-01-29 21:40 2021-01-30 01:46
Reporter: dirkz Platform: Mercury 20.06 / rotd-2021-01-27  
Assigned To: zs OS: MacOS Catalina, Intel  
Priority: normal OS Version: 10.15.7  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Compiler aborts when constructing invalid inst
Description: I want Mercury's mode checker to enforce following HTML validation rules via insts:
- An ul tag (unordered list) allows only li tags (list item) as direct children
- An li tag must have an ol tag as immediate parent

Expected result:
Compiler should report an error when creating an invalid inst.

Actual result:
Compiler aborts.

The error occurs with Mercury 20.06 as well as with rotd-2021-01-27.
Tags:
Steps To Reproduce: mmc --make html
Additional Information: $ mmc --make html
Making Mercury/int3s/html.int3
Making Mercury/ints/html.int
Making Mercury/cs/html.c
Uncaught Mercury exception:
Software Error: map.det_insert: key already present
    Key Type: parse_tree.prog_data.inst_name
    Key Value: user_inst(qualified(unqualified("html"), "non_empty_list"), [defined_inst(user_inst(qualified(unqualified("html"), "top_body_elem"), []))])
    Value Type: list.list(parse_tree.error_util.format_component)
** Error making `Mercury/cs/html.c'.
Attached Files: html.m (1,907 bytes) 2021-01-29 21:40
https://bugs.mercurylang.org/file_download.php?file_id=309&type=bug
 
Notes
(0001129)
zs   
2021-01-30 01:34   
I am testing a fix now.

However, if I were you, I would choose a HTML representation that
encoded HTML's invariants in the type, not in the mode. It would
not have any representation for
  • tags at all. Instead, the function
    symbol for lists would look like this:

    :- type html_elem
      ---> list(html_elem, list(html_elem))
      ...

    The
  • tags would be added only when a list is unparsed.
    (Not having an explicit representation for
  • guarantees
    that this representation cannot be put anywhere it shouldn't :-)
    And storing the first element of the list separately guarantees
    that the empty list is not representable.
    • (0001130)
    zs   
    2021-01-30 01:36   
    Sorry about the formatting of the above note. I didn't realize
    that Mantis does not quote html in notes :-( Those bullets were
    originally a sequence of <, l, i, and >.
    (0001131)
    zs   
    2021-01-30 01:46   
    Fix committed 2021 Jan 30.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    527 [mercury] Bug minor always 2021-01-27 13:00 2021-01-27 13:00
    Reporter: wangp Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: daio pass and inlining
    Description: The compiler aborts on gh72.m test during the inlining pass, with intermodule optimisation turned OFF.

    % mmc -s asm_fast.gc -O5 --no-intermod-opt gh72.m
    Uncaught Mercury exception:
    Software Error: predicate `hlds.instmap.merge_instmapping_delta_vars'/9: Unexpected: error merging var 5
    Stack dump follows:
       0 pred exception.throw/1-0 (erroneous) (exception.m:310)
       1 pred require.error/1-0 (erroneous) (require.m:172)
       2 pred require.unexpected/2-0 (erroneous) (require.m:203)
       3 2* pred hlds.instmap.merge_instmapping_delta_vars/9-0 (det) (instmap.m:1334 and others)
       5 pred hlds.instmap.merge_instmapping_delta/8-0 (det) (instmap.m:1290)
       6 pred hlds.instmap.merge_instmap_delta/8-0 (det) (instmap.m:1271)
       7 pred hlds.instmap.merge_instmap_deltas_2/8-0 (det) (instmap.m:1376)
       8 pred hlds.instmap.merge_instmap_deltas/7-0 (det) (instmap.m:1345)
       9 pred check_hlds.mode_util.recompute_instmap_delta_disj/9-0 (det) (mode_util.m:1602)
      10 pred check_hlds.mode_util.recompute_instmap_delta_1/8-0 (det) (mode_util.m:1391)
      11 pred check_hlds.mode_util.recompute_instmap_delta_conj/8-0 (det) (mode_util.m:1577)
      12 pred check_hlds.mode_util.recompute_instmap_delta_1/8-0 (det) (mode_util.m:1379)
      13 pred check_hlds.mode_util.recompute_instmap_delta/8-0 (det) (mode_util.m:1353)
      14 pred check_hlds.mode_util.recompute_instmap_delta_proc/5-0 (det) (mode_util.m:1346)
      15 pred transform_hlds.inlining.inline_in_proc/6-0 (det) (inlining.m:706)
      16 pred transform_hlds.inlining.inline_in_scc/6-0 (det) (inlining.m:298)
      17 10* pred transform_hlds.inlining.inline_in_sccs/5-0 (det) (inlining.m:282 and others)
      27 pred transform_hlds.inlining.inline_in_module/2-0 (det) (inlining.m:269)
      28 pred top_level.mercury_compile_middle_passes.maybe_do_inlining/6-0 (det) (mercury_compile_middle_passes.m:977)
      29 pred top_level.mercury_compile_middle_passes.middle_pass/8-0 (det) (mercury_compile_middle_passes.m:212)
      30 pred top_level.mercury_compile_main.after_front_end_passes/13-0 (det) (mercury_compile_main.m:2416)
      31 pred top_level.mercury_compile_main.process_augmented_module/14-0 (det) (mercury_compile_main.m:1793)
      32 pred top_level.mercury_compile_main.augment_and_process_module/15-0 (det) (mercury_compile_main.m:1687)
      33 pred list.map_foldl3/9-0 (det) (list.m:3335)
      34 pred top_level.mercury_compile_main.augment_and_process_all_submodules/15-0 (det) (mercury_compile_main.m:1627)
      35 pred top_level.mercury_compile_main.read_augment_and_process_module/11-0 (det) (mercury_compile_main.m:1447)
      36 pred top_level.mercury_compile_main.do_process_compiler_arg/10-0 (det) (mercury_compile_main.m:1207)
      37 pred top_level.mercury_compile_main.process_compiler_arg_build/11-0 (det) (mercury_compile_main.m:1091)
      38 pred make.build.build_with_module_options_args_invoked/13-0 (det) (make.build.m:234)
      39 pred make.build.build_with_module_options_args/12-0 (det) (make.build.m:185)
      40 pred top_level.mercury_compile_main.process_compiler_arg/12-0 (det) (mercury_compile_main.m:1052)
      41 pred top_level.mercury_compile_main.process_compiler_cmd_line_args/14-0 (det) (mercury_compile_main.m:1010)
      42 pred top_level.mercury_compile_main.do_op_mode_args/11-0 (det) (mercury_compile_main.m:845)
      43 pred top_level.mercury_compile_main.do_op_mode/10-0 (det) (mercury_compile_main.m:710)
      44 pred top_level.mercury_compile_main.main_after_setup/7-0 (det) (mercury_compile_main.m:672)
      45 pred top_level.mercury_compile_main.real_main_after_expansion/3-0 (det) (mercury_compile_main.m:443)
      46 pred top_level.mercury_compile_main.real_main/2-0 (det) (mercury_compile_main.m:137)
      47 pred mercury_compile.main/2-0 (det) (mercury_compile.m:32)


    The problem occurs when doing inlining in the predicate gh72.direct_arg_in_out_0_disj_init/3. It tries to merge the insts of a variable between two disjuncts:

            InstA
    bound(clobbered, inst_test_no_results,
      [bound_functor(cons(qualified(unqualified("gh72"), "f1"), 1, type_ctor(qualified(unqualified("gh72"), "t"), 0)), [ground(clobbered, none_or_default_func)]),
       bound_functor(cons(qualified(unqualified("gh72"), "f2"), 1, type_ctor(qualified(unqualified("gh72"), "t"), 0)), [ground(clobbered, none_or_default_func)]),
       bound_functor(cons(qualified(unqualified("gh72"), "f3"), 1, type_ctor(qualified(unqualified("gh72"), "t"), 0)), [ground(clobbered, none_or_default_func)]),
       bound_functor(cons(qualified(unqualified("gh72"), "f4"), 1, type_ctor(qualified(unqualified("gh72"), "t"), 0)), [ground(clobbered, none_or_default_func)])])

           InstB
    bound(clobbered, inst_test_no_results,
      [bound_functor(cons(qualified(unqualified("gh72"), "f1"), 1, type_ctor(qualified(unqualified("gh72"), "t"), 0)), [free]),
       bound_functor(cons(qualified(unqualified("gh72"), "f2"), 1, type_ctor(qualified(unqualified("gh72"), "t"), 0)),
         [bound(clobbered, inst_test_no_results,
            [bound_functor(cons(qualified(unqualified("gh72"), "package"), 2, type_ctor(unqualified(""), -1)),
               [bound(clobbered, inst_test_no_results, [bound_functor(string_const("fill2"), [])]), ground(clobbered, none_or_default_func)])])]),
       bound_functor(cons(qualified(unqualified("gh72"), "f3"), 1, type_ctor(qualified(unqualified("gh72"), "t"), 0)),
         [bound(clobbered, inst_test_no_results,
            [bound_functor(cons(qualified(unqualified("gh72"), "package"), 2, type_ctor(unqualified(""), -1)),
               [bound(clobbered, inst_test_no_results, [bound_functor(string_const("fill3"), [])]), ground(clobbered, none_or_default_func)])])]),
       bound_functor(cons(qualified(unqualified("gh72"), "f4"), 1, type_ctor(qualified(unqualified("gh72"), "t"), 0)), [ground(shared, none_or_default_func)])])
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    71 [mercury] Bug minor always 2008-07-30 17:55 2021-01-09 15:59
    Reporter: juliensf Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: compiler abort when building programs in debugging grades
    Description: The attached program aborts with the following:

    Uncaught Mercury exception:
    Software Error: map.lookup: key not found
        Key Type: term.var(parse_tree.prog_data.prog_var_type)
        Key Value: var(37)
        Value Type: ll_backend.var_locn.var_state

    Compile with: mmc --grade asm_fast.gc.tr.debug -C zinc_fdic_solver.m
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: zinc_fdic_solver.m (3,764 bytes) 2008-07-30 17:55
    https://bugs.mercurylang.org/file_download.php?file_id=56&type=bug
     
    Notes
    (0000109)
    zs   
    2008-08-01 12:29   
    The problem arises from the duplication by switch detection of the deconstruction unification that bind a typeclassinfo. Originally,
    that typeclassinfo is var 37. It is duplicated as var 81. The duplication
    updates the rtti_var_info but not the type_info varmap or the typeclass_info
    varmap, as shown below from this extract from the HLDS dump after switch detection:

    % type_info varmap:
    % I_1 (number 1) -> typeclass_info(TypeClassInfo_for_int_var_37, 1) (number 37)
    % typeclass_info varmap:
    % zinc_fdic_solver.int_var(I_1) -> TypeClassInfo_for_int_var_37

    % rtti_var_info:
    % TypeClassInfo_for_int_var_37 (number 37) -> typeclass_info for zinc_fdic_solver.int_var(I_1)
    % TypeClassInfo_for_int_var_81 (number 81) -> typeclass_info for zinc_fdic_solver.int_var(I_1)

    The code generator looks at the first two maps when generating layout structures for the debugger.
    (0001127)
    juliensf   
    2021-01-09 15:59   
    The abort message is now:

    Uncaught Mercury exception:
    Software Error: predicate `ll_backend.var_locn.actually_place_var'/6: Unexpected: placing nondummy var which has no state




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    512 [mercury] Bug minor always 2020-07-02 11:38 2020-10-29 19:36
    Reporter: wangp Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: branches of if-then-else disagree on liveness
    Description: See attached test case. This is not a recent bug as I can reproduce it with the 11.07 compiler as well.

    % mmc -C liveness_test_case.m -s asm_fast.gc -O5 --intermod-opt
    Uncaught Mercury exception:
    Software Error: predicate `ll_backend.liveness.require_equal'/4: Unexpected: branches of if-then-else disagree on liveness
    First:
    Rest: Cs_8
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: liveness_test_case.m (628 bytes) 2020-07-02 11:38
    https://bugs.mercurylang.org/file_download.php?file_id=301&type=bug
     
    Notes
    (0001123)
    zs   
    2020-10-29 19:36   
    Fix committed 2020 oct 23.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    525 [mercury] Bug minor have not tried 2020-10-29 19:35 2020-10-29 19:35
    Reporter: zs Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: compiler should detect missing included module
    Description: The compiler should generate an error message for situations
    such as:

    backend_libs.m has an include_module for erlang_rtti
    erlang_rtti is deleted, along with all import_modules for it
    the include_module for erlang_rtti becomes an orphan
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    524 [mercury] Bug block always 2020-10-14 20:21 2020-10-16 07:16
    Reporter: dirkz Platform: Mac  
    Assigned To: zs OS: macOS Catalina  
    Priority: normal OS Version: 10.15.7  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Installing rotd-2020-10-13 aborts with error
    Description: Installing rotd-2020-10-13 aborts with this error message:

    backend_libs.bytecode_data.c:256:14: error: "Weird-endian architecture"
                #error "Weird-endian architecture"
                 ^
    backend_libs.bytecode_data.c:339:14: error: "Weird-endian architecture"
                #error "Weird-endian architecture"
                 ^
    backend_libs.bytecode_data.c:457:14: error: "Weird-endian architecture"
                #error "Weird-endian architecture"
                 ^
    3 errors generated.
    make[2]: *** [backend_libs.bytecode_data.o] Error 1
    make[2]: *** Waiting for unfinished jobs....
    make[1]: *** [compiler] Error 2
    make: *** [all] Error 2
    Tags:
    Steps To Reproduce: sh configure --disable-most-grades
    make PARALLEL=-j8
    Additional Information: $ gcc -v
    Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
    Apple clang version 12.0.0 (clang-1200.0.32.2)
    Target: x86_64-apple-darwin19.6.0
    Thread model: posix
    InstalledDir: /Library/Developer/CommandLineTools/usr/bin


    $ llvm-gcc -v
    Apple clang version 12.0.0 (clang-1200.0.32.2)
    Target: x86_64-apple-darwin19.6.0
    Thread model: posix
    InstalledDir: /Library/Developer/CommandLineTools/usr/bin


    $ clang -v
    Apple clang version 12.0.0 (clang-1200.0.32.2)
    Target: x86_64-apple-darwin19.6.0
    Thread model: posix
    InstalledDir: /Library/Developer/CommandLineTools/usr/bin
    Attached Files: config.log (362,768 bytes) 2020-10-14 22:45
    https://bugs.mercurylang.org/file_download.php?file_id=308&type=bug
     
    Notes
    (0001113)
    juliensf   
    2020-10-14 21:07   
    Hi Dirk,

    The above will only occur if the configure script cannot determine the endianness of the system.
    Somewhere amongst the output of configure it should say something like:

        checking whether we can use unboxed 64-bit integers... yes
        checking whether architecture is big-endian... no
        checking whether architecture is little-endian... yes
        checking whether we can use files as locks... yes

    Do both the endianness checks return "no" on your system? If so, could you please check in config.log
    and see why those checks are failing? (Or post that file into Mantis and we'll take a look.)
    (0001114)
    juliensf   
    2020-10-14 21:31   
    BTW, I think the issue here is that Xcode 12 sets -Werror=implicit-function-declaration and the configure
    script contains several tests (including the ones for testing endianness) that do implicitly declare functions.
    (0001115)
    dirkz   
    2020-10-14 22:45   
    Hi Julien,

    both endianness checks return "no":
      checking whether we can use unboxed 64-bit integers... yes
      checking whether architecture is big-endian... no
      checking whether architecture is little-endian... no
      checking whether we can use files as locks... yes

    config.log (attached) states:
    configure:9044: checking whether architecture is big-endian
    configure:9071: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
    conftest.c:146:21: error: implicitly declaring library function 'exit' with type 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-declaration]
                        exit(0);
                        ^
    conftest.c:146:21: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit'
    1 error generated.
    configure:9071: $? = 1
    configure: program exited with status 1
    (0001116)
    zs   
    2020-10-14 22:55   
    Julien has already committed a diff to #include stdlib.h.
    It should show up in the next ROTD, or you could check it out
    of github, and try it out.
    (0001117)
    juliensf   
    2020-10-14 22:56   
    Hi Dirk,

    Thanks for that. The issue is the changed settings for Xcode 12; commit 00d5ede should fix the
    problem. (It will be included in the next rotd.)
    (0001118)
    dirkz   
    2020-10-15 03:22   
    Hi Julien,
    Hi Zoltan,

    rotd-2020-10-14 builds from source successfully now.

    Thank you for fixing this.
    (0001122)
    zs   
    2020-10-16 07:16   
    Fix committed 2020 oct 13.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    522 [mercury] Bug minor have not tried 2020-10-08 21:55 2020-10-16 07:15
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Compiler not building in Java grade with rotd-2020-09-29 onwards
    Description: The Java code we generate for update_opt_tuple/7 in compiler/optimization_options.m exceeds the 64k limit on method byte code size in Java.

    Making Java class files
    Mercury/javas/jmercury/libs__optimization_options.java:13287: error: code too large
      update_opt_tuple_7_p_0(
      ^
    Note: Some input files use unchecked or unsafe operations.
    Note: Recompile with -Xlint:unchecked for details.
    1 error
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001109)
    zs   
    2020-10-08 22:04   
    The obvious fix is to make each arm of the switch
    its own predicate. I can do that, if you like.

    BTW, why the hell is such a limit still in effect
    in 2020, especially without an override flag?
    Are they concerned about porting programs to PDP-11s?
    (0001110)
    juliensf   
    2020-10-08 22:28   
    Thanks, I suspect that's probably the best short term fix for this. (A better fix might be to get the
    MLDS->Java code generator to do such splitting on switches past a certain size threshold, but
    that may too much work for one instance of the problem.)

    IIRC, that limit (and a few others) are pretty deeply baked into the design of the JVM and changing
    them while preserving backwards compatibility would be non trivial.
    (0001121)
    zs   
    2020-10-16 07:15   
    Fix committed 2020 oct 13.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    508 [mercury] Bug minor have not tried 2020-05-17 01:31 2020-10-16 07:11
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Type constructors that are also Mercury operators result in invalid .int3 files
    Description: Type constructors that are also Mercury operators (like rule or pragma) result in .int3 files the compiler cannot read back in. This is due to the operators not being escaped in :- type_representation items. For example, extras/moose/grammar.m contains a type named rule/0, which results in the following in the .int3 file

        :- type_representation(grammar.rule, is_word_aligned_ptr)

    Currently, extras/moose and samples/muz cannot being compiled with the current ROTD.

    (Also, why does the first argument of the type_representation item need to be module qualified?)
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001120)
    zs   
    2020-10-16 07:11   
    Fix was committed 2020 may 17.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    515 [mercury] Bug minor always 2020-07-31 01:34 2020-10-16 07:06
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Library not building in deep profiling grades with rotd-2020-07-26
    Description: Compilation of the the standard library in grade asm_fast.gc.profdeep.stseg with rotd-2020-07-26 onwards results in:

    ../scripts/mgnuc --grade asm_fast.gc.profdeep.stseg -- -c exception.c -o exception.o
    In file included from exception.m:2101:0:
    ../runtime/mercury_exception_catch_body.h: In function ‘hand_written_exception_module’:
    ../runtime/mercury_exception_catch_body.h:61:5: error: ‘mercury__profiling_builtin__non_call_port_code_sr_5_0’ undeclared (first use in this function)
    ../runtime/mercury_exception_catch_body.h:61:5: note: each undeclared identifier is reported only once for each function it appears in
    ../runtime/mercury_exception_catch_body.h:64:5: error: ‘mercury__profiling_builtin__prepare_for_ho_call_2_0’ undeclared (first use in this function)
    ../runtime/mercury_exception_catch_body.h:82:5: error: ‘mercury__profiling_builtin__non_exit_port_code_sr_3_0’ undeclared (first use in this function)
    In file included from exception.m:2161:0:
    ../runtime/mercury_exception_catch_body.h:99:5: error: ‘mercury__profiling_builtin__non_redo_port_code_sr_2_0’ undeclared (first use in this function)
    ../runtime/mercury_exception_catch_body.h:115:5: error: ‘mercury__profiling_builtin__non_fail_port_code_sr_3_0’ undeclared (first use in this function)
    exception.c: At top level:

    This is occurring on testing.mercurylang.org. (Also, checked on my Linux machine with GCC 4.8)
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: PATCH.2020_07_31_exception (1,036 bytes) 2020-07-31 14:27
    https://bugs.mercurylang.org/file_download.php?file_id=304&type=bug
     
    Notes
    (0001101)
    zs   
    2020-07-31 14:27   
    I have fix for the linking issue (attached). However, a bootstrap in the deep
    profiling grade now gets a SIGSEGV when making the stage 3 dependencies,
    even when if I undo the commit that fixed Mantis bug 514 (commit c5b35aca...),
    which was the previous change that directly affected deep profiling.
    So this needs further investigation.
    (0001119)
    zs   
    2020-10-16 07:06   
    The fix was committed 2020 aug 1.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    523 [mercury] Bug minor have not tried 2020-10-13 00:47 2020-10-13 11:27
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Compiler abort with rotd-2020-10-{11,12}
    Description: Several modules in the compiler are causing it abort when compiled with grade hlc.gc, -O5 --intermodule-optimization.

    Uncaught Mercury exception:
    Software Error: predicate `check_hlds.simplify.common.common_standardize_and_record_construct'/13: Unexpected: GoalExpr0 has unexpected shape

    Affected files are:

        compiler/lp_rational.m
        compiler/transform.m
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001112)
    zs   
    2020-10-13 11:27   
    Fix committed 2020 oct 13.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    495 [mercury] Bug minor always 2020-02-04 14:02 2020-10-06 21:33
    Reporter: wangp Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: -O<n> options not additive
    Description: The -O<n> options are not additive in that they will reset certain options to default values, e.g. in

        mmc --optimise-constructor-last-call -O5 -C list.m

    the --optimise-constructor-last-call option has no effect.

    While the behaviour could be defended, I hit the problem trying to enable -O5 on the standard library by adding:

        EXTRA_MCFLAGS = -O5

    to Mmake.params. This silently disabled the --optimise-constructor-last-call option present in library/LIB_FLAGS. It turns out you need to write this instead:

        MCFLAGS += -O5
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001107)
    zs   
    2020-10-06 21:33   
    Feature implemented by 2020 september 29.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    520 [mercury] Bug minor always 2020-09-18 02:23 2020-10-02 17:46
    Reporter: keri Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: possible GCC ICE when compiling library/int.m in asm_fast.gc.tr.debug.stseg grade with -O1
    Description: I'm not really sure this is even a Mercury bug.

    When mercury is configured with --enabled-trail-grades an internal compiler error may occur when compiling library/int.m or library/uint.m in the asm_fast.gc.tr.debug.stseg grade and -O2 optimizations exist in CFLAGS.

    To reproduce:

    $ ./configure --enable-trail-grades
    $ echo "EXTRA_CFLAGS = -O1" >> Mmake.params
    $ make
    $ make install

    Alternatively, if mercury is already installed with a asm_fast.gc.tr.debug.stseg grade:

    $ cd mercury-srcdist/library
    $ mmc --compile-to-c --grade asm_fast.gc.tr.debug.stseg int
    $ mgnuc --grade asm_fast.gc.tr.debug.stseg -- -O1 -c int.c int.o

    In both cases the following ICE has been observed:

    int.c: In function 'int_module123':
    int.c:21687:1: error: unable to generate reloads for:
    (insn 162 161 163 11 (parallel [
                (set (reg/v:DI 43 r15 [ MR_mr3 ])
                    (ashift:DI (reg/v:DI 42 r14 [ MR_mr2 ])
                        (const_int 6 [0x6])))
                (clobber (reg:CC 17 flags))
            ]) "int.m":1013:18 520 {*ashldi3_1}
         (expr_list:REG_UNUSED (reg:CC 17 flags)
            (nil)))
    during RTL pass: reload
    int.c21687:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:3962

    The ICE only seems to occur with GCC 9.x. I've tried the following versions of GCC:

    * 8.3.0: no ICE
    * 9.2.0: ICE
    * 9.3.0: ICE
    * 10.2.0: no ICE
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001104)
    juliensf   
    2020-09-18 16:28   
    It's a Mercury bug to the extent that we would ideally apply workarounds to avoid the bugs in the affected versions of GCC.
    (0001106)
    juliensf   
    2020-10-02 17:46   
    This is the issue from bug 0000492. The compiler already has a workaround for the problem, but by setting EXTRA_CFLAGS=-O1 you are overriding that workaround.

    The underlying issue is not present in the GCC 8 and 10 branches, but seems to affect all versions of GCC 9 for x86_64.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    519 [mercury] Bug minor always 2020-09-17 05:14 2020-10-01 23:08
    Reporter: keri Platform:  
    Assigned To: juliensf OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: extras/graphics/mercury_tcltk library may contain reference to unknown matherr symbol
    Description: mtcltk.m contains the following:

    /*
    ** The following variable is a special hack that is needed in order for
    ** Sun shared libraries to be used for Tcl.
    */

    :- pragma foreign_code("C", "
        extern int matherr(void);
        int *tclDummyMathPtr = (int *) matherr;
    ").


    This workaround is no longer necessary with modern versions of Tcl and the matherr() function has been removed since version 8.4. [1]

    While libmercury_tcltk.so may be built, the resultant library may cause problems. For example, after building extras/graphics/mercury_tcltk:

    $ cd extras/graphics/samples/calc
    $ mmc --search-lib-files-dir ../../mercury_tcltk --library mercury_tcltk --make calc
    <snip>
    Making calc
    ** Error making 'calc'.
    ../../mercury_tcltk/libmercury_tcltk.so: undefined reference to 'matherr'
    collect2: error: ld returned 1 exit status


    We could either just remove the workaround or perhaps wrap it in some ifdef/endif block.


    [1] https://wiki.tcl-lang.org/page/tclDummyMathPtr
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001105)
    juliensf   
    2020-10-01 23:08   
    I've deleted it; I'm pretty sure we don't care about versions of Tcl from before 1999 any more.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    518 [mercury] Bug minor have not tried 2020-09-17 00:07 2020-09-17 07:18
    Reporter: keri Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Typo in extras/odbc.m
    Description: When compiling extras/odbc.m a function symbol (stat) is being used instead of a variable (Statement) leading to the following warning:

    odbc.m: In function 'odbc_module16':
    odbc.m:1349:5: warning: the comparison will always evaluate as 'true for the address of 'stat' will never be NULL [-Waddress]
    Tags:
    Steps To Reproduce:
    Additional Information: Attached is a diff to resolve this.
    Attached Files: mercury-extras-odbc.patch (455 bytes) 2020-09-17 00:07
    https://bugs.mercurylang.org/file_download.php?file_id=306&type=bug
     
    Notes
    (0001103)
    zs   
    2020-09-17 07:18   
    The supplied patch has been committed. Thank you.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    517 [mercury] Bug minor always 2020-09-16 23:51 2020-09-16 23:51
    Reporter: keri Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: extras/mopenssl fails to compile in a par grade with libressl
    Description: Using a par grade mopenssl.c fails to compile with libressl:

    Making Mercury/os/mopenssl.o
    mopenssl.m: In function 'mopenssl_module10':
    mopenssl.m:116.49: error: 'pthreads_thread_id' undeclared (first use in this function)
    mopenssl.m:116.49: note: each undeclared identifier is reported only once for each function it appears in
    mopenssl.m:116:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]
    mopenssl.m:117.45: error: 'pthreads_locking_callback' undeclared (first use in this function); did you mean 'CRYPTO_SET_locking_callback'?
    mopenssl.m:117.45: note: each undeclared identifier is reported only once for each function it appears in
    mopenssl.m:117:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]
    mopenssl.m: At top level:
    mopenssl.m:125:6: warning: no previous prototype for 'pthreads_locking_callback' [-Wmissing-prototypes]
    mopenssl.m:135.15: warning: no previous prototype for 'pthreads_thread_id' [-Wmissing-prototypes]
    ** Error making 'Mercury/os/mopenssl.o'.
    Tags:
    Steps To Reproduce: * use a version of Mercury configured with --enable-par-grades
    * compile extras/mopenssl on a host with libressl installed

    $ cd extras/mopenssl
    $ cp ../net/*.m ./
    $ mmc --grade asm_fast.par.gc.stseg --make libopenssl
    Additional Information: The attached diff adds function prototype declarations which allows mopenssl to compile.
    Attached Files: mercury-extras-mopenssl.patch (505 bytes) 2020-09-16 23:51
    https://bugs.mercurylang.org/file_download.php?file_id=305&type=bug
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    516 [mercury] Bug minor have not tried 2020-08-04 11:34 2020-08-09 20:39
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Failure of tests/general/mode_inference_reorder with recent ROTDs.
    Description: tests/general/mode_interference_reorder aborts with an uncaught exception when compiled
    with --intermodule-optimization -O5 using rotds 2020-07-30 through to 2020-08-01.

        Uncaught Mercury exception:
        Software Error: map.lookup: key not found
                Key Type: int
                Key Value: -1
                Value Type: hlds.hlds_pred.proc_info

    The last working ROTD was 2020-07-29.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001102)
    zs   
    2020-08-09 20:39   
    A fix for this symptom was committed 2020 aug 8.

    That diff documents the underlying problem but does not fix it,
    since the problem occurs only in very rare circumstances, and
    any proper fix would require work far out of proportion to its
    usefulness.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    513 [mercury] Bug minor have not tried 2020-07-15 20:16 2020-07-29 01:56
    Reporter: maoko Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: higher-order terms in freebsd bug.
    Description: Higher-order terms with multi deterministic behave weirdly in FreeBSD. The attached code print weird number whereas normally it should print 5. I guess it print some random value on the stack.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: a.m (481 bytes) 2020-07-15 20:16
    https://bugs.mercurylang.org/file_download.php?file_id=302&type=bug
    bug513.c (1,189 bytes) 2020-07-15 23:38
    https://bugs.mercurylang.org/file_download.php?file_id=303&type=bug
     
    Notes
    (0001094)
    zs   
    2020-07-15 22:38   
    On my Mac, the test case works in hlc, but fails in none.gc.
    (0001095)
    juliensf   
    2020-07-15 22:47   
    On my Linux system it fails (producing [take(0)]) on asm_fast.gc with the current rotd and 20.01.
    (It does work with Mercuy 14.01.1.)

    It also works with the MLDS backends in general (hlc.gc,java,csharp)
    (0001096)
    zs   
    2020-07-15 23:38   
    I have diagnosed the bug. It has nothing to do with higher order code or
    solutions. The problem is caused by incorrect tracking of where N is stored.

    The attached code is the code we generate for revert in LLDS grades.
    Initially, as the first argument, N is in r1. Since N is needed in the second
    disjunct but r1 may be overwritten in code executed after the if-then-else
    before execution backtracks to the second disjunct, we save N in framevar 1,
    and the second disjunct gets it from there.

    The problem is that (a) the else case of the if-then-else also gets N from
    framevar 1, but (b) the code for saving N in framevar 1 occurs *after* the
    test N % 2 = 0, and since 5 % 2 != 0, it is never executed. So yes, maoko
    was right: the value that the else case wraps up in take(), i.e. framevar 1,
    *is* a random value on the stack.
    (0001100)
    zs   
    2020-07-29 01:56   
    Fix committed 2020 July 29.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    514 [mercury] Bug minor always 2020-07-23 00:53 2020-07-28 19:19
    Reporter: keri Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: asm_fast.gc.profdeep.stseg grade fails to compile with GCC 10
    Description: Compiling Mercury with GCC 10 and profiling grades enabled can lead to a link-time failure:

    $ ./configure --enable-prof-grades

    $ make

    $ make install

    <snip>

    gcc -shared -Wl,--no-undefined \
        -o libmer_rt.so mercury.pic_o mercury_accurate_gc.pic_o mercury_agc_debug.pic_o mercury_atomic_ops.pic_o mercury_backjump.pic_o mercury_bitmap.pic_o mercury_builtin_types.pic_o mercury_construct.pic_o mercury_context.pic_o mercury_debug.pic_o mercury_deconstruct.pic_o mercury_deep_copy.pic_o mercury_deep_profiling.pic_o mercury_dlist.pic_o mercury_dummy.pic_o mercury_engine.pic_o mercury_file.pic_o mercury_float.pic_o mercury_getopt.pic_o mercury_getopt_long.pic_o mercury_grade.pic_o mercury_hash_table.pic_o mercury_heap_profile.pic_o mercury_hgc.pic_o mercury_ho_call.pic_o mercury_int.pic_o mercury_label.pic_o mercury_layout_util.pic_o mercury_memory.pic_o mercury_memory_handlers.pic_o mercury_memory_zones.pic_o mercury_minimal_model.pic_o mercury_misc.pic_o mercury_mm_own_stacks.pic_o mercury_overflow.pic_o mercury_par_builtin.pic_o mercury_prof.pic_o mercury_prof_mem.pic_o mercury_prof_time.pic_o mercury_profiling_builtin.pic_o mercury_reg_workarounds.pic_o mercury_region.pic_o mercury_regs.pic_o mercury_runtime_util.pic_o mercury_signal.pic_o mercury_stack_layout.pic_o mercury_stack_trace.pic_o mercury_stacks.pic_o mercury_stm.pic_o mercury_string.pic_o mercury_tabling.pic_o mercury_term_size.pic_o mercury_thread.pic_o mercury_threadscope.pic_o mercury_timing.pic_o mercury_trace_base.pic_o mercury_trace_term.pic_o mercury_trail.pic_o mercury_type_desc.pic_o mercury_type_info.pic_o mercury_type_tables.pic_o mercury_wrapper.pic_o mercury_wsdeque.pic_o \
        -Wl,-rpath,''/usr/local/lib/mercury/lib \
        -L/home/keri/mercury-srcdist-rotd-2020-07-17/install_grade_dir.asm_fast.gc.profdeep.stseg/boehm_gc -L/usr/local/lib -lgc_prof -lm ` case "asm_fast.gc.profdeep.stseg" in *.hlc.par*) echo -lpthread -ldl ;; *.par*) echo "-lpthread -ldl " ;; esac ` \
        `gcc -print-libgcc-file-name` -lm -lc
    /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: mercury_ho_call.pic_o:/home/keri/mercury-srcdist-rotd-2020-07-17/install_grade_dir.asm_fast.gc.profdeep.stseg/runtime/mercury_builtin_types_proc_layouts.h:71: multiple definition of `mercury_data__proc_layout__mercury____Compare___type_desc__type_ctor_desc_0_0'; mercury_builtin_types.pic_o:/home/keri/mercury-srcdist-rotd-2020-07-17/install_grade_dir.asm_fast.gc.profdeep.stseg/runtime/mercury_builtin_types_proc_layouts.h:71: first defined here

    <snip>

    /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: mercury_ho_call.pic_o:/home/keri/mercury-srcdist-rotd-2020-07-17/install_grade_dir.asm_fast.gc.profdeep.stseg/runtime/mercury_builtin_types_proc_layouts.h:41: multiple definition of `mercury_data__proc_layout__mercury____Unify___builtin__int8_0_0'; mercury_builtin_types.pic_o:/home/keri/mercury-srcdist-rotd-2020-07-17/install_grade_dir.asm_fast.gc.profdeep.stseg/runtime/mercury_builtin_types_proc_layouts.h:41: first defined here
    collect2: error: ld returned 1 exit status


    GCC 10 has included -fno-common in it's default set of flags. (The above build failure should be able to be reproduced with older versions of GCC by setting -fno-common in CFLAGS).


    The workaround I'm using at the moment is to is include -fcommon in CFLAGS.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001097)
    juliensf   
    2020-07-24 01:04   
    Placing proc layouts in common blocks is deliberate -- see the coment at the head of runtime/mercury_builtin_types_proc_layouts.h; we will need to arrange for -fcommon to be passed to GCC 10 and above.
    (0001098)
    zs   
    2020-07-24 13:09   
    I read that comment differently. To me, it says that the symbols of the *declarations*
    of the proc layout structures will end up in a common block whether we them to or not,
    and that we put those declarations into a separate .h file so that

    - we can control where those declarations are referenced from, and thereby
    - prevent those declarations from being mistaken by the linker for definitions.

    The better solution that the linkers at the time did not permit is to put the
    declarations in mercury_builtin_types.h, next to the definitions in the
    corresponding .c file. If all the compilers (and compiler versions) that
    we support have -fno-common or some equivalent, then we should switch to
    that solution.

    However, that will require us to fix another problem that I just discovered,
    which is that *some* of the proc_layout structures that we declare we don't define,
    and vice versa. Specifically, the definitions and declarations disagree about
    the arity of two type constructors in private_builtin.m: type_info and type_ctor_info.
    One says they are arity 0, while the other says arity 1, and the mismatch arises
    because the arity ends up in the name of the proc layout structure. I am just now
    bootchecking a fix for this problem. The only reason why this problem was not visible
    until now was the use of common storage, with its peculiar "declarations can act
    as definitions" rules.
    (0001099)
    zs   
    2020-07-28 19:19   
    Fix committed 2020 July 26.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    511 [mercury] Bug minor always 2020-06-19 18:22 2020-06-19 18:22
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: missing warning with --warn-unused-imports
    Description: The versions of two compiler modules before the application of the attached diff
    contain unused imports that the compiler

    - warns about if --warn-unused-imports is NOT specified, but
    - does NOT warn about if --warn-unused-imports IS specified,

    which is the exact opposite of the expected behavior.

    The reason for this inversion is that warn_unused_interface_import in
    module_qual.qual_errors.m generates a less-informative error message
    that it disables if --warn-unused-imports is specified, on the grounds that
    the code in unused_imports.m, which implements --warn-unused-imports,
    will generate a more informative error message for the same issue.
    However, in these cases, unused_imports.m does not do so.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: DIFF.bug511 (1,268 bytes) 2020-06-19 18:22
    https://bugs.mercurylang.org/file_download.php?file_id=300&type=bug
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    509 [mercury] Bug minor have not tried 2020-06-16 02:47 2020-06-16 02:47
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: higher_order.m optimizes soon-to-be-dead procedures
    Description: When the compiler has read in a bunch of predicate/function definitions from .opt files,
    those definitions get added to set of valid preds. higher_order.m looks for optimization
    opportunities among the set of valid preds. However, the common case is that
    those .opt files contain a whole bunch of predicates of which the current module
    uses only a few either directly or indirectly. (When have you written any module
    that calls all or even most of the predicates exported from e.g. list.m or map.m?)
    Optimizing the predicates that one of the following compiler passes will soon delete
    as dead code is a performance bug.

    We should modify either higher_order.m or its caller to delete dead procedures
    from the HLDS before it starts its work.

    Note that we will still need to do a round of dead proc elimination *after* higher_order.m,
    since higher_order.m can sometimes replace all calls to a predicate with calls to a
    specialized version, which makes the original version obsolete. However, maybe
    this could be done by higher_order.m itself *faster* than dead_proc_elim.m could
    do it, since it should be possible to avoid the need to construct a full call graph
    to do the job; counting unspecialized call sites should do the job.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    502 [mercury] Feature Request minor have not tried 2020-04-28 23:25 2020-06-09 11:37
    Reporter: zs Platform:  
    Assigned To: juliensf OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: print unsigned numbers
    Description: string.format and io.format should be able to print unsigned integers without
    the user having to explicitly convert them to a signed integer first.

    At the monent, signed ints can be printed with the d and i conversion chars,
    which print them as the signed ints they are, and with the o, u, x, X, and p
    conversion chars, which print them as if they were unsigned. I think the last
    five should be the conversion chars for which one should be able to pass
    *either* a i(int) poly_type, *or* a u(uint) polytype.
    Tags:
    Steps To Reproduce:
    Additional Information: When targeting C, the Mercury standard library can use either sprintf,
    or its own implementation. We have long defaulted to using sprintf, but
    we do already bypass it when dealing with data it would mishandle,
    such as non-ASCII UTF chars. The argument in favor of using sprintf
    has always been that it is faster than the library's format string interpreter,
    but this argument has lost most of its force when we started interpreting
    format strings at compile time. Perhaps it is time to stop using sprintf.
    Attached Files:
     
    Notes
    (0001090)
    juliensf   
    2020-04-29 17:42   
    It was always intended that the format predicates be extended to support all of the new integer types (not just uint). The first thing that needs to be decided is which conversion specifiers apply to which types (in particular should format support printing out unsigned integers as signed values).

    There are two main uses of sprintf in the standard library:

    1. in the primitive to_string conversion of things like integers and floats; here it's most probably a loss for us since the conversion specifier is fixed and we end up wasting time processing it.

    2. in the implementation of the format predicates

    I'm in favour of replacing use case (2) for the C backends now.
    (0001091)
    zs   
    2020-05-01 17:33   
    I don't know any use case that would justify being able to print uint values
    as signed with %d or %i. The use case for reverse (being able to print int
    values as unsigned with %u, %o, %x, %X or %p) was two-fold and obvious:
    the absence of uint at the time, and the fact that we implemented printing
    by calling C's print, which allowed it. In fact, it allowed this precisely because
    due to its variadic nature, printf couldn't be told that any integers passed to it
    were unsigned. So in both cases, the possible loss of meaning as a negative
    number was treated as unsigned was unavoidable. That is not the case here.
    (0001092)
    juliensf   
    2020-05-01 18:21   
    I'm not arguing that we need to support signed conversion specifiers with unsigned values -- I can't see any obvious use case for it either -- just that we need to define what is / will be supported.
    (0001093)
    juliensf   
    2020-06-09 11:37   
    Implemented by commit 9528f32.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    507 [mercury] Feature Request minor have not tried 2020-05-01 17:52 2020-05-01 17:52
    Reporter: zs Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: detect missing foreign_procs
    Description: We should add a compiler option that causes the compiler
    to generate a warning for every procedure that passes neither
    of the following tests:

    Test 1: it has a Mercury definition.

    Test 2: it has a definition in each of C, Java, C# and (maybe) Erlang.

    The test is for procedures, not predicate or functions,
    because foreign_procs are for procedures, and with mode-specific
    clauses, Mercury clauses can be as well. However, if a predicate
    or function has two or more procedures, and they all fail both tests,
    we should probably generate one message, not several.

    At the moment, I believe a substantial chunk of the test case failures
    in C# and Java grades are caused by missing foreign_procs for these
    languages that this option should help us find more easily. More important,
    enabling this warning for all modules in the library, which is compiled with
    --halt-at-warn, should help us not just to fix this, but *keep* it fixed.

    As for the option name, how about --warn-missing-foreign-procs?
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    505 [mercury] Feature Request minor have not tried 2020-05-01 16:46 2020-05-01 17:23
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: allow reference only to explicitly imported modules
    Description: This one could be viewed as either a feature request or a bug fix, depending
    on perspective.

    Have the type and mode checkers generate an error if a predicate defined
    in the module being compiled has a reference to a type, inst, mode, predicate,
    function, or typeclass that is not defined in an *explicitly* imported module.

    The point is that the compiler implicitly imports some modules. For example,
    if the module being compiled contains a try/catch goal, we implicitly import
    the exception module, because our implementation of try/catch includes
    adding references to entities defined in that module. Currently, this means
    that such modules need not explicitly import exception even if the *rest* of
    the module makes references to entities defined in exception.m, because
    such references are satisfied by the implicit import. But this behavior looks
    inconsistent to users, since they don't know or care how try/catch is
    implemented, from their point of view, exception.m became available
    to the module being compiled as if magic.

    This access-as-if-by-magic can happen to some other modules
    that we can import implicitly, and even to user modules, which can be
    made available to the module being compiled if intermodule optimization
    is enabled via the int-for-opt mechanism, whereby we read the interface
    files of not-explicitly-imported modules because they are needed to
    allow type- and mode-checking of code included in .opt files.
    This is why the restriction would apply *only* when type- and mode-checking
    predicates defined in the module being compiled; applying it to code
    included from .opt files would defeat the purpose of reading int-for-opt files.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    506 [mercury] Feature Request minor have not tried 2020-05-01 17:22 2020-05-01 17:23
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: --recommend-order
    Description: It would be nice if the compiler could recommend an order for the predicates
    (and functions) defined in a module. The order I am thinking of having the
    compiler recommend would be computed as:

    - Compute the SCCs of predicate call graph, each SCC containing
      a set of mutually recursive predicates.

    - Compute the dependencies between SCCs as a tree
      that the following steps flatten to a list that is *consistent*
      with the tree, in the sense that if SCC A contains a call to something
      in SCC B, then have SCC A appear before SCC B in the list of SCCs.

    - If the module contains N exported predicates, named e.g. Exported1
      through ExportedN, the compute the call tree of each exported predicate.
      (Consider each set of mutually-recursive exported predicates to be
      just one exported predicate, for simplicity of exposition in the following.)
      By the definition of SCCs, each call tree will contain either all the predicates
      in an SCC or none of them, so we can speak of each call tree as being
      composed of SCCs. Partition the SCCs into N+1 partitions, with partition I
      consisting of the SCCs that part of the call tree of *only* ExportedI,
      with the last partition consisting of the SCCs that are part of the call tree
      of more than one exported predicate. Put all the SCCs in each partition
      before all the SCCs in any later partitions.

    - In each of the first N partitions, put the one containing the exported predicate(s)
      first.

    - If the relative order of two SCCs in a partition is not determined by the rules
       above, order them by the line number of the context where the first reference
      to them occurs. (This may be a call to a predicate in the SCC, or the construction
      of a closure containing a reference to such a predicate.) This should yield
      a complete order of the SCCs that do contains some reference to them.
      The SCCs that have no such references contain dead code, and they should be
      reported as such.

    - Within each non-dead SCC, put the exported predicates (if any) first, in order of
      the line numbers of their declarations. The nonexported predicates should follow,
      in the order of the line numbers of the first references to them. This should establish
      a complete order among the non-dead predicates.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    503 [mercury] Feature Request minor have not tried 2020-04-28 23:51 2020-04-29 17:25
    Reporter: zs Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: unsigned shift amounts
    Description: At the moment, the shift amount is always a signed int, even when the
    value being shifted has type uint. It should be possible to make the shift amount
    an unsigned int. This would have the advantage that of the two checks that
    checked shifts have to do, checking for negative shift amounts and checking for
    shift amounts bigger than the word size, an unsigned shift amount would need
    only the latter.

    The key question is the syntax. Unlike e.g. C++, we cannot overload <<, >>, and
    their unchecked equivalents; we would need new function names. I can see
    using either <<< and >>>, or <<u and >>u as the names of the unsigned
    versions of << and >>. And maybe unchecked_{left,right}_shift_by_uint
    or unchecked_{left,right}_ushift for their unchecked versions.

    Any ideas for better names, or opinions on these names?
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001085)
    wangp   
    2020-04-29 16:26   
    The two checks are supposed to be performed using a single unsigned comparison on the shift amount, so is there anything to gain?

    I don't think the new operators would be used enough to justify them. Also, Java has >>> meaning logical right shift (I had to look that up) -- it would be best not to introduce operators that conflict with operators in well known languages.
    (0001086)
    zs   
    2020-04-29 16:39   
    The gain I am after is not efficiency. The gain is being able to write code
    such as "1u <<u NumBits" instead of "1u << uint.cast_to_int(NumBits)".
    I am working on a version of du_type_layout.m that would work at
    "create .int file" time instead of code generation time, and that code
    is full of things that cannot be negative: number of arguments in a functor,
    word lengths, bitfield sizes, shift amount etc. It is a pain having to choose
    between

    (a) using ints, and losing the >= 0 invariant, and
    (b) using uints, and having to pepper calls to most library functions
    with casts, because those functions take only signed ints, to the extent
    that the casts obscure the actual logic of the code.
    (0001087)
    zs   
    2020-04-29 16:40   
    On the topic of avoiding >>>, I agree; if we don't have to create
    such conflicts of notation, we shouldn't.
    (0001088)
    wangp   
    2020-04-29 17:03   
    You could define an overload in a compiler module to improve clarity:

    :- func uint << uint = uint.

    X << Y = uint.(X << cast_to_int(Y)).


    That is not to say we should not add named functions taking unsigned shift amounts to the standard library.
    (0001089)
    juliensf   
    2020-04-29 17:25   
    Java only has >>> for logical right shifts because it doesn't support unsigned types but does provide (some) unsigned operations on its signed types. AFAIK, it is the only well known language that has that.

    I'd be fine with unchecked_{left, right}_ushift for the unchecked versions. I'm not really a fan of things like >>u and <<u, but I can probably live with them. (I guess just having the functions left_ushift and right_ushift is too ungainly?)




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    504 [mercury] Feature Request minor have not tried 2020-04-28 23:58 2020-04-28 23:58
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: make checked shifts builtins
    Description: At the moment, we generate inline code for unchecked shifts, but a call
    to a library function for checked shifts. We should generate inline code
    for the latter as well. This would require extending the simple_code type
    in builtin_ops.m to be able to handle not just a test *or* an assignment,
    but a test *and* an assignment (if the test succeeds) *and* an abort
    (if it fails).

    That functionality should also allow us to generate inline code for
    checked quotients and remainders.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    497 [mercury] Feature Request minor always 2020-04-03 15:13 2020-04-20 15:09
    Reporter: wangp Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: make disable_warning forwards compatible
    Description: Currently if the compiler does not recognise a warning name in a disable_warning(s) goal, it will report an error. I think we can reduce the severity of an unknown warning name from an error to a warning. This will provide a transition period in which a source file that has been updated to suppress warnings when using a newer compiler version, will still compile (with warnings) when using an older compiler.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001077)
    zs   
    2020-04-04 02:43   
    Feature implemented 2020 april 4.
    (0001078)
    wangp   
    2020-04-04 13:07   
    Thanks for taking a look.

    However, the change is incomplete. When the clause is to be added in module_add_clause_2, MaybeBodyGoal is error1(...), the clause is not added, and compilation stops soon after.

    BTW, this also affects duplicated names in disable_warnings scopes. The error message says "Error:" but the error spec has severity_warning.
    (0001084)
    wangp   
    2020-04-20 15:08   
    Fixed in commit 4f32c5082




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    461 [mercury] Bug minor sometimes 2018-05-17 11:15 2020-04-20 15:06
    Reporter: wangp Platform:  
    Assigned To: wangp OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: MR_verify_final_engine_sleep_sync assertion failure (parallel conjunction)
    Description: Tests in par_conj fail intermittently in asm_fast.par.gc with an assertion failure of the form:

    dep_par_17: mercury_context.c:1839: MR_verify_final_engine_sleep_sync: Assertion `esync->d.es_action == MR_ENGINE_ACTION_NONE' failed.


    (As I remember, it doesn't just affect parallel conjunction but threads as well.)
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001081)
    wangp   
    2020-04-17 13:40   
    I found that I can reproduce this without parallel conjunction. The following command fails reliably on my machine. (parallel is GNU parallel; closeable_channel_test is from tests/hard_coded)

    parallel ./closeable_channel_test >/dev/null ::: `seq 1 1000`

    When the assertion in MR_verify_final_engine_sleep_sync fails, the value of esync->d.es_action is always MR_ENGINE_ACTION_SHUTDOWN.
    (0001082)
    wangp   
    2020-04-17 17:34   
    In MR_do_idle_worksteal we have:

            switch (esync->d.es_action) {
                case MR_ENGINE_ACTION_SHUTDOWN:
                    action_shutdown_ws_engine();

    Then the call sequence goes:

    action_shutdown_ws_engine -> MR_finalize_thread_engine -> MR_shutdown_engine_for_threads -> MR_verify_final_engine_sleep_sync

    Nothing changes esync->d.es_action before MR_verify_final_engine_sleep_sync asserts its value:

        assert(esync->d.es_action == MR_ENGINE_ACTION_NONE);


    So the fix is either to widen the assertion, or to set esync->d.es_action = MR_ENGINE_ACTION_NONE somewhere after switching on it.
    (0001083)
    wangp   
    2020-04-20 15:06   
    Fix committed 2020-04-20




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    480 [mercury] Bug minor always 2019-08-05 17:09 2020-04-15 12:58
    Reporter: wangp Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: regression in cse_detection.m
    Description: The attached test case fails to compile.

    % mmc -C cse_detection_regression.m
    cse_detection_regression.m:013: Error: invalid determinism for `to_bool'(in) =
    cse_detection_regression.m:013: out:
    cse_detection_regression.m:013: the primary mode of a function cannot be
    cse_detection_regression.m:013: `nondet'.
    cse_detection_regression.m:013: In `to_bool'(in) = out:
    cse_detection_regression.m:013: error: implicit determinism declaration not
    cse_detection_regression.m:013: satisfied.
    cse_detection_regression.m:013: Declared `det', inferred `nondet'.
    cse_detection_regression.m:022: Unification with `maybe.yes(V_8)' can fail.
    cse_detection_regression.m:024: Disjunction has multiple clauses with
    cse_detection_regression.m:024: solutions.
    cse_detection_regression.m:025: Unification with `maybe.no' can fail.
    For more information, recompile with `-E'.


    I bisected the problem to this change:

    commit 2466524308930c380483a90c7d767a74e7c8507b
    Author: Zoltan Somogyi <zoltan.somogyi@runbox.com>
    Date: Sun Jun 30 20:16:07 2019 +0200

        Fix cse_detection.m's interaction with uniqueness.
        
        This fixes github issue 0000064.

    compiler/cse_detection.m:
            When pulling a unification X = f(Y1, ..., Yn) out of an arm of
            a disjunction, switch or if-then-else, require the instantiation state
            of X to be free of unique or mostly_unique components.
        
            Put the requirements on X's inst into a single predicate.
        
            Add a mechanism to make debugging similar issues easier.
        
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: cse_detection_regression.m (503 bytes) 2019-08-05 17:09
    https://bugs.mercurylang.org/file_download.php?file_id=288&type=bug
    bug480b.m (470 bytes) 2019-08-19 13:48
    https://bugs.mercurylang.org/file_download.php?file_id=290&type=bug
     
    Notes
    (0001042)
    zs   
    2019-08-05 21:11   
    Commit 9fab528bba40d614fb5b715a350330a5f346da9f should fix
    most occurrences of this bug.
    (0001043)
    wangp   
    2019-08-19 13:48   
    Attaching a test case. (I previously posted it to the reviews list but it belongs here.)
    (0001044)
    zs   
    2019-08-19 19:07   
    It seems that with the current mode analysis system, there can't
    really be a simple satisfactory fix for the root cause of this problem.
    This is due to the fact that replacing "X = f(Y1, Y2)" with
    "X = f(A1, A2), A1 = Y1, A2 = Y2", which is the basic transformation
    on which cse is built, makes it lose track of any uniqueness in
    X's arguments.

    The original change to cse in June to fix github issue 64 was
    too conservative in that it avoided making that transformation
    not just when it would screw up uniqueness, but in other cases
    as well. The original and updated fixes to Mantis bug 480 made
    cse less conservative but still conservative enough. However,
    Peter's latest test case shows that the current approach will
    never be able to draw the line correctly between too conservative
    and not conservative enough. This is because it involves uniqueness
    in arguments that (a) the cse transformation would screw up, but
    (b) the program does not *care* if this uniqueness is screwed up,
    because it is only an accidental byproduct of that argument being
    a newly constructed term, and the uniqueness of this argument
    (the visited field in bug480b.m) is never required by any of its
    consumers. Part b is not a local property; it involves at least
    all of the rest of the procedure, and in the presence of mode inference,
    it may involve the code of the rest of the module as well.

    A way to solve this problem would be to downgrade unique insts
    to ground insts in situations that do not care about uniqueness.
    However, actually doing this would be hard, because it would require
    circular interaction between compiler phases. We do cse in stage 45,
    determinism analysis in stage 50, and unique mode checking in stage 55.
    Each phase depends on the results of the previous phase. We don't *know*
    which unique insts are required and which are not, until the end of
    stage 55, yet cse would need this info in stage 45.

    We *could* get cse to pull unifications out of disjunctions even if
    it would screw up uniqueness, but handle github issue 64 by recording
    this fact in the proc_info, and then redoing everything from cse onward
    if we get any error during unique mode analysis for any procedure
    that has been so marked. However, I would not call such a solution "simple",
    not least because a procedure may have done N such pulls involving unique args,
    and we don't know *which subset* of those N pulls we have to undo (to preserve
    uniqueness-correctness), which subset we *must not* undo (to preserve the
    expected determinism), and which subset would be fine either way.

    I would prefer to leave this issue in its current state with only one change:
    a note in NEWS mentioning that due to a bug fix, switches on variables' fields
    (as opposed to switches on variables themselves) may not be recognized as such,
    and telling people to replace such code with a switch on a variable. This would
    get users to do manually what cse used to do before the github 64 fix, the
    difference being that they should (would?) not be surprised by any errors
    involving uniqueness arising out of such a change.

    Since determinism analysis is inherently undecidable, such changes in heuristics
    are easily defensible.

    We could revisit this decision if/when a constraint based mode analysis
    is able to track uniqueness through the extra unifications added by cse.
    (0001045)
    wangp   
    2019-08-20 10:35   
    Thanks for the explanation. I think leaving it in the current state is acceptable.
    (0001080)
    zs   
    2020-04-15 12:58   
    Mantis bug 496 is a duplicate of this issue. It was resolved, to the extent
    possible, on 2020 feb 7.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    496 [mercury] Bug minor have not tried 2020-02-05 10:20 2020-04-15 12:56
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Determinism error in 20.01 for code that compiles successfully in 14.01.1
    Description: The attached predicate compiles successfully with Mercury 14.01.1 but
    gets a determinism error with 20.01. (It also compiles successfully with
    rotd-2018-05-10.)
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: bug496.m (1,807 bytes) 2020-02-05 10:20
    https://bugs.mercurylang.org/file_download.php?file_id=296&type=bug
     
    Notes
    (0001074)
    zs   
    2020-02-05 11:04   
    The cause of this bug is the fix for another bug: github 64.
    That fix did come with an announcement that reqressions like this
    would happen.

    I also think this bug is probably a duplicate of Mantis bug 480.

    The problem is that the code that constructs the final value of !:Actions
    gives it an inst that contains unique components (specifically, the constants
    action_canonicalise and action_split). In the presence of insts containing unique
    components, cse_detection.m refuses to automatically transform the switch
    on AllActions to the commented-out version, which directly leads to the bug.

    As mentioned in the discussion of bug 480, fixing this properly is hard.
    I can see a possible band-aid solution that *could* fix this and similar instances,
    though of course not all others. This would involve changing the test in
    cse_detection.m from "does the inst of the variant concerned (AllActions) include
    any unique components" to "does it contains any unique components on
    non-constants" (since constants do not have cells on the heap). The "could"
    part above is because I am pretty sure this change would revive github bug 64,
    but don't know whether fixing that in the constants-only case is possible.

    Even if it didn't, it would have the downside that it would make the rules
    followed by determinism analysis (when viewed from a user's point of view,
    and so including cse) more complex still.

    Who thinks this tradeoff is worth making?
    (0001075)
    juliensf   
    2020-02-05 11:25   
    I don't think the tradeoff is worth making; it's going to make an already complicated situation even more complicated.

    Question: how feasible is it to detect the above situation and make the error message suggest the refactoring?
    (0001076)
    zs   
    2020-02-05 11:45   
    It should be easy to

    - have cse record, in the proc_info the fact that it declined to pull a common unification
      out of a disjunction due to uniqueness concerns, and

    - have determinism analysis look at this flag, and if set, and there are determinism errors,
      print a message about this fact being a possible cause of the errors.

    What I am not sure about is whether we can give this message a useful context,
    for two reasons. One: by definition, a common deconstruction involves at least
    two contexts, maybe more, and listing them all probably wouldn't be useful.
    We can probably use the smallest context (i.e. the one with the smallest
    line number). Two, when cse pulls a deconstruction unification out of the arms
    of a disjunction, the pulled-out unification does not come from any one place,
    so there is no one "right" context it can record for it. Again, we can probably
    use the smallest context among the pulled-out unifications. This would then
    be a context we could report if there is a problem in the *next* invocation
    of cse on that procedure body. But given the approximations above, I am not sure
    whether the context they would yield would useful in the common cases.

    However, given that the pointer to the cause of the error would be useful
    even without a specific context, I will implement it.
    (0001079)
    zs   
    2020-04-15 12:56   
    The reminder about this possible cause of the determinism error,
    based on a flag set by cse_detection.m, was added to the compiler
    on 2020 feb 7.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    498 [mercury] Feature Request minor have not tried 2020-04-04 21:01 2020-04-04 21:01
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: handle misalignment of arguments in type errors better.
    Description: Suppose you have a predicate p with arguments A, B, C.
    When you add an extra arg at the start of the argument list, say X,
    then existing calls p(A, B, C) won't match the new definition p(X, A, B, C),
    but they *could* be taken as attempts to curry a call to p.

    We currently generate an error message that says 1: arg A should have type X,
    2: arg B should have type A, 3: arg C should have type B.

    The compiler should notice that each arg i has the type expected of arg i+j,
    where j is the number of added arguments, and generate an error message
    that reports *this*, instead of generating a message about each argument's
    wrong type.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    120 [mercury] Bug minor have not tried 2009-12-18 10:51 2020-02-04 17:24
    Reporter: juliensf Platform:  
    Assigned To: juliensf OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: won't fix  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: bootchecking in reg.gc fails on Mac OS 10.6
    Description: Bootchecking in grade reg.gc fails on Mac OS 10.6. It gets as far as building
    the stage 2 dependencies and then we get out of memory errors from the GC.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000253)
    juliensf   
    2010-02-27 18:23   
    This still fails even with the Boehm GC upgrade (to 7.2alpha4).
    (0001073)
    juliensf   
    2020-02-04 17:24   
    There's not much use fixing this; Apple no longer support OS 10.6, so there's no point in us supporting it.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    494 [mercury] Bug minor have not tried 2020-01-23 11:41 2020-01-27 04:13
    Reporter: juliensf Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: hard_coded/nonascii fails on Windows
    Description: hard_coded/nonascii fails on Windows (mingw64-{32,64},MSVC); it outputs "premature EOF" for most of the output.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001072)
    juliensf   
    2020-01-27 04:13   
    The reason for failure is that text mode in Windows treats the byte 0x1a (i.e. Ctrl-Z) as EOF. (There's not much we can do about this, short of switching files to binary mode on Windows.)




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    484 [mercury] Feature Request minor N/A 2019-09-18 23:00 2020-01-24 17:56
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: error message could be more specific
    Description: The error message is
    bug484.m:018: In clause for `p(in, out, out)':
    bug484.m:018: in call to predicate `list.foldl'/4:
    bug484.m:018: mode error: arguments `V_8, As, X, B' have the following insts:
    bug484.m:018: /* unique */ (pred(in, in, out) is det),
    bug484.m:018: free,
    bug484.m:018: ground,
    bug484.m:018: free
    bug484.m:018: which does not match any of the modes for predicate
    bug484.m:018: `list.foldl'/4.

    It should point that it is only the second argument whose mode is wrong.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: bug484.m (485 bytes) 2019-09-18 23:00
    https://bugs.mercurylang.org/file_download.php?file_id=292&type=bug
     
    Notes
    (0001071)
    zs   
    2020-01-24 17:56   
    Error message improved on 2020 jan 24.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    493 [mercury] Bug minor always 2020-01-22 14:50 2020-01-23 11:46
    Reporter: wangp Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: MLDS ground terms bug
    Description: MLDS backend crashes on the attached test case when --loop-invariants is enabled (or -O5).

    % ./build.sh
    + mmc -s hlc.gc --make-interface codepoint
    + mmc -s hlc.gc --loop-invariants -C bug
    Uncaught Mercury exception:
    Software Error: map.lookup: key not found
            Key Type: term.var(parse_tree.prog_data.prog_var_type)
            Key Value: var(7)
            Value Type: ml_backend.ml_gen_info.ml_ground_term
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: mlds_ground_term_bug.tar.gz (10,240 bytes) 2020-01-22 14:50
    https://bugs.mercurylang.org/file_download.php?file_id=295&type=bug
     
    Notes
    (0001070)
    zs   
    2020-01-23 11:46   
    Fix committed 2020 Jan 22.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    492 [mercury] Bug minor always 2020-01-13 18:41 2020-01-18 22:23
    Reporter: juliensf Platform: x86_64  
    Assigned To: juliensf OS: Fedora  
    Priority: normal OS Version: 31  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: make install fails with GCC internal error on Fedora 31
    Description: The 'make install' step fails for 20.01-beta-2020-01-12 on Fedora 31 with the following message when attempting to build the library in the asm_fast.gc.debug.stseg grade. The GCC version is 9.2.1.

    mmc --compile-to-c --grade asm_fast.gc.debug.stseg --mercury-linkage shared --flags LIB_FLAGS --flags INTER_FLAGS -R/home/juliensf/mercury-20.01-beta-2020-01-12/lib/mercury/lib/asm_fast.gc.debug.stseg -R/home/juliensf/mercury-20.01-beta-2020-01-12/lib/mercury/lib hash_table > hash_table.err 2>&1
    /home/juliensf/mercury-srcdist-20.01-beta-2020-01-12/install_grade_dir.asm_fast.gc.debug.stseg/scripts/mgnuc --grade asm_fast.gc.debug.stseg -- -c hash_table.c -o hash_table.o
    hash_table.c: In function ‘hash_table_module45’:
    hash_table.c:11468:1: error: unable to generate reloads for:
    (insn 498 497 499 32 (parallel [
                (set (reg/v:DI 43 r15 [ MR_mr3 ])
                    (ashift:DI (reg/v:DI 42 r14 [ MR_mr2 ])
                        (const_int 31 [0x1f])))
                (clobber (reg:CC 17 flags))
            ]) "hash_table.c":11443:33 520 {*ashldi3_1}
         (expr_list:REG_UNUSED (reg:CC 17 flags)
            (nil)))
    during RTL pass: reload
    hash_table.c:11468:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:3962
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <http://bugzilla.redhat.com/bugzilla> for instructions.
    Preprocessed source stored into /tmp/ccOvGbry.out file, please attach this to your bugreport.
    gmake[2]: *** [/tmp/mmake.kZqh3s:89984: hash_table.o] Error 1
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001065)
    wangp   
    2020-01-13 19:54   
    I previously reported it here:
    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91430
    (0001066)
    juliensf   
    2020-01-13 20:05   
    Do you know if there is a workaround we can use for it?
    (0001067)
    wangp   
    2020-01-13 20:52   
    Unfortunately, no.
    (0001068)
    juliensf   
    2020-01-15 14:42   
    Also, occurs with Alpine Linux 3.11 (GCC 9.2). I think we will just need to force GCC to use -O0 in debug grades with GCC 9.1 and 9.2. (The bug only seems to be triggered in debug grades.)
    (0001069)
    juliensf   
    2020-01-18 22:23   
    We now force the use of gcc -O0 in debug grades with GCC 9.
    (Confirmed that installation of the source distribution works with
    both Fedora 31 and Alpine Linux 3.11 out of the box.)




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    489 [mercury] Bug minor always 2020-01-09 14:31 2020-01-15 19:54
    Reporter: wangp Platform:  
    Assigned To: wangp OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: mmc --make gets confused by source files with same name as standard library module
    Description: mmc --make gets confused by a source file in the current directory that matches the name of a standard library module, e.g. in the attached test case, lexer.m contains the sub-module `test.lexer'.


    Test 1 - tries to make lexer.mih from lexer.m
    ---------------------------------------------
    % mmc -s hlc.gc -m test -v
    Making Mercury/mihs/lexer.mih
    Invoking self `mmc [...] lexer' <-- not test.lexer
    ...
    lexer.m:010: In module `lexer': error:
    lexer.m:010: the absence of an `:- import_module' or `:- use_module'
    lexer.m:010: declaration for `test' prevents access to the `:- import_module'
    lexer.m:010: declaration for its child module `test.other'.



    Test 2 - likewise for .opt files
    --------------------------------
    % mmc -s asm_fast.gc --intermod-opt -m test
    Making Mercury/opts/test.opt
    Making Mercury/opts/test.lexer.opt
    Making Mercury/opts/test.other.opt
    Making Mercury/opts/lexer.opt
    lexer.m:010: In module `lexer': error:
    lexer.m:010: the absence of an `:- import_module' or `:- use_module'
    lexer.m:010: declaration for `test' prevents access to the `:- import_module'
    lexer.m:010: declaration for its child module `test.other'.
    ** Error making `Mercury/opts/lexer.opt'.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: mmc_make_source_filename_confusion.tar.gz (10,240 bytes) 2020-01-09 14:31
    https://bugs.mercurylang.org/file_download.php?file_id=294&type=bug
     
    Notes
    (0001056)
    wangp   
    2020-01-09 16:23   
    Notes:

    do_get_module_dependencies assumes the SourceFileName returned by module_name_to_file_name can only be the source file for the given ModuleName, so the solution may require reading the `:- module` item before proceeding with make_module_dependencies.

    If a source file map is present, it may be helpful to rule out the default source file name: if "lexer.m" is mapped to `test.lexer' then it cannot be the source file for module `lexer'.
    (0001057)
    zs   
    2020-01-09 21:18   
    The documentation of the -f option states:

    "Output the module name to file name mapping for the list of source files given as non-option arguments to ‘mmc’ to Mercury.modules. This must be done before ‘mmc --generate-dependencies’ if there are any modules for which the file name does not match the module name. If there are no such modules the mapping need not be generated."

    So if there is NO source file map present, mmc --make is *allowed* to assume that lexer.m
    contains a module named "lexer", and *not* a module named "test.lexer".

    The error message it generates could of course be improved, e.g. by drawing attention
    to this fact, but in this case, I don't think the compiler is confused; more like it is misled,
    which is not its fault.

    Or am I missing something?
    (0001058)
    wangp   
    2020-01-09 21:53   
    The section on separate sub-modules states:

    "For a module named ‘foo.bar.baz’, The University of Melbourne Mercury implementation requires the source to be located in a file named foo.bar.baz.m, bar.baz.m, or baz.m."
    (0001059)
    zs   
    2020-01-11 18:57   
    We have two endpoints of a spectrum where the answer to the question
    "should you have to run mmc -f *.m?" is clear-cut.

    Endpoint A: every module is in a file whose name is the fully qualified module name.

    Endpoint B: every module is a file whose name has no relationship to the module name.

    It is clear that at Endpoint A, the answer is "no", while at endpoint B, it is "yes".

    At the moment, the answer is also "no" if every module is in a file whose name is either
    the fully qualified module name *or a subsequence* of the fully qualified sequence.
    The code that implements that check, in read_first_module_decl in parse_module.m,
    already has an XXX, on code that accepts module A.B.C not just as being in file A.C.m,
    but also as being in file A.D.B.C.m. And your bug report demonstrates another problem
    with the existing code.

    There are two ways to fix this bug. One is to change this code to require the expected
    module name and the actual module name to be identical. Without mmc -f, this would mean
    that the answer is "yes" everywhere except at Endpoint A. This would be a change from
    the current situation, and would require a change in the manual, but the rule would be simple
    and easy to obey: always use mmc -f. The other possible approach to the fix, which I read
    your initial note as supporting, would require the compiler to look for a known module name
    (test.lexer) in one file name after another (all being subsequences of the fully qualified
    module name) until it found one whose :- module declaration had the looked-for name.
    (In this case, we would need to look in just two places, test.lexer.m and lexer.m, but in
    general, the list could be a lot longer). In effect, this approach would require mmc
    --generate-dependencies to do a significant part of the job of mmc -f. I, for one,
    would find that solution more complex than necessary, from the user's point of view
    as well as from an implementor's.
    (0001060)
    wangp   
    2020-01-12 12:08   
    The current rules have always seemed oddly lax to me, and I think most larger Mercury project would be using mmc -f for one reason or another, so I have no problem with changing the compiler's behaviour such that modules must be in a file whose names is the fully qualified module name (.m), or else listed in the source file map.
    (0001061)
    zs   
    2020-01-12 12:14   
    In that case, I will post a proposed diff for doing this later today.

    I also propose that this change be part of 20.01. Any objections?
    (0001062)
    juliensf   
    2020-01-12 12:55   
    There are definitely some larger Mercury projects that do *not* use mmc -f; Opturion's runtime library is an example. That's not an objection since the fix is trivial, but the proposed change is going to break some things.

    No objections to including this in 20.01 for me.
    (0001063)
    zs   
    2020-01-12 22:28   
    Fix committed 2020 jan 12.
    (0001064)
    wangp   
    2020-01-13 10:49   
    A file listed in the source file map needs to be not returned as the source file for some different module. (assigning to self; Mantis only has a "Request feedback" button)




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    491 [mercury] Feature Request minor have not tried 2020-01-12 22:32 2020-01-12 22:32
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: implicit imports in interface files
    Description: We currently scan items in interface files we have just read in
    to find out what builtin modules they implicitly need (e.g. tabling_statistics.m
    if a pragma memo specifies the gathering of tabling statistics).

    Instead of requiring the N readers of the interface file to compute this set,
    the one generator of the interface file should compute this and put the
    result into the interface file as a new kind of declaration.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    490 [mercury] Feature Request minor N/A 2020-01-11 18:18 2020-01-11 18:18
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: when importing A.B, do not require importing A
    Description: Currently, a module X that imports A.B must also import A; if it does not, it gets
    an error about A.B being inaccessible. This makes C unnecessarily dependent on A,
    which is undesirable; for example, it leads to X having to be recompiled when
    a new submodule A.C gets added to A, even though X has nothing to do with A.C.

    This issue was discussed on m-rev in november of 2015 in a thread named
    "should we break up module_qual.m". This discussion reached a concensus
    in favour of this change.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    488 [mercury] Bug minor have not tried 2019-10-27 17:14 2019-10-28 05:02
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Variable as pred name in predmode decl causes generates incorrect error message
    Description: Using a variable as predicate name in a predmode decl, for example:

        :- pred MyPred(int::in, int::out) is semidet.

    results in the following:

       foo.m:007: Error: some but not all arguments have modes.
       foo.m:007: The argument without a mode is the first.

    Using a variable in a separate predicate or mode declaration for a predicate results in a
    correct error message.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001055)
    zs   
    2019-10-28 05:02   
    Fix committed 2019 10 28.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    487 [mercury] Bug minor always 2019-10-08 17:04 2019-10-08 21:06
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Incomplete and confusing error message
    Description: Among the error messages generated for the attached test case is:

        bug487.m:029: When the condition succeeds, the if-then-else defines, but when
        bug487.m:029: the condition fails, it does not.

    Defines what?
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: bug487.m (1,537 bytes) 2019-10-08 17:04
    https://bugs.mercurylang.org/file_download.php?file_id=293&type=bug
     
    Notes
    (0001054)
    zs   
    2019-10-08 21:06   
    Fix committed 2019 oct 8.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    486 [mercury] Bug minor have not tried 2019-09-29 04:00 2019-09-29 14:06
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Partially qualified types in foreign_enum pragmas not working with rotd-2019-09-28
    Description: extras/graphics/mercury_glut/glut.window.m contains the following type and foreign_enum declaration.

        :- type window.state
            ---> x
            ; y
            ; window_width
            ....

           :- pragma foreign_enum("C", window.state/0,
           [
               x - "GLUT_WINDOW_X",
               y - "GLUT_WINDOW_Y",
               window_width - "GLUT_WINDOW_WIDTH"

    Building the short interface for glut.window now results in:

        glut.window.m:689: Error: `:- pragma foreign_enum' declaration for the
        glut.window.m:689: undeclared type `state'/0.

    (The error goes away if the type name in the foreign_enum pragma is fully qualified.)
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001053)
    zs   
    2019-09-29 14:06   
    Fix committed 2019 sep 29.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    485 [mercury] Bug minor have not tried 2019-09-29 03:54 2019-09-29 14:05
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Various bits of extras not building with rotd-2019-09-28
    Description: Various graphics library bindings (e.g. the OpenGL one) in extras no longer build due to the fact
    that they contain things like:

        :- module foo.
        :- interface.

        :- type quad_boolean_state ---> color_writemask.

        :- implementation.

        :- pragma foreign_enum("C", quad_boolean_state/0, [
            color_writemask - "561"
        ]).

    Building the interface files now results in:

        foo.m:008: Error: the Mercury definition of `quad_boolean_state'/0 is not an.
        foo.m:008: enumeration type, so there must not be any
        foo.m:008: `:- pragma foreign_enum' declarations for it.
        foo.m:004: That Mercury definition is here.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001048)
    zs   
    2019-09-29 04:04   
    I think the bugs in each extra should be fixed by whoever understands that program
    the best.
    (0001049)
    juliensf   
    2019-09-29 04:18   
    Why does the compiler think that quad_boolean_state/0 is not an enumeration? Because it's a dummy type? If so, that's wrong, because the presence of a foreign_enum pragma should suppress the dummyness of the type.
    (0001050)
    zs   
    2019-09-29 04:31   
    The Mercury definition is a dummy type, and the type as a whole is a dummy type
    on every platform on which that foreign_enum is not applicable.

    The crux here is that

    - enum types have N functors of arity 0
    - dummy types have 1 functor of arity 0

    so yes, dummy types can be viewed as a special case of enum types
    in terms of whether a foreign enum is applicable to them.

    The question for me is: when someone writes code like that (Mercury dummy type
    paired with a foreign enum with one constant) is it likely to be an error? The type
    requires representation on some backends, but not others, which is strange.

    I haven't used foreign enums much, so I don't know the answer.
    (0001051)
    juliensf   
    2019-09-29 05:05   
    (Last edited: 2019-09-29 05:05)
    This issue arises in the OpenGL, GLFW and Allegro bindings. Since they are all bindings to C libraries the issue of the type requiring a representation on some backends but not others is a non-issue; those bindings cannot be meaningfully compiled with the other backends anyway.

    The information conveyed by such types is the foreign value of the functor. In the example I gave above, even though quad_boolean_state only has a single value in Mercury, the functions that use it in C can take many other values -- in Mercury, we represent those other values are represented using other enum types.

    Another reason this may arise is due to a library binding being incomplete.

    Both the code in extras and not treating foreign_enums as dummy types is intentional.
    (0001052)
    zs   
    2019-09-29 14:05   
    Fix committed 2019 sep 29.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    483 [mercury] Bug minor always 2019-09-02 16:17 2019-09-02 18:27
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Spurious warning about unused module import
    Description: The compiler generates a warning about an unused module import for the attached program. Entities exported by the module are used in the 'for' clause of the inst definition, but unused module check doesn't seem to be considering that.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: bug483.m (227 bytes) 2019-09-02 16:17
    https://bugs.mercurylang.org/file_download.php?file_id=291&type=bug
     
    Notes
    (0001047)
    zs   
    2019-09-02 18:27   
    Fix committed 2019 sep 2.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    482 [mercury] Bug minor have not tried 2019-08-25 16:23 2019-08-25 16:23
    Reporter: pbone Platform: x86_64  
    Assigned To: OS: Linux  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Deep profiler "Restart" menu option doesn't restart the mdprof_cgi server
    Description: When I clicked the restart button it brought me back to the home screen of the deep profiler without restarting the profiler (and re-reading my program's profile).
    Tags:
    Steps To Reproduce: 1. Build a program for deep profiling.
    2. Use the profiler to find the bottleneck, fix it.
    3. Recompile the program and re-run it producing an updated Deep.data file
    4. Click Restart in the deep profiler
    5. Observe that it returns to the home screen without reading the new profile with the performance improvement.
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    481 [mercury] Bug minor always 2019-08-19 13:38 2019-08-20 11:34
    Reporter: wangp Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: abort in MLDS code generator with --static-ground-terms
    Description: The compiler aborts on the following test case in hlc grades.

    % mmc -s hlc.gc -C mlds_ground_term.m
    Uncaught Mercury exception:
    Software Error: map.lookup: key not found
            Key Type: term.var(parse_tree.prog_data.prog_var_type)
            Key Value: var(4)
            Value Type: ml_backend.ml_gen_info.ml_ground_term
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: mlds_ground_term.m (329 bytes) 2019-08-19 13:38
    https://bugs.mercurylang.org/file_download.php?file_id=289&type=bug
     
    Notes
    (0001046)
    zs   
    2019-08-20 11:34   
    Fixed by commit 1afe0df4e95cf65f9e32a4f60caad2ea4d1c81cf.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    401 [mercury] Bug minor always 2015-12-17 18:00 2019-08-04 09:39
    Reporter: wangp Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: different module import styles in interface and implementation
    Description: In the following test case the module does a `:- use_module' in the interface section, but also `:- import_module' of the same module in the implementation section.

    % mmc -m int_impl_imports.err
    int_impl_imports.m:004: In module `int_impl_imports':
    int_impl_imports.m:004: warning: module `int_impl_imports_2' is imported in
    int_impl_imports.m:004: the interface, but it is not used in the interface.
    int_impl_imports.m:006: In definition of type `int_impl_imports.foo'/0:
    int_impl_imports.m:006: error: undefined type `int_impl_imports_2.bar'/0.
    int_impl_imports.m:006: (The module `int_impl_imports_2' has not been
    int_impl_imports.m:006: imported in the interface.)

    It worked up to at least rotd-2015-10-06 (which I happen to have installed).
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: int_impl_imports.m (175 bytes) 2015-12-17 18:00
    https://bugs.mercurylang.org/file_download.php?file_id=253&type=bug
    int_impl_imports_2.m (65 bytes) 2015-12-17 18:01
    https://bugs.mercurylang.org/file_download.php?file_id=254&type=bug
     
    Notes
    (0000872)
    zs   
    2015-12-17 23:38   
    The bug is caused by process_module_long_interfaces in modules.m.
    In int_impl_imports.m, the submodule int_impl_imports_2 is referenced twice:
    it is used in the interface, and imported in the implementation.
    grab_imported_modules process the import in the implementation first.
    This reads the _2 module's .int file, and (since the import is NOT
    in the interface) records that type bar is NOT available in the interface.
    So far, so good. But when grab_imported_modules calls process_module_long_interfaces for the use in the interface,
    it does not process the .int file again, since it has seen it before.

    Not processing the .int file again is both right and wrong. Right because
    it avoids double definitions, wrong because it leaves the incorrect permissions
    for the type bar.

    It is quote possible that earlier versions of Mercury got this right
    only by accident.
    (0000873)
    zs   
    2015-12-18 15:20   
    I am now sure that 14.01 got this right only by accident.
    It also processes int_impl_imports_2.int just once,
    for the import_module in the implementation. Its just that
    due to a bug, the effect of that import was to make the
    imported module available in ALL of int_impl_imports.m,
    not just its interface. I fixed that bug on nov 11 in
    commit 0821b301f25241bc706a325d4ae0cb9c18dd250b.
    The fix of THAT bug exposed THIS bug.

    I am now working on a fix.
    (0000875)
    zs   
    2016-01-14 15:46   
    fix committed 2016 jan 11.
    (0000876)
    wangp   
    2016-01-18 20:11   
    There is still a problem with the fix committed.

    In tests/valid_seq:

    % mmake int_impl_imports.depend
    % mmake int_impl_imports.int
    mmc --make-interface --grade asm_fast.gc --flags ../TESTS_FLAGS int_impl_imports
    int_impl_imports.m:004: In module `int_impl_imports':
    int_impl_imports.m:004: warning: module `int_impl_imports_2' is imported in
    int_impl_imports.m:004: the interface, but it is not used in the interface.
    int_impl_imports.m:006: In definition of type `int_impl_imports.foo'/0:
    int_impl_imports.m:006: error: undefined type `int_impl_imports_2.bar'/0.
    int_impl_imports.m:006: (The module `int_impl_imports_2' has not been
    int_impl_imports.m:006: imported in the interface.)
    `int_impl_imports.int' not written.
    (0001041)
    zs   
    2019-08-04 09:39   
    Fix committed 2019 aug 3.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    479 [mercury] Bug minor always 2019-07-07 06:31 2019-07-07 11:51
    Reporter: user411 Platform: Linux  
    Assigned To: OS: Debian  
    Priority: normal OS Version: 9  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE when compiling mercury code
    Description: mmc --make hello2
    Making Mercury/int3s/hello2.int3
    Making Mercury/ints/hello2.int
    Making Mercury/cs/hello2.c
    Making Mercury/os/hello2.o
    Making hello2
    In file included from /usr/include/stdlib.h:24:0,
                     from /usr/lib/mercury/inc/mercury_std.h:23,
                     from /usr/lib/mercury/inc/mercury_goto.h:13,
                     from /usr/lib/mercury/inc/mercury_init.h:84,
                     from Mercury/cs/hello2_init.c:16:
    /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
     # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
       ^~~~~~~
    In file included from /usr/include/stdlib.h:24:0,
                     from /usr/lib/mercury/inc/mercury_std.h:23,
                     from /usr/lib/mercury/inc/mercury_goto.h:13,
                     from /usr/lib/mercury/inc/mercury_init.h:84,
                     from Mercury/cs/hello2_init.c:16:
    /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
     # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
    ... error log truncated, see `hello2.err' for the complete log.
    Tags:
    Steps To Reproduce: Any mercury code gives me the same error.
    Additional Information:
    Attached Files:
     
    Notes
    (0001039)
    user411   
    2019-07-07 07:03   
    It seems that compiling mercury code with :

    --cflags -D_DEFAULT_SOURCE

    do not show the warning messages anymore.
    (0001040)
    wangp   
    2019-07-07 11:51   
    This was fixed in commit b70619d2f. Please use an ROTD or use your workaround.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    477 [mercury] Feature Request minor have not tried 2019-04-17 16:51 2019-04-20 14:58
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Infinite recursion through exception handlers
    Description: Code such as the following is may be worth a warning.

    :- pred reconstruct_route(logger::in, jscenario::in, jsolution::out)
        is cc_multi.

    reconstruct_route(Log, JScenario, JSolution) :-
        ( try []
            reconstruct_route(Log, JScenario, JSolution0)
        then
            JSolution = JSolution0
        catch_any Excp ->
            trace [io(!IO)] (
                Msg = "Exception during route reconstruction: " ++ string(Excp),
                slf4j.error(Log, Msg, !IO)
            ),
            JSolution = null_jsolution
        ).
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: bug477.m (871 bytes) 2019-04-18 00:37
    https://bugs.mercurylang.org/file_download.php?file_id=287&type=bug
     
    Notes
    (0001023)
    zs   
    2019-04-17 22:28   
    Can you please add a full test case?
    (0001029)
    juliensf   
    2019-04-18 00:37   
    There's a cut-down version that exhibits the behaviour attached. The current check carried out by simplify for recursive calls with the same input arguments doesn't look through higher-order calls since in general it cannot. I suspect it may be worth making a special case of try/2 (and its syntax sugared form) since wrapping an exception handler around the entry point to a Mercury program that is called from a foreign language application (which is the original setting for this) is not uncommon. Nor unfortunately is forgetting to use the correct predicate name inside the try goal which is what I did :-(
    (0001038)
    zs   
    2019-04-20 14:58   
    Feature implemented 2019 April 20.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    478 [mercury] Bug minor have not tried 2019-04-17 23:06 2019-04-18 05:27
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: ssdb directory does not build in csharp grade with commit 0d667a7
    Description: Compilation of the ssdb directory aborts in the csharp grade with commit 0d667a7 (i.e. what would have been rotd-2019-04-17).

    gmake[1]: Entering directory `/mnt/opturion/jfischer/mercury-4.git/ssdb'
    ../Mmake.common:469: warning: undefined variable `mer_ssdb.mhs'
    ../Mmake.common:472: warning: undefined variable `mer_ssdb.mhs'
    ../Mmake.common:478: warning: undefined variable `mer_ssdb.os'
    /tmp/mmake.og2WZB:930: warning: undefined variable `mer_ssdb.ms'
    /tmp/mmake.og2WZB:942: warning: undefined variable `mer_ssdb.ms'
    /tmp/mmake.og2WZB:1324: warning: overriding recipe for target `realclean_local'
    /tmp/mmake.og2WZB:978: warning: ignoring old recipe for target `realclean_local'
    { echo MCFLAGS += '--grade csharp --options-file ../Mercury.options --mercury-linkage shared --flags SSDB_FLAGS --allow-stubs --no-warn-stubs --use-subdirs '; echo MCFLAGS += ' '; echo CFLAGS += ' '; echo JAVACFLAGS += '-J"-Xmx1024m" '; echo CSCFLAGS += ' '; echo C2INITARGS += ' ../library/mer_std.init ../runtime/mer_rt.init '; echo MLLIBS += ' -lmer_std '; echo MLOBJS += ' '; echo LDFLAGS += ' '; echo LD_LIBFLAGS += ' '; echo EXTRA_LIBRARIES += ''; echo EXTRA_LIB_DIRS += ''; echo LIBGRADES = 'asm_fast.gc asm_fast.gc.debug.stseg asm_fast.gc.debug.trseg.stseg asm_fast.gc.decldebug.stseg asm_fast.gc.memprof asm_fast.gc.prof asm_fast.gc.profdeep.stseg asm_fast.gc.trseg asm_fast.par.gc.stseg csharp hlc.gc hlc.gc.trseg hlc.par.gc java '; echo INSTALL_PREFIX = '/usr/local/mercury-DEV'; echo LINKAGE = 'shared'; echo MERCURY_LINKAGE = 'shared'; } | /mnt/opturion/mercury/rotd-2019-04-17/bin/mmc --make --options-file - libmer_ssdb
    Making Mercury/int3s/mer_ssdb.int3
    Making Mercury/int3s/ssdb.int3
    ** Error reading file `mdb.browse.m' to generate dependencies.
    ** Module `mdb.browse' is imported or included by module `ssdb'.
    mercury_compile: cannot find source for module `mdb.browse' in directories `.'
    gmake[1]: *** [libmer_ssdb] Error 1
    gmake[1]: Leaving directory `/mnt/opturion/jfischer/mercury-4.git/ssdb'
    gmake: *** [ssdb] Error 2
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001024)
    juliensf   
    2019-04-17 23:20   
    Ditto for the Java grade. The issue is not present in rotd-2019-04-16.
    (0001025)
    zs   
    2019-04-17 23:23   
    The problem was probably triggered by commit df47de186bf59c8c97010455c29c7ad765bfa3da,
    but that was on March 31. So two things that may be
    worth looking into are (a) why hasn't been a problem
    in the last two weeks, and (b) why isn't this a problem
    in other grades?
    (0001026)
    zs   
    2019-04-17 23:25   
    It seems our notes crossed paths. If the problem was not present
    in rotd-2019-04-16, then the March 31 commit could not have been
    the cause.

    What was the last commit present in rotd-2019-04-16?
    (0001027)
    juliensf   
    2019-04-17 23:35   
    (Last edited: 2019-04-17 23:35)
    rotd-2019-04-16 was commit b70bdb2d9557ccc3f62abbc291a25dbc2f8dfc23.
    (FYI, commit ids for all rotds are listed on the download page.)

    The obvious point of difference between the csharp / java grades and the others is that the former
    are compiled using --use-mmc-make.
    (0001028)
    zs   
    2019-04-17 23:54   
    There has been only one commit since, and that was a refactoring that should have had
    only one change that could cause a change in behavior: the addition of this sanity test
    in modules.m:

    expect(unify(ModuleName, ParseTreeModuleName), ...)

    Does the problem still occur if this is taken out? I can't check since my machine
    does not have C#. (I will get a new laptop soon, which will get C# and Java.)
    (0001030)
    juliensf   
    2019-04-18 00:55   
    Yes, the problem still occurs if that check is taken out.
    (0001031)
    juliensf   
    2019-04-18 01:00   
    Annoyingly I can't check if the same issue occurs with --use-mmc-make and the C grades since
    we have some problem there with the .mh files in the browser directory not being created, specifically
    when we got to compile the trace directory:

        ./scripts/mgnuc --grade asm_fast.gc --c-debug --no-ansi -- -I. -IMercury/mihs/. -c mercury_trace_browse.c -o mercury_trace_browse.o
    mercury_trace_browse.c:28:25: fatal error: mdb.browse.mh: No such file or directory
    (0001032)
    juliensf   
    2019-04-18 01:13   
    Actually the issue with the trace directory is likely a manifestation of the same problem since building with --use-mmc-make works fine in asm_fast.gc with rotd-2019-04-16. (The C# and Java grades skip over the trace directory which is why the problem shows up in different places.)
    (0001033)
    zs   
    2019-04-18 01:16   
    I just found and fixed a cut-and-paste bug. I think it should fix bug 478.
    Please try it out.

    By the way, testing proposed bug fixes for bugs with --use-mmc-make have
    always been harder for me than testing for fixes for other kinds of bugs.
    For other bugs, I build the maybe-fixed executable in a workspace, and use
    a wrapper around lmc to try it out. But the lmc script sets up the environment
    only for compilations that do NOT use --use-mmc-make, so this does not
    work for --use-mmc-make bugs.

    Since I don't use --use-mmc-make frequently, this is rarely a problem for me.
    Since you use the Java and C# grades reasonably regularly, I expect it would be
    more of a problem for you. How do you handle it?
    (0001034)
    juliensf   
    2019-04-18 01:43   
    I've just restarted the ROTD build, so we'll know in a bit.

    Generally, if I'm working on stuff related to the C# and Java grades I just install the whole system
    and and work with that. (Once it is installed you can do an install from within the compiler directory if,
    for example, the work is related to the compiler.) That's obviously not a great solution and I suspect it's only bearable because I have access to machines with lots of cores and lots of memory, so parallel builds at -j8 or more are feasible.
    (0001035)
    zs   
    2019-04-18 01:48   
    That is what I do as well.

    The reason why I don't find it satisfactory is not the CPU workload,
    but the context switch overhead. I have to switch to doing something else
    while waiting for the install, and switch back later when it is complete.
    This wipes out details held in my brain's short term memory, requiring
    them to the rebuilt later (and maybe again and again).

    I was hoping you, or someone else who works with --use-mmc-make more than me,
    would have found it less work in the long term just to teach lmc about --use-mmc-make.
    (0001036)
    juliensf   
    2019-04-18 02:55   
    The fix worked.
    (0001037)
    zs   
    2019-04-18 05:27   
    Fix committed




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    476 [mercury] Bug minor have not tried 2019-04-07 15:20 2019-04-08 03:16
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Compiler aborts during typeclass check
    Description: With the attached test case, rotd-2019-02-23 aborts with the following error:

    Uncaught Mercury exception:
    Software Error: check_hlds.check_typeclass: predicate `check_hlds.check_typeclass.check_instance_pred'/14: Unexpected: no constraint on class method

    rather than printing a proper error message.
    Tags:
    Steps To Reproduce: Compile with: mmc -C
    Additional Information:
    Attached Files: bug476.m (1,694 bytes) 2019-04-07 15:20
    https://bugs.mercurylang.org/file_download.php?file_id=286&type=bug
     
    Notes
    (0001022)
    zs   
    2019-04-08 03:16   
    Fix committed 2019 april 8.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    475 [mercury] Feature Request minor N/A 2019-02-04 01:14 2019-02-04 01:14
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: flatten maybe output args across calls
    Description: Many predicates have an output argument which is a maybe(T): they either
    return no, or they return yes(value). The caller tests whether the result is yes(X).
    If it is, it picks up X = value, and the heap cell containing the yes wrapper
    is never referred to again.

    A compiler optimization should look for predicates where every call is like this,
    and transform them so that the callee returns TWO results: a boolean which
    is always meaningful, and a value of type T, which is meaningful only if the bool
    is yes.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    473 [mercury] Bug minor always 2018-11-17 22:37 2018-11-19 11:46
    Reporter: pbone Platform:  
    Assigned To: wangp OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: JS sources should be included for minified files in scripts/
    Description: There are some minified JavaScript files in scripts/ I noticed that the debian packaging system complained that their non-minified sources are not also included. Ideally those should be included and the minified versions build from them.

    I don't know how you actually go about doing that, just noting that Debian stuff complains and a readable version of the source orght to be provided.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001019)
    zs   
    2018-11-17 22:48   
    I presume you are talking about jstree.min.js and jquery.slim.min.js.
    They were added in the same commit in 2017, and not touched since.
    The log message says they are from jstree.com and jquery.com respectively.
    See whether those sites contain their nonminimized versions.
    (0001020)
    wangp   
    2018-11-18 10:35   
    There's no need to build the minified sources from the non-minified sources, just using the code in the original form is enough. I'll take care of it.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    474 [mercury] Bug major always 2018-11-18 23:01 2018-11-18 23:23
    Reporter: pbone Platform: i386  
    Assigned To: OS: Linux  
    Priority: normal OS Version: Debian 9  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Mercury cannot be installed, compiler crashes
    Description: The mercury compiler crashes when building the first libgrade:

    root@oxygen:/tmp/mercury-rotd-20181114# cat install_grade_dir.asm_fast.gc.decldebug.stseg/library/mer_std.dep_err
    Uncaught Mercury exception:
    Software Error: map.lookup: key not found
            Key Type: libs.options.option
            Key Value: profile_time
            Value Type: getopt_io.option_data
    Stack dump not available in this grade.

    It crashes when invoked with no arguments.

    root@oxygen:/tmp/mercury-rotd-20181114# ./compiler/mercury_compile
    Uncaught Mercury exception:
    Software Error: map.lookup: key not found
            Key Type: libs.options.option
            Key Value: profile_time
            Value Type: getopt_io.option_data
    Stack dump not available in this grade.

    I don't think this is a configuration problem because it works on amd64, this is just happening on i386 (32-bit). Maybe something to do with argument packing on 32bit systems when those arguments are used as map keys?
    Tags:
    Steps To Reproduce: I found this while building Mercury to make Debian packages. My scripts install a minimal system in /tmp/bootstrap and then clean the build directory and use the first version to build a more complete version, it seems that the second generation compiler is crashing.
    Additional Information:
    Attached Files:
     
    Notes
    (0001021)
    juliensf   
    2018-11-18 23:23   
    It's not likely to be argument packing since that's currently not enabled by default.

    - What version of GCC are you using?
    - Is the bootstrap compiler the hlc.gc.pregen one? If not, what grade is it compiled in?

    (Also, there are issues with the asm_fast grades on x86 systems at the moment, see 0000453.)




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    472 [mercury] Bug minor have not tried 2018-11-09 23:24 2018-11-17 22:40
    Reporter: pbone Platform: x86_64  
    Assigned To: zs OS: Linux  
    Priority: normal OS Version: 4.something  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Touching a .m file does not rebuild other modules that may depend on C foreign code that is opt-exported from that module
    Description: Within Plasma https://github.com/PlasmaLang/plasma I have a C header runtime/pz_format.h, I have some Makefile rules to touch src/pz.m and src/pz.bytecode.m if it is updated, so that any foreign code is rebuilt. However if I change an enum in runtime/pz_format.h causing these .m files to be touched and rebuilt the tests "make test" can fail.

    I think what might be happening is that because the Mercury code didn't actually change, mmc does not update the pz.mh file and therefore other .c files generated from output are not rebuilt to object code.

    I can work-around this by touching the .mh files as well, I still need to touch the .m file so that mmc checks the .mh file.
    Tags:
    Steps To Reproduce:
    Additional Information: Mercury 14.01.1
    Attached Files:
     
    Notes
    (0001016)
    pbone   
    2018-11-09 23:38   
    Here's the workaround in Plasma's Makefile:

    https://github.com/PlasmaLang/plasma/commit/c5c1fb9a55a3ba773308e228cae93e74a837f1e6
    (0001017)
    zs   
    2018-11-09 23:41   
    This is working as designed. Mmc does not generate .mh files directly;
    it generated .mh.tmp files, and then invokes mercury_update_interface
    to copy that across to the .mh file IF AND ONLY IF the new contents
    are different from the old contents. This saves a huge number of
    unnecessary recompilations. We do NOT want to undo this optimization
    just because your Makefile does not express all the dependencies.

    I think you need to change your Makefile to express the dependency
    of all the modules that need pz_format.h on pz_format.h directly,
    not through pz.m.
    (0001018)
    pbone   
    2018-11-17 22:40   
    I'll double check but I think I've only put this dependency all the .m files that that have a C FFI #include for pz_format.h. If I could also tell Mercury (easily?) that pz.write.o depends on pz_format.h because it reads pz.mh then that seems like the best option. I'll double check.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    458 [mercury] Feature Request minor N/A 2018-05-03 07:24 2018-10-03 09:23
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: optimize unify and compare for packed arguments
    Description: At the moment, when unifying or comparing the arguments of two functors,
    we extract each argument from each functor and unify/compare the corresponding
    arguments individually.

    If two or more arguments of a functor are packed together into a single word,
    we could test whether they are *all* equal by testing whether the words are equal. (We always set all the unused bits to zeroes.)

    For comparison, the situation is trickier, but there is still room for optimization.

    First, we would need to change our allocation strategy. Our current strategy
    of putting the first packed argument into the least significant bits and the
    following arguments into more and more significant bits is exactly wrong
    for comparing the packed arguments all at once: we would need to put
    an earlier packed argument into more significant bits than a later argument
    packed into the same word.

    Second, even then we could compare a sequence of arguments packed
    into a word by comparing the full word only if all the packed arguments
    compare as unsigned values. If any of them are of type int{8,16,32}, then
    those would have to compared separately. However, any contiguous subsequence
    of unsigned arguments could and should be compared together.

    The most complex part of this would be devising the right HLDS representation
    of the operations that compare more than one argument at a time. Maybe we could
    generate foreign proc goals for them.

    Also note that this feature request somewhat modifies Mantis 0000446;
    we should NOT fetch the arguments that are packed together into the same word
    separately.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001015)
    zs   
    2018-10-03 09:23   
    The diff implementing this feature request was committed 2018 oct 3.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    471 [mercury] Bug minor always 2018-09-22 14:01 2018-09-22 14:01
    Reporter: wangp Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: float rounding
    Description: float.round_to_int and math.round are implemented with
        floor(X + 0.5)

    There are problems with very large floats that behave as integers, e.g.
        round(8333333333388609.0) -> 8333333333388610.0

    or when the fractional part is the predecessor of 0.5, e.g.
        round_to_int(0.49999999999999994) -> 1

    See http://blog.frama-c.com/index.php?post/2013/05/02/nearbyintf1

    I think no real programs would intentionally depend on the current behaviour so we should be free to fix the implementation.

    ---

    BTW {ceiling,floor,round,truncate}_to_int should specify the behaviour if the value would overflow the result type [or if the input is NaN]. But that's only one aspect of overflow handling that we don't do yet.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    408 [mercury] Feature Request minor always 2016-04-18 11:00 2018-09-22 12:19
    Reporter: wangp Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: make_temp and make_temp_directory should not throw exceptions
    Description: We should add an alternative to io.make_temp which returns a success code instead of throwing an exception.

    io.make_temp_directory is still new (as of now) so we can still change it to return a success code without maintaining backwards compatibility.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000885)
    pbone   
    2016-04-18 11:20   
    I agree with this change and I'm happy to do it since I'm working on this code anyway.
    (0000978)
    pbone   
    2018-03-13 14:38   
    Unassigned things from me.
    (0001014)
    wangp   
    2018-09-22 12:19   
    make_temp is deprecated and its replacements don't throw exceptions.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    435 [mercury] Bug minor have not tried 2017-03-29 10:00 2018-09-22 12:16
    Reporter: juliensf Platform: x86_64-pc-linux-gnu  
    Assigned To: wangp OS: Alpine Linux  
    Priority: normal OS Version: 3.5  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Old workaround in runtime causes compilation warnings
    Description: The #include of <sys/signal.h> in runtime/mercury_memory_handlers.c and runtime/mercury_memory_zones.c causes compilation warnings with musl libc, namely:

        warning redirecting incorrect #include <sys/signal.h> to <signal.h>

    (glibc does a similar redirection minus the warning.)

    The #include of sys/signal.h is a workaround for problems with FreeBSD around 2001.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001013)
    wangp   
    2018-09-22 12:16   
    Fixed by commit 58345256f




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    469 [mercury] Bug major always 2018-09-16 12:25 2018-09-19 11:19
    Reporter: taigua Platform:  
    Assigned To: wangp OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: mercury-srcdist-rotd-2018-09-11 compile failed on MinGW64 (Win10 64bit)
    Description: Enviroment:
      Windows 10 64bit
      Msys2
      Mingw64: GCC 8.2.0

    Compile failed log:
    io.m: In function 'mercury__io__do_make_temp_8_p_0':
    io.m:16798:9: error: 'strncat' output may be truncated copying 6 bytes from a string of length 255 [-Werror=stringop-truncation]
    io.m: In function 'mercury__io__make_temp_file_6_p_0':
    io.m:24403:9: error: 'strncat' output may be truncated copying 6 bytes from a string of length 255 [-Werror=stringop-truncation]
    Tags:
    Steps To Reproduce: Compile steps:
    $ ./configure --prefix=D:/mercury --host=x86_64-w64-mingw32
    $ make PARALLEL=-j4

    Then it complains:
    io.m: In function 'mercury__io__do_make_temp_8_p_0':
    io.m:16798:9: error: 'strncat' output may be truncated copying 6 bytes from a string of length 255 [-Werror=stringop-truncation]
    io.m: In function 'mercury__io__make_temp_file_6_p_0':
    io.m:24403:9: error: 'strncat' output may be truncated copying 6 bytes from a string of length 255 [-Werror=stringop-truncation]
    Additional Information:
    Attached Files:
     
    Notes
    (0001012)
    wangp   
    2018-09-19 11:19   
    Should be fixed in commit 90c29e772




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    470 [mercury] Bug major always 2018-09-16 15:07 2018-09-16 17:18
    Reporter: taigua Platform:  
    Assigned To: wangp OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: mercury-srcdist-rotd-2018-09-11 compile failed on Linux (Ubuntu and Archlinux)
    Description: Enviroment: Ubuntu/Archlinux 64 bit
    GCC Version: gcc 5.4.0/ gcc 8.2.0

    Compile failed log:

    In file included from mercury_deconstruct.c:29:0:
    mercury_ml_expand_body.h: In function ‘MR_expand_functor_args’:
    mercury_ml_expand_body.h:719:28: error: ‘MR_ALLOC_ID’ undeclared (first use in this function)
    mercury_ml_expand_body.h:719:28: note: each undeclared identifier is reported only once for each function it appears in
    In file included from mercury_deconstruct.c:40:0:
    mercury_ml_expand_body.h: In function ‘MR_expand_functor_args_limit’:
    mercury_ml_expand_body.h:719:28: error: ‘MR_ALLOC_ID’ undeclared (first use in this function)
    In file included from mercury_deconstruct.c:58:0:
    mercury_ml_expand_body.h: In function ‘MR_expand_args_only’:
    mercury_ml_expand_body.h:719:28: error: ‘MR_ALLOC_ID’ undeclared (first use in this function)
    /tmp/mmake.0B6hj1:1495: recipe for target 'mercury_deconstruct.o' failed
    Tags:
    Steps To Reproduce: Compile steps:
    $ ./configure --prefix=~/mercury
    $ make PARALLEL=-j4 # This step success
    $ make PARALLEL=-j4 install

    Then it complains:
    In file included from mercury_deconstruct.c:29:0:
    mercury_ml_expand_body.h: In function ‘MR_expand_functor_args’:
    mercury_ml_expand_body.h:719:28: error: ‘MR_ALLOC_ID’ undeclared (first use in this function)
    mercury_ml_expand_body.h:719:28: note: each undeclared identifier is reported only once for each function it appears in
    In file included from mercury_deconstruct.c:40:0:
    mercury_ml_expand_body.h: In function ‘MR_expand_functor_args_limit’:
    mercury_ml_expand_body.h:719:28: error: ‘MR_ALLOC_ID’ undeclared (first use in this function)
    In file included from mercury_deconstruct.c:58:0:
    mercury_ml_expand_body.h: In function ‘MR_expand_args_only’:
    mercury_ml_expand_body.h:719:28: error: ‘MR_ALLOC_ID’ undeclared (first use in this function)
    /tmp/mmake.0B6hj1:1495: recipe for target 'mercury_deconstruct.o' failed
    Additional Information:
    Attached Files:
     
    Notes
    (0001011)
    wangp   
    2018-09-16 17:18   
    Thanks for the report. The problem is probably only with low-level C memprof grades, fixed now in commit bb35de8b3.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    467 [mercury] Feature Request minor always 2018-08-18 16:15 2018-09-07 10:23
    Reporter: wangp Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: compiling with -Wuninitialized or -Wmaybe-uninitialized
    Description: The high-level C backend generates code like this:

        if (succeeded)
          U_4 = UPrime_5;
        else
        {
          mercury__require__error_1_p_0((MR_String) "uint.det_from_int: cannot convert int to uint");
        }
        return U_4;

    gcc does not know that the function call will not return so it MAY warn that U_4 is never initialised. mgnuc just happens to suppress the warnings on x86 and x86-64 for an unrelated reason:

    case "$FULLARCH" in
        i*86-*|x86_64*)
            # The use of stack_pointer in the ASM_JUMP macro defined in
            # runtime/mercury_goto.h causes lots of warnings about using possibly
            # uninitialized variables; there's no easy way to suppress them except
            # by disabling the warning.
            case "$COMPILER" in
                gcc)
                    CHECK_OPTS="$CHECK_OPTS -Wno-uninitialized"
                    ;;
            esac
            ;;

    Ideally we would ONLY disable uninitialized variable warnings in the low-level C grades where it is unavoidable.

    In high-level C grades, I think we should declare the C function corresponding to an `erroneous' Mercury procedure as not returning, e.g. using the macro MR_NO_RETURN or similar. MR_NO_RETURN has implementations for gcc/clang/msvc. C11 also adds _Noreturn.

    Alternatively, we could add assert(0) after calls to functions that will not return, but presumably that would increase code size.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001007)
    juliensf   
    2018-08-19 15:21   
    No objections from me to using MR_NO_RETURN on erroneous procedures. (We probably can't rely on C11 just yet, although MR_NO_RETURN could be updated to use _Noreturn if the C implementation is C11.)
    (0001010)
    zs   
    2018-09-07 10:23   
    I started work on adding a new function flag that will tell mlds_to_c_func.m
    whether it should emit MR_NO_RETURN for a function being declared or defined.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    468 [mercury] Bug minor always 2018-08-19 13:05 2018-09-03 12:29
    Reporter: wangp Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: free argument packed with other argument uses uninitialised variable
    Description: In high-level C grades, the goal from packed_arg_partial_inst.m

            X = struct(42, _, yes, orange, _, _, _),

    compiles to

            {
              MR_Word TypeCtorInfo_13_13;
              MR_Integer Var_10;
              MR_Word Var_11;
              MR_Word Var_12;
              MR_Word Var_6;
              MR_Word Var_7;
              MR_Word Var_8;
              MR_String Var_9;

              Var_10 = (MR_Integer) 42;
              Var_11 = (MR_Integer) 1;
              Var_12 = (MR_Integer) 2;
              {
                MR_Word base;
                base = (MR_Word) MR_new_object(MR_Word, ((MR_Integer) 3 * sizeof(MR_Word)), NULL, NULL);
                (env_ptr)->packed_arg_partial_inst__foo_2_p_0_env_0__X_5 = base;
                MR_hl_field(MR_mktag(0), base, 0) = ((MR_Box) (Var_10));
                MR_hl_field(MR_mktag(0), base, 1) = (MR_Box)
            (((((MR_Unsigned) (Var_6) << (MR_Integer) 6)) |
             (((((MR_Unsigned) (Var_11) << (MR_Integer) 5)) |
             (((((MR_Unsigned) (Var_12) << (MR_Integer) 3)) |
             (((((MR_Unsigned) (Var_7) << (MR_Integer) 2)) |
             (MR_Unsigned) (Var_8)))))))));
                MR_hl_field(MR_mktag(0), base, 2) = NULL;
              }

    where Var_6, Var_7, Var_8 are used without being initialised.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001008)
    zs   
    2018-08-19 15:24   
    I am working on a change that involves that code anyway.
    (0001009)
    zs   
    2018-09-03 12:29   
    Fix committed 2018 sep 3.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    464 [mercury] Bug minor N/A 2018-07-25 15:12 2018-08-19 17:02
    Reporter: wangp Platform:  
    Assigned To: wangp OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: MR_fatal_error should not read errno
    Description: MR_fatal_error prints "Error = %d" if errno happens to be non-zero when it is called, leading to potential confusion if the value in errno has nothing to do with the reason MR_fatal_error was called, and spurious test failures.

    There are too many calls to MR_fatal_error for me to go through right now. My guess is that the majority of calls to MR_fatal_error do not follow a function call that returned an error and set errno.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001003)
    zs   
    2018-07-27 14:07   
    The obvious solution is to add an enum arg to MR_fatal_error, with two
    values: PRINT_ERRNO_MSG and DONT_PRINT_ERRNO_MSG, and fix
    all the C compiler errors that result by specifying one or the other
    at all the complained-about call sites.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    460 [mercury] Bug minor random 2018-05-17 11:04 2018-08-09 22:07
    Reporter: wangp Platform:  
    Assigned To: wangp OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: failure of hard_coded/thread_barrier_test in asm_fast.par.gc
    Description: Got a seemingly hard to reproduce failure of this thread_barrier_test in asm_fast.par.gc yesterday.

    Comparing thread_barrier_test.out with thread_barrier_test.exp*,
        results in thread_barrier_test.res
    ** thread_barrier_test.out did not match the expected output
    ** (closest match was thread_barrier_test.res1)
    --- thread_barrier_test.exp 2015-10-19 16:49:08.017755334 +1100
    +++ thread_barrier_test.out 2018-05-16 18:04:31.775872403 +1000
    @@ -41,7 +41,7 @@
     Messages from thread 1:
         thread starting
         fib(10) = 89
    - waiting: before release
    + waiting: after release
         done waiting: after release
     Messages from thread 2:
         thread starting
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    426 [mercury] Bug minor always 2016-10-21 15:47 2018-08-09 22:05
    Reporter: juliensf Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Tabling broken on 32-bit Cygwin
    Description: Pretty much every tabling test case and the compiler itself (the CTGC code uses pragma memo)
    abort with an error about having detected infinite recursion. In the tabling transformation, det procedures are transformed as follows:

        p(A, B) :-
           TO = <table pointer for p/2>,
           impure table_lookup_insert(T0, A, T),
           impure table_loop_setup(T, Status),
           (
               Status = loop_active,
               error("detected infinite recursion in ...")
          ;
               Status = loop_inactive,
               ...
          )

    On Cygwin the variable Status gets set to a rubbish value at some points. It actually ends up matching the default case of the C switch we generate for the above Mercury switch but then falls through to the infinite recursion case. (Enabling assertions would cause it to abort.) I haven't tracked down why this is occurring although it may have something to do with the fact that on Windows sizeof(int) == sizeof(long). (Is the tabling code making assumption that sizeof(long) > sizeof(int) somewhere?)




         
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: fast_loose.txt.gz (338,918 bytes) 2018-08-09 22:05
    https://bugs.mercurylang.org/file_download.php?file_id=285&type=bug
     
    Notes
    (0001006)
    wangp   
    2018-08-09 22:05   
    Probably the same issue with the fast_loose.m test case on 32-bit Linux, but strangely it's only reproducible in .par grades (at least hlc.par.gc and reg.par.gc).

    I've attached a debug log with MR_TABLE_DEBUG and MERCURY_OPTIONS=-dT enabled if it would help. The last lines show:

    TABLE 0x804f498: gen f036a279 type 0x804edf8 => 0xf0149508
    status of memo table 0xf0149508: -262636112 (f0587db0)

    where f0587db0 is an address seen earlier:

    allocated answer block 0xf0149508 -> 0xf0587db0, 1 words
    saving to answer block: 0xf0587db0, slot 0 = 6351




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    281 [mercury] Bug minor always 2013-05-06 13:15 2018-08-08 13:12
    Reporter: juliensf Platform: x86_64  
    Assigned To: OS: Mac OS X  
    Priority: normal OS Version: 10.8.3  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Tabling test case failures
    Description: The following tests cases fail in the grade none.gc.decldebug with 13.05-beta-2013-05-06.

    * tests/tabling/specified

    A diff of the expected and actual outputs:

    aplp_vs_vplp: tabling works
     apli_vs_vpli: tabling works
    -vvll_vs_vpll: tabling works
    +vvll_vs_vpll: tabling does not appear to work

    * tests/tabling/specified_stats

    The latter appeared to go into a loop and not terminate.

    (This was all at the default optimisation level.)
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0001004)
    wangp   
    2018-08-08 12:32   
    In the final set of trials, vp_ll_fib, the "faster" predicate vp_ll_fib is not that much faster (consistently) over the "slower" predicate vv_ll_fib for the heuristics in perform_trials.

    These parameters just happen to work on my machine:

    perform_trials(vvll_vs_vpll, [7, 3, 0, 4], 7304, 30, 0, 0, !IO).

    The faster predicate manages to run twice as fast as the slower predicate for ten trials in a row, breaking out of the loop. I wouldn't count on it being repeatable on different machines.

    NumTrials0: 0, Time: 330, MTime: 100, IntN: 7304, NumDouble: 1
    NumTrials0: 1, Time: 230, MTime: 100, IntN: 7334, NumDouble: 2
    NumTrials0: 2, Time: 250, MTime: 100, IntN: 7364, NumDouble: 3
    NumTrials0: 3, Time: 260, MTime: 100, IntN: 7394, NumDouble: 4
    NumTrials0: 4, Time: 240, MTime: 110, IntN: 7424, NumDouble: 5
    NumTrials0: 5, Time: 250, MTime: 100, IntN: 7454, NumDouble: 6
    NumTrials0: 6, Time: 240, MTime: 100, IntN: 7484, NumDouble: 7
    NumTrials0: 7, Time: 250, MTime: 100, IntN: 7514, NumDouble: 8
    NumTrials0: 8, Time: 250, MTime: 100, IntN: 7544, NumDouble: 9
    vvll_vs_vpll: tabling works


    I think the NumDoubles threshold in perform_trials can be relaxed. Also, perform_trials should give up more easily. I guess the 10 second time limit on a single trial will probably not be reached on a modern machine, and 1000 potential trials makes the test take took long.
    (0001005)
    wangp   
    2018-08-08 13:12   
    Should be fixed by commits bc0e8e812 and 1a5df94bc




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    466 [mercury] Bug minor have not tried 2018-07-29 04:50 2018-07-29 04:50
    Reporter: juliensf Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Test failures in asm_fast.par.gc.stseg
    Description: Several tests are failing (due to code generator aborts) in the grade asm_fast.par.gc.stseg

       tests/par_conj/par_dep_7
       tests/par_conj/dep_par_21
       tests/par_conj/dep_par_24
       tests/par_conj/dep_par_24b

    all abort with:

    Uncaught Mercury exception:
    Software Error: predicate `ll_backend.var_locn.actually_place_var'/7: Unexpected: placing nondummy var which has no state

      tests/par_conj/consume_in_some_branches
      tests/par_conj/consume_wait

    abort with:

    Uncaught Mercury exception:
    Software Error: predicate `ll_backend.var_locn.clobber_lval_in_var_state_map'/6: Unexpected: empty state

       tests/par_conj/consume_in_some_branches_and_after

    aborts with:

    Uncaught Mercury exception:
    Software Error: predicate `ll_backend.var_locn.var_locn_check_and_set_magic_var_location'/4: Unexpected: in use
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    465 [mercury] Bug trivial always 2018-07-27 10:05 2018-07-27 10:05
    Reporter: yuan Platform: MS-VisualC2010  
    Assigned To: OS: Windows  
    Priority: normal OS Version: 10  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: link lib error when compiling hello.m
    Description: C:\Users\Yun\Downloads\hello>mmc.bat -v hello
    % Parsing module `hello' and imported interfaces...
    % Module qualifying items...
    % done.
    % Expanding equivalence types...
    % done.
    % Converting parse tree to hlds...
    % done.
    % Writing auto-dependency file `hello.d'... done.
    % Post-processing type definitions...
    % Checking typeclasses...
    % Checking instance declaration types...
    % Checking typeclass instances...
    % Checking for cyclic classes...
    % Checking for missing concrete instances...
    % Checking functional dependencies on instances...
    % Checking typeclass constraints...
    % Checking that insts have matching types... done.
    % Type-checking...
    % Type-checking clauses...
    % Program is type-correct.
    % Purity-checking clauses...
    % Program is purity-correct.
    % Substituting implementation-defined literals...
    % done.
    % Transforming polymorphic unifications... done.
    % Mode-checking clauses...
    % Program is mode-correct.
    % Detecting switches...
    % done.
    % Detecting common deconstructions...
    % done.
    % Doing determinism checking...
    % done.
    % Program is determinism-correct.
    % Checking for backtracking over unique modes...
    % Program is unique-mode-correct.
    % Transforming try goals...
    % done.
    % Simplifying goals...
    % done.
    % Transforming tabled predicates... done.
    % Transforming lambda expressions... done.
    % Transforming stm expressions... done.
    % Fully expanding equivalence types... done.
    % Generating type_ctor_info structures... done.
    % Specializing higher-order and polymorphic predicates...
    % done.
    % Maybe apply source to source debugging transformation ...
    % done.
    % Inlining...
    % done.
    % Eliminating dead procedures...
    % done.
    % Updating interface:
    % hello.mh' has not changed.
    % Simplifying goals...
    % done.
    % Marking static ground terms...
    % done.
    % Mapping args to regs... done.
    % Converting HLDS to MLDS...
    % done.
    % Generating RTTI data...
    % done.
    % Detecting tail calls...
    % done.
    % Optimizing MLDS...
    % done.
    % Flattening nested functions...
    % done.
    % Optimizing MLDS again...
    % done.
    % Converting MLDS to C...
    % Writing to file `hello.c'...
    % done.
    % Writing to file `hello.mih.tmp'...
    % done.
    % Updating interface:
    % hello.mih' has not changed.
    % Finished converting MLDS to C.
    % Compiling `hello.c':
    % Invoking system command `cl -IC:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc\inc -IC:\mercury-14.01-vs2013\lib\mercury\conf -IC:\mercury-14.01-vs2013\lib\mercury\inc -DMR_HIGHLEVEL_CODE -DMR_CONSERVATIVE_GC -DMR_BOEHM_GC -DMR_TAGBITS=2 -nologo -c hello.c -Fohello.obj'...
    % done.
    hello.c
    % Touching `hello.c_date'... done.
    % Creating initialization file...
    % Invoking system command `mkinit -g hlc.gc -o hello_init.c.tmp -I C:\mercury-14.01-vs2013\lib\mercury\modules\hlc.gc -f C:\Users\Yun\AppData\Local\Temp\mtmp002.308'...
    % done.
    % Updating interface:
    % hello_init.c' has not changed.
    % Compiling initialization file...
    % Compiling `hello_init.c':
    % Invoking system command `cl -IC:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc\inc -IC:\mercury-14.01-vs2013\lib\mercury\conf -IC:\mercury-14.01-vs2013\lib\mercury\inc -DMR_HIGHLEVEL_CODE -DMR_CONSERVATIVE_GC -DMR_BOEHM_GC -DMR_TAGBITS=2 -nologo -c hello_init.c -Fohello_init.obj'...
    % done.
    hello_init.c
    % Linking...
    % Invoking system command `lib @C:\Users\Yun\AppData\Local\Temp\mtmp002.310'...
    % done.
    % Invoking system command `echo C:\Users\Yun\AppData\Local\Temp\mtmp002.30E.lib'...
    % done.
    C:\Users\Yun\AppData\Local\Temp\mtmp002.30E.lib
    % Invoking system command `cl -Fehello.exe C:\Users\Yun\AppData\Local\Temp\mtmp002.30E.lib -link -LIBPATH:C:\mercury-14.01-vs2013\lib\mercury\lib -LIBPATH:C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc -nologo -subsystem:console -machine:x86 -entry:wmainCRTStartup -defaultlib:libcmt C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc\libmer_std.lib C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc\libmer_rt.lib C:\mercury-14.01-vs2013\lib\mercury\lib\libgc.lib '...


    C:\Users\Yun\Downloads\hello>cl -Fehello.exe C:\Users\Yun\AppData\Local\Temp\mtmp002.30E.lib -link -LIBPATH:C:\mercury-14.01-vs2013\lib\mercury\lib -LIBPATH:C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc -nologo -subsystem:console -machine:x86 -entry:wmainCRTStartup -defaultlib:libcmt C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc\libmer_std.lib C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc\libmer_rt.lib C:\mercury-14.01-vs2013\lib\mercury\lib\libgc.lib
    LINK : warning LNK4001: Object file not specified; library used
    libmer_std.lib(io.obj) : error LNK2019: Unresolved external symbol ___report_rangecheckfailure, this symbol is referenced in function _mercury__io__read_char_code_2_4_p_0
    libmer_std.lib(parsing_utils.obj) : error LNK2001: Unresolved external symbol ___report_rangecheckfailure
    libmer_std.lib(string.obj) : error LNK2001: Unresolved external symbol ___report_rangecheckfailure
    libgc.lib(dbg_mlc.obj) : error LNK2001: Unresolved external symbol ___report_rangecheckfailure
    libmer_rt.lib(mercury_wrapper.obj) : error LNK2019: Unresolved external symbol _fesetround, this symbol is referenced in function _MR_process_options
    libmer_rt.lib(mercury_float.obj) : error LNK2019: Unresolved external symbol __dclass, the symbol is referenced in function _MR_is_nan
    hello.exe : fatal error LNK1120: 3 external commands that cannot be resolved
    Tags:
    Steps To Reproduce: 1. create a hello.m in the tutorial https://www.mercurylang.org/documentation/papers/book.pdf
    2. run mmc.bat --make hello -v in cmd
    3. run cl -Fehello.exe C:\Users\Yun\AppData\Local\Temp\mtmp002.30E.lib -link -LIBPATH:C:\mercury-14.01-vs2013\lib\mercury\lib -LIBPATH:C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc -nologo -subsystem:console -machine:x86 -entry:wmainCRTStartup -defaultlib:libcmt C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc\libmer_std.lib C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc\libmer_rt.lib C:\mercury-14.01-vs2013\lib\mercury\lib\libgc.lib in cmd
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    463 [mercury] Bug minor always 2018-07-17 19:54 2018-07-20 16:51
    Reporter: keri Platform:  
    Assigned To: juliensf OS: Linux  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: build failure on Linux when mono 5 is installed
    Description: Mono 5 installs both csc and mcs binaries. If the mercury configure script is invoked *without* --with-csharp-compiler=/path/to/mcs, then csc is selected as the C# compiler:

    $ ./configure
    <snip>
    checking for mono... /usr/bin/mono
    checking for a C sharp compiler...
    checking for csc... /usr/bin/csc
    checking version of .NET libraries... 4.0.0.0

    This leads to an eventual build failure:

    mmc --generate-dependencies --grade reg.gc --mercury-linkage shared --flags LIB_FLAGS --flags INTER_FLAGS -R/usr/lib64/mercury/lib/reg.gc -R/usr/lib64/mercury/lib --no-warn-nothing-exported --no-warn-unused-imports mer_std
    mercury_compile: `--host-env-type posix` is incompatible with
      `--csharp-compiler-type microsoft'.
    Mercury Compiler, version 14.01.1, configured for x86_64-pc-linux-gnu
    Copyright (C) 1993-2014 The University of Melbourne
    Usage: mmc [<options>] <arguments>
    Use `mmc --help' for more information.
    gmake[2]: *** [/var/tmp/portage/dev-lang/mercury-14.01.1/temp/mmake.ypfgqB:1500: mer_std.depend] Error 1


    This looks to be a different flavour of an older bug (see bug 0000255) where the Chicken Scheme Compiler (csc) would be selected as the C# compiler. However this time, the csc binary does pass the 'grep "^Microsoft"' configure check:

    $ csc
    Microsoft (R) Visual C# Compiler version 2.6.0.62309 (d3f6b8e7)
    Copyright (C) Microsoft Corporation. All rights reserved.
    warning CS2008: No source files specified.
    error CS1562: Outputs without source must have the /out option specified


    The version of mono installed is 5.12:
    $ mono --version
    Mono JIT compiler version 5.12.0.226
    Tags:
    Steps To Reproduce: after installing mono 5:

    $ ./configure
    $ make
    Additional Information:
    Attached Files:
     
    Notes
    (0001001)
    juliensf   
    2018-07-18 16:24   
    The basic problem is that Mercury's current detection and recognition of
    C# compilers predates the inclusion of the Roslyn C# compiler in Mono.
    In particular, Mercury requires (as mentioned in the error message), that
    if you are using a MS C# compiler then it needs to be running on Windows.
    (This is mainly so that it set up the command lines used to invoke the C#
    compiler appropriately, e.g. use Windows style paths etc.)
    (0001002)
    juliensf   
    2018-07-20 16:51   
    Fixed by commit c323cc2.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    462 [mercury] Feature Request minor N/A 2018-06-08 22:40 2018-06-08 22:41
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: packing notag arguments
    Description: Given a type such as

    :- type t1
       ---> f1(int8, bool, bool, int8, int).

    we currently pack the first four arguments into a single word.

    However, given a type such as

    :- type t2
       ---> f2(nt_int8, nt_bool, nt_bool, nt_int8, int).

    where

    :- type nt_int8
       ---> nt_int8(int8).

    :- type nt_bool
       ---> nt_bool(bool).

    we do NOT pack the first four args of f2 into a single word.
    We should be able to.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: pack_args_notag.m (3,416 bytes) 2018-06-08 22:40
    https://bugs.mercurylang.org/file_download.php?file_id=284&type=bug
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    451 [mercury] Feature Request minor N/A 2018-02-20 16:41 2018-06-08 22:19
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: unpack packed args only as necessary in field updates
    Description: Given a type such as

    :- type thing
        ---> thing(bool, bool, int, bool, bool, t6 :: bool),

    and two variables A and B of this type, the field update
    unification B = A ^ t6 := ... now gets compiled to code that
    picks up the value of every argument of A, except possibly
    the one being replaced, and puts them one-by-one into
    the newly allocated memory cell. Since the adjacent bools
    are packed into one word, the first of those steps requires
    using shifts and masks to unpack all of arguments 1, 2, 4 and 5,
    operations that the second step then reverses.

    In the common situation where the code following the field update
    does not look at the fields that were not updated, we should be able
    to generate code that picks up the first word of A as a complete entity
    and assigns it to the first word of B. For the third word, part of which is
    being replaced, it should still be possible to pick up the value of the
    4th and 5th argument as a unit, and shift and OR it together with the
    new value of the 6th field *without* separating the 4th and 5th from each
    other.
    Tags:
    Steps To Reproduce:
    Additional Information: This probably needs to be done during code generation, because
    a post-code-generation optimization pass would have no way of knowing
    that the values of the padding bits don't matter.
    Attached Files: y.m (788 bytes) 2018-02-20 16:41
    https://bugs.mercurylang.org/file_download.php?file_id=275&type=bug
     
    Notes
    (0001000)
    zs   
    2018-06-08 22:19   
    Implemented for hlc grades in a diff committed on 2018 June 2.

    Not yet implemented for LLDS grades.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    459 [mercury] Bug minor always 2018-05-07 02:08 2018-05-07 07:45
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: bootcheck applies stage 2 settings to stage 1
    Description: Doing a bootcheck in the csharp and java grades sets use_mmc_make and use_subdirs. This is fine for the stage 2, but the bootcheck script applies
    these settings to stage 1 as well. If the stage 1 did NOT use subdirs,
    then this will screw it up.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000999)
    zs   
    2018-05-07 07:45   
    Fix committed 2018 may 6.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    457 [mercury] Bug minor always 2018-04-29 12:19 2018-04-30 18:49
    Reporter: wangp Platform:  
    Assigned To: wangp OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: abort on construct_statically in var_locn
    Description: The compiler aborts on the attached test case in low-level C grades with --loop-invariants --intermod-opt. The --loop-invariants option calls the mark_static_terms pass, which is (as I understand) otherwise only used for MLDS grades. var_locn.m aborts when it sees the construct_statically introduced by mark_static_terms.

    The original comment:
      % XXX We should probably throw an exception if we find either
      % construct_statically or reuse_cell here.
    was added by Quan for his RBMM work. I suspect var_locn_assign_dynamic_cell_to_var should just treat construct_statically like construct_dynamically.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: construct_statically_abort.m (623 bytes) 2018-04-29 12:19
    https://bugs.mercurylang.org/file_download.php?file_id=283&type=bug
     
    Notes
    (0000998)
    wangp   
    2018-04-30 18:49   
    Fixed in commit 72bc36afc




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    456 [mercury] Feature Request minor N/A 2018-04-26 10:47 2018-04-26 10:47
    Reporter: wangp Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: structured concurrency
    Description: Explains it well:
    https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/

    Spawning threads which can run indefinitely long is almost never what I want.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    455 [mercury] Bug minor always 2018-04-21 13:01 2018-04-21 21:16
    Reporter: wangp Platform:  
    Assigned To: juliensf OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: intermodule optimisation with fixed sized integer modules
    Description: The compiler crashes on the attached test case:

    % mmc --intermod-opt -m mod_a
    Making Mercury/cs/mod_a.c
    Uncaught Mercury exception:
    Software Error: check_hlds.simplify.simplify_goal_call: predicate `check_hlds.simplify.simplify_goal_call.simplify_make_binary_op_goal_expr'/8: Unexpected: cannot find unchecked_left_shift
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: mod_a.m (389 bytes) 2018-04-21 13:01
    https://bugs.mercurylang.org/file_download.php?file_id=281&type=bug
    mod_b.m (280 bytes) 2018-04-21 13:02
    https://bugs.mercurylang.org/file_download.php?file_id=282&type=bug
     
    Notes
    (0000996)
    juliensf   
    2018-04-21 17:43   
    The problem is that the simplification pass can introduce calls to unchecked_left_shift, but that
    dead predicate elimination hasn't been updated correctly to tell it not to delete the clauses
    for that predicate; I'll post a fix for this later this evening.
    (0000997)
    juliensf   
    2018-04-21 21:16   
    Fixed in commit bb55d65.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    445 [mercury] Bug minor N/A 2018-01-24 16:57 2018-03-19 15:19
    Reporter: wangp Platform:  
    Assigned To: wangp OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: __builtin_bswap16/32 support
    Description: Detect support for __builtin_bswap{16,32} in configure, or figure out the earliest version of gcc/clang that support those builtins on relevant platforms.

    e.g. the builtins are unavailable in gcc 4.2.1 on OpenBSD 6.2 (which is stuck on an old gcc for ideological reasons). It may be that we should only support clang on OpenBSD.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000962)
    juliensf   
    2018-01-24 17:54   
    (Last edited: 2018-01-24 17:56)
    bswap32 and bswap64 first appeared in GCC 4.3.
    bswap16 first appeared in GCC 4.8.

    They are *not* listed among the platform specific builtins so I would assume
    they are available on all platforms from those versions onward.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    453 [mercury] Bug crash always 2018-03-09 15:57 2018-03-16 15:15
    Reporter: wangp Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: asm_fast does not work with gcc 5.4
    Description: One of the test cases (of many) which crash is hard_coded/bit_buffer_test.

    This configuration crashes:
    Ubuntu 16.04 i386
    gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)
    Mercury rotd 2016-02-18 and rotd 2018-03-07
    asm_fast.gc
    (none.gc, reg.gc, hlc.gc are OK)
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000976)
    wangp   
    2018-03-13 14:23   
    The previous configuration (gcc 5.4.0, asm_fast.gc, x86) passes bootcheck if the Mercury libraries are statically linked, i.e. ./configure --disable-dynamic-link
    (0000988)
    wangp   
    2018-03-15 12:57   
    I can reproduce a crash more simply with a call to string.count_codepoints/2. I've copied that predicate to a separate module for ease of debugging, and generated the assembly with mmake string2.pic_s. Then we can edit the assembly and create libmer_std.so with: as -g string2.pic_s -o string2.pic_o && mmake libmer_std.so


    This is the start of string2.count_codepoints:

               .globl _entry_mercury__string2__count_codepoints_2_0
       .type _entry_mercury__string2__count_codepoints_2_0,@function
    _entry_mercury__string2__count_codepoints_2_0:
       call 0f
    0:
       popl %ebx
       addl $_GLOBAL_OFFSET_TABLE_+[.-0b],%ebx
          
    # 0 "" 2
    .LDL1:
    #NO_APP
    .L4:
            movl -12(%ebp), %ebx
            leal .L5@GOTOFF(%ebx), %eax
    .LBB2:
            .loc 1 281 0
            movl MR_engine_base@GOT(%ebx), %eax
            movl 8(%eax), %ecx
            ...

    The four lines beginning with "call 0f" are due to MR_INLINE_ASM_FIXUP_REGS, to (as I understand it) load the position of the code into ebx. Right afterwards, gcc has added an instruction to copy something off the stack into ebx (presumably it would have stashed the correct value on the stack, but we've jumped into the middle of a C function).

    Inserting an instruction "movl %ebx, -12(%ebp)" to cancel out that instruction makes this particular predicate work, so I think this is on the right track.
    (0000989)
    wangp   
    2018-03-15 14:59   
    On the other hand... x86 usage is only decreasing, linking with Mercury shared libraries is not very important, and inter-function jumps were never officially supported by gcc anyway. Maybe it is time to drop support for the combination?
    (0000990)
    juliensf   
    2018-03-15 16:14   
    If you disable optimization in GCC (e.g. -O0) does the problem still occur?
    (0000991)
    wangp   
    2018-03-15 16:26   
    It works at -O0, but not -O1, and not at -O1 with -f* options I could find disabled (everything listed by "gcc -O1 -Q --help=optimizers").
    (0000992)
    wangp   
    2018-03-15 16:40   
    My guess is that it is related to this change in GCC 5.0:

    https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode
    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54232

    Previously EBX was reserved for the GOT address so GCC probably had no need to save/restore it. If EBX can be used for other purposes then GCC might try to restore a value from the stack after our inline asm. The question is how to convince GCC not to do that.
    (0000993)
    wangp   
    2018-03-15 17:04   
    (convince GCC not to restore the GOT address from the stack, not only directly after the MR_INLINE_ASM_FIXUP_REGS sequence)
    (0000994)
    juliensf   
    2018-03-15 17:11   
    You could try starting at -O0 and adding optimizations. (Past experience of this
    kind of thing indicates that GCC is not entirely truthful about which optimizations it applies at which optimization level.)
    (0000995)
    wangp   
    2018-03-16 15:15   
    Ok, bootcheck still passes with these options (which are what gcc reports as being enabled by -O1):

    -fbranch-count-reg
    -fcombine-stack-adjustments
    -fcompare-elim
    -fcprop-registers
    -fforward-propagate
    -fguess-branch-probability
    -fif-conversion
    -fif-conversion2
    -finline-functions-called-once
    -fipa-profile
    -fipa-pure-const
    -fipa-reference
    -freorder-blocks
    -fshrink-wrap
    -fsplit-wide-types
    -fssa-phiopt
    -ftree-bit-ccp
    -ftree-builtin-call-dce
    -ftree-ccp
    -ftree-ch
    -ftree-coalesce-vars
    -ftree-copy-prop
    -ftree-dce
    -ftree-dse
    -ftree-fre
    -ftree-pta
    -ftree-sink
    -ftree-slsr
    -ftree-sra
    -ftree-ter


    Regardless, gcc 5 and up do not use a fixed PIC register on x86. Jumping into the middle of a function and putting the GOT address into EBX is not going to work if the rest of the function is not expecting it there.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    433 [mercury] Bug minor have not tried 2017-03-23 15:04 2018-03-13 14:38
    Reporter: pbone Platform: amd64  
    Assigned To: pbone OS: Linux Mint  
    Priority: normal OS Version:  
    Status: acknowledged Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: mmc --make calls programs without full path
    Description: if you have multiple installations of Mercury then calling tools like mkinit without the full path can lead to problems.
    Tags:
    Steps To Reproduce:
    I have two installations of Mercury. In /usr I have 14.01.1 (this is the one I'm filing the bug against). And I have a recent ROTD in /usr/local (linked there by stow, stow is cool, check it out). But /usr/local is earlier in my path than /usr so that I can override my system's tools.

    $ which mmc
    /usr/local/bin/mmc

    If I invoke the version in /usr it breaks.

    $ /usr/bin/mmc --make hello
    Making Mercury/int3s/hello.int3
    Making Mercury/ints/hello.int
    Making Mercury/cs/hello.c
    Making Mercury/os/hello.o
    ** Error making `hello'.
    Mercury/cs/hello_init.c: In function ‘mercury_init’:
    Mercury/cs/hello_init.c:1736:29: error: ‘ML_std_library_init’ undeclared (first use in this function)
    Mercury/cs/hello_init.c:1736:29: note: each undeclared identifier is reported only once for each function it appears in
    Mercury/cs/hello_init.c:1737:27: error: ‘ML_std_library_finalize’ undeclared (first use in this function)
    Mercury/cs/hello_init.c: At top level:
    Mercury/cs/hello_init.c:1866:1: error: expected identifier or ‘(’ before ‘/’ token

    It appears to be excuting the first mkinit it finds in my $PATH, which is incompatible. If I override $PATH, then it works without a problem.
    Additional Information: I intend to fix this bug in the immediate future, I'm filing it now so that I can have a URL to point to it.
    Attached Files:
     
    Notes
    (0000946)
    pbone   
    2017-04-05 11:02   
    I've been looking at this issue.

    I'd like to store the full path to each of these tools (mkinit, mgnuc etc) in the configuration. scripts/Mercury.config.in seems like the best place to do that, and a similar change will need to be made for Mmake.

    It's also desirable to use the libexec directory, and in particular allow ./configure to set these directories rather than creating them ourselves, ignoring ./configure. However that may make it a little tricker to "move" a mercury installation, but that too should be solvable.

    Does anyone else seen any potential problems we may create by encoding the full paths in Mercury.config and allowing these files to be installed in different locations via ./configure's parameters?

    Thanks.
    (0000947)
    wangp   
    2017-04-05 11:24   
    I think using full paths is the correct thing to do.

    Allowing configure to adjust locations may get in the way of a different goal. I would like to see mmc --make and mmake use absolute paths built at runtime relative to a top-level directory either (1) deduced automatically based on the full path to mmc or mmake, or (2) manually overridden. This would allow moving the Mercury installation without touching any files. It would be especially useful for making prebuilt binary packages that could run immediately out of any user's home directory. (C compiler differences may still hamper that.)
    (0000948)
    pbone   
    2017-04-05 11:40   
    We can already move an installation by editing/rebuilding Mercury.config (and maybe another file). This change would make it more difficult to move an installation, there's just be more to edit within Mercury.config since it wouldn't build paths at runtime.

    There's another option. Rather than either writing (in Mercury.config) the path to each tool/library, or writing the prefix and building paths at runtime, we could write the path to @bindir@ and @libexecdir@ and build paths from those at runtime. It'd be a little easier to move an installation, but give full flexibility to autoconf/building packages for distros.

    I think either this, or writing the path to each tool in Mercury.config is the correct thing to do. There may be other ways to move an installation, such as by providing a simpler Mercury.config file that is based on most Linux distros' defaults with only one variable for the prefix.
    (0000949)
    wangp   
    2017-04-05 12:01   
    You can edit Mercury.config, but it is too difficult. Using Mercury on any (recent) Linux distribution should be as easy as tar xf mercury-bindist-xxxx.tar.gz

    I'm wary of introducing a variable syntax to Mercury.config. Which locations need customisation? I don't think anyone would object to libexec. If I remember, we had agreement to move most scripts out of bin.
    (0000950)
    juliensf   
    2017-04-05 12:03   
    Files containing paths are:

       lib/mercury/conf/Mercury.config
       lib/mercury/mdb/mdbrc
       lib/mercury/mmake/Mmake.vars

    as well as a bunch of scripts in the bin directory.

    Also, macOS you won't just be able to shift an installation without rewriting all of the install_names in the dylibs.

    @wangp: C compiler differences will definitely hamper that! In principle, we could build information about
    known C compilers into the system, so that by setting --cc, --c-compile-type and --fullarch appropriately
    it would select the correct set of flags. (I think I posted something to the developers list about this several years ago.) Of course, you will still have a problem with new C compiler versions that the Mercury compiler doesn't know about.
    (0000977)
    pbone   
    2018-03-13 14:38   
    Unassigned things from me.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    406 [mercury] Bug minor have not tried 2016-03-06 01:18 2018-03-13 14:38
    Reporter: juliensf Platform: x86_64  
    Assigned To: pbone OS: OS X  
    Priority: normal OS Version: 10.9.5  
    Status: acknowledged Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: parallelism in standalone java example aborts
    Description: The example in samples/java_interface/standalone_java crashes with an OutOfMemoryError exception due to it trying to allocate ~2030 native threads. Commenting out the call to the parallelised Fiobnacci function in JavaMain.java causes the example to work.
    Tags:
    Steps To Reproduce:
    Additional Information: Java Information:

    java version "1.8.0_05"
    Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
    Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
    Attached Files:
     
    Notes
    (0000979)
    pbone   
    2018-03-13 14:38   
    Unassigned things from me.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    336 [mercury] Bug minor always 2014-06-20 10:30 2018-03-13 14:38
    Reporter: wangp Platform:  
    Assigned To: pbone OS:  
    Priority: low OS Version:  
    Status: acknowledged Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version: 15.11  
    Summary: java programs do not wait for all threads to finish
    Description: The program terminates soon after the main thread exits, even if other threads are running.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000702)
    pbone   
    2014-06-20 11:49   
    Hi Peter,

    I'm about to do some work on the Java concurrency stuff for MCit. So I'll look at this at the same time.

    Thanks.
    (0000705)
    juliensf   
    2014-06-24 12:37   
    The behaviour of multi-threaded programs when the main thread terminates needs to be specified
    somewhere, reference manual(?) or in the comment at the head of thread.m. Furthermore the behaviour
    should be consistent across backends.
    (0000712)
    pbone   
    2014-06-26 18:50   
    Hi.

    What should be the behavior if an error is raised. For example:
     + The exit status is set to non-zero (I think it should wait).
     + An exception is uncaught in main/2 (Should it exit immediately?)
     + Can a mercury program call abort() like one can in C?
     + An internal error (in Mercury) (it should exit immediately).

    Thanks
    (0000714)
    wangp   
    2014-06-27 10:51   
    > What should be the behavior if an error is raised. For example:
    > + The exit status is set to non-zero (I think it should wait).

    Yes. It just sets a global variable.

    > + An exception is uncaught in main/2 (Should it exit immediately?)

    I think so.

    > + Can a mercury program call abort() like one can in C?

    Yes. Mercury can't prevent anyone doing so anyway.

    > + An internal error (in Mercury) (it should exit immediately).

    Yes. We can't continue after an internal (fatal) error.
    (0000715)
    pbone   
    2014-06-27 10:55   
    > > + Can a mercury program call abort() like one can in C?
    >
    > Yes. Mercury can't prevent anyone doing so anyway.

    What I mean is, do we provide something like abort in Mercury? (I don't remember one myself), something like:

    :- pred abort(int::in, io::di, io::uo) is det.

    Which doesn't return.
    (0000716)
    juliensf   
    2014-06-27 11:09   
    By making the determinism of abort/3 det, you are telling the compiler that it _does_ return.
    A better signature would be:

        :- pred abort(int::in, io::di) is erroneous.

    In any case, I don't see the need for abort in Mercury. Every time I have needed something like it, throwing an exception back to the top-level has always sufficed.
    (0000718)
    pbone   
    2014-06-27 11:20   
    Okay cool, I wasn't proposing abort/3 just asking if we already had something like this.
    (0000980)
    pbone   
    2018-03-13 14:38   
    Unassigned things from me.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    335 [mercury] Bug minor always 2014-06-17 15:42 2018-03-13 14:38
    Reporter: wangp Platform:  
    Assigned To: pbone OS:  
    Priority: normal OS Version:  
    Status: acknowledged Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: assertion failure in MR_do_sleep
    Description:     /*
        ** Either we slept and were notified, or were notified before we slept.
        ** Either way, check why we were notified.
        */
        MR_assert(state == ENGINE_STATE_NOTIFIED);
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000701)
    wangp   
    2014-06-17 15:44   
    Sorry, I hit enter which submitted the issue prematurely.

    I get said assertion failure on any program in asm_fast.par.gc and -DMR_LOWLEVEL_DEBUG.
    (0000981)
    pbone   
    2018-03-13 14:38   
    Unassigned things from me.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    333 [mercury] Bug minor always 2014-06-16 11:41 2018-03-13 14:38
    Reporter: wangp Platform:  
    Assigned To: pbone OS:  
    Priority: normal OS Version:  
    Status: acknowledged Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: MR_num_idle_engines count goes wrong
    Description: Hi Paul, I think you can solve this faster than I can.

    I've made a copy of the parallel fib benchmark, except that it repeats. Parallel execution works for the first fib call. Afterwards, fewer engines do any work. Soon, parallel execution never occurs again.

    MR_num_idle_engines should be the culprit:

    Program received signal SIGINT, Interrupt.
    0x0000000000405dac in fib_par_plain_module1 () at fib_par_plain.c:206
    206 MR_parent_sv(3) = MR_r1;
    (gdb) p MR_num_idle_engines
    $2 = -2
    (gdb) c
    Continuing.
    fib(40) = 165580141
    fib(40) = 165580141
    ^C
    Program received signal SIGINT, Interrupt.
    0x00007ffff6789d00 in sem_wait () from /lib64/libpthread.so.0
    (gdb) p MR_num_idle_engines
    $3 = 0
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: fib_par_plain.m (435 bytes) 2014-06-16 11:41
    https://bugs.mercurylang.org/file_download.php?file_id=216&type=bug
     
    Notes
    (0000700)
    pbone   
    2014-06-16 12:14   
    It looks very odd where MR_num_idle_engines is -2. I'll take a look but I think 0000334 should be done first and might even help with this bug.

    Thanks.
    (0000982)
    pbone   
    2018-03-13 14:38   
    Unassigned things from me.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    295 [mercury] Bug minor always 2013-07-27 02:03 2018-03-13 14:38
    Reporter: juliensf Platform:  
    Assigned To: pbone OS:  
    Priority: normal OS Version:  
    Status: acknowledged Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: io.read_line_as_string/3 and CRLF line endings on Windows
    Description: On Windows io.read_line_string/3 does not return a CRLF line ending in C grades, but does
    in Java grades. It would be preferable if this was consistent (or at least documented).
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000557)
    juliensf   
    2013-07-27 02:06   
    Same for io.read_line/3.
    (0000983)
    pbone   
    2018-03-13 14:38   
    Unassigned things from me.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    274 [mercury] Bug minor always 2013-01-08 12:34 2018-03-13 14:38
    Reporter: juliensf Platform:  
    Assigned To: pbone OS:  
    Priority: normal OS Version:  
    Status: acknowledged Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: possibly incorrect purity cast in deep profiler
    Description: The purity cast in predicate build_var_use_lists in deep_profiler/autopar_types.m is possibly
    in the wrong spot.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000984)
    pbone   
    2018-03-13 14:38   
    Unassigned things from me.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    163 [mercury] Bug major sometimes 2010-09-10 11:14 2018-03-13 14:38
    Reporter: pbone Platform:  
    Assigned To: pbone OS:  
    Priority: low OS Version:  
    Status: acknowledged Product Version:  
    Product Build: Resolution: unable to reproduce  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: mdprof_cgi (deep profiler webserver) seems to lock up and leave processes running that should have timed out.
    Description: Since setting up the deep profiler demo on taura I've noticed that deep profiler pages sometimes refused to be displayed, my browser waits forever for them.

    At the same time taura appears to be running many, many mdprof_cgi processes, killing them, and sometimes restarting apache temporarily fixes the problem.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000286)
    pbone   
    2010-09-10 11:16   
    I think that if the mdprof_cgi daemon processes dies due to an exception that the CGI process that is waiting for it fails to time-out/report the exception.
    (0000303)
    pbone   
    2011-02-02 13:10   
    I've lowered the priority and reproducibility of this bug. I haven't seen it for a while - it may exist but I'm not sure.
    (0000374)
    pbone   
    2011-11-02 14:22   
    This bug has stuck again, the problem with fixing it is that we don't really know how to cause it to happen.
    (0000985)
    pbone   
    2018-03-13 14:38   
    Unassigned things from me.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    157 [mercury] Bug minor always 2010-07-14 13:46 2018-03-13 14:38
    Reporter: wangp Platform:  
    Assigned To: pbone OS:  
    Priority: normal OS Version:  
    Status: acknowledged Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: mtags uninitialised value warnings
    Description: perl v5.10.1 spews warnings on mtags.

    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 78.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 198.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 162.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 79.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 79.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 79.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 79.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 79.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 79.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 79.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 79.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 79.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 94.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 94.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 94.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 94.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 94.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 94.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 94.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 94.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 94.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 78.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 198.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 162.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 78.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 78.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 198.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 198.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 162.
    Use of uninitialized value $decl in pattern match (m//) at /usr/local/bin/mtags line 451, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Use of uninitialized value $decl in string eq at /usr/local/bin/mtags line 461, <SRCFILE> line 162.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000307)
    pbone   
    2011-02-05 13:43   
    I can reproduce this by running mtags against tests/valid/constr_inst_syntax.m
    (0000987)
    pbone   
    2018-03-13 14:38   
    Unassigned things from me.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    156 [mercury] Bug text have not tried 2010-07-11 12:02 2018-03-13 14:38
    Reporter: pbone Platform:  
    Assigned To: pbone OS:  
    Priority: normal OS Version:  
    Status: acknowledged Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Headers in deep profiler clique report are incorrect.
    Description: The headers under 'Time' are incorrect when in "Times and per-call Times" mode. The same header label 'time' is used to represent self time and self and decedents time. The attachment contains the HTML page rendered by mdprof_cgi where the issue can be seen.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: mdprof_cgi.html (27,376 bytes) 2010-07-11 12:02
    https://bugs.mercurylang.org/file_download.php?file_id=105&type=bug
     
    Notes
    (0000986)
    pbone   
    2018-03-13 14:38   
    Unassigned things from me.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    454 [mercury] Bug minor always 2018-03-09 16:25 2018-03-13 14:19
    Reporter: wangp Platform:  
    Assigned To: wangp OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: arith_int64 failure
    Description: arith_int64 fails on Ubuntu 16.04 x86_64
    gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)
    Mercury rotd 2018-03-07

    --- arith_int64.out 2018-03-09 16:23:20.780057386 +1100
    +++ arith_int64.exp 2018-02-03 23:05:01.000000000 +1100
    @@ -17,20 +17,20 @@
     
     *** Test unary operation '-' ***
     
    -- -9223372036854775808 = -9223372036841988320
    -- -2147483648 = 2160271136
    -- -64768 = 12852256
    -- -128 = 12787616
    -- 0 = 12787488
    -- 1 = 12787487
    -- 2 = 12787486
    -- 8 = 12787480
    -- 10 = 12787478
    -- 16 = 12787472
    -- 127 = 12787361
    -- 64767 = 12722721
    -- 2147483647 = -2134696159
    -- 9223372036854775807 = -9223372036841988319
    +- -9223372036854775808 = -9223372036854775808
    +- -2147483648 = 2147483648
    +- -64768 = 64768
    +- -128 = 128
    +- 0 = 0
    +- 1 = -1
    +- 2 = -2
    +- 8 = -8
    +- 10 = -10
    +- 16 = -16
    +- 127 = -127
    +- 64767 = -64767
    +- 2147483647 = -2147483647
    +- 9223372036854775807 = -9223372036854775807
     
     *** Test unary operation 'abs' ***
     
    @@ -56,15 +56,15 @@
     nabs -64768 = -64768
     nabs -128 = -128
     nabs 0 = 0
    -nabs 1 = 12787487
    -nabs 2 = 12787486
    -nabs 8 = 12787480
    -nabs 10 = 12787478
    -nabs 16 = 12787472
    -nabs 127 = 12787361
    -nabs 64767 = 12722721
    -nabs 2147483647 = -2134696159
    -nabs 9223372036854775807 = -9223372036841988319
    +nabs 1 = -1
    +nabs 2 = -2
    +nabs 8 = -8
    +nabs 10 = -10
    +nabs 16 = -16
    +nabs 127 = -127
    +nabs 64767 = -64767
    +nabs 2147483647 = -2147483647
    +nabs 9223372036854775807 = -9223372036854775807
     
     *** Test binary operation '+' ***
     
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: sgt_int64.m (276 bytes) 2018-03-09 18:02
    https://bugs.mercurylang.org/file_download.php?file_id=279&type=bug
    bar_baz.m (759 bytes) 2018-03-13 06:14
    https://bugs.mercurylang.org/file_download.php?file_id=280&type=bug
     
    Notes
    (0000968)
    wangp   
    2018-03-09 16:56   
    For this program:

    main(!IO) :-
        X = 1i64,
        Y = -X,
        write_int64(Y, !IO),
        nl(!IO).

    the compiler is producing:

    void MR_CALL
    main_2_p_0(void)
    {
      {
        int64_t X_4 = INT64_C(1);
        int64_t Y_5 = (INT64_C(12789120) - X_4);

        mercury__io__write_int64_3_p_0(Y_5);
        mercury__io__nl_2_p_0();
      }
    }
    (0000970)
    wangp   
    2018-03-09 17:57   
    The problem is with a compiler in the .pregen grade.
    (0000971)
    wangp   
    2018-03-09 18:04   
    Ok, it's to do with (un)boxed int64s in a static ground term, see sgt_int64.m.
    (0000972)
    zs   
    2018-03-09 20:52   
    I have noticed that both unify_gen.m and ml_unify_gen.m still retain
    in most of their code the assumption that every argument of a functor
    occupies exactly one word in the memory cell. There are places that
    do deal with floats that take up double words and places that deal
    with two or more enum fields being packed into the same word,
    but they are post-processing the output of a word-oriented computation.

    I have started changing this over the last week or so, and will continue
    working on it, since doing so is prerequisite for improving argument packing.
    I think it very likely that this work will fix this bug.
    (0000973)
    zs   
    2018-03-13 06:14   
    The attached program, bar_baz.m, has code to allocate
    both a 64 bit float and a 64 bit integer both dynamically and statically.
    In pregen grades, all four allocations are boxed. This suggests to me
    that the bug is not in the allocation code, but I cannot check it
    since I don't have a 32 bit system. Can someone else who does
    try out this program (compiled with --no-inlining)?
    Maybe you could also check whether doing a deconstruct
    does the right thing for all of FX, FY, IX and IY, since deconstruct
    has special code (MR_arg_value_uncommon) for 64 bit floats
    but not for 64 bit ints.
    (0000974)
    wangp   
    2018-03-13 11:21   
    The problem is that MR_BOXED_INT64S should be defined in .pregen grades (whether or not we are on a 32-bit or 64-bit machine). I will run a bootcheck then send a patch.
    (0000975)
    wangp   
    2018-03-13 14:19   
    Fixed in commit b58cc673e




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    409 [mercury] Bug minor have not tried 2016-06-16 13:04 2018-03-09 17:04
    Reporter: wangp Platform:  
    Assigned To: wangp OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: functor_ho_inst failing on 32-bit
    Description: This was on Solaris/x86 but I assume it would affect any 32-bit platform.

    FAILED TEST hard_coded/functor_ho_inst in grade asm_fast.gc
    FAILED TEST hard_coded/functor_ho_inst_2 in grade asm_fast.gc
    FAILED TEST hard_coded/functor_ho_inst_excp in grade asm_fast.gc
    FAILED TEST hard_coded/functor_ho_inst_excp_2 in grade asm_fast.gc

    Uncaught Mercury exception:
    Software Error: transform_hlds.float_regs: predicate `transform_hlds.float_regs.lookup_pred_inst_info'/5: Unexpected: no higher order inst
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000969)
    wangp   
    2018-03-09 17:04   
    Fixed by commit ac3891136




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    359 [mercury] Bug minor always 2014-09-05 17:31 2018-03-06 15:45
    Reporter: wangp Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: constrained polymorphic modes
    Description: Saving test cases to fix some other time.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: lambda.m (548 bytes) 2014-09-05 17:31
    https://bugs.mercurylang.org/file_download.php?file_id=223&type=bug
    ho_constrained_poly_inst.m (269 bytes) 2018-03-06 15:24
    https://bugs.mercurylang.org/file_download.php?file_id=277&type=bug
    create_test_unification.m (393 bytes) 2018-03-06 15:41
    https://bugs.mercurylang.org/file_download.php?file_id=278&type=bug
     
    Notes
    (0000793)
    wangp   
    2014-10-09 11:44   
    The problem in lambda.m:
    http://www.mercurylang.org/list-archives/users/2002-August/001921.html
    (0000843)
    mark   
    2015-07-15 11:37   
    A workaround for this is to use an explicit pred expression. For the lambda.m example, write:

        P = (pred(Z::out(bound(1))) is det :- id(1, Z))

    This will ensure that the inst variable for call to id/2 is bound in the way that is intended.
    (0000966)
    wangp   
    2018-03-06 15:31   
    While investigating something else, I found that modecheck_higher_order_call calls inst_expand which does not look past a top-level node of constrained_inst_vars. So this does not work, but I think there is no reason it should not work.

    :- inst b == (pred(in) is semidet).

    :- pred p2(pred(int)::in(I)) is semidet <= I =< b.

    p2(X) :- X(42).
    (0000967)
    wangp   
    2018-03-06 15:45   
    The compiler crashes on create_test_unification.m:

    Software Error: predicate `parse_tree.prog_mode.get_arg_insts'/4: Unexpected: defined_inst

    simplify_goal_switch.create_test_unification calls inst_expand (which does not touch an inst with constrained_inst_vars at the top level) followed by get_arg_insts (which expects the inst to be expanded).




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    432 [mercury] Feature Request minor always 2017-03-21 13:12 2018-02-22 14:06
    Reporter: wangp Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: pack constructor arguments in same word as primary tag
    Description: When we have a data constructor with a primary tag, whose arguments have a total width less than or equal to the number of remaining bits, we could pack the arguments into the same word as the tag instead of a separate cell.

    e.g.

    :- type bits_or_string
        ---> bits(bool, bool, bool)
        ; string(string).

    This would be more useful once we have smaller-than-word-size ints.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000944)
    zs   
    2017-03-21 15:48   
    That is a good idea.

    Actually, it could also be applied to secondary tags. If a type has enough non-constant functors to need a secondary tag for some functors, then at the moment, we allocate
    the entire first word of the memory cells of those functors to the secondary tag.
    However, we could allocate only the minimum number of secondary tag bits
    needed to distinguish those functors, and allocate the rest to hold the packable
    arguments of those functors.

    However, I expect this would be useful much more rarely than Peter's original
    proposal.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    452 [mercury] Bug minor always 2018-02-21 15:16 2018-02-22 14:05
    Reporter: wangp Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: model_det need_bit_vec_check
    Description: The compiler aborts on the attached test case:

    % mmc -s hlc.gc -C -v ml_lookup_switch_test.m
    ...
    % Converting HLDS to MLDS...
    Uncaught Mercury exception:
    Software Error: ml_backend.ml_lookup_switch: predicate `ml_backend.ml_lookup_switch.ml_gen_simple_atomic_lookup_switch'/13: Unexpected: model_det need_bit_vec_check


    (This is not urgent to fix.)
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: ml_lookup_switch_test.m (725 bytes) 2018-02-21 15:16
    https://bugs.mercurylang.org/file_download.php?file_id=276&type=bug
     
    Notes
    (0000965)
    zs   
    2018-02-22 14:05   
    Fix committed feb 22.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    449 [mercury] Bug minor have not tried 2018-02-09 10:23 2018-02-13 12:55
    Reporter: juliensf Platform:  
    Assigned To: juliensf OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Switches on uint64s not working in java grade
    Description: The test case tests/hard_coded/uint64_switch_test fails in the Java grade
    due to the generate code trying to perform a switch on a long value, which
    Java doesn't support.
    Tags:
    Steps To Reproduce: MERCURY_OPTIONS=
    gmake[3]: Entering directory `/mnt/opturion/jfischer/mercury-5.git/tests/hard_coded'
    { echo MCFLAGS += '--grade java --options-file /mnt/opturion/jfischer/mercury-5.git/stage2/Mercury.options --mercury-linkage static --flags ../TESTS_FLAGS --flags ../WS_FLAGS --use-subdirs '; echo MCFLAGS += ' '; echo CFLAGS += ' '; echo JAVACFLAGS += '-J"-Xmx1024m" '; echo CSCFLAGS += ' '; echo C2INITARGS += ' /mnt/opturion/jfischer/mercury-5.git/stage2/library/mer_std.init /mnt/opturion/jfischer/mercury-5.git/stage2/runtime/mer_rt.init '; echo MLLIBS += ' '; echo MLOBJS += ' '; echo LDFLAGS += ' '; echo LD_LIBFLAGS += ' '; echo EXTRA_LIBRARIES += ''; echo EXTRA_LIB_DIRS += ''; echo LIBGRADES = 'asm_fast.gc csharp erlang hlc.gc java '; echo INSTALL_PREFIX = '/mnt/opturion/jfischer/test-from-bytes'; echo LINKAGE = 'shared'; echo MERCURY_LINKAGE = 'shared'; } | /mnt/opturion/jfischer/mercury-5.git/stage2/scripts/mmc --make --options-file - uint64_switch_test.depend
    gmake[3]: Leaving directory `/mnt/opturion/jfischer/mercury-5.git/tests/hard_coded'
    gmake[3]: Entering directory `/mnt/opturion/jfischer/mercury-5.git/tests/hard_coded'
    { echo MCFLAGS += '--grade java --options-file /mnt/opturion/jfischer/mercury-5.git/stage2/Mercury.options --mercury-linkage static --flags ../TESTS_FLAGS --flags ../WS_FLAGS --use-subdirs '; echo MCFLAGS += ' '; echo CFLAGS += ' '; echo JAVACFLAGS += '-J"-Xmx1024m" '; echo CSCFLAGS += ' '; echo C2INITARGS += ' /mnt/opturion/jfischer/mercury-5.git/stage2/library/mer_std.init /mnt/opturion/jfischer/mercury-5.git/stage2/runtime/mer_rt.init '; echo MLLIBS += ' '; echo MLOBJS += ' '; echo LDFLAGS += ' '; echo LD_LIBFLAGS += ' '; echo EXTRA_LIBRARIES += ''; echo EXTRA_LIB_DIRS += ''; echo LIBGRADES = 'asm_fast.gc csharp erlang hlc.gc java '; echo INSTALL_PREFIX = '/mnt/opturion/jfischer/test-from-bytes'; echo LINKAGE = 'shared'; echo MERCURY_LINKAGE = 'shared'; } | /mnt/opturion/jfischer/mercury-5.git/stage2/scripts/mmc --make --options-file - uint64_switch_test
    Making Mercury/int3s/uint64_switch_test.int3
    Making Mercury/ints/uint64_switch_test.int
    Making Mercury/javas/jmercury/uint64_switch_test.java
    Making Java class files
    Mercury/javas/jmercury/uint64_switch_test.java:133: error: incompatible types: possible lossy conversion from long to int
            switch (Value_6) {
                   ^
    Note: Mercury/javas/jmercury/uint64_switch_test.java uses unchecked or unsafe operations.
    Note: Recompile with -Xlint:unchecked for details.
    Additional Information:
    Attached Files:
     
    Notes
    (0000963)
    juliensf   
    2018-02-09 10:30   
    Not a limitation shared by C#, so this only affects the Java grade.
    (0000964)
    juliensf   
    2018-02-13 12:55   
    Fixed in commit 63572bc.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    450 [mercury] Bug minor sometimes 2018-02-13 10:17 2018-02-13 10:17
    Reporter: juliensf Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: tests/invalid/sub_c failing when running tests with -j8
    Description: tests/invalid/sub_c fails due to (presumably) file creation time
    issues when running the tests with -j8. (On Linux/x86_64.)

    MERCURY_OPTIONS= --deep-random-write=25 --mdb-disable-progress
    gmake[3]: Entering directory `/mnt/opturion/jfischer/mercury-3.git/tests/invalid'
    /mnt/opturion/jfischer/mercury-3.git/stage2/scripts/mmc --generate-dependencies --grade asm_fast.gc --mercury-linkage static --flags ../TESTS_FLAGS --flags ../WS_FLAGS --verbose-error-messages --no-intermodule-optimization sub_c > sub_c.dep_err 2>&1
    gmake[3]: Leaving directory `/mnt/opturion/jfischer/mercury-3.git/tests/invalid'
    gmake[3]: Entering directory `/mnt/opturion/jfischer/mercury-3.git/tests/invalid'
    /mnt/opturion/jfischer/mercury-3.git/stage2/scripts/mmc --make-short-interface --grade asm_fast.gc --mercury-linkage static --flags ../TESTS_FLAGS --flags ../WS_FLAGS sub_a
    /mnt/opturion/jfischer/mercury-3.git/stage2/scripts/mmc --make-private-interface --grade asm_fast.gc --mercury-linkage static --flags ../TESTS_FLAGS --flags ../WS_FLAGS sub_a
    /mnt/opturion/jfischer/mercury-3.git/stage2/scripts/mmc --make-interface --grade asm_fast.gc --mercury-linkage static --flags ../TESTS_FLAGS --flags ../WS_FLAGS sub_a.m
    /mnt/opturion/jfischer/mercury-3.git/stage2/scripts/mmc --make-interface --grade asm_fast.gc --mercury-linkage static --flags ../TESTS_FLAGS --flags ../WS_FLAGS sub_a
    cp: cannot stat ‘sub_a.sub1.int.tmp’: No such file or directory
    Error creating `sub_a.sub1.int': can't open input file: No such file or directory
    Error: problem updating interface files.
    gmake[3]: *** [sub_a.date] Error 1
    gmake[3]: Target `sub_c.runtest' not remade because of errors.
    gmake[3]: Leaving directory `/mnt/opturion/jfischer/mercury-3.git/tests/invalid'
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    448 [mercury] Bug minor always 2018-02-07 05:30 2018-02-07 05:30
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: singleton warning generation ignores variables in quantifications
    Description: The problem is that quantification replaces the list of variables being quantified
    by a scope, ostensibly because that information is not needed by later compiler
    passes. However, it *is* needed by the code that generates warnings for singleton
    predicates.

    As it is, we get bad singleton warnings for code such as

        some [X] ( ... X ... )

    and may NOT get singleton warnings for code such as

        some [X] ( ... code in which there is no variable named X ... )
    Tags:
    Steps To Reproduce: The two halves of the problem are demonstrated by the test cases
    valid/bad_singleton_warning.m and warnings/missing_singleton_warning.m,
    which I just added to the repository.
    Additional Information: Simply keeping the quantified variables in place causes problems for later passes;
    it is such code in these later passes that are the actual bugs.
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    447 [mercury] Feature Request feature N/A 2018-02-06 18:16 2018-02-06 18:16
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: direct_arg_switch type representation
    Description: Some types, such as item and pragma_type in the Mercury compiler,
    consist of many functors of arity 1, each of whose arguments is a structure
    represented by an aligned pointer to the heap.

    At the moment, on 64 bit machines, we represent the first 7 functors
    as tagged pointers to those structures, and the remaining functors
    as two-word cells on the heap, with the first word being a secondary tag
    and the second being the structure pointer to the argument.

    This is probably the best representation we can get *if* the first 7 functors
    are the ones that occur most often. However, this may not be the case.
    Programmers can reorder the functors to *make* it the case, but this may
    not be desirable on software engineering grounds; for example, it may
    require that related functors not be put next to each other.

    It would be nice to have a pragma that tells the compiler the order of
    frequency of occurrence of the functors, so it can optimize the representation
    of the most frequently occurring functors. (Specifying the complete order
    would make this work regardless of the number of primary tag bits available.)

    It would be even better if a profiler generated that information automatically.
    This could be done by instrumenting e.g. every complete switch on the type
    to record which branch was taken.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    446 [mercury] Feature Request feature N/A 2018-01-30 02:32 2018-01-30 02:32
    Reporter: zs Platform:  
    Assigned To: zs OS:  
    Priority: low OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: smarter comparisons of structures
    Description: The code we automatically generate two compare structures such as f(int, int, ..., int)
    looks like this:

       X = f(X1, X2, ..., Xn),
       Y = f(Y1, Y2, ..., Yn),
       ( if
          compare(R1, X1, Y),
          R1 != "="
       then
         R = R1
       else if
          compare(R2, X2, Y2),
          R2 != "="
       then
          R = R2
       ...
      )

    The problem with this is that we execute the code to retrieve X2 ... Xn and Y2 ... Yn
    even if X1 != X2.

    We should instead generate code that picks up the value of Xi and Yi just before
    we call compare on them, in the condition of the relevant if-then-else.

    If the comparison of Xi and Yi is quick (such as when they are integers),
    then the heap cells of X and Y should still be in the cache.

    If the comparison is NOT quick, such as when Xi and Yi are complex data structures,
    having to pick up Xi+1 and Yi+1 from the heap may add an extra cache miss.
    We should experiment with storing Xi+1 and Yi+1 in the stack frame in such cases
    (and in such cases *only*). That may pay back if Xi = Yi, but would be a cost if
    Xi != Yi (since in that case we won't need to compare Xi+1 and Yi+1).

    The same considerations apply to unify predicates.
    Tags:
    Steps To Reproduce:
    Additional Information: We should test whether, and if so how well, the stack_opt optimization can do this task already.
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    444 [mercury] Bug crash always 2018-01-11 12:34 2018-01-12 17:33
    Reporter: wangp Platform:  
    Assigned To: wangp OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: static linking with musl crashes
    Description: When using musl, static linking (i.e. --linkage static) causes the program to crash during initialisation of the GC. It has to do with passing the "-Wl,-defsym -Wl,_DYNAMIC=0" in the linking step. The program will not crash if _DYNAMIC is not defined.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000960)
    wangp   
    2018-01-11 12:50   
    Without "-Wl,-defsym -Wl,_DYNAMIC=0", the binary DOES have a symbol _DYNAMIC but with a non-zero address:

    bash-4.4$ nm -a hello | grep _DYNAMIC
    00000000006dcdf8 d _DYNAMIC

    bash-4.4$ ./hello
    Hello, world
    (0000961)
    wangp   
    2018-01-12 17:33   
    Fixed by commit ee177a481




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    434 [mercury] Bug minor always 2017-03-29 09:55 2018-01-09 10:42
    Reporter: juliensf Platform: x86_64-pc-linux-gnu  
    Assigned To: wangp OS: Alpine Linux  
    Priority: normal OS Version: 3.5  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Alpine Linux / musl libc / x86_64 support
    Description: Installing rotd-2017-03-28 from the source distribution on Alpine Linux (x86_64-pc-linux-gnu) results in a successful install, but the executables (e.g. hello world) generated by the compiler abort with:

        GC_is_visible test failed
        Aborted

    This seems to be occurring in every grade.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000945)
    FlyingJester   
    2017-03-30 18:46   
    I can confirm the same issue on VoidLinux for amd64, using musl.

    A possible clue to the issue is that using "--linkage static --mercury-linkage static" produces working executables.
    (0000955)
    wangp   
    2017-06-25 11:32   
    Progress:

    - upstream bdwgc has the necessary changes for musl (including parallel marking)

    - need to compile bdwgc with -DNO_GETCONTEXT -DHAVE_DL_ITERATE_PHDR

    - there is some other difference between the autotools-based buid and the Makefile.direct-based build. Mercury programs would crash when linked with libgc.{a,so} produced by Makefile.direct, but would run correctly when linked with the libgc produced by the autotools-generated makefile.

    - thread.spawn/spawn_native will need to set a reasonable stack size as musl gives threads something like 80 kB by default. We should also allow the user to choose a stack size when creating a thread.
    (0000959)
    wangp   
    2018-01-09 10:42   
    Fixed as of commit 323bad9ff




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    443 [mercury] Bug minor always 2017-11-15 16:30 2017-11-15 16:30
    Reporter: juliensf Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Segmentation fault in high-level C .par.trseg grades
    Description: The attached program causes a segmentation fault when compiled in the
    grade hlc.par.gc.trseg. Thread local trailing has been supported since commit 1d50d41; I suspect it was broken for the high-level C backend when spawn_native/4 was implemented (based on the lack of any reference to trailing in library/thread.m.). The attached program is fine in asm_fast.par.gc.trseg.stseg.

    Reported against rotd-2015-11-21. Occurs in the current ROTD (2017-11-15).
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: test.m (442 bytes) 2017-11-15 16:30
    https://bugs.mercurylang.org/file_download.php?file_id=274&type=bug
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    442 [mercury] Bug minor always 2017-11-13 14:04 2017-11-13 14:04
    Reporter: juliensf Platform: x86_64  
    Assigned To: OS: Linux  
    Priority: normal OS Version: Oracle 7  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Building compiler with -j4 and --use-mmc-make fails
    Description: Doing a parallel build of the compiler (-j4) with --use-mmc-make fails,
    the first error is:

        Making Mercury/int3s/term_io.int3
        Making Mercury/int3s/ops.int3
        Making Mercury/int3s/string.format.int3
        Making Mercury/int3s/string.format.int3
        Making Mercury/int3s/string.parse_runtime.int3
        Making Mercury/int3s/string.parse_runtime.int3
        Making Mercury/int3s/string.parse_util.int3
        ** Error making `Mercury/int3s/string.parse_runtime.int3'.
        cp: cannot stat ‘Mercury/int3s/string.parse_runtime.int3.tmp’: No such file or directory
        Error creating `Mercury/int3s/string.parse_runtime.int3': can't open input file: No such file or directory
        Error: problem updating interface files.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    441 [mercury] Bug minor always 2017-10-18 22:47 2017-10-18 23:42
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: assigned Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Invalid C code for program in hlc.gc grade
    Description: The attached program compiles and runs successfully in the asm_fast.gc grade. The generated C code
    fails to compile in the hlc.gc grade with the following error:

    Mercury/cs/test_vfm2.c: In function ‘test_vfm2__hello_1_f_0’:
    Mercury/cs/test_vfm2.c:130:18: error: void value not ignored as it ought to be
         HeadVar__2_2 = vfm2__printLine_2_f_0(TypeCtorInfo_5_5, TypeCtorInfo_6_6, ((MR_Box) (Var_4)), FIO_3);
                      ^
    ** Error making `Mercury/os/test_vfm2.o'.

    This is using rotd-2017-10-15 (although it also occurs with old roads).
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: vfm2_bug.tar.gz (702 bytes) 2017-10-18 22:47
    https://bugs.mercurylang.org/file_download.php?file_id=273&type=bug
     
    Notes
    (0000958)
    zs   
    2017-10-18 23:42   
    The problem is NOT we generate the line that the error message is for.
    The problem is that vfm2.m knows that fio is a dummy type, and makes
    the return type of vfm2__printline_2_f_0 void accordingly, even though it keeps
    the definition of fio(T) *private*. This means that fio is NOT known to be a dummy
    type anywhere but inside the vfm2 module.

    We will need to split the concept of "dummy type" into two: dummy types
    that are known to be dummy everywhere, and those known to be dummy
    only in their defining module.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    411 [mercury] Bug major always 2016-06-22 14:03 2017-08-22 10:38
    Reporter: wangp Platform:  
    Assigned To: wangp OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: abstract type not hidden
    Description: In the test case, foo.m exports an abstract type `foo' but bar.m is able to see that it is an equivalence type for int.

    Of the compilers I have installed:
    mercury-srcdist-rotd-2015-07-01 works correctly
    mercury-srcdist-rotd-2015-08-10 is broken
    Tags:
    Steps To Reproduce: mmc -m bar.m
    Additional Information:
    Attached Files: foo.m (426 bytes) 2016-06-22 14:03
    https://bugs.mercurylang.org/file_download.php?file_id=257&type=bug
    bar.m (410 bytes) 2016-06-22 14:04
    https://bugs.mercurylang.org/file_download.php?file_id=258&type=bug
     
    Notes
    (0000886)
    wangp   
    2016-06-22 14:08   
    Oops, the step to reproduce is obviously "mmc -m bar" without the .m suffix.
    (0000954)
    wangp   
    2017-06-22 15:38   
    I nearly filed this bug again, having forgotten about it. Strange coincidence!
    (0000957)
    wangp   
    2017-08-22 10:38   
    Fix committed.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    440 [mercury] Feature Request minor N/A 2017-08-10 11:08 2017-08-10 11:08
    Reporter: wangp Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: mdb: tab completion for function symbols
    Description: It would improve the mdb experience greatly if you could tab complete function symbols in the term path part of a print command (and the browser?). For unnamed fields it may be worth cycling through the argument numbers. If the current subterm has exactly one argument, TAB could complete that without any prefix from the user.

    pp 5/1/box_content/1/1/5/1/2/1/box_content/1/1/1/5/1/1/spanbox_content
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    439 [mercury] Bug minor always 2017-08-06 13:09 2017-08-06 13:09
    Reporter: wangp Platform:  
    Assigned To: OS:  
    Priority: low OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: cannot build module which imports empty nested sub-module
    Description: Both mmc --make and mmake are unable to build a module which tries to import an empty nested sub-module. Obviously this is extremely low priority, and the fix may be to disallow such sub-modules.


    % mmc -m empty_submodule
    Making Mercury/int3s/empty_submodule.int3
    empty_submodule.m:014: Warning: submodule `empty_submodule.nested' of module
    empty_submodule.m:014: `empty_submodule' is empty.
    ** Error reading file `empty_submodule.nested.m' to generate dependencies.
    ** Module `empty_submodule.nested' is imported or included by module `empty_submodule'.
    mercury_compile: cannot find source for module `empty_submodule.nested' in
      directories `.'


    % mmake empty_submodule.depend && mmake empty_submodule
    gmake: *** No rule to make target 'empty_submodule.nested.int', needed by 'empty_submodule.c_date'. Stop.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: empty_submodule.m (469 bytes) 2017-08-06 13:09
    https://bugs.mercurylang.org/file_download.php?file_id=272&type=bug
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    437 [mercury] Bug minor always 2017-08-05 12:35 2017-08-06 02:50
    Reporter: wangp Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: abort on empty nested sub-module
    Description: The compiler throws an exception if a nested sub-module is empty.

    % mmc parent.m
    Uncaught Mercury exception:
    Software Error: map.det_remove: key not found
        Key Type: mdbcomp.sym_name.sym_name
        Key Value: qualified(unqualified("parent"), "sub")
        Value Type: parse_tree.split_parse_tree_src.split_module_entry
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: parent.m (169 bytes) 2017-08-05 12:35
    https://bugs.mercurylang.org/file_download.php?file_id=270&type=bug
     
    Notes
    (0000956)
    zs   
    2017-08-06 02:50   
    Fix committed 5 aug 2017.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    438 [mercury] Bug minor always 2017-08-05 14:55 2017-08-05 14:55
    Reporter: wangp Platform:  
    Assigned To: OS:  
    Priority: normal OS Version:  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: partial module qualification of use_module imported entity
    Description: Commit 5649f36 (Handle "use_module in interface, import_module in implementation") changed the language definition such that entities imported via use_module must be *fully* module qualified.

    In the attached test case, we are still able to refer to a partially qualified bar.baz.in_baz (should be foo.bar.baz.in_baz).
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: submodule_test.tar.gz (10,240 bytes) 2017-08-05 14:55
    https://bugs.mercurylang.org/file_download.php?file_id=271&type=bug
     
    There are no notes attached to this issue.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    410 [mercury] Bug minor always 2016-06-17 10:29 2017-06-17 11:00
    Reporter: juliensf Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Syntax error causes compiler abort
    Description: In the attached program a missing parenthesis in a predmode declaration is causing the following
    compiler abort:

    Uncaught Mercury exception:
    Software Error: map.lookup: key not found
        Key Type: int
        Key Value: 1
        Value Type: hlds.hlds_pred.proc_info

    This is occurring with rotd-2016-06-09.
    Tags:
    Steps To Reproduce:
    Additional Information: Mercury 14.01 correctly reports the syntax error:
    Attached Files: bug410.m (2,810 bytes) 2016-06-17 10:29
    https://bugs.mercurylang.org/file_download.php?file_id=256&type=bug
     
    Notes
    (0000953)
    zs   
    2017-06-17 11:00   
    Fix committed 17 june 2017.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    436 [mercury] Bug minor always 2017-04-28 16:38 2017-05-03 10:42
    Reporter: wangp Platform:  
    Assigned To: juliensf OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: unknown constructor in foreign_enum
    Description: The compiler silently allows a constructor in a pragma foreign_enum that do not correspond a constructor of the type.
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: foreign_enum_unknown_ctor.m (207 bytes) 2017-04-28 16:38
    https://bugs.mercurylang.org/file_download.php?file_id=269&type=bug
     
    Notes
    (0000951)
    juliensf   
    2017-04-28 16:45   
    That's a bit naughty of it -- I'll take a look it.
    (0000952)
    juliensf   
    2017-05-03 10:42   
    Fixed in commit c40f4300f.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    431 [mercury] Bug minor have not tried 2017-03-05 23:52 2017-03-06 15:45
    Reporter: dirkz Platform: Mac  
    Assigned To: juliensf OS: OS X Yosemite  
    Priority: normal OS Version: 10.10.5  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: Install fails during make install of java grade in rotd-2017-02-22
    Description: The installation of Mercury with the default set of grades fails on Mac OS X during installation of the Java grade.
    Tags:
    Steps To Reproduce: 1. sh configure (OK)
    2. make PARALLEL=-j6 (OK)
    3. make PARALLEL=-j6 install (ERROR; see attached mer_std.err)
    Additional Information:
    Attached Files: mer_std.err (4,090 bytes) 2017-03-05 23:52
    https://bugs.mercurylang.org/file_download.php?file_id=268&type=bug
     
    Notes
    (0000940)
    juliensf   
    2017-03-06 01:15   
    What are the versions of OS X and Java are you using?
    (0000941)
    dirkz   
    2017-03-06 04:45   
    I'm using Mac OS X Yosemite 10.10.5

    Entering "java -version" in terminal shows this result:
    java version "1.6.0_65"
    Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
    Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)
    (0000942)
    juliensf   
    2017-03-06 08:42   
    Ah, the OS version was above -- my phone chose to display it using a tiny font so I couldn't read it :-(

    It looks as though we are generating code that is not compatible with Java 1.6 for the uint type.
    I think I know what the problem is. (I can confirm that the current ROTD does work with Java 1.8,
    so if that's an option, you may wish to use that until a fix is available.)
    (0000943)
    juliensf   
    2017-03-06 15:45   
    Fixed in rotd-2017-03-06. (Part of the MLDS->Java code generator was not handling the builtin uint type correctly; the problem would only show in versions of Java that don't support autoboxing.)




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    430 [mercury] Bug minor always 2017-01-28 17:47 2017-01-29 14:39
    Reporter: wangp Platform:  
    Assigned To: juliensf OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: optional underscores in numeric literals
    Description: The parser does not accept these literals:

    0_0
    0_0.0
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files:
     
    Notes
    (0000939)
    juliensf   
    2017-01-29 14:39   
    Fixed in commit b3835dd.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    429 [mercury] Bug minor always 2017-01-19 18:47 2017-01-20 04:24
    Reporter: wangp Platform:  
    Assigned To: zs OS:  
    Priority: normal OS Version:  
    Status: resolved Product Version:  
    Product Build: Resolution: fixed  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: cse causes switch to be reported as non-switch
    Description: The compiler reports for the given test case:

    switch_scope.m:016: Error: the goal inside the require_complete_switch [Index]
    switch_scope.m:016: scope is not a switch on `Index'.


    The problem is more apparent from the HLDS dump. After pass 045-cse the predicate looks like:

    switch_scope.clear(I, P0, P) :-
      require_complete_switch [Index] (
        ( % conjunction
          P0 = pair.(V_15 - V_14)
          ,
          ( % cannot_fail switch on `I'
            % I has functor switch_scope.first/0
            ( % conjunction
              V_12 = V_15
              ,
              Y = V_14
              ,
              V_12 = bool.yes
              ,
              V_13 = bool.no
              ,
              P = pair.(V_13 - Y)
            )
          ;
            % I has functor switch_scope.second/0
            ( % conjunction
              V_15 = X
              ,
              V_14 = V_10
              ,
              V_10 = bool.yes
              ,
              V_11 = bool.no
              ,
              P = pair.(X - V_11)
            )
          )
        )
      ).
    Tags:
    Steps To Reproduce:
    Additional Information:
    Attached Files: switch_scope.m (425 bytes) 2017-01-19 18:47
    https://bugs.mercurylang.org/file_download.php?file_id=267&type=bug
     
    Notes
    (0000938)
    zs   
    2017-01-20 04:24   
    Fix committed 2017 jan 20.




    View Issue Details
    ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
    428 [mercury] Bug major always 2016-10-25 06:14 2016-10-25 06:14
    Reporter: lpimmes Platform: Dell Precision laptop  
    Assigned To: OS: Ubuntu  
    Priority: urgent OS Version: 16.04  
    Status: new Product Version:  
    Product Build: Resolution: open  
    Projection: none      
    ETA: none Fixed in Version:  
        Target Version:  
    Summary: standalone_c complains about return value 0 (OK) from main/2.
    Description: Modified mercury_lib.m to output "STANDALONE" on console.

    Any help would be appreciated.
    Thanks.
    Tags:
    Steps To Reproduce: luke@luke-Precision-7710:~/mercury/standalone_c$ ls
    c_main.c Makefile mercury_lib.m

    *.c and Makefile are original files from installation.

    > make
    mmc --make libmercury_lib
    Making Mercury/int3s/mercury_lib.int3
    Making Mercury/ints/mercury_lib.int
    Making Mercury/cs/mercury_lib.c
    Making Mercury/os/mercury_lib.o
    Mercury/cs/mercury_lib.c:247:1: warning: return type of ‘main’ is not ‘int’ [-Wmain]
     main(void)
     ^
    Making libmercury_lib.a
    Making Mercury/os/mercury_lib.pic_o
    Mercury/cs/mercury_lib.c:247:1: warning: return type of ‘main’ is not ‘int’ [-Wmain]
     main(void)
     ^
    Making libmercury_lib.so
    ** Error making `libmercury_lib.so'.
    /usr/bin/ld: cannot find -lmer_std
    /usr/bin/ld: cannot find -lmer_rt
    collect2: error: ld returned 1 exit status
    Makefile:123: recipe for target 'mercury_lib.init' failed
    make: *** [mercury_lib.init] Error 1
    luke@luke-Precision-7710:~/mercury/standalone_c$
    Additional Information: mmc: 14.01
    Attached Files: standalone_c.tar.gz (30,720 bytes) 2016-10-25 06:14
    https://bugs.mercurylang.org/file_download.php?file_id=266&type=bug
     
    There are no notes attached to this issue.