Mercury Bugs

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

569

[mercury] Bug

minor

always

2023-12-04 12:26

2023-12-06 12:51

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:

timestamp regression with nested submodules in mmc --make

Description:

Here is a problem with nested submodules attributed to commit 4d4ef3e3a "Cache timestamps by target file."

This sequence of commands:
```
#!/bin/sh
touch nested_module_test.m
mmc -m nested_module_test
sleep 1
echo --------
mmc -m nested_module_test
```

exhibits this incorrect behaviour:

Making Mercury/int3s/nested_module_test.int3
Making Mercury/int0s/nested_module_test.int0
Making Mercury/ints/nested_module_test.int
Making Mercury/cs/nested_module_test.c
Making Mercury/os/nested_module_test.o
Making nested_module_test
--------
Making Mercury/int3s/nested_module_test.int3
Making Mercury/os/nested_module_test.sub.o
Making nested_module_test

where nested_module_test.sub.o and nested_module_test are re-made by the second call to mmc --make, when they should already be up-to-date.

The previous (correct) behaviour is:

Making Mercury/int3s/nested_module_test.int3
Making Mercury/int0s/nested_module_test.int0
Making Mercury/ints/nested_module_test.int
Making Mercury/cs/nested_module_test.c
Making Mercury/os/nested_module_test.o
Making Mercury/os/nested_module_test.sub.o
Making nested_module_test
--------
Making Mercury/int3s/nested_module_test.int3
** Nothing to be done for `nested_module_test'.

[Actually, nested_module_test.int3 should not need to be remade either - that is a long-standing bug, but a minor one.]

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

nested_module_test.m (651 bytes) 2023-12-04 12:26
https://bugs.mercurylang.org/file_download.php?file_id=326&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

568

[mercury] Bug

major

always

2023-12-04 10:35

2023-12-05 13:42

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:

nested sub-modules broken in mmc --make

Description:

mmc --make fails to make programs making using of nested sub-modules.

The problem first appears with commit 764eab72a "Stop using module_dep_infos in computing filenames."

% mmc --make nested_module_test
** dependencies for `Mercury/int3s/nested_module_test.int3' do not exist: nested_module_test.sub.m
** This indicates a bug in `mmc --make'.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

nested_module_test.m (651 bytes) 2023-12-04 10:35
https://bugs.mercurylang.org/file_download.php?file_id=325&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

567

[mercury] Bug

major

always

2023-11-07 13:00

2023-11-08 17:59

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:

regression due to merging consecutive switches

Description:

I have bisected a regression to commit 43dd12bd5b9608dcd150ea0c7bdc1e3f256f15d2
"Merge consecutive switches on the same variable."

See the attached test case.

This is incorrect:

% mmc -O2 regression_merge_switches && ./regression_merge_switches
header(field_name("Message-ID"), header_value("Tue, 7 Nov 2023 12:29:43 +1100"))
header(field_name("Message-ID"), header_value("<20231107122943.GB219@example>"))

The correct output is this:

% mmc -O1 regression_merge_switches && ./regression_merge_switches
header(field_name("Date"), header_value("Tue, 7 Nov 2023 12:29:43 +1100"))
header(field_name("Message-ID"), header_value("<20231107122943.GB219@example>"))

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

regression_merge_switches.m (2,046 bytes) 2023-11-07 13:00
https://bugs.mercurylang.org/file_download.php?file_id=324&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

566

[mercury] Bug

minor

always

2023-10-12 12:40

2023-10-16 17:01

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:

undefined variable warnings with GNU Make 4.4.0.90

Description:

Since GNU Make 4.4.0.90, we get warnings about undefined variables '*' and '@':

/tmp/mmake.RTEA5X:64: warning: undefined variable '*'
/tmp/mmake.RTEA5X:64: warning: undefined variable '@'
/tmp/mmake.RTEA5X:64: warning: undefined variable '@'

The problem first appears with GNU Make commit 15dfad96d77c9445d11be939a5042675e4ca8c65 "[SV 63439, SV 63452] Don't warn on undefined internal variables"
https://git.savannah.gnu.org/cgit/make.git/commit/?id=15dfad96d77c9445d11be939a5042675e4ca8c65

The code that ultimately triggers these warnings is in Mmake.vars.in, from lines 374 onwards, that says:

# `TARGET_<prog>FLAGS' is used to pass different flags to <prog> for
# different targets. By setting MCFLAGS-foo, for example, you can add
# extra values to TARGET_MCFLAGS that will used only for compiling foo.m.
#
# For each program <prog>, `TARGET_<prog>FLAGS' expands to
# `$(<prog>FLAGS-$@)' and/or `$(<prog>FLAGS-$*)'.
# $@ and $* are the builtin variables that expand to the
# current target and (for pattern rules) the base name of the current target,
# respectively. So $* is used for flags variables used by pattern rules,
# whereas $@ is used for flags variables used by hard-coded rules,
# including the ones in the generated .dep files.
#
# The code below uses some tricky GNU Make hacks to avoid expanding
# <prog>FLAGS-$* and <prog>FLAGS-$@ if these vars are not defined,
# so that we can avoid spurious warnings if the warning about
# undefined variables is enabled.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

VPATH is evaluated once before considering any target, and
this value of VPATH is used to find prerequisites of all targets (from what I gather).

Here is a makefile for demonstration:

    VPATH = srcs.$@ \
        $(shell echo Evaluating VPATH now for target [$@] >&2 )

    # Put foo.c in srcs.foo
    foo: foo.c
        @echo VPATH in recipe is $(VPATH)

    # Put bar.c in current dir
    bar: bar.c
        @echo VPATH in recipe is $(VPATH)

This is the log for `make --warn-undefined-variables -d -r foo`.
foo.c cannot be found because VPATH is set to "srcs.", and *not* "srcs.foo".

    GNU Make 4.4.1
    Built for x86_64-unknown-linux-gnu
    Copyright (C) 1988-2023 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    Reading makefiles...
    Reading makefile 'Makefile'...
    Makefile:1: warning: undefined variable '@'
    Makefile:1: warning: undefined variable '@'
    Evaluating VPATH now for target []
    Updating makefiles....
     Considering target file 'Makefile'.
      Looking for an implicit rule for 'Makefile'.
      No implicit rule found for 'Makefile'.
     Finished prerequisites of target file 'Makefile'.
     No need to remake target 'Makefile'.
    Updating goal targets....
    Considering target file 'foo'.
     Considering target file 'foo.c'.
      File 'foo.c' does not exist.
      Looking for an implicit rule for 'foo.c'.
      No implicit rule found for 'foo.c'.
     Finished prerequisites of target file 'foo.c'.
     Must remake target 'foo.c'.
    make: *** No rule to make target 'foo.c', needed by 'foo'. Stop.

This is the log for `make --warn-undefined-variables -d -r bar`.
bar.c exists in the current directory so it is found.
VPATH is evaluated again only when executing the recipe, now with $@ set to the target.

    GNU Make 4.4.1
    Built for x86_64-unknown-linux-gnu
    Copyright (C) 1988-2023 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    Reading makefiles...
    Reading makefile 'Makefile'...
    Makefile:1: warning: undefined variable '@'
    Makefile:1: warning: undefined variable '@'
    Evaluating VPATH now for target []
    Updating makefiles....
     Considering target file 'Makefile'.
      Looking for an implicit rule for 'Makefile'.
      No implicit rule found for 'Makefile'.
     Finished prerequisites of target file 'Makefile'.
     No need to remake target 'Makefile'.
    Updating goal targets....
    Considering target file 'bar'.
     File 'bar' does not exist.
     Considering target file 'bar.c'.
      Looking for an implicit rule for 'bar.c'.
      No implicit rule found for 'bar.c'.
     Finished prerequisites of target file 'bar.c'.
     No need to remake target 'bar.c'.
    Finished prerequisites of target file 'bar'.
    Must remake target 'bar'.
    Evaluating VPATH now for target [bar]
    Makefile:10: update target 'bar' due to: target does not exist
    echo VPATH in recipe is srcs.bar
    Putting child 0x557e7dcb1010 (bar) PID 18703 on the chain.
    Live child 0x557e7dcb1010 (bar) PID 18703
    VPATH in recipe is srcs.bar
    Reaping winning child 0x557e7dcb1010 PID 18703
    Removing child 0x557e7dcb1010 PID 18703 from chain.
    Successfully remade target file 'bar'.
    Directory srcs. cache invalidated (count 2 != command 4)

So what mmake tries to do with VPATH (i.e. trying to take into account target-specific flags to change where to look for prerequisites) probably never actually worked.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

208

[mercury] Bug

feature

N/A

2011-07-31 15:38

2023-10-08 12:24

Reporter:

aross

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:

add help and version command line options to mslice and mdice

Description:

-h and -v are pretty standard command line options, but mslice and mdice don't support them. For example:

ajrross@goofy:~$ mslice -h
unrecognized option `-h'

Since the usage information of both programs is already displayed when the user gives an incorrect number of arguments, -h could show the same information.

Tags:

Steps To Reproduce:

Additional Information:

version rotd-2011-07-29

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

563

[mercury] Bug

crash

always

2022-08-03 13:04

2023-09-04 15:05

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

565

[mercury] Bug

major

have not tried

2023-09-04 00:27

2023-09-04 14:07

Reporter:

juliensf

Platform:

Assigned To:

juliensf

OS:

Priority:

normal

OS Version:

Status:

assigned

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Installed mmake cannot build programs

Description:

Attempting to build hello word, using the mmake from an installed compiler results in:

gmake: *** No rule to make target `builtin.int', needed by `hello.c_date'. Stop.

This appears to be occurring as far back as rotd-2023-07-01 (which is the oldest compiler I have
installed on my system).

Tags:

Steps To Reproduce:

$ mmake hello.depend
$ mmake hello

Additional Information:

Linux x86_64 / gcc 4.8.5

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

494

[mercury] Bug

minor

have not tried

2020-01-23 11:41

2023-08-02 11:11

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:

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

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

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

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

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:

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

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

561

[mercury] Bug

minor

have not tried

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

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

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:

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

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

555

[mercury] Feature Request

minor

N/A

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

553

[mercury] Feature Request

minor

have not tried

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:

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

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

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

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:

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

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:

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

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[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

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:

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

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?

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

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:

Platform:

Assigned To:

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

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:

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

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:

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:

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

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:

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

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:

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

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:

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

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

540

[mercury] Feature Request

minor

have not tried

2021-11-08 17:29

Reporter:

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:

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

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

537

[mercury] Feature Request

feature

N/A

2021-08-31 20:40

Reporter:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

535

[mercury] Bug

minor

always

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

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:

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

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

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:

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

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:

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

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

527

[mercury] Bug

minor

always

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:

[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

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

525

[mercury] Bug

minor

have not tried

2020-10-29 19:35

Reporter:

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:

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

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:

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

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:

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

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:

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

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:

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

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:

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

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

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

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

517

[mercury] Bug

minor

always

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:

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

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:

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

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

511

[mercury] Bug

minor

always

2020-06-19 18:22

Reporter:

Platform:

Assigned To:

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

Reporter:

Platform:

Assigned To:

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

507

[mercury] Feature Request

minor

have not tried

2020-05-01 17:52

Reporter:

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:

Platform:

Assigned To:

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:

Platform:

Assigned To:

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

504

[mercury] Feature Request

minor

have not tried

2020-04-28 23:58

Reporter:

Platform:

Assigned To:

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:

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

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

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:

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

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.

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

498

[mercury] Feature Request

minor

have not tried

2020-04-04 21:01

Reporter:

Platform:

Assigned To:

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

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:

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:

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

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:

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

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:

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

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

491

[mercury] Feature Request

minor

have not tried

2020-01-12 22:32

Reporter:

Platform:

Assigned To:

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

Reporter:

Platform:

Assigned To:

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:

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

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:

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

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:

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

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:

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

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

482

[mercury] Bug

minor

have not tried

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:

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

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:

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

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:

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

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:

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

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:

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

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

475

[mercury] Feature Request

minor

N/A

2019-02-04 01:14

Reporter:

Platform:

Assigned To:

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

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

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:

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

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:

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:

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

471

[mercury] Bug

minor

always

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

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

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

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

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

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:

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

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

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

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

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.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

466

[mercury] Bug

minor

have not tried

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

Reporter:

yuan

Platform:

MS-VisualC2010

Assigned To:

OS:

Windows

Priority:

normal

OS Version:

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

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:

Platform:

Assigned To:

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:

Platform:

Assigned To:

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

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:

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:

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

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

456

[mercury] Feature Request

minor

N/A

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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:

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

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

450

[mercury] Bug

minor

sometimes

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

Reporter:

Platform:

Assigned To:

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

Reporter:

Platform:

Assigned To:

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

Reporter:

Platform:

Assigned To:

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

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

443

[mercury] Bug

minor

always

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

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:

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

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