Mercury Bugs

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

573

[mercury] Bug

minor

always

2024-02-22 15:16

2024-02-23 16:44

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:

mmc --make regression remaking .opt files unnecessarily

Description:

Commit 8b5cc5125 ("Use string builders for .*opt files.")
introduces a regression where .opt files are remade unnecessarily.
Using the samples/diff program for example:

    % mmc --intermod-opt -j32 -m diff
    [... trimmed output ...]
    Making diff

    % touch match.m

    % mmc --intermod-opt -m diff
    Making Mercury/int3s/match.int3
    Making Mercury/ints/match.int
    Making Mercury/opts/match.opt
    ** Nothing to be done for `diff'.

    % mmc --intermod-opt -m diff
    Making Mercury/int3s/match.int3
    Making Mercury/opts/match.opt
    ** Nothing to be done for `diff'.

where every subsequent invocation of mmc --make will keep remaking match.opt.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

572

[mercury] Bug

minor

always

2024-02-19 10:44

2024-02-20 17:38

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:

Code generator abort in debugging grades

Description:

The attached is a cut-down version of a program that causes an abort in debugging grades originally reported by Volker Wysk on the reviews list on 3 January 2024. Compiling it in a debugging grade results in:

Uncaught Mercury exception:
Software Error: predicate `ll_backend.liveness.require_equal'/4: Unexpected: branches of if-then-else disagree on liveness
First: ArgDesc_3, Values_4, MDef_5, Default_6, TypeClassInfo_for_argument_21, TypeInfo_22_22
Rest: ArgDesc_3, Values_4, MDef_5, Default_6, TypeInfo_22_22

Tags:

Steps To Reproduce:

mmc -s asm_fast.gc.debug -C bug572.m

Additional Information:

https://lists.mercurylang.org/archives/reviews/2024-January/024517.html

Attached Files:

bug572.m (2,643 bytes) 2024-02-19 10:44
https://bugs.mercurylang.org/file_download.php?file_id=329&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

571

[mercury] Feature Request

minor

have not tried

2024-02-09 15:29

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:

Improve unsatisfiable typeclass constraint errors

Description:

The attached program generates the following error messages:

    unsat_error.m:015: In clause for predicate `create_schedule'/3:
    unsat_error.m:015: unsatisfiable typeclass constraint:
    unsat_error.m:015: `unsat_error.logger(L)'.

For cases like this it would better if we could provide the user some indication of the cause of this constraint being unsatisfiable, namely that the there is no constraint on the type variable Logger in the predicate declaration.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

unsat_error.m (314 bytes) 2024-02-09 15:29
https://bugs.mercurylang.org/file_download.php?file_id=328&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

570

[mercury] Bug

crash

always

2023-12-13 13:20

2023-12-13 19: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:

merge switch after switch bug

Description:

The compiler aborts during the deforestation, when simplify tries to merge a switch after switch:

% mmc -C --deforestation bug.m
Uncaught Mercury exception:
Software Error: map.lookup: key not found
        Key Type: parse_tree.prog_data.cons_id
        Key Value: cons(qualified(unqualified("bug"), "prepare_edit"), 0, type_ctor(qualified(unqualified("bug"), "prepare_temp"), 0))
        Value Type: uint
Stack dump follows:
   0 pred exception.throw/1-0 (erroneous) (exception.m:312)
   1 pred require.error/1-0 (erroneous) (require.m:173)
   2 pred require.report_lookup_error/3-0 (erroneous) (require.m:277)
   3 pred map.lookup/3-0 (det) (map.m:1333)
   4 pred check_hlds.simplify.simplify_goal_conj.build_maps_second_switch_cons_id/5-0 (det) (simplify_goal_conj.m:663)
   5 pred check_hlds.simplify.simplify_goal_conj.build_maps_second_switch/7-0 (det) (simplify_goal_conj.m:648)
   6 pred check_hlds.simplify.simplify_goal_conj.try_to_merge_switch_after_switch/6-0 (det) (simplify_goal_conj.m:586)
   7 6* pred check_hlds.simplify.simplify_goal_conj.simplify_conj/10-0 (det) (simplify_goal_conj.m:285 and others)
  13 pred check_hlds.simplify.simplify_goal_conj.simplify_goal_plain_conj/10-0 (det) (simplify_goal_conj.m:82)
  14 pred check_hlds.simplify.simplify_goal.simplify_goal_expr/10-0 (det) (simplify_goal.m:331)
  15 pred check_hlds.simplify.simplify_goal.simplify_goal/8-0 (det) (simplify_goal.m:285)
  16 2* pred check_hlds.simplify.simplify_goal_switch.simplify_switch_cases/15-0 (det) (simplify_goal_switch.m:278 and others)
  18 pred check_hlds.simplify.simplify_goal_switch.simplify_goal_switch/10-0 (det) (simplify_goal_switch.m:85)
  19 pred check_hlds.simplify.simplify_goal.simplify_goal_expr/10-0 (det) (simplify_goal.m:344)
  20 pred check_hlds.simplify.simplify_goal.simplify_goal/8-0 (det) (simplify_goal.m:285)
  21 pred check_hlds.simplify.simplify_proc.do_simplify_top_level_goal/6-0 (det) (simplify_proc.m:708)
  22 pred check_hlds.simplify.simplify_proc.simplify_top_level_goal/7-0 (det) (simplify_proc.m:611)
  23 pred check_hlds.simplify.simplify_proc.simplify_goal_update_vars_in_proc/11-0 (det) (simplify_proc.m:201)
  24 pred transform_hlds.pd_util.pd_simplify_goal/5-0 (det) (pd_util.m:264)
  25 pred transform_hlds.deforest.push_goal_into_goal/8-0 (det) (deforest.m:1844)
  26 pred transform_hlds.deforest.handle_deforestation/9-0 (det) (deforest.m:761)
  27 3* pred transform_hlds.deforest.deforest_conj/6-0 (det) (deforest.m:566 and others)
  30 pred transform_hlds.deforest.deforest_goal_expr/6-0 (det) (deforest.m:319)
  31 pred transform_hlds.deforest.deforest_goal/4-0 (det) (deforest.m:294)
  32 pred transform_hlds.deforest.deforest_proc_deltas/5-0 (det) (deforest.m:230)
  33 pred transform_hlds.deforest.deforest_proc/3-0 (det) (deforest.m:204)
  34 5* pred list.foldl/4-0 (det) (list.m:3731 and others)
  39 pred transform_hlds.deforest.deforest_module/3-0 (det) (deforest.m:132)
  40 pred top_level.mercury_compile_middle_passes.maybe_deforestation/7-0 (det) (mercury_compile_middle_passes.m:1130)
  41 pred top_level.mercury_compile_middle_passes.middle_pass/10-0 (det) (mercury_compile_middle_passes.m:232)
  42 pred top_level.mercury_compile_main.after_front_end_passes/15-0 (det) (mercury_compile_main.m:2177)
  43 pred top_level.mercury_compile_main.process_augmented_module/17-0 (det) (mercury_compile_main.m:2052)
  44 pred top_level.mercury_compile_main.augment_and_process_module/15-0 (det) (mercury_compile_main.m:1926)
  45 pred list.map_foldl3/9-0 (det) (list.m:4080)
  46 pred top_level.mercury_compile_main.augment_and_process_all_submodules/16-0 (det) (mercury_compile_main.m:1872)
  47 pred top_level.mercury_compile_main.read_augment_and_process_module_ok/17-0 (det) (mercury_compile_main.m:1730)
  48 pred top_level.mercury_compile_main.read_augment_and_process_module/15-0 (det) (mercury_compile_main.m:1672)
  49 pred top_level.mercury_compile_main.do_process_compiler_arg/13-0 (det) (mercury_compile_main.m:1238)
  50 pred top_level.mercury_compile_main.setup_and_process_compiler_arg/17-0 (det) (mercury_compile_main.m:1102)
  51 pred top_level.mercury_compile_main.setup_and_process_compiler_cmd_line_args/19-0 (det) (mercury_compile_main.m:1013)
  52 pred top_level.mercury_compile_main.do_op_mode_args/16-0 (det) (mercury_compile_main.m:859)
  53 pred top_level.mercury_compile_main.do_op_mode/14-0 (det) (mercury_compile_main.m:662)
  54 pred top_level.mercury_compile_main.main_after_setup/9-0 (det) (mercury_compile_main.m:614)
  55 pred top_level.mercury_compile_main.real_main_after_expansion/5-0 (det) (mercury_compile_main.m:315)
  56 pred top_level.mercury_compile_main.real_main/2-0 (det) (mercury_compile_main.m:153)
  57 pred mercury_compile.main/2-0 (det) (mercury_compile.m:32)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug.m (2,436 bytes) 2023-12-13 13:20
https://bugs.mercurylang.org/file_download.php?file_id=327&type=bug

There are no notes attached to this issue.

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

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

440

[mercury] Feature Request

minor

N/A

2017-08-10 11:08

Reporter:

wangp

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

mdb: tab completion for function symbols

Description:

It would improve the mdb experience greatly if you could tab complete function symbols in the term path part of a print command (and the browser?). For unnamed fields it may be worth cycling through the argument numbers. If the current subterm has exactly one argument, TAB could complete that without any prefix from the user.

pp 5/1/box_content/1/1/5/1/2/1/box_content/1/1/1/5/1/1/spanbox_content

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

439

[mercury] Bug

minor

always

2017-08-06 13:09

Reporter:

wangp

Platform:

Assigned To:

OS:

Priority:

low

OS Version:

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

cannot build module which imports empty nested sub-module

Description:

Both mmc --make and mmake are unable to build a module which tries to import an empty nested sub-module. Obviously this is extremely low priority, and the fix may be to disallow such sub-modules.

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

% mmake empty_submodule.depend && mmake empty_submodule
gmake: *** No rule to make target 'empty_submodule.nested.int', needed by 'empty_submodule.c_date'. Stop.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

empty_submodule.m (469 bytes) 2017-08-06 13:09
https://bugs.mercurylang.org/file_download.php?file_id=272&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

437

[mercury] Bug

minor

always

2017-08-05 12:35

2017-08-06 02:50

Reporter:

wangp

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

abort on empty nested sub-module

Description:

The compiler throws an exception if a nested sub-module is empty.

% mmc parent.m
Uncaught Mercury exception:
Software Error: map.det_remove: key not found
    Key Type: mdbcomp.sym_name.sym_name
    Key Value: qualified(unqualified("parent"), "sub")
    Value Type: parse_tree.split_parse_tree_src.split_module_entry

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

parent.m (169 bytes) 2017-08-05 12:35
https://bugs.mercurylang.org/file_download.php?file_id=270&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

438

[mercury] Bug

minor

always

2017-08-05 14:55

Reporter:

wangp

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

partial module qualification of use_module imported entity

Description:

Commit 5649f36 (Handle "use_module in interface, import_module in implementation") changed the language definition such that entities imported via use_module must be *fully* module qualified.

In the attached test case, we are still able to refer to a partially qualified bar.baz.in_baz (should be foo.bar.baz.in_baz).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

submodule_test.tar.gz (10,240 bytes) 2017-08-05 14:55
https://bugs.mercurylang.org/file_download.php?file_id=271&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

410

[mercury] Bug

minor

always

2016-06-17 10:29

2017-06-17 11:00

Reporter:

juliensf

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Syntax error causes compiler abort

Description:

In the attached program a missing parenthesis in a predmode declaration is causing the following
compiler abort:

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

This is occurring with rotd-2016-06-09.

Tags:

Steps To Reproduce:

Additional Information:

Mercury 14.01 correctly reports the syntax error:

Attached Files:

bug410.m (2,810 bytes) 2016-06-17 10:29
https://bugs.mercurylang.org/file_download.php?file_id=256&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

436

[mercury] Bug

minor

always

2017-04-28 16:38

2017-05-03 10:42

Reporter:

wangp

Platform:

Assigned To:

juliensf

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

unknown constructor in foreign_enum

Description:

The compiler silently allows a constructor in a pragma foreign_enum that do not correspond a constructor of the type.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

foreign_enum_unknown_ctor.m (207 bytes) 2017-04-28 16:38
https://bugs.mercurylang.org/file_download.php?file_id=269&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

431

[mercury] Bug

minor

have not tried

2017-03-05 23:52

2017-03-06 15:45

Reporter:

dirkz

Platform:

Mac

Assigned To:

juliensf

OS:

OS X Yosemite

Priority:

normal

OS Version:

10.10.5

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Install fails during make install of java grade in rotd-2017-02-22

Description:

The installation of Mercury with the default set of grades fails on Mac OS X during installation of the Java grade.

Tags:

Steps To Reproduce:

1. sh configure (OK)
2. make PARALLEL=-j6 (OK)
3. make PARALLEL=-j6 install (ERROR; see attached mer_std.err)

Additional Information:

Attached Files:

mer_std.err (4,090 bytes) 2017-03-05 23:52
https://bugs.mercurylang.org/file_download.php?file_id=268&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

430

[mercury] Bug

minor

always

2017-01-28 17:47

2017-01-29 14:39

Reporter:

wangp

Platform:

Assigned To:

juliensf

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

optional underscores in numeric literals

Description:

The parser does not accept these literals:

0_0
0_0.0

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

429

[mercury] Bug

minor

always

2017-01-19 18:47

2017-01-20 04:24

Reporter:

wangp

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

cse causes switch to be reported as non-switch

Description:

The compiler reports for the given test case:

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

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

switch_scope.clear(I, P0, P) :-
  require_complete_switch [Index] (
    ( % conjunction
      P0 = pair.(V_15 - V_14)
      ,
      ( % cannot_fail switch on `I'
        % I has functor switch_scope.first/0
        ( % conjunction
          V_12 = V_15
          ,
          Y = V_14
          ,
          V_12 = bool.yes
          ,
          V_13 = bool.no
          ,
          P = pair.(V_13 - Y)
        )
      ;
        % I has functor switch_scope.second/0
        ( % conjunction
          V_15 = X
          ,
          V_14 = V_10
          ,
          V_10 = bool.yes
          ,
          V_11 = bool.no
          ,
          P = pair.(X - V_11)
        )
      )
    )
  ).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

switch_scope.m (425 bytes) 2017-01-19 18:47
https://bugs.mercurylang.org/file_download.php?file_id=267&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

428

[mercury] Bug

major

always

2016-10-25 06:14

Reporter:

lpimmes

Platform:

Dell Precision laptop

Assigned To:

OS:

Ubuntu

Priority:

urgent

OS Version:

16.04

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

standalone_c complains about return value 0 (OK) from main/2.

Description:

Modified mercury_lib.m to output "STANDALONE" on console.

Any help would be appreciated.
Thanks.

Tags:

Steps To Reproduce:

luke@luke-Precision-7710:~/mercury/standalone_c$ ls
c_main.c Makefile mercury_lib.m

*.c and Makefile are original files from installation.

> make
mmc --make libmercury_lib
Making Mercury/int3s/mercury_lib.int3
Making Mercury/ints/mercury_lib.int
Making Mercury/cs/mercury_lib.c
Making Mercury/os/mercury_lib.o
Mercury/cs/mercury_lib.c:247:1: warning: return type of ‘main’ is not ‘int’ [-Wmain]
main(void)
^
Making libmercury_lib.a
Making Mercury/os/mercury_lib.pic_o
Mercury/cs/mercury_lib.c:247:1: warning: return type of ‘main’ is not ‘int’ [-Wmain]
main(void)
^
Making libmercury_lib.so
** Error making `libmercury_lib.so'.
/usr/bin/ld: cannot find -lmer_std
/usr/bin/ld: cannot find -lmer_rt
collect2: error: ld returned 1 exit status
Makefile:123: recipe for target 'mercury_lib.init' failed
make: *** [mercury_lib.init] Error 1
luke@luke-Precision-7710:~/mercury/standalone_c$

Additional Information:

mmc: 14.01

Attached Files:

standalone_c.tar.gz (30,720 bytes) 2016-10-25 06:14
https://bugs.mercurylang.org/file_download.php?file_id=266&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

427

[mercury] Bug

minor

have not tried

2016-10-23 01:54

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:

Use of long and unsigned long in C runtime code

Description:

Various parts of the C version of the Mercury runtime cast things to 'long' or 'unsigned long', presumably on the assumption that this is equal to or greater than the size of MR_Word, MR_Integer, MR_Unsigned.
This assumption is untrue on 64-bit Windows systems were longs are 32-bit quantities. Most of this was cleaned up during the development of the initial 64-bit Windows port, but there are still various spots (mainly debugging code) that do this.

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:

425

[mercury] Bug

minor

always

2016-10-06 13:23

2016-10-10 20: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:

mmc --make loop on wrongly named module

Description:

Test case:

echo 'module rong_name.' >wrong_name.m
mmc -m wrong_name --debug-make

produces

Module dependencies file 'Mercury/module_deps/wrong_name.module_dep' not found in directories `.', `/home/wangp/local/stow/mercury-srcdist-rotd-2016-10-04/lib/mercury/ints'.
Module dependencies file 'Mercury/module_deps/wrong_name.module_dep' not found in directories `.', `/home/wangp/local/stow/mercury-srcdist-rotd-2016-10-04/lib/mercury/ints'.
Module dependencies file 'Mercury/module_deps/wrong_name.module_dep' not found in directories `.', `/home/wangp/local/stow/mercury-srcdist-rotd-2016-10-04/lib/mercury/ints'.

etc. until the process runs out of file descriptors.

Started occurring between rotd-2015-07-01 and rotd-2015-08-10 (that I have installed).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

424

[mercury] Bug

minor

always

2016-10-04 12:13

2016-10-07 15:28

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:

error creating temporary file with --restricted-command-line

Description:

This mainly affects Windows, but can be tested on other platforms by passing --restricted-command-line.

% mmc -m e --restricted-command-line
Making Mercury/int3s/e.int3
Making Mercury/ints/e.int
Making Mercury/cs/e.c
Making Mercury/os/e.o
Making e
Could not create temporary file: error opening temporary file: Invalid argument
** Error making `e'.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

418

[mercury] Bug

minor

always

2016-09-07 13:57

2016-10-07 14:34

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:

io error exceptions not working

Description:

There is some problem with exceptions not being thrown or caught properly in low-level C grades, as in the attached test case:

./test|no_such_cmd
zsh: command not found: no_such_cmd
Errno = 32: Broken pipe
Mercury runtime: reached not_reached

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

test.m (633 bytes) 2016-09-07 13:57
https://bugs.mercurylang.org/file_download.php?file_id=263&type=bug
throw_from_foreign.m (778 bytes) 2016-09-19 17:53
https://bugs.mercurylang.org/file_download.php?file_id=265&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

346

[mercury] Bug

minor

always

2014-07-11 17:41

2016-10-06 20:27

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:

non-ANSI functions in header files

Description:

dir.mih references DIR, but is included into C files compiled with gcc -ansi. For some reason this elicits an error from the gcc on AIX but seemingly not elsewhere.

There might be other similar problems.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

422

[mercury] Bug

minor

always

2016-10-03 12:40

2016-10-04 21:11

Reporter:

juliensf

Platform:

x86_64

Assigned To:

OS:

OS X

Priority:

normal

OS Version:

10.9.5

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Intermittent runtime aborts in parallel conjunction tests

Description:

Various tests in tests/par_conj intermittently abort on my system with:

Mercury runtime: Unable to init shared engine thread.

For example, with the spawn_many test case, about half the invocations correct and the other
half abort with the above message.

This is occurring in the grade none.par.gc.stseg.ll_debug.

Tags:

Steps To Reproduce:

Additional Information:

The C compiler on my system is:

Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

404

[mercury] Bug

minor

always

2016-02-09 10:05

2016-10-03 13:42

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:

mmc --rebuild not working

Description:

mmc --rebuild is no longer causing anything to be rebuild. (Presumably caused by commit 1fcdc4c)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

357

[mercury] Bug

minor

always

2014-09-02 16:05

2016-10-03 10:58

Reporter:

juliensf

Platform:

x86_64

Assigned To:

juliensf

OS:

OS X

Priority:

normal

OS Version:

10.9

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

15.11

Summary:

Parallel conjunction broken on OS X

Description:

Parallel conjunctions are broken on OS X (I used asm_fast.par.gc, but
this presumably applies to the other grades as well), because although OS X defines the function
sem_init (called from mercury_context.c), it defines it to only return an error.

Possible solutions to this are either to use named semaphores, e.g. with sem_open, or to use
Grand Central Dispatch. (I'm not sure how well the latter would work with GCC though.)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

421

[mercury] Bug

minor

always

2016-10-01 22:59

2016-10-02 11:12

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:

Code generator aborts in parallel conjunction tests

Description:

The following tests are failing with rotd-2016-09-28 in .par grades:

    tests/par_conj/consume_wiat
    tests/par_conj/consume_in_some_branches
    tests/par_conj/consume_in)some_branches_and_after
    tests/par_conj/dep_par_24
    tests/par_conj/dep_par_24b
    tests/par_conj/dep_par_7

The symptoms are something like:

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

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

Tags:

Steps To Reproduce:

Attempting to compile the above in any grade containing a .par grade, e.g.

$ mmc -C --grade asm_fast.par.gc consume_wait

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

398

[mercury] Bug

minor

have not tried

2015-12-09 16:00

2016-09-28 16:04

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:

mercury_compile.exe fails to link on Cygwin64 / MinGW64 with GCC 4.9.X

Description:

Building the compiler on Cygwin64 and some versions of MinGW64 results in the compiler executable failing to link. The error is as follows:

top_level_init.o:top_level_init.c:(.rdata$.refptr._bss_start__[.refptr._bss_start__]+0x0): undefined reference to `_bss_start__'
top_level_init.o:top_level_init.c:(.rdata$.refptr._data_start__[.refptr._data_start__]+0x0):
undefined reference to `_data_start__'
top_level_init.o:top_level_init.c:(.rdata$.refptr._bss_end__[.refptr._bss_end__]+0x0):
undefined reference to `_bss_end__'
top_level_init.o:top_level_init.c:(.rdata$.refptr._data_end__[.refptr._data_end__]+0x0):
undefined reference to `_data_end__'

Tags:

Steps To Reproduce:

Additional Information:

This as reported on the users list at <http://www.mercurylang.org/list-archives/developers/2015-November/016491.html>. I have noticed it myself on Cygwin64 (using Cygwin GCC 4.9.3 and binutils 2.25). Ian has reported it as occurring with MSYS2/MinGW64 GCC 4.9.2 and binutils 2.25. Using MSYS2/MinGW64 GCC 5.2 does work (on my machine), so it may be that there is a problem with GCC 4.9.X on 64-bit Windows. (I haven't tried GCC 5 on Cygwin64 yet as it would need to be built from source.)

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

419

[mercury] Feature Request

minor

always

2016-09-14 12:15

2016-09-21 04:57

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:

cannot write floats in break point conditions

Description:

The mercury_trace_term.c parser does not accept float arguments. I don't know if more work would be required to make the break condition work. It is not very important to me.

mdb> cond 2 != gray(float(1.0))
syntax error in term: gray(float(1.0))
^ here

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

420

[mercury] Bug

major

always

2016-09-14 16:06

2016-09-19 14:31

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:

try goals lost in .opt files

Description:

`try' goals are not written out to .opt files. When the body is open coded into the caller, any exceptions that it was supposed to catch would not be caught.

This is similar to bug 0000391 for trace goals.

The test case currently produces this in the .opt file:

try_goal_opt.bad_try(V_5, V_6, V_10, V_11) :-
    ( % try
      % io(V_10, V_11)
      exception.magic_exception_result(V_12),
      ( % disjunction
        V_12 = exception.succeeded(V_14) : exception.exception_result({}),
        V_14 = {} : {},
        some [] (
          V_15 = V_10,
          call(V_5, V_8, V_15, V_11)
        ),
        some [] (
          V_6 = V_8
        )
      ;
        V_12 = exception.exception(V_13) : exception.exception_result({}),
        V_9 = exception.exc_univ_value(V_13),
        exception.throw(V_9),
        V_11 = V_10
      )
    ).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

try_goal_opt.m (403 bytes) 2016-09-14 16:06
https://bugs.mercurylang.org/file_download.php?file_id=264&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

417

[mercury] Bug

minor

have not tried

2016-09-06 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:

new_arg_ref may return interior pointer

Description:

new_arg_ref (and perhaps other predicates) may return an interior pointer into an object. If all other references to the base object are lost then the object may be garbage collected, leaving references to its arguments dangling.

(I did not try to confirm the bug 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:

416

[mercury] Bug

crash

always

2016-08-31 17:04

Reporter:

maxime

Platform:

Java backend

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:

mutable thread_local java backend missing initialValue()

Description:

In the java backend, when compiling a thread_local mutable, mmc generates a static field
static java.lang.ThreadLocal<Type> module__mutable_variable_name_of_mutable = new java.lang.InheritableThreadLocal<Type>();
which is set via set(...) to the initial value into a initialise declaration (static code block).
The issue is that the InheritableThreadLocal MUST override the initialValue() method, returning the initial value.
Why? because in threads may have been created by a container before the static block has executed, leading in the end to a NullPointerException, because a such a thread from a thread-pool is executing code using the mutable, which does not have a parent-child relation with the thread in which the mutable was initialized.

Tags:

Steps To Reproduce:

Create a module with a thread_local mutable, compile to a jar, create a main java, which creates threads before calling anything from the jar, then from multiple threads, use the mutable.

Additional Information:

The generated code should either be
static java.lang.ThreadLocal<Type> module__mutable_variable_name_of_mutable = new java.lang.InheritableThreadLocal<Type>() {
protected java.lang.Integer initialValue() {return <VALUE>;}
};

Or
static java.lang.ThreadLocal<Type> module__mutable_variable_name_of_mutable;
and in the initialization code, instead of doing a set(...), do a
new java.lang.InheritableThreadLocal<Type>() {
protected java.lang.Integer initialValue() {return <VALUE>;}
};

Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

415

[mercury] Bug

minor

have not tried

2016-08-30 00:50

2016-08-30 18: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:

Segmentation fault during mode checking

Description:

Attempting to compile the attached module (which provides an inst. preserving version of the list module's chunk/3 predicate), results in a segmentation fault on OS X with rotd-2016-08-26. (This is probably a stack overflow rather than anything else, it's just that the OS X is not very good at reporting them as such.)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

ip_chunk.m (1,831 bytes) 2016-08-30 00:50
https://bugs.mercurylang.org/file_download.php?file_id=262&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-08-12 15:57

2016-08-28 13:31

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:

better treatment of absolute pathnames

Description:

The compiler doesn't like absolute pathnames in Mercury.modules files, e.g.

    % mmc -f /tmp/*.m
    % mmc --generate-dependencies foo
    Uncaught Mercury exception:
    Software Error: dir./: second argument is absolute
    Stack dump not available in this grade.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

414

[mercury] Bug

minor

always

2016-07-25 16:53

2016-07-29 03:42

Reporter:

pbone

Platform:

x86_64

Assigned To:

OS:

Linux Mint

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

The switch detection fails to detect this switch

Description:

The switch detection code fails to detect the larger switch, and instead detects a can_fail switch within a disjunction.

    Replay = Loader ^ loader_replay_options,
    (
        ( Replay = replay_none
        ; Replay = replay_save(_)
        ),
        Prefix = Loader ^ loader_prefix
    ;
        Replay = replay_load(_),
        Prefix = Loader ^ loader_replay_prefix
    ).

When I deconstruct Loader outside of the switch and assignment unifications within the switch things work correctly.

Tags:

Steps To Reproduce:

$ mmc --allow-stubs --grade asm_fast.gc --compile-to-c testb.m -Dall -dall
testb.m:011: Error: invalid determinism for `prefix_locator'(in) = out:
testb.m:011: the primary mode of a function cannot be `nondet'.
testb.m:011: In `prefix_locator'(in) = out:
testb.m:011: error: implicit determinism declaration not satisfied.
testb.m:011: Declared `det', inferred `nondet'.
testb.m:034: The switch on Replay does not cover
testb.m:034: `replay_load'/1.
testb.m:037: Disjunction has multiple clauses with solutions.
testb.m:038: Unification of `Replay' and `testb.replay_load(V_7)' can fail.
For more information, recompile with `-E'.

Additional Information:

Mercury ROTD 2016-07-18
GCC 5.4.0 20160609

Attached Files:

testb.m (888 bytes) 2016-07-25 16:53
https://bugs.mercurylang.org/file_download.php?file_id=261&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

196

[mercury] Bug

minor

sometimes

2011-04-13 23:10

2016-07-17 20:56

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:

Binary compatibility checks in C grades don't work.

Description:

The binary compatibility checks in runtime/mercury_goto.h don't work. I was able to modify the grade string and re-compile the runtime and link it against the standard library and object files that had been generated against an older version of this header file.

I suspect that the static variable in generated C files that refers to the grade variable is being optimized a way and therefore the linker happily links the mis-matched objects.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

412

[mercury] Bug

minor

always

2016-07-03 21:12

2016-07-17 18:25

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:

compiler does not report some unused imported modules

Description:

The compiler does not report as unused any of the standard library modules imported in the implementation section of the test file.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

unused_imports.m (2,782 bytes) 2016-07-03 21:12
https://bugs.mercurylang.org/file_download.php?file_id=259&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

major

always

2009-03-09 22:32

2016-07-01 10:11

Reporter:

maclarty

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:

compiler throws exception in hlc.gc

Description:

$ tar -xzf bug.tar.gz
$ mmc --version
Mercury Compiler, version rotd-2009-03-08, configured for x86_64-unknown-linux-gnu
Copyright (C) 1993-2009 The University of Melbourne
$ mmc --grade hlc.gc run.m
Uncaught Mercury exception:
Software Error: map.lookup: key not found
    Key Type: parse_tree.prog_data.type_ctor
    Key Value: type_ctor(qualified(unqualified("interpreter"), "value"), 0)
    Value Type: hlds.hlds_data.hlds_type_defn
Stack dump not available in this grade.

Error still occurs with -O-1.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug.tar.gz (1,657 bytes) 2009-03-09 22:32
https://bugs.mercurylang.org/file_download.php?file_id=70&type=bug
bug2.m (97 bytes) 2009-03-11 18:01
https://bugs.mercurylang.org/file_download.php?file_id=72&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

214

[mercury] Bug

minor

always

2011-09-02 03:41

2016-06-30 17:32

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:

15.11

Summary:

confusing type error

Description:

The attached model produces the following type error:

    bug.m:036: In predicate `solve_mip_cg'/2:
    bug.m:036: type error: unsatisfied typeclass constraint:
    bug.m:036: `bug.linear_expr(int, V_15, int)'
    bug.m:036: The constraint is due to:

But no constraints are listed; also the type error produced is incidental to the actual error.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug.m (4,718 bytes) 2011-09-02 03:41
https://bugs.mercurylang.org/file_download.php?file_id=126&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

184

[mercury] Bug

crash

always

2011-02-03 17:28

2016-06-30 11:46

Reporter:

mgiuca

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:

15.11

Summary:

Unresolved polymorphism in typeclass crashes mmc

Description:

The following program causes a software error in mmc (I believe I am using the HLC grade -- is there any way to check this?):

:- module compileerror.

:- interface.

:- func test = int.

:- implementation.

:- import_module list.

test = f([]).

:- typeclass myclass(T) where [
    func f(T) = int
].

:- instance myclass(list(T)) <= myclass(T) where [
    f(_) = 4
].

Uncaught Mercury exception:
Software Error: map.lookup: key not found
    Key Type: parse_tree.prog_data.prog_constraint
    Key Value: constraint(qualified(unqualified("compileerror"), "myclass"), [type_variable(var(1), kind_star)])
    Value Type: set_ordlist.set_ordlist(hlds.hlds_data.constraint_id)
Stack dump not available in this grade.

There are two factors which cause this. First, the instance for list has a constraint on T -- this can be any constraint but it doesn't crash unless there is a constraint on T. Second, I am calling 'f' with a type with unresolved polymorphism (the empty list has type list(T) and I have not bound the type variable T). Had I written f([] : list(int)) and added an instance myclass(int), it would compile successfully.

What I would have expected is to receive a warning due to unresolved polymorphism, along the lines of:
compileerror.m:005: In function `test'/0:
compileerror.m:005: warning: unresolved polymorphism.
compileerror.m:005: The variable with an unbound type was:
compileerror.m:005: V_2: list.list(T)
compileerror.m:005: The unbound type variable will be implicitly bound to the
compileerror.m:005: builtin type `void'.

Then I suppose this would cause an error, since `void' is not an instance of myclass:
compileerror.m:011: In clause for function `test'/0:
compileerror.m:011: unsatisfiable typeclass constraint:
compileerror.m:011: `compileerror.myclass(void)'.

This would then communicate to the user the folly of passing a list with an unspecified type to a method which really needs the list elements to have a concrete instance of myclass.

Tags:

Steps To Reproduce:

Additional Information:

It seems as though the problem is that things are happening in the wrong order inside the compiler. With minor changes, I can cause the "unresolved polymorphism" warning to occur, so I think the problem is that mmc is trying to choose a "type dictionary" or "vtable" for the elements-of-the-list type *before* it assigns the type `void'. I figure that if it assigned the type `void' earlier, then it would cause the above more user-friendly error instead.

For what it's worth, this situation does cause the following error in GHCI for Haskell:
    Ambiguous type variable `a' in the constraint:
      `MyClass a' arising from a use of `f' at compileerror.hs:2:7-10
    Probable fix: add a type signature that fixes these type variable(s)

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

major

always

2008-01-14 17:15

2016-06-23 14:48

Reporter:

juliensf

Platform:

Assigned To:

OS:

Priority:

high

OS Version:

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

another tabling bug with the high-level C backend

Description:

The attached module causes an assertion failure in the compiler when compiled with

mmc -C --grade hlc.gc -O0 --no-optimize-dead-procs

Tags:

Steps To Reproduce:

Additional Information:

The code in question is derived from the FlatZinc interpreter.
While compiling with --optimize-dead-procs causes the assertion failure to not
occur we cannot compile the original code in the FlatZinc interpreter with that option
enabled since that would trigger bug 0000022.

Attached Files:

fzn_table_bug2.m (1,015 bytes) 2008-01-14 17:15
https://bugs.mercurylang.org/file_download.php?file_id=32&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

407

[mercury] Bug

minor

have not tried

2016-04-12 15:17

2016-06-22 15:41

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:

Exception.getMessage can return null

Description:

io.m assumes java.lang.Exception.getMessage will not return null, but it can.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

326

[mercury] Feature Request

feature

always

2014-04-23 11:45

2016-04-04 12:07

Reporter:

wangp

Platform:

Assigned To:

wangp

OS:

Priority:

low

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

disable rpath

Description:

It should be possible to disable setting the rpath. Perhaps it should be off by default when statically linking the Mercury standard library and runtime.

--no-runtime-library-directory does not work.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

373

[mercury] Bug

minor

always

2015-01-13 17:40

2016-02-24 09:44

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:

15.11

Summary:

string.to_float imprecisely specified

Description:

string.to_float does not explicitly describe the literals that it will accept, and may be backend dependent. As it is, it goes beyond Mercury float literals and that accepted by parsing_utils.float_literal_as_string.

Examples:

"1" (missing fractional part and exponent)
"+1" (leading plus)
".1" (leading dot)
"1."
"1.e"
"1e"

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

405

[mercury] Bug

minor

always

2016-02-20 03:04

2016-02-23 03:24

Reporter:

FlyingJester

Platform:

amd64

Assigned To:

OS:

Windows

Priority:

normal

OS Version:

8.1

Status:

confirmed

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Compiler Software Exception in Certain Projects

Description:

Trying to build my project MEdit, I run into the following error:

Uncaught Mercury exception:
Software Error: check_hlds.cse_detection: predicate `check_hlds.cse_detection.detect_cse_in_proc'/4: Unexpected: mode check fails when repeated

I had thought this was only an issue with Mercury 14, but it seems to occur with the newest ROTD as well.

Tags:

Steps To Reproduce:

Download the MEdit sources from https://github.com/FlyingJester/medit
Run either just `make` (which requires yasm) or `make medit_mercury`

Additional Information:

I'm not really sure if this is actually an error in the compiler or in my own code, but if it is in my code the error reporting could be much improved.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

403

[mercury] Bug

minor

always

2016-02-09 10:02

2016-02-18 14:36

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:

Normal termination of a program in the Java grade does not flush stdout

Description:

Normal termination of a program compiled in the Java grade does not flush stdout.
This is leading to the failure of (at least) the following test cases in the Java grade:

    general/duplicate_label
    general/interpreter
    general/prune_switch

(And probably some others in the hard_coded directory.)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

402

[mercury] Bug

minor

always

2016-01-02 03:51

2016-01-10 01: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:

state variables not supported in require_complete_switch scope heads

Description:

Referring to the current state of a a state variable in a require_complete_switch scope results in syntax error. For example,

     require_complete_switch [!.Value] (
          ...
      )

results in:

     bug402.m:014: Expected a variable, got `(!. Value)'.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug402.m (370 bytes) 2016-01-02 03:51
https://bugs.mercurylang.org/file_download.php?file_id=255&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

400

[mercury] Bug

minor

always

2015-12-16 23: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:

ROTDs can no longer compile extras/trailed_update

Description:

Attempting to compile the trailed_update library in the extras results in a mode error in the var module.
The module compiles successfully with Mercury 14.01.X.

A cut down test case is attached.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug400.m (514 bytes) 2015-12-16 23:13
https://bugs.mercurylang.org/file_download.php?file_id=252&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

388

[mercury] Bug

minor

have not tried

2015-07-10 13:50

2015-12-14 10:31

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:

15.11

Summary:

Inconsistent permissions on library jar files

Description:

The Java archives for the standard libraries are installed in such a way that they only user readable and writeable. Aside from not being very useful in multi-user environments, this is also inconsistent with the permissions on the library files in other grades (which are group readable and writeable and world readable.)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

fix-java-jar-index.diff (1,733 bytes) 2015-07-10 14:16
https://bugs.mercurylang.org/file_download.php?file_id=246&type=bug
fix-java-jar-index.log (986 bytes) 2015-07-10 14:16
https://bugs.mercurylang.org/file_download.php?file_id=247&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

399

[mercury] Bug

minor

have not tried

2015-12-14 10:27

2015-12-14 10:28

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:

race condition on Windows when comparing a file to itself.

Description:

The attached patch fixes a race condition on Windows when comparing a file to itself.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

fix-java-jar-index.diff (1,733 bytes) 2015-07-10 14:16
https://bugs.mercurylang.org/file_download.php?file_id=250&type=bug
fix-java-jar-index.log (986 bytes) 2015-07-10 14:16
https://bugs.mercurylang.org/file_download.php?file_id=251&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

115

[mercury] Bug

minor

always

2009-11-05 21:50

2015-11-30 16:50

Reporter:

petdr

Platform:

Assigned To:

juliensf

OS:

Priority:

low

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

segfault for predicate names containing multibyte utf8 char

Description:

If you don't quote a predicate name which contains a multibyte utf8 character the compiler segfaults.

eg
:- pred dèja(int::int) is semidet.
seg faults while
:- pred 'dèja'(int::int) is semidet.

compiles fine.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

test.m (98 bytes) 2009-11-05 21:50
https://bugs.mercurylang.org/file_download.php?file_id=88&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-09-28 11:31

2015-11-29 16:08

Reporter:

maclarty

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:

:- pragma source_file ignored for warnings about unused imports in the interface.

Description:

A :- pragma source_file directive at the top of a mercury file is ignored for warnings about unused imports in the interface.

Tags:

Steps To Reproduce:

Additional Information:

Compiling the attached file with:

mmc sc

gives:

sc.m:001: In module `sc':
sc.m:001: warning: module `list' is imported in the interface, but is not
sc.m:001: used in the interface.
x:013: In clause for predicate `main'/2:
x:013: error: undefined predicate `foo'/2.

The warning has the wrong context.

Attached Files:

sc.m (200 bytes) 2007-09-28 11:31
https://bugs.mercurylang.org/file_download.php?file_id=7&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-03-04 01:48

2015-11-15 23: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:

another compiler abort when using debug grades

Description:

The attached program causes the compiler to abort with:

Uncaught Mercury exception:
Software Error: continuation_info.m: Unexpected: find_typeinfos_for_tvars: can't find rval for type_info var V_59

when compiled in a debug grade. It compiles successfully in non-debug grades.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

fzn_missing_rval.m (7,333 bytes) 2008-03-04 01:48
https://bugs.mercurylang.org/file_download.php?file_id=43&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-10-11 12:18

2015-11-11 19: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:

15.11

Summary:

no error for unknown types in interface if defined in implementation

Description:

The compiler does not issue an error for unknown types in the interface if the type is later defined in the implementation.

This may be the same bug as 0000011.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

not_abstract.m (138 bytes) 2007-10-11 12:18
https://bugs.mercurylang.org/file_download.php?file_id=9&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

264

[mercury] Bug

minor

always

2012-10-02 22:55

2015-11-02 16:55

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:

function mode lost without warning

Description:

It's possible to place a function with non-default mode into a ground term then extract it back out, now with the default mode assumed.

According to the manual this should be forbidden:

As a consequence of this, it is a mode error to pass a higher-order
function term that does not match this standard mode to somewhere where
its higher-order inst information may be lost[...]

which was apparently implemented:
http://www.mercury.csse.unimelb.edu.au/mailing-lists/mercury-users/mercury-users.0308/0013.html

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

default_ho_inst.m (482 bytes) 2012-10-02 22:55
https://bugs.mercurylang.org/file_download.php?file_id=161&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

232

[mercury] Bug

minor

always

2011-11-24 11:16

2015-11-02 16:07

Reporter:

pbone

Platform:

Assigned To:

pbone

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:

The thread pinning code in the parallel runtime doesn't work on older Linux systems.

Description:

There are two alternatives for the thread pinning code in Mercury's Parallel low-level C runtime. hwloc() and sched_setaffinity(). When libhwloc is not available sched_setaffinity will be used. Later versions of glibc provide several
macros to manipulate bitsets for use with sched_setaffinity, some or all of these macros may be unavailable on some systems. Currently mercury expects all the macros to be available whenever sched_setaffinity is available - which is not the case on older versions of glibc (such as on RHEL 5).

Furthermore, Non-linux OSs that support sched_setaffinity may also have problems.

To work-around this issue install libhwloc.

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-09-29 11:05

2015-11-02 13:08

Reporter:

user90

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:

Uncaught mode error leads to crash in codegen.m

Description:

The following program:

%-----------------------------------------------------------------------------%
:- module hello.
:- interface.
:- import_module io.

:- pred main(io::di, io::uo) is det.

:- implementation.
:- import_module string.

:- type abc ---> a ; b ; c.
:- inst ab ---> a ; b.

:- func abc2ab(abc::in) = (abc::out(ab)) is det.

abc2ab(X) = X.

main(!IO) :-
    X = abc2ab(c),
    io.write_string("X = " ++ X^string, !IO).
%-----------------------------------------------------------------------------%

Makes the compiler abort:

  Uncaught Mercury exception:
  Software Error: code_gen.m: Unexpected: semidet model in det context
  Stack dump not available in this grade.

A similar case: if I change 'main' to this:

main(!IO) :-
    X = abc2ab(c),
    ( X = a,
        io.write_string("X = a: " ++ X^string, !IO)
    ;
        X = b,
        io.write_string("X = b: " ++ X^string, !IO)
    ;
        X = c,
        io.write_string("X = c: " ++ X^string, !IO)
    ).

I get a compiler warning:

  hello.m:029: In clause for `main(di, uo)':
  hello.m:029: warning: unification of `X' and hello.c cannot succeed
  hello.m:029: `X' has instantiatedness `bound((hello.a) ; (hello.b))'.

and then codegen.m aborts again -- I guess the 'X=c' branch is removed as
dead code.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

191

[mercury] Bug

minor

always

2011-03-22 13:52

2015-11-02 11:10

Reporter:

colanderman

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:

indirect instance implementations ignore special insts

Description:

If a typeclass requires a predicate of a specific inst, but an instance indirectly defines that predicate (using "is"), the inst is not properly checked and an implementation with a more general inst (e.g. in or out) can be used. Result is a software error during compile, below.

Tags:

Steps To Reproduce:

Additional Information:

Software Error: code_gen.m: Unexpected: semidet model in det context

Attached Files:

instbug.m (507 bytes) 2011-03-22 13:52
https://bugs.mercurylang.org/file_download.php?file_id=116&type=bug
inst_match.patch (526 bytes) 2011-04-05 12:21
https://bugs.mercurylang.org/file_download.php?file_id=119&type=bug
inst_match2.patch (14,424 bytes) 2011-04-07 13:37
https://bugs.mercurylang.org/file_download.php?file_id=120&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

187

[mercury] Bug

minor

always

2011-03-06 17:12

2015-10-31 21:00

Reporter:

colanderman

Platform:

Assigned To:

juliensf

OS:

Priority:

normal

OS Version:

Status:

confirmed

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

15.11

Summary:

Strange error with disjunctive definitions returning existential typeclass instance

Description:

I don't know how to describe this but with code. Compile it and observe the error. Now uncomment the last line, and comment out the two preceding (to use an equivalent definition of the function f). Recompile and it works as expected.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

test.m (265 bytes) 2011-03-06 17:12
https://bugs.mercurylang.org/file_download.php?file_id=113&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

117

[mercury] Bug

minor

always

2009-11-28 02:36

2015-10-31 19:04

Reporter:

pjrm

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:

No error message for false non_empty_list declaration; runtime segfault

Description:

(The available "Severity" values aren't quite right for a compiler. I chose "minor" on the grounds that it affects only incorrect programs, though it's among the more serious of this class, in that it still compiles, but the resulting executable segfaults.)

I have a program where a function's output variable's mode is declared as out(non_empty_list), but where in fact the result can be empty. The program compiles with no warnings (whether with --debug or --grade=hlc.gc), but segfaults when it generates an empty list for a caller that assumes non-emptiness. (I have a feeling that in some cases the executable silently produces wrong results rather than segfaulting, though I'm not certain.)

I haven't yet made a minimal example, but can do so on request.

Tested with rotd-2009-02-26 and a 2007 version.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

nonempty12.m (230 bytes) 2009-12-01 03:02
https://bugs.mercurylang.org/file_download.php?file_id=89&type=bug
call_nonempty12.m (269 bytes) 2009-12-01 03:03
https://bugs.mercurylang.org/file_download.php?file_id=90&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

318

[mercury] Bug

minor

always

2014-02-13 11:31

2015-10-29 15:23

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:

pragma foreign_type depends on item order

Description:

An error is reported for a pragma foreign_type if the type name is not declared earlier.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

foreign.m (135 bytes) 2014-02-13 11:31
https://bugs.mercurylang.org/file_download.php?file_id=203&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

278

[mercury] Bug

minor

always

2013-04-04 23:16

2015-10-29 14:47

Reporter:

pbone

Platform:

x86_64

Assigned To:

OS:

Debian Linux

Priority:

normal

OS Version:

7.0

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

15.11

Summary:

Compiler crash from bad state variable use.

Description:

If I refer to the wrong state variable in the head of a lambda expression, I can reliably crash the compiler. I have a test case.

Tags:

Steps To Reproduce:

Attached in the testcase It crashes when I compile it with 'mmc --make' It also crashes in the Java grade.

mmc -V prints out the following just before the crash.
% Converting parse tree to hlds...
% Processing clause 1 for predicate `bug.main/2'...
% Processing clause 1 for predicate `bug.build_map/5'...

The exception thrown is:
Uncaught Mercury exception:
Software Error: hlds.make_hlds.state_var: predicate `hlds.make_hlds.state_var.svar_find_final_renames_and_copy_goals'/7: Unexpected: readonly status
Stack dump not available in this grade.
** Error making `Mercury/cs/bug.c'.

I'm using the 12.08 beta (The release MCit is using)

Additional Information:

Attached Files:

bug278.m (841 bytes) 2013-04-04 23:19
https://bugs.mercurylang.org/file_download.php?file_id=173&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

397

[mercury] Bug

minor

always

2015-10-13 17:43

2015-10-20 18:00

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:

Clang fails to deal with -R command line parameter

Description:

Not necessarily our bug, but clang 3.4 does not like -R/foo:

clang -R/foo --version
clang: error: unknown argument: '-R/foo'
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: i386-unknown-freebsd10.1
Thread model: posix

https://llvm.org/bugs/show_bug.cgi?id=18164

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

395

[mercury] Bug

minor

have not tried

2015-10-12 14:46

2015-10-20 18:00

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:

non tail recursion in lexer.m

Description:

In lexer.m, execute_get_token_action calls skip_to_eol which calls get_token_2 which calls execute_get_token_action.

I believe this is the cause of a C stack overflow on FreeBSD/i386/gcc48/hlc.gc.

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:

396

[mercury] Bug

minor

always

2015-10-12 15:44

2015-10-20 18:00

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:

non tail recursion in prog_io.m

Description:

read_items_loop calls read_items_loop_2 which calls read_items_loop

In high-level C grades this can overflow the C stack when reading a module with a large number of items.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

394

[mercury] Bug

minor

have not tried

2015-09-20 01:43

2015-10-14 10:12

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:

Building compiler with --use-mmc-make broken (rotd-2015-09-18)

Description:

Building the compiler in the hlc.gc or java grade using rotd-2015-09-18 and --use-mmc-make results in the following error:

Making Mercury/cs/hlds.passes_aux.c
Making Mercury/cs/hlds.pred_table.c
Making Mercury/cs/hlds.quantification.c
Error opening file `Mercury/opts/hlds.quantification.opt.tmp' for output: can't append to file: No such file or directory** Error making `Mercury/cs/hlds.quantification.c'.
/var/folders/pd/5lypc6_j3vnf65q9x5y9s3p40000gn/T//mmake.D1F8M2:1421: recipe for target 'top_level' failed
gmake[1]: *** [top_level] Error 1
gmake[1]: Leaving directory '/Users/jfischer/Mercury-Workspaces/mercury.local-5/compiler'
/var/folders/pd/5lypc6_j3vnf65q9x5y9s3p40000gn/T//mmake.cjoMVE:1073: recipe for target 'compiler' failed
gmake: *** [compiler] Error 2

Tags:

Steps To Reproduce:

Additional Information:

Commenting the line that enables --optimize-unused-args for the hlds.quantification module in compiler/Mercury.options is a workaround.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

389

[mercury] Feature Request

minor

have not tried

2015-07-21 10:45

2015-09-30 15:31

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:

aligned_pointer foreign type assertion

Description:

This is a proposal for a foreign type assertion. The user promises that values of this type would be clear in the tag bits (most likely a word-aligned pointer). The compiler would therefore be able to apply the direct arg optimisation to functors with a single argument of that foreign type.

(just writing it down for now, I won't be implementing it soon)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

391

[mercury] Bug

minor

always

2015-08-14 16:56

2015-09-18 17: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:

trace conditions lost in .opt files

Description:

Conditions on trace goals are not written out to .opt files, thus trace goals may be executed when their conditions are not met.

The .opt file for the attached module includes:

require_lt.require_lt(A_3, B_4) :-
    (
      % trace
      % compiletime(flag(checks))
      % quantified vars
      require_lt.require_lt0(A_3, B_4)
    ).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

require_lt.m (398 bytes) 2015-08-14 16:56
https://bugs.mercurylang.org/file_download.php?file_id=248&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

393

[mercury] Bug

minor

always

2015-09-15 10:40

2015-09-18 06: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:

#line directives in .mh cause unnecessary recompilations

Description:

This is a source of mysterious recompilations that I was experiencing in debug grades. I had a mutable declaration near the *end* of a file:

:- mutable(debug_num, int, 0, ground, [untrailed, attach_to_io_state]).

resulting in a #line directive in the .mh file:

#ifndef WRITEPDF__RASTER_DECL_GUARD
#define WRITEPDF__RASTER_DECL_GUARD
#line 1400 "../writepdf/raster.m"
#ifdef MR_HIGHLEVEL_CODE
    extern MR_Integer writepdf__raster__mutable_variable_debug_num;
#else
    extern MR_Word writepdf__raster__mutable_variable_debug_num;
#endif
#ifdef MR_THREAD_SAFE
    extern MercuryLock writepdf__raster__mutable_variable_debug_num_lock;
#endif

Adding or removing blank lines would be enough to triggering recompilation of seemingly unrelated .c files.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

363

[mercury] Bug

minor

always

2014-09-17 17:22

2015-08-23 14: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:

misleading error message for missing comma in foreign_proc attribute list

Description:

The attached program causes the following error message.

foo.m:009: Error: invalid `:- pragma foreign_proc' declaration: invalid second
foo.m:009: argument: expecting a foreign proc attribute or list of
foo.m:009: attributes.

The invalid argument is the *third* argument, not the second.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

foo.m (249 bytes) 2014-09-17 17:22
https://bugs.mercurylang.org/file_download.php?file_id=227&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

392

[mercury] Bug

minor

always

2015-08-17 14:13

2015-08-17 15:38

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:

compiler abort with deforestation

Description:

Reproduceable with 14.01 and master.

% mmc -O0 --deforestation -C deforest_bug.m

Uncaught Mercury exception:
Software Error: ll_backend.code_gen: predicate `ll_backend.code_gen.generate_goal'/7: Unexpected: nondet model in det/semidet context
Stack dump follows:
   0 pred exception.throw/1-0 (erroneous) (exception.m:289)
   1 pred require.error/1-0 (erroneous) (require.m:172)
   2 pred require.unexpected/3-0 (erroneous) (require.m:210)
   3 pred ll_backend.code_gen.generate_goal/7-0 (det) (code_gen.m:123)
   4 pred ll_backend.proc_gen.generate_category_code/11-0 (det) (proc_gen.m:786)
   5 pred ll_backend.proc_gen.generate_proc_code/9-0 (det) (proc_gen.m:405)
   6 pred top_level.mercury_compile_llds_back_end.llds_backend_pass_for_proc/12-0 (det) (mercury_compile_llds_back_end.m:396)
   7 pred top_level.mercury_compile_llds_back_end.llds_backend_pass_for_pred/11-0 (det) (mercury_compile_llds_back_end.m:296)
   8 3* pred top_level.mercury_compile_llds_back_end.llds_backend_pass_by_preds_loop_over_preds/11-0 (det) (mercury_compile_llds_back_end.m:264 and others)
  11 pred top_level.mercury_compile_llds_back_end.llds_backend_pass_by_preds/7-0 (det) (mercury_compile_llds_back_end.m:211)
  12 pred top_level.mercury_compile_llds_back_end.llds_backend_pass/8-0 (det) (mercury_compile_llds_back_end.m:138)
  13 pred top_level.mercury_compile.mercury_compile_after_front_end/11-0 (det) (mercury_compile.m:1706)
  14 pred top_level.mercury_compile.mercury_compile/11-0 (det) (mercury_compile.m:1537)
  15 pred top_level.mercury_compile.compile/13-0 (det) (mercury_compile.m:1462)
  16 pred list.map_foldl2/7-2 (det) (list.m:2835)
  17 pred top_level.mercury_compile.compile_all_submodules/13-0 (det) (mercury_compile.m:1281)
  18 pred top_level.mercury_compile.process_module_2/9-0 (det) (mercury_compile.m:1254)
  19 pred top_level.mercury_compile.process_module/7-0 (det) (mercury_compile.m:1144)
  20 pred top_level.mercury_compile.process_arg_2/7-0 (det) (mercury_compile.m:850)
  21 pred top_level.mercury_compile.process_arg_build/9-0 (det) (mercury_compile.m:812)
  22 pred make.util.build_with_module_options_args_invoked/13-0 (det) (make.util.m:1064)
  23 pred make.util.build_with_module_options_args/12-0 (det) (make.util.m:1016)
  24 pred top_level.mercury_compile.process_arg/9-0 (det) (mercury_compile.m:785)
  25 pred top_level.mercury_compile.process_arg_list/11-0 (det) (mercury_compile.m:756)
  26 pred top_level.mercury_compile.process_args/9-0 (det) (mercury_compile.m:707)
  27 pred top_level.mercury_compile.process_all_args/9-0 (det) (mercury_compile.m:613)
  28 pred top_level.mercury_compile.main_after_setup/8-0 (det) (mercury_compile.m:514)
  29 pred top_level.mercury_compile.real_main_after_expansion/3-0 (det) (mercury_compile.m:341)
  30 pred top_level.mercury_compile.real_main/2-0 (det) (mercury_compile.m:126)
  31 pred top_level.main/2-0 (det) (top_level.m:56)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

deforest_bug.m (750 bytes) 2015-08-17 14:13
https://bugs.mercurylang.org/file_download.php?file_id=249&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

390

[mercury] Bug

minor

always

2015-08-05 17:11

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:

MR_ALLOC_ID visibility

Description:

In non-memprof grades a MR_ALLOC_ID symbol is visible outside foreign_proc bodies, unlike in memprof grades. It is easy to move code from a foreign_proc to a foreign_code block and have it compile, only to find out much later that it is broken in memprof grades.

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:

385

[mercury] Bug

minor

always

2015-04-06 18:47

2015-07-22 09:08

Reporter:

dirkz

Platform:

MinGW/MSYS 32bit rotd-2015-03-10

Assigned To:

juliensf

OS:

Windows 7 Professional 64 bit

Priority:

normal

OS Version:

Win 7 64 bit

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

mercury_compile.exe crashes during compilation of large fact table on MinGW/MSYS

Description:

mercury_compile.exe crashes without giving any error message at all.

It seems that the crash occurs where Mercury normally makes the .int3-file.

The same module compiles without any problems on Mac OS X version 10.10.

Mercury-Version: rotd-2015-03-10

Tags:

Steps To Reproduce:

mmc --make --grade none.gc contextOfDataPoints

Additional Information:

As a workaround, I can use pragma fact_table.

Attached Files:

contextOfDataPoints.m.gz (138,275 bytes) 2015-04-06 18:47
https://bugs.mercurylang.org/file_download.php?file_id=243&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

381

[mercury] Bug

major

always

2015-03-01 00:09

2015-07-15 12:07

Reporter:

ttmrichter

Platform:

Some Lenovo i5 laptop or other

Assigned To:

OS:

Linux Mint

Priority:

normal

OS Version:

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Compiler deals poorly with '.' character constants.

Description:

Unifying variables with '.' causes compiler to fail with "operator precedence error".

Tags:

Steps To Reproduce:

Compile attached code. If line 10 is not commented out (as uploaded) the compiler will explode. If line 10 is commented out, the compiler is happy.

Additional Information:

Mercury Compiler, version rotd-2015-02-20, on x86_64-unknown-linux-gnu

Attached Files:

bug.m (401 bytes) 2015-03-01 00:09
https://bugs.mercurylang.org/file_download.php?file_id=238&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

339

[mercury] Bug

major

always

2014-06-22 07:19

2015-07-14 17:30

Reporter:

sebgod

Platform:

Windows NT 6.3 x86_64

Assigned To:

juliensf

OS:

Windows

Priority:

normal

OS Version:

8.1

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

mmc --java with Oracle Java 1.8.0 fails on Windows

Description:

Making Java class files
An exception has occurred in the compiler (1.8.0). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you.
java.lang.AssertionError: the -J flag should be caught by the launcher.
        at com.sun.tools.javac.main.Option$20.process(Option.java:330)
        at com.sun.tools.javac.main.Main.processArgs(Main.java:260)
        at com.sun.tools.javac.main.Main.compile(Main.java:414)
        at com.sun.tools.javac.main.Main.compile(Main.java:381)
        at com.sun.tools.javac.main.Main.compile(Main.java:370)
        at com.sun.tools.javac.main.Main.compile(Main.java:361)
        at com.sun.tools.javac.Main.compile(Main.java:56)
        at com.sun.tools.javac.Main.main(Main.java:42)

Tags:

Steps To Reproduce:

Compile any program using the Java grade

Additional Information:

Break resulted only from installation of the Java JDK 8.0;
recompilation of the Mercury compiler did work but did not change the given output.

System Description

Using the latest MinGW with gcc 4.7 for 32bit
Java 1.8.0
.NET 4.5.1
Bootstrapped (with ROTD from June 2014) Mercury-dev

Attached Files:

fix-java8-flag-reorder.diff (1,247 bytes) 2014-12-16 02:54
https://bugs.mercurylang.org/file_download.php?file_id=229&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

293

[mercury] Bug

minor

always

2013-07-10 13:55

2015-07-08 13:19

Reporter:

juliensf

Platform:

x86-64

Assigned To:

juliensf

OS:

Linux

Priority:

normal

OS Version:

Fedora 19

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

asm_fast grades do not work with GCC 4.8

Description:

The asm_fast grades do not work with GCC 4.8 on Fedora 19 x86-64 (and probably elsewhere).
(The configure test for gcc labels is failing due to a segmentation fault on my system.)
This was with Mercury 13.05.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

348

[mercury] Bug

minor

have not tried

2014-07-18 15:07

2015-07-08 13:15

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:

Failure of tests/general/string_format_special_floats with MSVC

Description:

When using MSVC as a C compiler, the test case tests/general/string_format_special_float fails as the MS libc doesn't appear to
implement the C99 behaviour for printing nan, inf etc.

With VS2012 we get:

Plus Infinity:
                  %e: failure '1.#INF00
                  %f: failure '1.#INF00
                  %g: failure '1.#INF'
                  %E: failure '1.#INF00
                  %F: failure ''
                  %G: failure '1.#INF'
Minus Infinity:
                  %e: failure '-1.#INF0
                  %f: failure '-1.#INF0
                  %g: failure '-1.#INF'
                  %E: failure '-1.#INF0
                  %F: failure ''
                  %G: failure '-1.#INF'
Not a number:
                  %e: failure '-1.#IND0
                  %f: failure '-1.#IND0
                  %g: failure '-1.#IND'
                  %E: failure '-1.#IND0
                  %F: failure ''
                  %G: failure '-1.#IND'

We should probably check for special float values before calling sprintf
and just handle them directly using Mercury. (This would also avoid some
inconsistencies in the output of these tests due to do differences in C
libraries.)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

280

[mercury] Bug

minor

always

2013-04-11 14:06

2015-07-07 15:23

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:

Parser stack overflow with MSVC

Description:

Attempting to compile compiler/options.c (from the rote-2012-04-10 srcdist) with MSVC
results in:

fatal error C1026: parser stack overflow, program too complex

It looks as though the C code we generate for the predicate long_option/2 is too
heavily nested; I'll try to separate it out a bit and see if that avoids the limitation.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

387

[mercury] Bug

major

always

2015-07-06 12:50

2015-07-07 14:58

Reporter:

pbone

Platform:

x86_64

Assigned To:

OS:

Debian

Priority:

normal

OS Version:

stretch

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Polymorphism pass miscompiles some try goals.

Description:

I get the following error:

polymorphism_try_bug.m:031: In clause for `test(in, di, uo)':
polymorphism_try_bug.m:031: mode mismatch in disjunction.
polymorphism_try_bug.m:031: The variable `TypeInfo_25' has these
polymorphism_try_bug.m:031: instantiation states:
polymorphism_try_bug.m:031: line 26: free
polymorphism_try_bug.m:031: line 26: ground

My predicate contains a try goal with a catch_any block. The TypeInfo in question is the type info for the exception, which passed out of the try goal in a maybe_error type and named-appart.

Tags:

Steps To Reproduce:

mmc --use-grade-subdirs -O3 --allow-stubs --no-warn-stubs --compile-to-c test_bdd_bug.m

Additional Information:

Attached Files:

polymorphism_try_bug.m (1,608 bytes) 2015-07-06 12:50
https://bugs.mercurylang.org/file_download.php?file_id=244&type=bug
bug387.m (597 bytes) 2015-07-06 17:30
https://bugs.mercurylang.org/file_download.php?file_id=245&type=bug

Notes

I tried breaking the predicate into two parts so that I can put the try goal in a predicate that explicitly returns an existential type. (My idea is that the types should be named apart and the type of the exception should be set when MaybeBDD is unified with error and deconstructed.

    :- some [E] pred test_try(bexpr(V)::in, maybe_error(bdd(V), {string, E})::out)
        is det.

    test_try(BooleanExpression, MaybeBDD) :-
        promise_equivalent_solutions [MaybeBDD] (
        ( try []
            BDDPrime = make_bdd(BooleanExpression)
          then
            MaybeBDD = ok(BDDPrime)
          catch_any ExpPrime ->
            MaybeBDD = error({"My error message", ExpPrime})
        )).

    test2(BooleanExpression, !IO) :-
        test_try(BooleanExpression, MaybeBDD),
        ( MaybeBDD = ok(BDD)
        ; MaybeBDD = error({ErrMessage, _}),
            % This deconstructon should determine the type of the error.
            write_string(ErrMessage, !IO),
            sorry($pred, "Error")
        ),
        io.write(BDD, !IO).

But this doesn't work. and using `new error` doesn't work because error is not existentially typed itself. (I'm learning more about existential types BTW.)

    :- type maybe_error(T)
        ---> ok(T)
        ; some [E] error(string, E).

    test2(BooleanExpression, !IO) :-
        promise_equivalent_solutions [MaybeBDD] (
        ( try []
            BDDPrime = make_bdd(BooleanExpression)
          then
            MaybeBDD = ok(BDDPrime)
          catch_any ExpPrime ->
            MaybeBDD = 'new error'("My error message", ExpPrime)
        )),
        ( MaybeBDD = ok(BDD)
        ; MaybeBDD = error(ErrMessage, _),
            % This deconstructon should determine the type of the error.
            write_string(ErrMessage, !IO),
            sorry($pred, "Error")
        ),
        io.write(BDD, !IO).

This works, it solves the problem in the same way as your use of univ. I've learnt that if I want the type of the error to be determined when error is deconstructed, then I need error to have the existential type applied to it. (Or univ, if I want it a little later).

We can make it a type error for the type of an exception to escape the catch_any branch. Or indeed any branching structure, this will allow us to produce a better error message. Do you agree? is a type error the way to go here? (My reasoning is that the program is incorrectly typed.)

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

386

[mercury] Bug

major

always

2015-06-29 01:37

2015-07-01 01:36

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:

rotd-2015-03-24 and following broken

Description:

rotd-2015-03-24 and the following rotds break when installing from the source distribution.
During the install_grades step, compiling library/array.m to C results in:

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

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

384

[mercury] Bug

minor

always

2015-03-31 11:22

2015-04-02 12:13

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 1 compiler directory fails in hlc.gc grade with syntax errors in optimisation interfaces

Description:

Build the current git HEAD with rotd-2015-03-30 in hlc.gc with -O5 --intermodule-optimization
fails in the compiler directory due to:

gmake[1]: Entering directory '/Users/jfischer/Mercury-Workspaces/mercury.local-4/compiler'
/Users/jfischer/Mercury-Install/mercury-rotd-2015-03-30/bin//mmc --compile-to-c --grade hlc.gc -O5 --intermodule-optimization --flags COMP_FLAGS --no-common-struct analysis > analysis.err 2>&1
/var/folders/pd/5lypc6_j3vnf65q9x5y9s3p40000gn/T//mmake.MygSwR:1973876: recipe for target 'analysis.c_date' failed
gmake[1]: *** [analysis.c_date] Error 1
gmake[1]: Leaving directory '/Users/jfischer/Mercury-Workspaces/mercury.local-4/compiler'

The contents of analysis.err are:

hlds.passes_aux.opt:003: Error: syntax error in inst body at bound/1.
hlds.passes_aux.opt:004: Error: syntax error in inst body at bound/1.

Looking at hlds.passes_aux.opt, the insts in question are:

:- inst (hlds.passes_aux.par_proc_task) == bound((hlds.passes_aux).update_proc($typed_inst(pred(hlds.hlds_module.module_info, hlds.hlds_pred.proc_info, hlds.hlds_pred.proc_info), ((hlds.passes_aux).proc_task))) ; (hlds.passes_aux).update_proc_ids($typed_inst(pred(hlds.hlds_module.module_info, hlds.hlds_pred.pred_proc_id, hlds.hlds_pred.proc_info, hlds.hlds_pred.proc_info), ((hlds.passes_aux).proc_ids_task))) ; (hlds.passes_aux).update_proc_ids_pred($typed_inst(pred(hlds.hlds_module.module_info, hlds.hlds_pred.pred_proc_id, hlds.hlds_pred.pred_info, hlds.hlds_pred.proc_info, hlds.hlds_pred.proc_info), ((hlds.passes_aux).proc_ids_pred_task)))).
:- inst (hlds.passes_aux.seq_proc_task) == bound((hlds.passes_aux).update_module($typed_inst(pred(hlds.hlds_pred.pred_proc_id, hlds.hlds_pred.proc_info, hlds.hlds_pred.proc_info, hlds.hlds_module.module_info, hlds.hlds_module.module_info), ((hlds.passes_aux).module_task))) ; (hlds.passes_aux).update_module_cookie($typed_inst(pred(hlds.hlds_pred.pred_proc_id, hlds.hlds_pred.proc_info, hlds.hlds_pred.proc_info, hlds.hlds_module.module_info, hlds.hlds_module.module_info, univ.univ, univ.univ), ((hlds.passes_aux).module_cookie_task)), ground) ; (hlds.passes_aux).update_module_pred($typed_inst(pred(hlds.hlds_pred.pred_proc_id, hlds.hlds_pred.pred_info, hlds.hlds_pred.proc_info, hlds.hlds_pred.proc_info, hlds.hlds_module.module_info, hlds.hlds_module.module_info), ((hlds.passes_aux).module_pred_task))) ; (hlds.passes_aux).update_module_pred_cookie($typed_inst(pred(hlds.hlds_pred.pred_proc_id, hlds.hlds_pred.pred_info, hlds.hlds_pred.proc_info, hlds.hlds_pred.proc_info, hlds.hlds_module.module_info, hlds.hlds_module.module_info, univ.univ, univ.univ), ((hlds.passes_aux).module_pred_cookie_task)), ground)).

I would guess the issue here is the appearance of $typed_inst in the inst which isn't valid Mercury syntax.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

383

[mercury] Bug

minor

always

2015-03-25 13:59

2015-03-25 19:53

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:

Program behaviour changes when trie string switches are used

Description:

The behaviour of the attached program with the attached input differs depending on
whether the predicate cadmium_op_table/2 is compiled into a trie string switch or not.

Tags:

Steps To Reproduce:

  $ mmc --make bug
  $ ./bug < bug.inp

yields:

error("Syntax error at token \'main\': operator precedence error", 5)

  $ mmc --no-smart-indexing --make bug
  $ ./bug < bug.inp

yields:

term(varset(var_supply(0), empty, empty), functor(atom("transform"), [functor(atom("="), [functor(atom("main"), [], context("<standard input>", 5)), functor(atom("."), [functor(atom("zinc2merc"), [], context("<standard input>", 5)), functor(atom("high_level"), [], context("<standard input>", 5))], context("<standard input>", 5))], context("<standard input>", 5))], context("<standard input>", 5)))

The latter is the expected output for this program.

Additional Information:

The problem did not exist in rotd-2015-02-20. It exists in rotd-2015-02-27 onwards.
(The change that added trie string switches was committed on 2015-02-24; the next
rotd build was 2015-02-27.)

Attached Files:

bug.m (7,737 bytes) 2015-03-25 14:00
https://bugs.mercurylang.org/file_download.php?file_id=241&type=bug
bug.inp (435 bytes) 2015-03-25 14:00
https://bugs.mercurylang.org/file_download.php?file_id=242&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

382

[mercury] Bug

crash

always

2015-03-15 00:22

2015-03-16 03:15

Reporter:

pbone

Platform:

x86_64

Assigned To:

OS:

Debian

Priority:

normal

OS Version:

8.0

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

arg-pack-bits optimisation broken with foreign_enums.

Description:

The arg-pack-bits optimisation is incorrectly applied to members of structures which are foreign enums. In this example I have two types each has two fields and therefore could be stored in 1 bit each. However they are foreign enums and in this case may contain values that may use an arbitrary number of bits. Mercury incorrectly assumes that they use fewer bits and attempts to pack them.

Tags:

Steps To Reproduce:

Code that uses the following structure is mis-compiled. I'm attaching a full example. Note that the 3rd field is necessary to trigger the crash.

:- type addrinfo
    ---> addrinfo(
                ai_family :: family,
                ai_socktype :: socktype,
                ai_protocol :: protocol_num
            ).

:- type family
    ---> fam_inet
    ; fam_inet6.

:- type socktype
    ---> sock_stream
    ; sock_dgram.

:- pragma foreign_enum("C", family/0,
    [fam_inet - "AF_INET",
     fam_inet6 - "AF_INET6"]).

:- pragma foreign_enum("C", socktype/0,
    [sock_stream - "SOCK_STREAM",
     sock_dgram - "SOCK_DGRAM"]).

The error goes away when I set --arg-pack-bits=0

Additional Information:

Note that the solution will need to be aware of cases where the foreign enum is in the implementation section of a different module.

Attached Files:

bug_pack_bits.m (2,542 bytes) 2015-03-15 00:22
https://bugs.mercurylang.org/file_download.php?file_id=239&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

380

[mercury] Bug

minor

always

2015-02-25 15:55

2015-02-28 14:18

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:

mercury_string.h not always included in high-level C grades

Description:

mercury_string.h is not always included by the generated C file unless the module imports the string module, but the compiler may generate references to macros defined in that file. The easiest fix would be to include mercury_string.h in mercury.h

% mmc -s hlc.gc -c words
words.m: In function ‘words__word_1_p_0’:
words.m:12:7: warning: implicit declaration of function ‘MR_nth_code_unit’ [-Wimplicit-function-declaration]
word("aback").
^
words.m:12:17: warning: implicit declaration of function ‘MR_offset_streq’ [-Wimplicit-function-declaration]
word("aback").

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

words.m (603 bytes) 2015-02-25 15:55
https://bugs.mercurylang.org/file_download.php?file_id=237&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

366

[mercury] Bug

minor

always

2014-10-27 16:15

2015-02-20 15:20

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:

enable inst_matches_final_bug and ho_default_func_4

Description:

The aforementioned test cases can now be enabled after the hack in inst_matches_final was removed.

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:

377

[mercury] Bug

minor

always

2015-02-18 01:46

2015-02-19 01:46

Reporter:

mvd23jsdf4

Platform:

x86_64

Assigned To:

juliensf

OS:

Fedora

Priority:

normal

OS Version:

Status:

feedback

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Debugger doesn't have help installed.

Description:

After building and installing the debugger, mdb doesn't have any help files.

Tags:

Steps To Reproduce:

./configure --prefix=$HOME/.local --enable-minimal-install --enable-additional-libgrades=asm_fast.gc.debug,asm_fast.gc.decldebug
make PARALLEL=-j2
make PARALLEL=-j2 install

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

378

[mercury] Bug

minor

have not tried

2015-02-18 01:52

2015-02-19 01:42

Reporter:

mvd23jsdf4

Platform:

x86_64

Assigned To:

OS:

Fedora

Priority:

normal

OS Version:

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Cannot access library source files when debugging

Description:

When debugging an application and the code enters a library file, you are unable to view that source. see attached source file.

Tags:

Steps To Reproduce:

./configure --prefix=$HOME/.local --disable-most-grades --enable-additional-libgrades=reg.gc.debug,reg.gc.decldebug
make PARALLEL=-j2
make PARALLEL=-j2 install
mmc --make --debug fib2
mdb ./fib2

[mercuryuser@localhost fib2]$ mdb ./fib2
Melbourne Mercury Debugger, mdb version 14.01.1.
Copyright 1998-2014 The University of Melbourne.
mdb is free software, covered by the GNU General Public License.
There is absolutely no warranty for mdb.
       1: 1 1 CALL pred fib2.main/2-0 (det) fib2.m:16
/home/mercuryuser/.local/lib/mercury/mdb/mdb_doc: No such file or directory.
mdb> list
            else fib(N - 1) + fib(N - 2)).

> main(!IO) :-
       io.read_line_as_string(Result, !IO),
       (if
mdb> next

       4: 1 1 COND pred fib2.main/2-0 (det) c2;?; fib2.m:19
mdb> list
       io.read_line_as_string(Result, !IO),
       (if
> Result = ok(String),
           string.to_int(string.strip(String), N)
        then
mdb> step
       5: 3 2 CALL func string.strip/1-0 (det) string.m:6331 (fib2.m:20)
mdb> list
mdb: cannot find file string.m
mdb>

Additional Information:

Attached Files:

fib2.m (546 bytes) 2015-02-18 01:52
https://bugs.mercurylang.org/file_download.php?file_id=235&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

379

[mercury] Bug

minor

always

2015-02-18 02:06

2015-02-19 01:38

Reporter:

mvd23jsdf4

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:

GCC 4.9.2 Giving Error

Description:

The GCC (version 4.9.2) on Fedora 21 is showing warnings on compile. See the attached file crypt.m.

Tags:

Steps To Reproduce:

    [mercuryuser@localhost crypt]$ mmc --make --debug crypt
    Making Mercury/int3s/crypt.int3
    Making Mercury/ints/crypt.int
    Making Mercury/cs/crypt.c
    Making Mercury/os/crypt.o
    Making crypt
    In file included from /usr/include/stdlib.h:24:0,
                     from /home/mercuryuser/local/lib/mercury/inc/mercury_std.h:23,
                     from /home/mercuryuser/local/lib/mercury/inc/mercury_goto.h:13,
                     from /home/mercuryuser/local/lib/mercury/inc/mercury_init.h:84,
                     from Mercury/cs/crypt_init.c:18:
    /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 /home/mercuryuser/local/lib/mercury/inc/mercury_std.h:23,
                     from /home/mercuryuser/local/lib/mercury/inc/mercury_goto.h:13,
                     from /home/mercuryuser/local/lib/mercury/inc/mercury_init.h:84,
                     from Mercury/cs/crypt_init.c:18:
    /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 `crypt.err' for the complete log.

Additional Information:

Attached Files:

crypt.m (1,147 bytes) 2015-02-18 02:06
https://bugs.mercurylang.org/file_download.php?file_id=236&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

376

[mercury] Bug

minor

always

2015-02-06 15:25

2015-02-17 12:35

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:

base_string_to_int ignores overflow unless base 10

Description:

base_string_to_int should always check for under/overflow despite the faulty reasoning in commit 51b8f76. The fix should be easy enough but I will leave this bug report for a bit in case there are dissenting opinions.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

368

[mercury] Bug

minor

always

2014-12-02 22:19

2015-02-08 12:18

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:

Table reset predicates not generated in Erlang grade

Description:

The module compiler/ctgc.selector contains a number of predicates that are the subject of memo pragmas and that have the reset attribute specified. The reset predicates are called by other predicates
in this module. Although tabling is not supported by the Erlang backend, we still need to generate
dummy versions of the reset predicates where there are references to them. This is the cause
of the errors from the Erlang compiler about undefined functions in the build output below.

Tags:

Steps To Reproduce:

Build the Mercury compiler in the erlang grade.

Additional Information:

Making Mercury/int3s/transform_hlds.ctgc.selector.int3
Making Mercury/ints/transform_hlds.ctgc.selector.int
Making Mercury/erls/transform_hlds__ctgc__selector.erl
ctgc.selector.m:066: Ignoring the pragma memo for predicate
ctgc.selector.m:066: `transform_hlds.ctgc.selector.normalize_selector_with_type_information'/4
ctgc.selector.m:066: mode 0 due to lack of support on this back end.
ctgc.selector.m:288: Ignoring the pragma memo for predicate
ctgc.selector.m:288: `transform_hlds.ctgc.selector.type_contains_subtype_1'/4
ctgc.selector.m:288: mode 0 due to lack of support on this back end.
ctgc.selector.m:330: Ignoring the pragma memo for predicate
ctgc.selector.m:330: `transform_hlds.ctgc.selector.type_arg_types'/3 mode 0
ctgc.selector.m:330: due to lack of support on this back end.
Making Mercury/beams/transform_hlds__ctgc__selector.beam
ctgc.selector.m:295: syntax error before: ','
ctgc.selector.m:334: syntax error before: ','
Mercury/erls/transform_hlds__ctgc__selector.erl:354: function table_reset_for_type_contains_subtype_1_4_2_p_0/0 undefined
Mercury/erls/transform_hlds__ctgc__selector.erl:355: function table_reset_for_type_arg_types_3_2_p_0/0 undefined
** Error making `Mercury/beams/transform_hlds__ctgc__selector.beam'.
/var/folders/pd/5lypc6_j3vnf65q9x5y9s3p40000gn/T//mmake.YQsUfH:1400: recipe for target 'top_level' failed
gmake[1]: *** [top_level] Error 1
gmake[1]: Leaving directory '/Users/jfischer/Mercury-Workspaces/mercury.local-4/compiler'
/var/folders/pd/5lypc6_j3vnf65q9x5y9s3p40000gn/T//mmake.nCDJA5:1066: recipe for target 'compiler' failed
gmake: *** [compiler] Error 2

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

375

[mercury] Bug

major

always

2015-01-19 14:52

2015-01-21 01:07

Reporter:

lpimmes

Platform:

OSx 10.9

Assigned To:

OS:

Priority:

urgent

OS Version:

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

io.seek_binary_output(Stream, set, 32, Out3, Out4), % rec1 NOT working

Description:

Seeking to an offset, the second record, in binTest file and then writing new results only writes a single record.
Initially three records present; now only a single record remains.
Any ideas? Thanks.
This invites the question: overwrite record at position, versus insert new record at seek position.

Tags:

Steps To Reproduce:

Change true/false switches in main/2 to achieve results for test:
1 write binTest, true, false
2 false, true read binTest at offset, record 2, OK
3 false, false write to binTest at offset, record 2; fails.

                                % ioBinFile 522>which mmc
                % /usr/local/mercury-14.01/bin/mmc

                % ioBinFile 511>./ioBinFile
                % Opened 'binTest' successfully.
                % Offsets rec0: 0, rec1: 32, rec2: 62.
                % ioBinFile 513>cat binTest
                % rec("The man ran home.", 3092).
                % rec("The girl saw me.", 312).
                % rec("Each person saw you.", 532).

                % set to false, recompile main/2
                % ioBinFile 517>./ioBinFile
                % Opened 'binTest' successfully.
                % Offset after seek: 32.
                % Read record: rec('The girl saw me.', 312)

                % Not working, just record output; first and third one removed.
                % false, false; default last term in if / then / else
                % ioBinFile 521>./ioBinFile
                % Opened 'binTest' successfully for seek writing.
                % Stream name: binTest; seek to position: 32.
                % ioBinFile 521>cat binTest
                % rec("Dr. Smith", 3).

Additional Information:

Attached Files:

ioBinFile.m (4,993 bytes) 2015-01-19 14:52
https://bugs.mercurylang.org/file_download.php?file_id=234&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

374

[mercury] Bug

crash

always

2015-01-14 15:34

2015-01-15 14:04

Reporter:

juliensf

Platform:

x86_64-w64-mingw32

Assigned To:

juliensf

OS:

Windows

Priority:

normal

OS Version:

Status:

assigned

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

rotd-2015-01-13 fails to install with mingw64

Description:

Building from the source distribution with the mingw-builds x86_64-4.9.2-posix-rseh t_v3-rev1 compiler
aborts during 'make install' when building the optimisation interface for library.m in grade asm_fast.gc.
The abort occurs during expansion of equivalence types. I strongly suspect this is down to C stack
exhaustion but haven't confirmed this yet.

Tags:

Steps To Reproduce:

Additional Information:

The same occurs with the mingw-builds x86_4.8.1-posix-seh-rev5 compiler.

32-bit builds of the same rotd using the standard mingw32 compiler are unaffected.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

372

[mercury] Bug

minor

have not tried

2015-01-05 13:16

Reporter:

pbone

Platform:

x86_64

Assigned To:

OS:

Debian Linux

Priority:

normal

OS Version:

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Finalisers run after main/2 throws an exception.

Description:

We have decided that module finalisers should not run if main/2 throws an exception. The C# backend always runs finalisers. It does not implement the correct behaviour.

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:

370

[mercury] Bug

minor

always

2014-12-22 11:54

2015-01-03 21:07

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:

unused module imports and string.format

Description:

The compiler reports unused module import warnings after string.format is specialised.

% lmc --warn-unused-imports f.m
f.m:001: In module `f':
f.m:001: warning: modules `stream', `string.format' and `string.parse_util'
f.m:001: are imported, but are not used.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

f.m (275 bytes) 2014-12-22 11:54
https://bugs.mercurylang.org/file_download.php?file_id=232&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

371

[mercury] Bug

major

always

2014-12-22 12:18

2014-12-23 00:45

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:

can't locate string.format.format_signed_int_component_nowidth_noprec/3

Description:

% mmc -C f2.m
Uncaught Mercury exception:
Software Error: hlds.pred_table: predicate `hlds.pred_table.lookup_builtin_pred_proc_id'/8: Unexpected: can't locate string.format.format_signed_int_component_nowidth_noprec/3

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

f2.m (391 bytes) 2014-12-22 12:18
https://bugs.mercurylang.org/file_download.php?file_id=233&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

369

[mercury] Bug

crash

always

2014-12-16 03:17

2014-12-16 10:18

Reporter:

sebgod

Platform:

Windows NT 6.3 x86_64

Assigned To:

OS:

Windows

Priority:

normal

OS Version:

8.1

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Software Error: hlds.pred_table: predicate `hlds.pred_table.lookup_builtin_pred_proc_id'/8: Unexpected: can't locate put/5

Description:

Using the latest Mercury compiler (git commit fd822d712a8f1170a9fab3d9a1d05dd5e404106b)
Compiling the attached example module yields following exception:
Making Mercury\int3s\stream_put5_bug.int3
Making Mercury\ints\stream_put5_bug.int
Making Mercury\asm_fast.gc\i686-pc-mingw32\Mercury\cs\stream_put5_bug.c
Uncaught Mercury exception:
Software Error: hlds.pred_table: predicate `hlds.pred_table.lookup_builtin_pred_proc_id'/8: Unexpected: can't locate stream.put/5
Stack dump not available in this grade.
Error: system command received signal 1.
** Error making `Mercury\asm_fast.gc\i686-pc-mingw32\Mercury\cs\stream_put5_bug.c'.

Tags:

Steps To Reproduce:

mmc -m stream_put5_bug

Additional Information:

Unfortunately I'm not sure when this bug exactly appeared (the program I used to compile was working fine for a while).
An educated guess is that this appeared after the string.format changes in the compiler.

System Description

Using the latest MinGW with gcc 4.7 for 32bit
Java 1.8.0
.NET 4.5.1
Bootstrapped (with ROTD from June 2014) Mercury-dev

Attached Files:

stream_put5_bug.m (352 bytes) 2014-12-16 03:17
https://bugs.mercurylang.org/file_download.php?file_id=230&type=bug
pred_table_fix_lookup_builtin_pred_proc_id.diff (1,552 bytes) 2014-12-16 03:18
https://bugs.mercurylang.org/file_download.php?file_id=231&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

367

[mercury] Bug

minor

have not tried

2014-11-27 14:27

2014-12-03 18:23

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:

array binary search predicates use builtin.compare

Description:

approx_binary_search_2 implicitly calls builtin.compare (@<) instead of the supplied ordering function.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

181

[mercury] Bug

minor

always

2011-02-02 13:49

2014-12-02 22:20

Reporter:

pbone

Platform:

Assigned To:

pbone

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Feedback framework uses partial instationation which is not well supported.

Description:

mdbcomp/feedback.m uses partial instantiation to retrieve feedback information from the feedback_info structure. This is not well supported in all grades, for instance it prevents the erlang grade from building the compiler.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

365

[mercury] Bug

minor

sometimes

2014-10-20 11:40

Reporter:

pbone

Platform:

x86_64

Assigned To:

OS:

Linux

Priority:

low

OS Version:

Debian testing

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

hard_coded/parse test failes in asm_fast.gc.par.stseg with libhwloc

Description:

The hard_coded/parse test failes in asm_fast.gc.par.stseg. The test fails to compile because it cannot find libnuma during linking. This test unlike others uses static linking and lubnuma is a dependency of libhwloc. It looks like a static version of libnuma is not provided on Debian. The fix is pretty clear, configure should test if we can use libhwloc is usable for dynamic and static linking and if it fails in either it should be disabled in that case.

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:

231

[mercury] Bug

trivial

always

2011-11-22 16:30

2014-10-09 12:48

Reporter:

colanderman

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 way to specify instantiatedness of char type

Description:

There is currently no way to specify the instantiatedness of a char type, e.g.:

:- inst whitespace ---> ' '; '\t'; '\n'.

The above instantiatednesses are represented as atoms, but since instantiatednesses of character values are internally represented as type char_const(), this leads to mode errors such as:

Final instantiatedness of `HeadVar__1' was `bound('\t' ; '\n' ; ' ')',
expected final instantiatedness was `bound('\t' ; '\n' ; ' ')'.

Attached is a patch which fixes this bug.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

char_inst.m (222 bytes) 2011-11-22 16:30
https://bugs.mercurylang.org/file_download.php?file_id=138&type=bug
mercury-compiler-char-inst.patch (1,974 bytes) 2011-11-22 16:31
https://bugs.mercurylang.org/file_download.php?file_id=139&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

364

[mercury] Bug

minor

sometimes

2014-10-01 16:25

2014-10-07 11:37

Reporter:

pbone

Platform:

x86_64

Assigned To:

pbone

OS:

Linux

Priority:

normal

OS Version:

Debian jessie

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Autoparallelisation analysis crashes on nondet disjunctions.

Description:

Matthias Guedemann submitted this bug via e-mail users@mercurylang.org in September 2014.

> mdprof_create_feedback chokes on the created Deep.data file. I always
> get the error:
>
> ,----
> | Uncaught Mercury exception:
> | Software Error: measurements: predicate `measurements.check_total_calls'/3: Unexpected: TotalCalls \= CallsA + CallsB
> | Stack dump not available in this grade.
> `----
>
> when using
>
> % mdprof_create_feedback --implicit-parallelism Deep.data feedback.data

Tags:

Steps To Reproduce:

MCFLAGS:
--deep-profiling --profile-for-feedback

mdprof_create_feedback --implicit-parallelism Deep.data feedback.data

Additional Information:

I'd like to attempt to explain what's happening, this may be pretty detailed
so feel free to ignore it, I'm mostly explaining this to myself :-).

The autoparallelisation analysis scans your whole program for places where
parallelism could help (it skips parts of the program where it's obvious
that it won't help). It crashes when it looks in
euler_81_82_83_problem_set.euler_edge_81/4 which is nondeterminisic. It
tries to calculate the cost of every goal including the disjunction as a
whole, however it assumes that the disjunction is either a switch or a
"semidet disjunction" which is another special case. This incorrect
assumption causes the analysis to crash (because a consistency check fails).
It might be possible to comment out the consistency check, but then I'd be
concerned that something else would crash because of the same faulty
assumption. I'll see if I can fix the bug in the next week or so.

Attached Files:

euler.tgz (1,145,111 bytes) 2014-10-01 16:25
https://bugs.mercurylang.org/file_download.php?file_id=228&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

296

[mercury] Bug

minor

always

2013-07-31 12:58

2014-10-05 17:33

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:

ui mode and multiple clauses

Description:

from Michael:

This code triggers a mode error:

:- mode get_text_content0(in, out, ui) is det.

get_text_content0([], [], _IO).
get_text_content0([Node|Nodes], [Text|Texts], IO) :-
     get_text_content_from_node(Node, Text, IO), % <-- error here for IO
     get_text_content0(Nodes, Texts, IO).

However if I write the switch explicitly, it's fine:

get_text_content0(Nodes, Texts, IO) :-
     (
         Nodes = [],
         Texts = []
     ;
         Nodes = [Node|Nodes0],
         get_text_content_from_node(Node, Text, IO),
         get_text_content0(Nodes0, Texts0, IO),
         Texts = [Text|Texts0]
     ).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

361

[mercury] Bug

minor

always

2014-09-15 14:59

2014-09-16 13:22

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 loose determinism decl. and pragma loop_check

Description:

The attached program causes a compiler abort in both C backends.

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

Uncaught Mercury exception:
Software Error: ml_backend.ml_code_gen: predicate `ml_backend.ml_code_gen.ml_gen_maybe_convert_goal_code_model'/7: Unexpected: nondet in semi
Stack dump not available in this grade.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug361.m (793 bytes) 2014-09-15 14:59
https://bugs.mercurylang.org/file_download.php?file_id=225&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

362

[mercury] Bug

minor

always

2014-09-15 15:10

2014-09-16 11:10

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:

Program cause compiler to abort in mmos grades (but not mmsc)

Description:

The attached program causes the following abort in the compiler when compiled with:

   $ mmc --grade asm_fast.gc.mmos

Uncaught Mercury exception:
Software Error: map.lookup: key not found
    Key Type: int
    Key Value: 0
    Value Type: hlds.hlds_pred.proc_info
Stack dump not available in this grade.

The program compiles and works correctly in the mmsc grades.

Tags:

Steps To Reproduce:

Additional Information:

The test program is similar, but not identical, to that of bug 0000360 and bug 0000361.

Attached Files:

bug362.m (860 bytes) 2014-09-15 15:10
https://bugs.mercurylang.org/file_download.php?file_id=226&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-02-01 20:57

2014-09-02 12:27

Reporter:

bvn

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:

unclear error message in case the end_module declaration differs from the :- module description

Description:

The compiler bails out this message:

Making Mercury/ints/rdfStore_support.int
Uncaught Mercury exception:
Software Error: modules.m: Unexpected: standardize_impl_items: unexpected items
Stack dump not available in this grade.
make: *** [nim_tcp_xml_server] Error 1

The situation to reproduce: compile a module MX. Then make a copy of MX to become MY. Change in MY the :- module mx. :- module my. and then recompile.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

352

[mercury] Bug

minor

always

2014-08-18 17:41

2014-09-01 18:14

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:

tabled_for_io with Mercury descendants

Description:

In the example, p has attributes may_call_mercury and tabled_for_io. At the end of p, table_io stats prints that the I/O counter = 2. If you retry over p, then at the end, table_io stats prints that counter = 1. Obviously this leads to problems later.

I see that there is an undocumented attribute tabled_for_io_unitize. Perhaps that should be implied if tabled_for_io and may_call_mercury are used together?

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

table_io_callback.m (845 bytes) 2014-08-18 17:41
https://bugs.mercurylang.org/file_download.php?file_id=221&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

146

[mercury] Bug

minor

always

2010-05-24 11:18

2014-09-01 12:46

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:

inf and Nan

Description:

The following is from the BUGS file in the Mercury distribution.

--------

Subject: bug report - Inf and NaN
Date: Wed, 4 Oct 1995 02:48:19 +1000 (EST)

The following module causes an "undefined variable Inf" error in the
generated C code, because 1E400 == Infinity, which gets printed as `Inf'.

:- module hello.
:- interface.
:- import_module io.

:- pred main(io__state::di, io__state::uo) is det.

:- implementation.

main -->
io__write_float(1E400),
io__write_string("\n").

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

356

[mercury] Bug

crash

always

2014-08-30 10:30

2014-08-31 11:11

Reporter:

C4Cypher

Platform:

x86_64-pc-linux-gnu

Assigned To:

OS:

Ubuntu

Priority:

normal

OS Version:

14.04 'Trusty'

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

mmc exception thrown from instmap.m line 600

Description:

Okay, I'm still going through it all, I'm just floored that I got mmc to spit out a runtime error.

Making Mercury/asm_fast.gc.trseg.debug.stseg/x86_64-pc-linux-gnu/Mercury/cs/luaMR.state.c
Uncaught Mercury exception:
Software Error: hlds.instmap: predicate `hlds.instmap.instmapping_set_vars_corresponding'/4: Unexpected: not_reached

Here's a pastebin of the source I was working on: http://pastebin.com/Z6Fau9b3

The lines that I was editing (trying to get the switch to infer as det) when mmc started to throw exceptions are 682 - 684. The entire clause is pasted for convenience.

lua_pcall(L, A) = R :-
    impure Result = lua_pcall(L, A, 0),
    ( Result = returned(R) % line 682
    ; Result = returned_error(Error), throw(Error)
    ; unexpected($module, $pred, "Invalid result value. (WTF?)") % line 684
    ).

Using if-> calls rather than raw disjuncts originally triggered this. I'm going to be focusing on trying to re-arrange this clause in a manner that does not cause mmc to toss cookies.

I've located the exception I've triggered in the source, instmap.m line 600, although I don't know the inner workings of the compiler to begin knowing how to interpret it.

expect(negate(unify(Inst, not_reached)), $module, $pred, "not_reached"),

Note: I also compiled the same code under asm_fast.gc.trseg and got the same response.

Tags:

Steps To Reproduce:

I've created a branch from my project with my code in the exact state it was in when I produced this issue:

https://github.com/C4Cypher/Apollo-lander/tree/mmc-exception-thrown-from-instmap.m-line-600

I was able to produce this with the line

mmc --make testluaMR

with both asm_fast.gc.trseg.debug.stseg and asm_fast.gc.trseg

emphasis placed on the options I'm using in Mercury.options

Additional Information:

I'm at a loss. This library is in mid-development, and as such, it's very unstable ... I'm a long way from making a stable release. Please let me know if there's any kind of information that might help provide more light on this.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

354

[mercury] Bug

minor

always

2014-08-24 09:16

2014-08-30 08:55

Reporter:

chemoelectric

Platform:

AMD64

Assigned To:

OS:

Gentoo Linux

Priority:

normal

OS Version:

not applicable

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Building mercury_cairo fails in version 14.01

Description:

Whenever I attempt to build mercury_cairo with Mercury 14.01 I get a failure as follows:

Installing grade reg.gc.decldebug.stseg
Making Mercury/reg.gc.decldebug.stseg/x86_64-unknown-linux-gnu/Mercury/cs/cairo.c
Uncaught Mercury exception:
Software Error: transform_hlds.table_gen: predicate `transform_hlds.table_gen.type_save_category'/2: Unexpected: unexpected category
** Error making `Mercury/reg.gc.decldebug.stseg/x86_64-unknown-linux-gnu/Mercury/cs/cairo.c'.

Tags:

Steps To Reproduce:

mmc --make libmercury_cairo.install

Additional Information:

I have tried both gcc-4.8.3 and gcc-4.9.1. My C library is glibc 2.19. My Cairo is version 1.12.16 and is located in /usr. (I adjusted Cairo.options to suit.)

Attached Files:

bug354.m (2,632 bytes) 2014-08-24 23:14
https://bugs.mercurylang.org/file_download.php?file_id=222&type=bug

Notes

I/O tabling has two main purposes. The first and more important is to allow the debugger to replay parts of the program execution for the programmer, which requires making I/O operations idempotent (so that we get the same results on the second, third etc "execution" as on the first). The second purpose is to let the person using the debugger actually see a list of the I/O actions, and their results.

I believe that the root of the problem here is that the compiler can do the second part only if it has access to the type_infos describing the types of the arguments of the I/O action. With the current infrastructure for representing typeclass information, this is not always possible in the presence of typeclass constraints on I/O action predicates. The reason is that polymorphism.m can hide the typeinfo for a type variable that is subject to a typeclass constraint arbitrarily deep inside the typeclass_info for that constraint, but the RTTI can encode such locations only up to a fixed depth (currently only the shallowest embedded is encodable). Rather than allow I/O tabling for SOME typeclass-constrained predicates but not others, the current system consistently does not allow it for any. Of course, the error indication could be better.

When I designed the I/O tabling system, I did NOT design it for I/O actions whose types include typeclass constraints. There were two reasons for this. First, none of the I/O actions in the Mercury standard library have typeclass constraints; second, I/O actions are written in languages like C, which themselves have no class system.

While fully fixing this limitation would be desirable, it would also be a huge amount of work. However, there are two possible short term fixes.

The first fix is actually a simple workaround. I haven't tested it with mercury_cairo, but it works with bug354.m: simply compile the module with the mmc flag --trace-table-io-only-retry. This tells the compiler to generate I/O tabling code that serves only the first purpose I mentioned above (making I/O actions idempotent in mdb), but not the second (printing those actions in mdb).
chemoelectric, please enable this flag for all the modules of mercury_cairo, and tell us what happens.

The second possible fix, which I will look into in the next few days, would make this unnecessary by automatically imposing the effect of --trace-table-io-only-retry on any I/O predicates that have typeclass constraints on them.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

355

[mercury] Feature Request

minor

have not tried

2014-08-29 03:20

Reporter:

Platform:

Assigned To:

OS:

Priority:

none

OS Version:

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

it would be nice to be able to defer type errors till runtime

Description:

This page shows how it can be done: https://www.haskell.org/ghc/docs/latest/html/users_guide/defer-type-errors.html

The basic idea is: report a warning instead of an error, and replace the code that has the type error with code that throws an exception.

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:

350

[mercury] Bug

minor

always

2014-08-05 17:36

2014-08-25 14:39

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:

winpthreads support

Description:

Currently threaded grades are unsafe if using winpthreads with mingw-w64, which is different from pthreads-win32. We build Boehm GC with -DGC_WIN32_THREADS (i.e. Win32 API) but the Mercury runtime still creates threads using the pthread API without registering them with the GC.

A (tiny) change will allow building Boehm GC with winpthreads. We'll try to get that upstream, and then we should upgrade.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

353

[mercury] Bug

minor

always

2014-08-19 11:11

Reporter:

wangp

Platform:

Assigned To:

wangp

OS:

Priority:

normal

OS Version:

Status:

assigned

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

misuse of tabled_for_io in the standard library

Description:

dir.open_2 is tabled_for_io but is a non-primitive I/O operation as it directly calls dir.read_first_entry. It should leave that to the Mercury code in dir.open to do.

Foreign procs marked tabled_for_io should not throw exceptions. The throws should be deferred until back in Mercury code.

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:

351

[mercury] Bug

minor

always

2014-08-08 17:47

2014-08-12 19:50

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 compiling integer.m with parallel conjunction

Description:

The master branch fails to bootcheck for me at -O5 --intermod-opt in asm_fast.gc, after the commit[1] which introduces a parallel conjunction to integer.m. The error log is attached.

The 14.01 branch seems fine.

[1] cb161d615520c277a90a74de3a13682b20cc0a7e

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

integer.err (5,322 bytes) 2014-08-08 17:47
https://bugs.mercurylang.org/file_download.php?file_id=220&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

349

[mercury] Bug

minor

always

2014-07-22 15:44

2014-07-28 15:48

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:

io stream predicates thread-safe or not

Description:

Programs which use different streams in different threads should not be unnecessarily serialised on the global lock. But I think it's also quite likely that users write to the same stream, stdout or stderr, from different threads without explicit synchronisation. This can produce garbled output but it basically works, at least for testing, so I think it needs to be allowed.

The underlying I/O routines (probably) have their own locking, but we also perform our own bookkeeping, like line counts, with the protection of the global lock. To safely mark the io procedures as `thread_safe' then requires per-stream locks or perhaps the use of atomic operations.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

345

[mercury] Bug

minor

always

2014-07-11 17:14

2014-07-14 10:20

Reporter:

wangp

Platform:

Assigned To:

OS:

Priority:

low

OS Version:

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

name mangling produces very long symbols

Description:

gcc 4.2.0 on on AIX 7.1 happens to crash on very long symbols. I suspect there is a fixed size buffer somewhere about 256 bytes long.

While this is not a bug in Mercury, we may want to use a different name mangling algorithm which produces shorter and, preferably, more readable symbols, e.g. only escaping the characters which are not allowed in C identifiers.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

125

[mercury] Bug

minor

always

2010-01-06 15:40

2014-07-10 17:28

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:

thread.spawn should spawn OS thread in low-level C grades

Description:

In low-level C grades, thread.spawn creates a new context but not a OS thread. The idea was to multiplex contexts onto OS threads, but this isn't implemented and won't work unless you use non-blocking I/O everywhere, including in user-defined foreign procs. We should just create a new OS thread, as we do in high-level C grades.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-09-27 23:33

2014-07-10 14:01

Reporter:

anonymous

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:

deep profiler bug with unify/compare for tuples

Description:

The following was orginally reported by Peter Wang on the mercury-bugs list.
-----------------------------------------------------------------

Hi,

Here's a test case for a bug in the deep profiler. I think the problem
is in the unification or comparison of a type T which contains a
(non-singleton) tuple which contains T, e.g.

    :- type node
        ---> node(
                    set({node, resource})
                ).

You need to enable this line in mercury_deep_call_port_body.h to
make the bug more obvious:

  #ifdef MR_DEEP_PROFILING_LOWLEVEL_DEBUG
    /* After we copy it, MR_next_call_site_dynamic is not meaningful; */
    /* zeroing it makes debugging output less cluttered. */
    MR_next_call_site_dynamic = NULL;
  #endif

Unification or comparison involving values of that type will then
segfault, as it tries to dereference MR_next_call_site_dynamic when it
is NULL.

I think what happens is that mercury_unify_compare_body.h merges
together the code for for call and exit ports, with the assumption that
no further calls will be made. However, in the MR_TYPECTOR_REP_TUPLE
case MR_generic_compare/unify will be called for each of the arguments,
thereby entering call/exit ports with the deep profiler invariants been
broken. Uncommenting that line above makes it obvious when that
happens, as MR_next_call_site_dynamic will be clobbered after comparing
the first subtype of the tuple, and not setting it up before comparing
the next argument.

The strange thing is, if the tuple is replaced by a d.u. type then
things seem to work, although the code for tuples and du's seem pretty
much the same. So I may be wrong.

Peter

%-----------------------------------------------------------------------------%

:- module cc.
:- interface.

:- import_module io.

:- pred main(io::di, io::uo) is det.

%-----------------------------------------------------------------------------%
%-----------------------------------------------------------------------------%

:- implementation.

:- import_module set.

%-----------------------------------------------------------------------------%

:- type resource
    ---> uri(string).

:- type tuple(T, U) == {T, U}.
%:- type tuple(T, U) ---> tuple(T, U).

:- func mk(T, U) = tuple(T, U).

mk(T, U) = {T, U}.
%mk(T, U) = tuple(T, U).

:- type node
    ---> node(
                set(tuple(node, resource))
            ).

%-----------------------------------------------------------------------------%

main(!IO) :-
    Child = node(
        set.init
    ),
    A = node(
        set.make_singleton_set(mk(Child, uri("foo")))
    ),
    B = node(
        set.make_singleton_set(mk(Child, uri("bar")))
    ),
    write_string("#################\n", !IO),

% ( unify(A, B) ->
% io.write_string("unify\n", !IO)
% ;
% io.write_string("not unify\n", !IO)
% ),

    compare(R, A, B),
    io.print(R, !IO),
    io.nl(!IO),

    write_string("################# done\n", !IO).

%-----------------------------------------------------------------------------%
% vim: ft=mercury ts=8 sw=4 et wm=0 tw=0

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

344

[mercury] Bug

minor

always

2014-07-05 02:09

2014-07-05 02:30

Reporter:

nx2059123

Platform:

x86_64

Assigned To:

OS:

CentOS Linux

Priority:

normal

OS Version:

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Cannot find files when compiling with --debug option

Description:

When you try to compile a file with the --debug option you get an error.
Various files are not found when compiling with the --debug option

[mercury-user@localhost mercury]$ mmc --debug ./hello.m
mkinit: error opening file `/home/mercury-user/local/lib/mercury/modules/asm_fast.gc.debug/mer_rt.init': No such file or directory
mkinit: error opening file `/home/mercury-user/local/lib/mercury/modules/asm_fast.gc.debug/mer_std.init': No such file or directory
mkinit: error opening file `/home/mercury-user/local/lib/mercury/modules/asm_fast.gc.debug/mer_browser.init': No such file or directory
mkinit: error opening file `/home/mercury-user/local/lib/mercury/modules/asm_fast.gc.debug/mer_mdbcomp.init': No such file or directory

Tags:

Steps To Reproduce:

[mercury-user@localhost mercury-srcdist-14.01]$ pwd
/home/mercury-user/local/src/mercury-srcdist-14.01

[mercury-user@localhost mercury-srcdist-14.01]$ uname -a
Linux localhost.localdomain 2.6.32-431.20.3.el6.x86_64 0000001 SMP Thu Jun 19 21:14:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[mercury-user@localhost mercury-srcdist-14.01]$ gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[mercury-user@localhost mercury-srcdist-14.01]$ ./configure --prefix=$HOME/local

config.status: executing default commands

the set of library grades to install will be
   asm_fast.gc
   asm_fast.gc.debug.stseg
   asm_fast.gc.decldebug.stseg
   asm_fast.gc.memprof
   asm_fast.gc.prof
   asm_fast.gc.profdeep
   asm_fast.gc.trseg
   asm_fast.gc.trseg.debug.stseg
   asm_fast.par.gc.stseg
   hlc.gc
   hlc.gc.trseg
   hlc.par.gc

Configuring to install 12 grades.
This will likely take 2 to 6 hours.
You can make the install faster by installing fewer grades
as shown by the fine-tuning section of the INSTALL file or by
compiling the files of each grade in parallel which you can do
via a command such as make PARALLEL=-j2 install.
[mercury-user@localhost mercury-srcdist-14.01]$

[mercury-user@localhost mercury-srcdist-14.01]$ make
[mercury-user@localhost mercury-srcdist-14.01]$ make install

-- Installation complete.

-- Don't forget to add /home/mercury-user/local/bin to your PATH,
-- /home/mercury-user/local/man to your MANPATH,
-- and /home/mercury-user/local/info to your INFOPATH,
-- to copy deep_profiler/mdprof_cgi to /usr/lib/cgi-bin,
-- and to add the following lines to the `.emacs' file
-- in your home directory:
    (add-to-list 'load-path
        "/home/mercury-user/local/lib/mercury/elisp")
    (autoload 'mdb "gud" "Invoke the Mercury debugger" t)
gmake[1]: Leaving directory `/home/mercury-user/local/src/mercury-srcdist-14.01'
[mercury-user@localhost mercury-srcdist-14.01]$

[mercury-user@localhost mercury]$ mmc --debug ./hello.m
mkinit: error opening file `/home/mercury-user/local/lib/mercury/modules/asm_fast.gc.debug/mer_rt.init': No such file or directory
mkinit: error opening file `/home/mercury-user/local/lib/mercury/modules/asm_fast.gc.debug/mer_std.init': No such file or directory
mkinit: error opening file `/home/mercury-user/local/lib/mercury/modules/asm_fast.gc.debug/mer_browser.init': No such file or directory
mkinit: error opening file `/home/mercury-user/local/lib/mercury/modules/asm_fast.gc.debug/mer_mdbcomp.init': No such file or directory

Additional Information:

% hello.m
:- module hello.
:- interface.
:- import_module io.
:- pred main(io::di, io::uo) is det.

:- implementation.
main(!IO) :-
io.write_string("Hello, World!\n", !IO).

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

334

[mercury] Bug

major

sometimes

2014-06-16 12:10

2014-06-30 15:06

Reporter:

pbone

Platform:

x86_64

Assigned To:

pbone

OS:

Debian Linux

Priority:

high

OS Version:

jessie or sid

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Low level C parallel grades crash with libc6 > 2.19.x and newer Intel processors

Description:

Intel's latest processors include some transactional memory support instructions (TSX). These can be used to implement lock free data structures and can also be used to implement more traditional locking primitives such as mutexes. Specifically new versions of eglibc use this to implement lock elision for pthreads mutexes: http://lwn.net/Articles/534758/ If you have a supported processor eglibc will use this by default.

There has been a dormant bug in Mercury (or possibly Boehm GC) that now shows up since I upgraded to libc6 2.19.1, I use a Intel i7-4770 which has the TSX feature and now some parallel Mercury programs crash. A GP fault is thrown by some code in the pthreads library.

Tags:

Steps To Reproduce:

Using an Intel i7-4770 processor (without a K suffix), and eglibc 2.19.1 build Mercury with GRADE=asm_fast.gc.par.stseg in the Mmake.params file (I was doing this to test parallel profiling). The resulting compiler will intermittently crash.

Additional Information:

Mercury is not the only program to have a bug like this show up with the new libc. libtirpc has a similar problem. If you use Debian testing and NFS (or anything with portmap), then upgrading libtirpc from sid will fix this.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

340

[mercury] Bug

minor

always

2014-06-23 16:17

2014-06-25 17:36

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:

strerror not thread-safe

Description:

io.m uses strerror in a couple of cases as if it is thread-safe when it is not, and probably there are other cases in the runtime. An alternative is strerror_r, or strerror_s on Windows. I think we should create a wrapper MR_strerror around both, and forget about trying to lock around uses of strerror().

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

338

[mercury] Bug

minor

always

2014-06-20 17:58

2014-06-25 17:35

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:

asm_fast.par.gc programs crash on Windows

Description:

Strangely enough it works as long as I set MERCURY_OPTIONS=-Pn so it's probably something with the CPU detection. Filing this so I don't forget.

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:

342

[mercury] Bug

major

always

2014-06-24 16:03

2014-06-25 16:39

Reporter:

juliensf

Platform:

Assigned To:

juliensf

OS:

Priority:

urgent

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

string.format broken in non-C grades

Description:

The attached program should print "16.0"; when using the Mercury implementation of format
(i.e when using_sprintf returns false), it prints "10.0". This affects all of the non-C backends.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

fmt_bug.m (284 bytes) 2014-06-24 16:03
https://bugs.mercurylang.org/file_download.php?file_id=217&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

341

[mercury] Bug

minor

always

2014-06-24 05:58

2014-06-24 11:40

Reporter:

nx2059

Platform:

MingW32

Assigned To:

juliensf

OS:

Windows

Priority:

normal

OS Version:

8.1

Status:

resolved

Product Version:

Product Build:

Resolution:

no change required

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

MingW32 Build Errors

Description:

Various unknown types cause errors on builds (off64_t, off_t, etc..)

Tags:

Steps To Reproduce:

$ cd mercury-srcdist-14.01

$ gcc --version
gcc.exe (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$./configure --disable-most-grades

$make

...

make[2]: Leaving directory `/src/mercury-srcdist-14.01/robdd'
/tmp/mmake.YhJAkb:1045: warning: undefined variable `DESTDIR'
cd library && PATH=../scripts:../util:../mfilterjavac:../../mfilterjavac:$PATH M
MAKE_VPATH=. MMAKE_DIR=../scripts DESTDIR= ../scripts/mmake
make[2]: Entering directory `/src/mercury-srcdist-14.01/library'
../scripts/mgnuc --grade hlc.gc.pregen -- -c tree234.c -o tree234.o
In file included from c:\mingw\include\unistd.h:36:0,
                 from ../runtime/mercury_timing.h:23,
                 from benchmarking.m:163,
                 from tree234.c:32:
c:\mingw\include\io.h:301:1: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int, off64_t, int);
^
c:\mingw\include\io.h:301:36: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int, off64_t, int);
                                    ^
c:\mingw\include\io.h:302:1: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
^
c:\mingw\include\io.h:302:39: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
                                       ^
In file included from ../runtime/mercury_timing.h:23:0,
                 from benchmarking.m:163,
                 from tree234.c:32:
c:\mingw\include\unistd.h:65:20: error: unknown type name 'off_t'
int ftruncate(int, off_t);
                    ^
c:\mingw\include\unistd.h:67:38: error: unknown type name 'off_t'
__CRT_INLINE int ftruncate(int __fd, off_t __length)
                                      ^
make[2]: *** [tree234.o] Error 1
make[2]: Leaving directory `/src/mercury-srcdist-14.01/library'
make[1]: *** [library] Error 2
make[1]: Leaving directory `/src/mercury-srcdist-14.01'
make: *** [all] Error 2

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

337

[mercury] Bug

minor

always

2014-06-20 10:58

Reporter:

wangp

Platform:

Assigned To:

OS:

Priority:

low

OS Version:

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

csharp stream problems

Description:

In the csharp backend (with mono), io.read_char returns immediately after one character instead of waiting for a whole line first. io.read_char returns 0 for some unprintable characters, e.g. backspace, delete. This also makes io.read_line_as_string return an error as soon as you hit backspace while editing a line.

Maybe we need to switch to buffered streams in csharp.

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:

330

[mercury] Bug

minor

always

2014-05-26 10:43

2014-05-27 16: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:

slice directory does not build in debugging grade

Description:

SLICE_FLAGS contains --force-disable-tracing

After commit 5254245ae34ab6b3ca0f7dcd3c7fc807e1407f7d "Eliminate some unnecessary labels in low level grades." the modules in the slice directory no longer compile with GRADE=asm_fast.gc.debug, producing errors like:

mdbcomp.goal_path.c:2847:2: error: label ‘_entry_mercury__fn__mdbcomp__goal_path__goal_path_add_at_end_2_0_i7’ used but not defined

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

mdbcomp.goal_path.c (270,554 bytes) 2014-05-27 10:34
https://bugs.mercurylang.org/file_download.php?file_id=214&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

322

[mercury] Bug

minor

always

2014-03-24 13:49

2014-05-15 13:28

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:

mingw-w64 compiled program crashes

Description:

Mercury 14.01 branch

Cross-compiling with x86_64-w64-mingw32-gcc from Ubuntu
gcc version 4.6.3 (GCC)

For the given (small) test program:

asm_fast.gc CRASH
asm_jump.gc OK
reg.gc OK
none.gc OK
hlc.gc OK

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug.m (204 bytes) 2014-03-24 13:49
https://bugs.mercurylang.org/file_download.php?file_id=207&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

329

[mercury] Bug

crash

always

2014-05-11 14:09

2014-05-13 15:33

Reporter:

lpimmes

Platform:

Maverick 10.9

Assigned To:

juliensf

OS:

OS X

Priority:

urgent

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

duplicate

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Uncaught Mercury exception:

Description:

-library-version 1.0.2411.0 --host-env-type posix --target-env-type posix --unboxed-float -O2 --make --fully-strict -E -v -O 6 --use-subdirs --search-lib-files-dir . --init-file stringCut_lib.init --link-object libstringCut_lib.a --compile-to-c --use-subdirs stringCut'
Uncaught Mercury exception:
Software Error: map.lookup: key not found
    Key Type: string
    Key Value: "cutInfo"
    Value Type: tree234.tree234(parse_tree.prog_data.type_ctor, hlds.hlds_data.hlds_type_defn)
% Touching `Mercury/err_dates/stringCut.err_date'... done.
% Parsing module `stringCut' and imported interfaces...
% Module qualifying items...
% done.

Tags:

Steps To Reproduce:

Unzip strgCut.zip
>make
... error appears

-------
Any ideas? Help would be appreciated.
stringCut_lib.m compiles OK
stringCut.m did compile this morning. Added cutInfo tracking.
Thanks.

Additional Information:

Attached Files:

strgCut.zip (4,568 bytes) 2014-05-11 14:09
https://bugs.mercurylang.org/file_download.php?file_id=213&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

327

[mercury] Bug

minor

always

2014-04-30 11:05

2014-05-13 15:28

Reporter:

juliensf

Platform:

Assigned To:

juliensf

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

no change required

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

incorrect binutils used with mingw64

Description:

Some MinGW64 installations name include "gcc" in the name of the ranlib executable, as in

x86_64-w64-mingw32-gcc-ranlib

When host is set to x86_64-w64-mingw32 the configure script looks for x86_64-w64-mingw32-ranlib, but not the above. (On my system it falls back to using ranlib, which is incorrect since that's the
32-bit version.)

Ditto for ar and nm.

Tags:

Steps To Reproduce:

Additional Information:

A workaround is to manually specify the names of ar, ranlib and nm to configure using the variables
AR, RANLIB and NM, for example:

AR=x86_64-w64-mingw32-gcc-ar RANLIB=x86_64-w64-mingw32-gcc-ranlib NM=x86_64-w64-mingw32-gcc-nm ./configure ... etc

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

328

[mercury] Bug

tweak

always

2014-05-01 17:19

2014-05-01 20:05

Reporter:

pbone

Platform:

All

Assigned To:

OS:

All

Priority:

low

OS Version:

All

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

dir.foldl2 should be called dir.fold2

Description:

The foldl functions and predicates in the dir module do not guarantee any specific order. Therefore the l (indicating left) in their name is a misnomer. The should be deprecated in favor of names without the 'l'.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

323

[mercury] Bug

minor

always

2014-04-02 22:53

2014-04-03 01:21

Reporter:

bwitkowski

Platform:

Linux

Assigned To:

OS:

Debian

Priority:

normal

OS Version:

wheezy (7.0)

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Matching on adts makes and instantiation state subtyping is impossible.

Description:

Matching on a subtype doesn't carry the information about the inst of the subtype which makes using pattern matching and instantiation state subtyping impossible to use. See the attached file for details.

Tags:

Steps To Reproduce:

$ mmc --version
Mercury Compiler, version 13.05.2, configured for x86_64-unknown-linux-gnu
Copyright (C) 1993-2013 The University of Melbourne

$ mmc -E subtyping.m
subtyping.m:019: In clause for `use_everything(in, out)':
subtyping.m:019: mode error in conjunction. The next 2 error messages
subtyping.m:019: indicate possible causes of this error.
subtyping.m:019: In clause for `use_everything(in, out)':
subtyping.m:019: in argument 1 of call to predicate `subtyping.use_bar'/2:
subtyping.m:019: mode error: variable `Bar' has instantiatedness `ground',
subtyping.m:019: expected instantiatedness was
subtyping.m:019: `bound(subtyping.bar(ground))'.
subtyping.m:019: In clause for `use_everything(in, out)':
subtyping.m:019: in argument 2 of clause head:
subtyping.m:019: mode error in unification of `HeadVar__2' and `String'.
subtyping.m:019: Variable `HeadVar__2' has instantiatedness `free',
subtyping.m:019: variable `String' has instantiatedness `free'.

Additional Information:

Attached Files:

subtyping.m (491 bytes) 2014-04-02 22:53
https://bugs.mercurylang.org/file_download.php?file_id=208&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

303

[mercury] Bug

minor

always

2013-11-06 17:44

2014-03-04 16:11

Reporter:

juliensf

Platform:

MinGW

Assigned To:

juliensf

OS:

Windows

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Installation of java grade fails on Windows 7 / MinGW for 13.05.2-beta-2013-10-31

Description:

Installation of the java grade fails when building on Windows 7 with MinGW with a compiler abort.
(The end of the install log is below.) The system was:

Windows 7
MinGW/GCC 4.6.2
javac 1.7.0_09

The problem does *not* occur on Windows XP, MinGW GCC 4.5.0, javac 1.7.0_01.
(The Java version is probably irrelevant, since the problem is with the compiler not the
Java version of the library.)

Tags:

Steps To Reproduce:

- add javac bin directory to MSYS PATH
- unpack 13.05.2-beta-2013-10-31 tarball
- ./configure --enable-libgrades=asm_fast.gc,java --prefix=…
- make PARALLEL=-j2
- make PARALLEL=-j2 install

Additional Information:

Making Mercury\javas\jmercury\string__builder.java^M
Making Mercury\javas\jmercury\thread__channel.java^M
Making Mercury\javas\jmercury\thread__mvar.java^M
Making Mercury\javas\jmercury\thread__semaphore.java^M
Making Java class files^M
Note: Some input files use unchecked or unsafe operations.^M
Note: Recompile with -Xlint:unchecked for details.^M
Making mer_std.jar^M
Uncaught Mercury exception:^M
Software Error: parse_tree.module_cmds: predicate `parse_tree.module_cmds.list_class_files_for_jar'/6: Unexpected: io.file_type failed: No such file or directory^M
make[2]: *** [libmer_std.install] Error 1

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

320

[mercury] Bug

minor

always

2014-02-19 16:12

2014-02-21 17:09

Reporter:

pbone

Platform:

Assigned To:

juliensf

OS:

Priority:

normal

OS Version:

Status:

feedback

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

instantiation states and "unused module import" warnings do not interact properly.

Description:

A Mercury module containing a module import for some other Mercury module and an instantiation state deceleration for a type in that module but nothing else to do with that module generated an unused module import warning.

Tags:

Steps To Reproduce:

Compile the attached module with "mmc -c", it should be warnings-clean but isn't. mmc outputs:

paul@oxygen> mmc -c unused_import_inst_bug.m
unused_import_inst_bug.m:001: In module `unused_import_inst_bug':
unused_import_inst_bug.m:001: warning: module `maybe' is imported in the
unused_import_inst_bug.m:001: interface, but is not used in the interface.

Additional Information:

Attached Files:

unused_import_inst_bug.m (455 bytes) 2014-02-19 16:12
https://bugs.mercurylang.org/file_download.php?file_id=205&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

have not tried

2009-02-18 21:21

2014-02-21 17:04

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:

existentially quantified data constructors and inst subtyping do not work together

Description:

The attached program reports and error when compiled with mmc -C.
The appears to be the result of two insts that should unify not unify because
one of them includes a component that corresponds to an introduced
type-info.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

inst_subtype_exists.m (1,287 bytes) 2009-02-18 21:21
https://bugs.mercurylang.org/file_download.php?file_id=68&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

317

[mercury] Bug

major

always

2014-02-07 15:33

2014-02-10 10:38

Reporter:

lpimmes

Platform:

Assigned To:

juliensf

OS:

OSx 10.9.1

Priority:

high

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

no change required

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

:- pragma memo(findLngCmnSubsqStck/3). WORKING; not sure how to do static Asymptotic analysis

Description:

Answers for longest common subsequence appear to be correct.
If pragma commented out, we take forever on longer test cases. Thus pragma is working,
but how?
I returned number of calls to findLngCmnSubsqStck/3. Number of calls remains the
same regardless of pragma or not. I would expect calls to be reduced significantly.
This is a bug in my understanding. Thank goodness pragma works, because it really speeds things
up.
I would like to resolve what other authors have determined:
'total number of calls is at most 2(m+1)(n+1)+1 and the time is O(mn)'

Tags:

Steps To Reproduce:

See listing for comments of trace run. Perhaps I counted incorrectly.
Thanks again to the Mercury team, and Mercury!

Additional Information:

Example output:
% lngCommSubseqStck 495>./lngCommonSubseqStck
% Input test case 0, 1, 2, 3, 4, ... Output longest common subsequence.
% ^d to quit.
% Caching really speeds up execution, but same number of calls.
% 0
% LongestCommonSubsequence('a', 'a')='a',
% a length: 1, b length: 1, findLngCmnSubsqStck calls: 2.
% 1
% LongestCommonSubsequence('aa', 'bb')='',
% a length: 2, b length: 2, findLngCmnSubsqStck calls: 4.
% 2
% LongestCommonSubsequence('aaa', 'bbb')='',
% a length: 3, b length: 3, findLngCmnSubsqStck calls: 7.
% 3
% LongestCommonSubsequence('aaaa', 'bbbb')='',
% a length: 4, b length: 4, findLngCmnSubsqStck calls: 11.
% 4
% LongestCommonSubsequence('aaaaa', 'bbbbb')='',
% a length: 5, b length: 5, findLngCmnSubsqStck calls: 16.
% 5
% LongestCommonSubsequence('aaaaaa', 'bbbbbb')='',
% a length: 6, b length: 6, findLngCmnSubsqStck calls: 22.
% 6
% LongestCommonSubsequence('aaaaaaa', 'bbbbbbb')='',
% a length: 7, b length: 7, findLngCmnSubsqStck calls: 29.
% 7
% LongestCommonSubsequence('aaaaaaaa', 'bbbbbbbb')='',
% a length: 8, b length: 8, findLngCmnSubsqStck calls: 37.
% 9
% LongestCommonSubsequence('aaaaaaaaaa', 'bbbbbbbbbb')='',
% a length: 10, b length: 10, findLngCmnSubsqStck calls: 56.

Attached Files:

lngCommonSubseqStck.m (9,448 bytes) 2014-02-07 15:33
https://bugs.mercurylang.org/file_download.php?file_id=201&type=bug
lngCommonSubseqStck_tbl.m (12,434 bytes) 2014-02-07 19:34
https://bugs.mercurylang.org/file_download.php?file_id=202&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

316

[mercury] Bug

major

always

2014-02-05 18:11

2014-02-05 18:33

Reporter:

lpimmes

Platform:

Assigned To:

juliensf

OS:

OSx 10.9.1

Priority:

high

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

no change required

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Declared `det', inferred `semidet'. --- [H|T] first argument input

Description:

This function compiles, except for det error.
In this case, I really need det, not semidet, otherwise callers including main will not work.

:- pred charToStrLst(list(char), list(string), list(string)).
:- mode charToStrLst(in, in, out) is det.
charToStrLst([H | T], Accum, LstStr) :- % [H|T] can fail
    (if list.is_empty([H|T])
    then
    LstStr = Accum
    else
    format("%c", [c(H)], Str),
     charToStrLst(T, [Str | Accum], LstStr)
    ).

All I needed to accomplish is convert, e.g., "foo" to ["f", "o", "o"].

longCommSubseq.m:097: In `charToStrLst'(in, in, out):
longCommSubseq.m:097: error: determinism declaration not satisfied.
longCommSubseq.m:097: Declared `det', inferred `semidet'.
longCommSubseq.m:098: In argument 1 of clause head:
longCommSubseq.m:098: unification of `HeadVar__1' and `list.[H | T]' can
longCommSubseq.m:098: fail.
% Program contains determinism error(s).

Tags:

Steps To Reproduce:

mmc --make --fully-strict -E -v -O 0 --use-subdirs longCommSubseq

Additional Information:

See attached file.
Thanks.

Attached Files:

longCommSubseq.m (4,585 bytes) 2014-02-05 18:11
https://bugs.mercurylang.org/file_download.php?file_id=200&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

315

[mercury] Bug

major

always

2014-01-31 14:01

2014-02-01 05:47

Reporter:

lpimmes

Platform:

Assigned To:

OS:

OSx

Priority:

high

OS Version:

10.9.1

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Software Error: detected need for minimal model in pred rodcut.r_n/3

Description:

In another program
:- pragma memo(fib/3). works OK here, but mode is det.

Trying memo on mode is multi. Comment out memo on two pred, output runs and is correct.
Uncomment memo and we get

Software Error: detected need for minimal model in pred rodcut.r_n/3

Not sure how to create det function, because I need to make decision for base and recursive cases,
i.e., multiple output.
rodcut will be very slow for larger values of N, which is why I want memoization.
See listing attached file.
Thanks.

Tags:

Steps To Reproduce:

Partial listing:

...
% Implement rn, bottom of page 362 Dynamic programming, Cormen text.
% Should be implementing 15.2 rn = max (p_i + r_n-i)
% 1 <= i <= n, r0=0
%%%% Cannot use multi mode on functions, use pred, and declare main to be cc_multi.

:- pred r_n(int, array(int), int).
:- mode r_n(in, in, out) is multi.
%:- pragma memo(r_n/3).
r_n(1, P, Mx) :-
    Mx = getRevenue(1, P).
r_n(N, P, Mx) :-
    r_nAux(getRevenue(N, P), 1, N-1, P, Mx).

:- pred r_nAux(int, int, int, array(int), int).
:- mode r_nAux(in, in, in, in, out) is multi.
%:- pragma memo(r_nAux/5).
r_nAux(Mx, LowIndx, HighIndx, P, Max) :-
    (
     if LowIndx > HighIndx then
       Max = Mx
    else
       r_n(LowIndx, P, Lw),
       r_n(HighIndx, P, Hg),
        NewMax = int.max(Mx, Lw + Hg),
        r_nAux(NewMax, LowIndx + 1, HighIndx -1, P, Max)
    ).
...

Additional Information:

Attached Files:

rodcut.m (3,694 bytes) 2014-01-31 14:01
https://bugs.mercurylang.org/file_download.php?file_id=197&type=bug
bug315.m (570 bytes) 2014-01-31 15:15
https://bugs.mercurylang.org/file_download.php?file_id=198&type=bug
rodcut2.m (2,654 bytes) 2014-01-31 15:15
https://bugs.mercurylang.org/file_download.php?file_id=199&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

302

[mercury] Bug

block

always

2013-10-30 12:02

2014-01-31 10:15

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:

can't bootcheck in asm_fast.gc.debug.stseg

Description:

Bootcheck in asm_fast.gc.debug.stseg crashes when making dependencies for the standard library, on both 32-bit and 64-bit.

May or may not be like bug 0000065.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug302.m (1,402 bytes) 2014-01-30 18:08
https://bugs.mercurylang.org/file_download.php?file_id=195&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

311

[mercury] Bug

minor

always

2014-01-23 06:09

2014-01-28 16:31

Reporter:

plsm

Platform:

i686

Assigned To:

OS:

Linux Debian

Priority:

normal

OS Version:

3.2.46-1+deb7u1

Status:

assigned

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Gathering solutions depends on how predicate is programmed

Description:

I have a predicate that has several solutions that I want to collect. Depending on how I program the predicate, either all solutions are correctly collected by predicates in module solutions, or some solutions or even just one are returned by predicates.

I have tested in mercury compiler 11.07 and 13.05.2

Tags:

Steps To Reproduce:

Additional Information:

System Description

Attached Files:

bugSolutions.m (2,964 bytes) 2014-01-23 06:09
https://bugs.mercurylang.org/file_download.php?file_id=191&type=bug
bug311.m (6,251 bytes) 2014-01-28 14:24
https://bugs.mercurylang.org/file_download.php?file_id=194&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2009-06-12 14:56

2014-01-28 15:55

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 throws exception with --profile-for-implicit-parallelism

Description:

rotd-2009-06-09 aborts with an exception when compiling the standard library module
erlang_rtti_implementation.m in grade asm_fast.gc.profdeep with --profile-for-implicit-parallelism
enabled.

Uncaught Mercury exception:
Software Error: llds_out.m: Unexpected: stack var out of range
Stack dump not available in this grade.

Compiling with --no-inline-simple acts a workaround.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

erlang_rtti_implementation.m (8,995 bytes) 2009-06-15 01:32
https://bugs.mercurylang.org/file_download.php?file_id=76&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

307

[mercury] Bug

minor

always

2014-01-06 22:32

2014-01-10 15:58

Reporter:

bacuh

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:

internal compiler error in assign_by_spills during make install of mercury

Description:

make install fails with

  mercury_ho_call.c: In function ‘MR_generic_unify’:
  mercury_ho_call.c:721:1: internal compiler error: in assign_by_spills, at lra-assigns.c:1281
   }
   ^

at my site.

This happens with 13.05.x and 14.01. I may try more older versions to find the one introducing this behaviour. Just ask if this was helpful. Also if there's some investigation I can do or further information I can provide.

Tags:

Steps To Reproduce:

  pkgdir=/tmp # or anything else

  ./configure --prefix=/usr --mandir=/usr/share/man \
              --infodir=/usr/share/info --disable-debug-grades \
              --disable-inefficient-grade

  make PARALLEL="$NOMATTERWHAT"

  make INSTALL_PREFIX="$pkgdir"/usr \
       INSTALL_MAN_DIR="$pkgdir"/usr/share/man \
       INSTALL_INFO_DIR="$pkgdir"/usr/share/info \
       MERCURY_COMPILER="$pkgdir"/usr/bin/mercury_compile \
       MERCURY_CONFIG_DIR="$pkgdir"/usr/lib/mercury \
       PARALLEL="$NOMATTERWHAT" install

Additional Information:

messages surrounding above error:

  /var/build/build/mercury-compiler/src/mercury-srcdist-13.05.2/install_grade_dir.asm_fast.gc/scripts/mgnuc --grade asm_fast.gc --c-debug --no-ansi -- -fpic -DMR_PIC \
      -c mercury_hgc.c -o mercury_hgc.pic_o
  /var/build/build/mercury-compiler/src/mercury-srcdist-13.05.2/install_grade_dir.asm_fast.gc/scripts/mgnuc --grade asm_fast.gc --c-debug --no-ansi -- -fpic -DMR_PIC \
      -c mercury_ho_call.c -o mercury_ho_call.pic_o
  mercury_ho_call.c: In function ‘MR_generic_unify’:
  mercury_ho_call.c:721:1: internal compiler error: in assign_by_spills, at lra-assigns.c:1281
   }
   ^
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See <https://bugs.archlinux.org/> for instructions.
  /tmp/mmake.GoLNnI:1599: recipe for target 'mercury_ho_call.pic_o' failed
  make[2]: *** [mercury_ho_call.pic_o] Error 1
  make[2]: Leaving directory '/var/build/build/mercury-compiler/src/mercury-srcdist-13.05.2/install_grade_dir.asm_fast.gc/runtime'
  To clean up from failed install, remove /var/build/build/mercury-compiler/src/mercury-srcdist-13.05.2/install_grade_dir.asm_fast.gc
  /tmp/mmake.GMvojB:1408: recipe for target 'install_grades' failed
  make[1]: *** [install_grades] Error 1
  make[1]: Leaving directory '/var/build/build/mercury-compiler/src/mercury-srcdist-13.05.2'
  Makefile:37: recipe for target 'install' failed
  make: *** [install] Error 2

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

306

[mercury] Bug

minor

always

2013-12-18 06:12

2014-01-08 16:00

Reporter:

Pedro Mariano

Platform:

Assigned To:

juliensf

OS:

Priority:

low

OS Version:

Status:

confirmed

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Java grade and non alphabetic field name

Description:

If the field name of some type starts with a digit, compiling in the java grade fails. I've attached a simple program to illustrate the bug.

There is no problem compiling to C.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

javaField.m (1,143 bytes) 2013-12-18 06:12
https://bugs.mercurylang.org/file_download.php?file_id=186&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

165

[mercury] Bug

minor

always

2010-10-04 10:43

2014-01-08 15:59

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:

java backend generates invalid code for contrived type

Description:

The Java backend currently generates invalid code for this type:

:- type '$blah'
---> '$blah'(int)
; '$blah2'.

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:

301

[mercury] Bug

minor

always

2013-10-29 14:37

2013-10-29 17:37

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:

incorrect handling of deconstructions in float_reg.m pass

Description:

The compiler aborts on this test case when targeting low-level grades with float registers enabled. (I have a fix, just want a bug number)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

float_reg_deconstruct.m (824 bytes) 2013-10-29 14:37
https://bugs.mercurylang.org/file_download.php?file_id=184&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

299

[mercury] Bug

minor

always

2013-09-16 16:09

2013-10-29 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:

unaligned memory access for unboxed doubles

Description:

Unaligned memory access instructions occur on 32-bit architectures when an unboxed double begins on an odd-numbered slot, crashing on some architectures (e.g. SPARC).

I think we can "just" split the dword read/write into two instructions for odd-numbered slots.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

unaligned.m (1,323 bytes) 2013-09-16 16:36
https://bugs.mercurylang.org/file_download.php?file_id=182&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

294

[mercury] Bug

major

always

2013-07-24 18:23

2013-09-29 15:12

Reporter:

pbone

Platform:

Assigned To:

pbone

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

GCC 4.6 and 4.7 break asm_fast.par grades

Description:

The mandelbrot program crashes when compiled with gcc 4.6 or 4.7. I have not tested 4.8. 4.5 works.

I found that passing -fno-reorder-functions to GCC avoids the problem. I don't yet know why.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

patch (1,741 bytes) 2013-07-24 18:24
https://bugs.mercurylang.org/file_download.php?file_id=178&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

298

[mercury] Bug

minor

always

2013-09-16 15:41

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:

missing .mh include

Description:

foo1.m calls the C function declared in a (non-local) foreign_decl in foo2.m. In the low-level C grades, foo1.c does not include foo2.mh.

I think the manual suggests that it should:
"By default, the contents of `pragma foreign_decl' declarations are
also visible in the same kinds of declarations in other modules that
import the module containing the `pragma foreign_decl' declaration."

In the high-level C grades, foo1.c does include foo2.mih (mih).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

foo1.m (656 bytes) 2013-09-16 15:41
https://bugs.mercurylang.org/file_download.php?file_id=180&type=bug
foo2.m (556 bytes) 2013-09-16 15:41
https://bugs.mercurylang.org/file_download.php?file_id=181&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-03-04 15:03

2013-09-09 16:22

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 during liveness detection

Description:

The attached file aborts during liveness detection with these options:

mmc -O2 --optimise-higher-order --optimise-constant-propagation --no-common-struct -C string2

(this is just a cut down string.m. The same thing happens with the full file.)

% Computing liveness in function `string2.foldr'/3 mode 0
Uncaught Mercury exception:
Software Error: hlds_llds.m: Unexpected: goal_info_get_post_births: no code_gen_info

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

string2.m (2,558 bytes) 2008-03-04 15:03
https://bugs.mercurylang.org/file_download.php?file_id=44&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

297

[mercury] Bug

major

always

2013-08-29 13:26

2013-09-04 11:52

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:

compile-time evaluation of typed_unify changes behaviour

Description:

The attached program is broken by the compile-time evaluation of typed_unify when --optimise-constant-propagation is enabled (-O3).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

t.m (834 bytes) 2013-08-29 13:26
https://bugs.mercurylang.org/file_download.php?file_id=179&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

292

[mercury] Bug

major

always

2013-07-07 01:39

2013-07-12 01:36

Reporter:

urilabob

Platform:

linux

Assigned To:

juliensf

OS:

fedora

Priority:

normal

OS Version:

19 (kernel 3.9.8

Status:

resolved

Product Version:

Product Build:

Resolution:

no change required

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

'make install' fails on missing dependency (bryant.h) for robdd.m

Description:

Attempting to install mercury-srcdist-13.05 fails because the make of robdd.m fails to find bryant.h. Doubtless it's a shell variable not set properly environment or something of that sort - but I haven't been able to figure out what. The final part of the transcript is attached.

Tags:

Steps To Reproduce:

sh configure
make
make install (which fails)

Additional Information:

Attached Files:

make_install_transcript.txt (848 bytes) 2013-07-07 01:39
https://bugs.mercurylang.org/file_download.php?file_id=177&type=bug

Notes

Hi Julien, thanks for looking at it. I can't think of any environment changes that I am making from the standard one that could possibly affect this. The only non-standard installs I have are JavaBayes, Jess (java expert systems environment), the lptp theorem prover (built on top of swi prolog), and the Vue topic map system. Actually, writing this down made me realise that lptp could have an implementation of robdds that could somehow conflict, but grepping robdd and bryant over it didn't turn up anything. Oh, and I'm using lxde window manager rather than gnome, but it would be pretty weird if there were name clashes there. In case you can see something I can't, I'm appending the printenv output at the bottom.

I thought it might be a hangover from the first failed attempt to build mercury, so I rolled the system back to before the initial mercury install, and tried again. I got exactly the same failure.

The only other thought I have is that the mercury sources are on a folder shared from the host. But I'm running the build as root, and root has full permissions on the folder, so I wouldn't have thought that could make a difference. If you think there's any possibility this could be the cause, I could try moving the source to the guest's root disk, just in case. Other than that, I'm stumped.

XDG_VTNR=1
XDG_SESSION_ID=105
HOSTNAME=localhost.localdomain
SAL_USE_VCLPLUGIN=gtk
IMSETTINGS_INTEGRATE_DESKTOP=yes
XDG_MENU_PREFIX=lxde-
SHELL=/bin/bash
TERM=xterm
HISTSIZE=1000
GNOME_KEYRING_CONTROL=/home/rim/.cache/keyring-2Jnk7U
QT_GRAPHICSSYSTEM_CHECKED=1
IMSETTINGS_MODULE=none
USER=rim
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36:
DESKTOP_SESSION=LXDE
MAIL=/var/spool/mail/rim
PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/rim/.local/bin:/home/rim/bin
QT_IM_MODULE=xim
PWD=/share/SW/LPTP
XMODIFIERS=@im=none
LANG=en_US.UTF-8
GNOME_KEYRING_PID=6118
HISTCONTROL=ignoredups
divider=10
_LXSESSION_PID=6121
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
SHLVL=3
XDG_SEAT=seat0
HOME=/root
BOOT_IMAGE=/vmlinuz-3.9.8-300.fc19.x86_64
XDG_CONFIG_HOME=/home/rim/.config
LOGNAME=rim
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-0TqbEFGzMQ,guid=9cc6be088e2b649c3aaa305851dd7061
PREFERRED=/usr/bin/startlxde
LESSOPEN=||/usr/bin/lesspipe.sh %s
DISPLAY=:0
XDG_RUNTIME_DIR=/run/user/1000
GTK_IM_MODULE=gtk-im-context-simple
XDG_CURRENT_DESKTOP=LXDE
XAUTHORITY=/root/.xauthZ65N3X
_=/bin/printenv
OLDPWD=/share/SW

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

291

[mercury] Bug

minor

always

2013-07-02 01: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:

HLDS dumps don't contain clauses unless --dump-hlds-options=x is also given

Description:

--dump-hlds-options=C used (IIRC) to cause the clauses to be included in the HLDS dumps.
It now doesn't unless the 'x' HLDS dump option is also given. I don't recall that this used to be the
case and since 'x' corresponds to predicate type information it also seems wrong.

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:

285

[mercury] Bug

tweak

have not tried

2013-05-22 11:24

2013-06-28 15:54

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:

Mode error is misleading

Description:

A mode error can be causes when code is multidet when it is declared as det. In these case the error text uses the phrase "multiple clauses with solutions". Even for single clause predicates.

Tags:

Steps To Reproduce:

Create a single clause predicate declared as det such as:

update_atom_in_map(Atom, SubstsA, Status, OrigHt, !Map) :-
    (
        ( map.search(!.Map, Atom, EntryPrime) ->
            Entry = EntryPrime
        ; version_hash_table.search(OrigHt, Atom, EntryPrime) ->
            Entry = EntryPrime
        ;
            false
        ), # HERE is the error, this should be a -> rather than a ,
        Entry = memo_table_entry(SubstsB, _),
        Substs = SubstsA `union` SubstsB
    ;
        Substs = SubstsA
    ),
    set(Atom, memo_table_entry(Substs, Status), !Map).

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

288

[mercury] Bug

minor

always

2013-06-04 03:27

2013-06-24 11:12

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:

Some mercury binary files are built without respecting LDFLAGS

Description:

Compiling mercury (on Linux) with 'make EXTRA_LDFLAGS=...' produces a number of binary files which do not respect EXTRA_LDFLAGS:

* /usr/lib/mercury/lib/libgc.so
* /usr/lib/mercury/lib/<grade>/libmer_trace.so
* /usr/lib/mercury/lib/<grade>/libmer_eventspec.so
* /usr/lib/mercury/lib/<grade>/libmer_rt.so
* /usr/bin/mfiltercc
* /usr/bin/info_to_mdb
* /usr/bin/mkinit_erl
* /usr/bin/mdemangle
* /usr/bin/mkinit

Tags:

Steps To Reproduce:

Additional Information:

Attached is a patch which passes through ALL_LDFLAGS to targets that currently do not respect user-defined LDFLAGS.

Attached Files:

mercury-linker-flags.patch (5,206 bytes) 2013-06-04 03:27
https://bugs.mercurylang.org/file_download.php?file_id=175&type=bug
mercury-linker-flags-v2.patch (5,242 bytes) 2013-06-07 00:19
https://bugs.mercurylang.org/file_download.php?file_id=176&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

287

[mercury] Bug

minor

always

2013-05-28 12:55

2013-06-05 16:02

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:

configure requires m4

Description:

The configure script expects m4 to be present:

m4 -DDEFAULT_MERCURY_DEBUGGER_INIT_DIR=TESTS_MDB_INIT_DIR \
-DDEFAULT_MERCURY_DEBUGGER_DOC=TESTS_MDB_DOC \
"`pwd`"/scripts/mdbrc.in > $test_mdbrc.in

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

259

[mercury] Feature Request

minor

always

2012-07-08 03:58

2013-06-04 03:41

Reporter:

ony

Platform:

All

Assigned To:

OS:

All

Priority:

high

OS Version:

All

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Impossible to override /lib dir with /lib64 etc

Description:

To support multilib install we need to have possibility to use /usr/lib64 instead of /usr/lib.
Appropriate patch based on rotd-2012-07-01 attached

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

0001-Allow-usr-lib64-override-required-for-multilib.patch (2,422 bytes) 2012-07-08 03:58
https://bugs.mercurylang.org/file_download.php?file_id=155&type=bug
0001-Add-man-info-and-lisp-dirs-configuring.patch (1,869 bytes) 2012-07-08 06:39
https://bugs.mercurylang.org/file_download.php?file_id=156&type=bug
0002-Add-man-info-and-lisp-dirs-configuring.patch (1,847 bytes) 2012-07-08 08:54
https://bugs.mercurylang.org/file_download.php?file_id=157&type=bug
mercury-13.05-bug259-dirs-overriding.patch (2,680 bytes) 2013-05-19 03:39
https://bugs.mercurylang.org/file_download.php?file_id=174&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

222

[mercury] Bug

minor

always

2011-10-18 19:14

2013-05-28 13:47

Reporter:

gloomdemon

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:

mmc can't compile csharp grade without --make under mingw

Description:

rotd 2011-10-11, simple hello world program

command 'mmc --make --grade csharp hello' compiles all
command 'mmc --grade csharp hello.m':

$ mmc --grade csharp hello.m
mkinit: error opening file `hello.c': No such file or directory
mkinit: error opening file `c:\mingw\mercury\lib\mercury\modules\csharp\mer_rt.init': No such file or directory
mkinit: error opening file `c:\mingw\mercury\lib\mercury\modules\csharp\mer_std.init': No such file or directory
Error: system command received signal 1.

create files: hello.cs, hello.cs_date, hello.d

mercury compiled with configure options: CFLAGS=-O2 CPPFLAGS=-O2 ./configure --prefix=c:/mingw/mercury --enable-libgrades=asm_fast.gc,asm_fast.gc.debug,asm_fast.gc.decldebug,hlc.gc,hlc.par.gc,reg.gc,csharp --enable-csharp-grade --enable-new-mercuryfile-struct

Tags:

Steps To Reproduce:

Additional Information:

hello.m:

:- module hello.

:- interface.
:- import_module io.

:- pred main(io::di, io::uo) is det.

:- implementation.
:- import_module int.

main(!IO) :-
io.write_string("hello ", !IO).

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

183

[mercury] Bug

minor

have not tried

2011-02-03 11:11

2013-05-22 16:16

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:

--warn-dead-procs should not warn about foreign-exported procs.

Description:

If a predicate, such as handle_event_excp in ssdb.m, is not called from Mercury but is foreign exported for Java and C#, then compiling to C with --warn-dead-procs tells the user that it may safely be deleted.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

262

[mercury] Bug

minor

always

2012-08-27 08:42

2013-05-22 13:42

Reporter:

vezhlys

Platform:

amd64

Assigned To:

OS:

NetBSD

Priority:

normal

OS Version:

6_RC1

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Mercury doesn't compile on NetBSD

Description:

Mercury programming language doesn't compile in NetBSD operating system. I tried to compile it using from NetBSD source package management (pkgsrc). It ended up with error:

os_dep.c:503:9: error: redefinition of 'GC_data_start'
os_dep.c:454:9: note: previous definition of 'GC_data_start' was here
gmake[3]: *** [os_dep.o] Error 1
gmake[3]: Leaving directory `/usr/pkgsrc/lang/mercury/work/mercury-compiler-11.07/boehm_gc'
gmake[2]: *** [submake] Error 2
gmake[2]: Leaving directory `/usr/pkgsrc/lang/mercury/work/mercury-compiler-11.07/boehm_gc'
gmake[1]: *** [boehm_gc] Error 2
gmake[1]: Leaving directory `/usr/pkgsrc/lang/mercury/work/mercury-compiler-11.07'
gmake: *** [install] Error 2
*** Error code 2

Stop.
make: stopped in /usr/pkgsrc/lang/mercury
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/lang/mercury

It seems that solution is simple. I commented two duplicate definitions GC_data_start and GC_find_limit as they were defined exactly the same a bit earlier in the same file (see lines 454-456). Mercury compiled fine then. I looked into current version of os_dep.c file and it is the same (pkgsrc retrieves mercury-compiler-11.07.tar.gz currently) because of this it should fail too.

Tags:

Steps To Reproduce:

Compile mercury on netbsd.

Additional Information:

--- os_dep.c 2012-08-27 01:08:21.000000000 +0300
+++ os_dep.c 2012-08-27 01:09:19.000000000 +0300
@@ -500,8 +500,8 @@
# endif /* ECOS */

#if defined(NETBSD) && defined(__ELF__)
- ptr_t GC_data_start = NULL;
- ptr_t GC_find_limit(ptr_t, GC_bool);
+ //ptr_t GC_data_start = NULL;
+ //ptr_t GC_find_limit(ptr_t, GC_bool);

extern char **environ;

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

161

[mercury] Bug

major

have not tried

2010-09-08 16:45

2013-05-21 16:51

Reporter:

pbone

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:

Calling io.seen/2 twice in a row can crash the runtime with a segfault.

Description:

The following program crashes the runtime with a segfault.

:- module main.
:- interface.
:- import_module io.
:- pred main(io::di, io::uo) is det.

:- implementation.

main(!IO) :- seen(!IO), seen(!IO).

This was reported via the #mercury IRC channel on the Freenode IRC network.
I'm waiting for the user to tell me what version of Mercury they're using and which grade they're using. I havn't attempted to reproduce this myself.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

257

[mercury] Bug

minor

always

2012-06-22 12:49

2013-05-21 14:04

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:

require_complete_switch var does not appear in sub-goal

Description:

The compiler doesn't warn if the variable named in a
require_complete_switch does not appear anywhere in the sub-goal, e.g.

    :- type xyz ---> x ; y ; z.

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

    oops(G, N) :-
        require_complete_switch [Gee]
        (
            G = x,
            N = 1
        ;
            G = y,
            fail
        ).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

263

[mercury] Bug

crash

always

2012-08-29 18:53

2013-05-17 16:16

Reporter:

lpimmes

Platform:

Assigned To:

juliensf

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

no change required

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Segmentation fault: not enough memory when invoking solutions/2

Description:

Working with mercury language is quiet rewarding.

But running into a memory problem of some kind, as expected with
Traveling salesman problem.

% Using generator length of 7 (see code): [2, 3, 4, 5, 6, 7, 8]
% tsp2 501>MERCURY_OPTIONS=--solutions-heap-size-kwords=1024000
% tsp2 501>echo $MERCURY_OPTIONS
% --solutions-heap-size-kwords=1024000
% tsp2 501>./tsp2
% Segmentation fault: 11
% tsp2 501>

See attached tsp2.m file. (shows gcc and mmc, darwin versions)
Any help would be appreciated, thanks.

Tags:

Steps To Reproduce:

Compile, then run uploaded file(tsp2.m).

tsp2 493>cat tsp2.bash
#/bin/bash
mmc --make --fully-strict -E -v -O 0 --use-subdirs tsp2

Additional Information:

gcc 4.2
mmc 11.7

Aside: When analyzing mercury programs asymptotically, we can sometimes determine
implicit for-loops, i.e., O(n), O(n^2), and so on, even n! if using solutions/2. But, I am not so sure if this is sufficient for 'Analysis of Algorithms graduate course'. Unification takes time, and so does resolution theorem proving. In other words, more computations are taking place 'behind the mercury code' so to speak. Any ideas, heuristics or suggestions (sites)?

Attached Files:

tsp2.m (14,014 bytes) 2012-08-29 18:53
https://bugs.mercurylang.org/file_download.php?file_id=159&type=bug
tsp2upd.m (15,136 bytes) 2012-09-12 01:12
https://bugs.mercurylang.org/file_download.php?file_id=160&type=bug

Notes

Follow Julian's advice about stseg; tsp2.m is working now.
Yes, TSP is an np-complete problem; just examining mercury under heavy stress.

%% cd mercury-compiler-11.07.2/
%% ./configure --with-cc="gcc -m64" --enable-libgrades=hlc.gc,none.gc,none.gc.stseg,java,erlang
%% ...
Unable to delete original file, so:
Download tsp2upd.m ; mv tsp2upd.m tsp2.m

                % RUN
%% ~ 515>cd $MERCURYPROGRAMS
%% mercuryPrograms 513>cd algor91503/
%% algor91503 512>cd tsp2

%% tsp2 489>ulimit -H -s
%% 65532
%% Cannot set to a higher value.

%% Edit code and change generator length, then recompile.
%% Generator lengths shown are: 10, 9, 8, 7.

%% tsp2 489>which mmc
%% /usr/local/mercury-11.07.2/bin/mmc
%% tsp2 489>mmc --grade none.gc.stseg --fully-strict -E -v -O 0 --use-subdirs tsp2

                % 10! = 3628800
                % 430 m ~= 7 hours, most of the time spent swapping in and out of memory, as timer shows.
%% tsp2 487>time ./tsp2
%% #Permutations: 3628800, Generator length: 10 using [2 3 4 5 6 7 8 9 10 11 ],
%% minimum distance 23: 1_8(2) 8_6(2) 6_5(3) 5_4(1) 4_3(3) 3_9(2) 9_7(1) 7_11(1) 11_2(3) 2_10(3) 10_1(2)

%% real 430m26.708s
%% user 7m36.750s
%% sys 12m29.934s

                % 9! = 362880
%% tsp2 489>./tsp2
%% #Permutations: 362880, Generator length: 9 using [2 3 4 5 6 7 8 9 10 ],
%% minimum distance 23: 1_8(2) 8_6(2) 6_5(3) 5_4(1) 4_3(3) 3_9(2) 9_7(1) 7_2(4) 2_10(3) 10_1(2)

% % real 0m32.049s
% % user 0m30.823s
% % sys 0m1.051s

                % 8! = 40320
%% tsp2 489>./tsp2
%% #Permutations: 40320, Generator length: 8 using [2 3 4 5 6 7 8 9 ],
%% minimum distance 24: 1_5(4) 5_4(1) 4_3(3) 3_9(2) 9_7(1) 7_2(4) 2_6(5) 6_8(2) 8_1(2)

                % 7/! = 5040
%% tsp2 505>./tsp2
%% #Permutations: 5040, Generator length: 7 using [2 3 4 5 6 7 8 ],
%% minimum distance 23: 1_3(5) 3_4(3) 4_5(1) 5_7(1) 7_2(4) 2_6(5) 6_8(2) 8_1(2)
%% tsp2 505>

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

282

[mercury] Bug

minor

always

2013-05-06 13:20

Reporter:

juliensf

Platform:

x86_64

Assigned To:

OS:

Mac OS X

Priority:

normal

OS Version:

10.8.3

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

GNU-specific regexps in test filters

Description:

The following fail in grade none.gc.decldebug:

* debugger/cmd_quote
* debugger/completion
* debugger/declarative/builtin_call_rep
* mmc_make/rebuild

This appears to be because various regexps used to filter the output of those tests with grep and
sed are GNU-specific and don't work with the BSD versions of those tools.

Reported against 13.05-beta-2013-05-06.

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:

253

[mercury] Feature Request

minor

N/A

2012-02-15 17:25

2013-04-12 13:43

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:

MS C# compiler should be invoked with -nologo

Description:

The MS C# compiler should be invoked with -nologo in order to suppress the banner message.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

279

[mercury] Bug

minor

always

2013-04-10 16:45

2013-04-11 03:05

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:

make install from stage 2 dir does not work with csharp grade

Description:

Doing make install from the stage 2 directory does not work if one of the grades
to be installed is the csharp grade because the link to the file containing the strong
name is incorrect.

Making Mercury/css/thread.semaphore.cs
Making mer_std.dll
** Error making `mer_std.dll'.
error CS1548: Error during assembly signing. The specified key file `../mercury.snk' does not exist
Compilation failed: 1 error(s), 0 warnings
make[1]: *** [libmer_std.install] Error 1

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

277

[mercury] Bug

major

always

2013-03-05 10:43

2013-03-20 16:18

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:

float bugs on 64-bit if built with pregenerated C sources

Description:

string.format("%f", [f(1.234)])

In low-level C, 64-bit, using a compiler built from the pregenerated source distribution, that returns "0.000000".

string.from_float works correctly.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

203

[mercury] Bug

minor

always

2011-07-11 14:22

2013-03-18 15:23

Reporter:

juliensf

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:

Problem with DESTDIR and Darwin

Description:

Reported by Jeremy Huddleston (jeremyhu@macports.org) on mercury-bugs:

--------

And one more bug to report...

mercury-11.01 fails to make install the first time.

This looks like some bad logic for making boehm_gc a second time during the make install.

cp ./libatomic_ops-install/lib/libatomic_ops.a gc.a
cp: ./libatomic_ops-install/lib/libatomic_ops.a: No such file or directory
gmake[3]: *** [gc.a] Error 1
gmake[3]: Leaving directory
`/opt/local/var/macports/build/_Volumes_Home_jeremy_src_macports_trunk_dports_lang_mercury/mercury/work/mercury-11.01/install_grade_dir.hlc.gc/boehm_gc'
gmake[2]: *** [submake] Error 2
gmake[2]: Leaving directory
`/opt/local/var/macports/build/_Volumes_Home_jeremy_src_macports_trunk_dports_lang_mercury/mercury/work/mercury-11.01/install_grade_dir.hlc.gc/boehm_gc'
To clean up from failed install, remove
/opt/local/var/macports/build/_Volumes_Home_jeremy_src_macports_trunk_dports_lang_mercury/mercury/work/mercury-11.01/install_grade_dir.hlc.gc
gmake[1]: *** [install_grades] Error 1
gmake[1]: Leaving directory `/opt/local/var/macports/build/_Volumes_Home_jeremy_src_macports_trunk_dports_lang_mercury/mercury/work/mercury-11.01'
make: *** [install] Error 2
make: Leaving directory `/opt/local/var/macports/build/_Volumes_Home_jeremy_src_macports_trunk_dports_lang_mercury/mercury/work/mercury-11.01'
shell command " cd "/opt/local/var/macports/build/_Volumes_Home_jeremy_src_macports_trunk_dports_lang_mercury/mercury/work/mercury-11.01" && /usr/bin/make -w install
DESTDIR=/opt/local/var/macports/build/_Volumes_Home_jeremy_src_macports_trunk_dports_lang_mercury/mercury/work/destroot " returned error 2

Here's the full log, but I'm just doing a fairly standard ./configure && make && make install DESTDIR=/path/to/stage

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

main.log.gz (131,988 bytes) 2011-07-11 14:24
https://bugs.mercurylang.org/file_download.php?file_id=123&type=bug
0001-Fix-for-bug-203-DESTDIR-brokes-installation.patch (2,036 bytes) 2012-07-06 07:22
https://bugs.mercurylang.org/file_download.php?file_id=154&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

276

[mercury] Bug

minor

always

2013-02-27 15:23

2013-02-27 15:24

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:

io.call_system/4 inconsistency between C and Java grades

Description:

The attached Mercury program calls io.call_system/4 and it calls the C program foo.
foo exits with exit status 2. In C grades we get:

    ok(2)

In the Java grade we get:

    error(io_error("system command killed by signal number 2"))

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

foo.c (70 bytes) 2013-02-27 15:23
https://bugs.mercurylang.org/file_download.php?file_id=171&type=bug
syscall_bug.m (209 bytes) 2013-02-27 15:24
https://bugs.mercurylang.org/file_download.php?file_id=172&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

275

[mercury] Bug

minor

always

2013-02-18 11:47

2013-02-20 11:58

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:

hidden symbol pthread_atfork

Description:

On Ubuntu 12.04 (at least) the linker spits out an error message when you try to build most programs in a parallel grade, e.g. hlc.par.gc.

/usr/bin/ld: test: hidden symbol `pthread_atfork' in /usr/lib/i386-linux-gnu/libpthread_nonshared.a(pthread_atfork.oS) is referenced by DSO

The solution appears to be to pass -pthread at the link step, either in addition to or replacing -lpthread. Actually we should probably pass -pthread for compilation steps as well.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

226

[mercury] Bug

tweak

N/A

2011-11-03 10:21

2013-01-08 12:33

Reporter:

colanderman

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:

lazy.read_if_val unsound

Description:

lazy.read_if_val is semantically unsound. It should be marked semipure and lazy.force marked impure, or it should be removed.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

261

[mercury] Bug

major

always

2012-07-26 00:38

2013-01-07 16:48

Reporter:

petdr

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:

building mdbcomp in C# grade attempts to link with non-existant mer_rt.dll

Description:

Attempting to build the compiler in the csharp grade leads to the following error

Making mer_mdbcomp.dll
** Error making `mer_mdbcomp.dll'.
error CS0006: Metadata file `mer_rt.dll' could not be found
Compilation failed: 1 error(s), 0 warnings
make[1]: *** [libmer_mdbcomp] Error 1
make[1]: Leaving directory `/home/MISCRITITCOM/petdr/merc/workspaces/1107.csharp/mdbcomp'
make: *** [mdbcomp] Error 2

this is because we are calling the following command

% Invoking system command `dmcs -nowarn:162,219 -define:MR_HIGHLEVEL_DATA -target:library -out:mer_mdbcomp.dll -lib:../boehm_gc -lib:../runtime -lib:../library -lib:../trace -lib:../mdbcomp -lib:../browser -r:mer_std.dll -r:mer_rt.dll Mercury/css/mdbcomp.cs Mercury/css/mer_mdbcomp.cs Mercury/css/mdbcomp.feedback.cs Mercury/css/mdbcomp.goal_path.cs Mercury/css/mdbcomp.prim_data.cs Mercury/css/mdbcomp.program_representation.cs Mercury/css/mdbcomp.rtti_access.cs Mercury/css/mdbcomp.slice_and_dice.cs Mercury/css/mdbcomp.trace_counts.cs Mercury/css/mdbcomp.feedback.automatic_parallelism.cs'...

juliensf tells me that it goes wrong at around line 223 of Mmake.workspace

My quick solution is to create a dummy mer_rt.dll in the runtime directory, as a workaround.

Tags:

Steps To Reproduce:

1. Add GRADE=csharp to Mmake.params
2. GRADE=csharp mmake --use-mmc-make

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

272

[mercury] Bug

major

always

2013-01-02 16:55

2013-01-04 11:51

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:

The polymorphism pass can generate mode-incorrect code.

Description:

When used with typeclasses and existential types it is possible that the polymorphism pass can create code that does not properly instantiate the typeclass variables.

Tags:

Steps To Reproduce:

Use the attached testcase.

Additional Information:

I found this bug while trying to create a test case for bug271, they may be related.

Attached Files:

bug272.m (464 bytes) 2013-01-04 11:51
https://bugs.mercurylang.org/file_download.php?file_id=168&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

270

[mercury] Bug

crash

always

2012-12-30 05:58

2012-12-31 00:22

Reporter:

maurojh

Platform:

PC Intel Core I7 2.8GHz, 2.9GB m

Assigned To:

juliensf

OS:

Ubuntu Linux

Priority:

urgent

OS Version:

10.04

Status:

confirmed

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

When one uses fact_table, the mercury compiler crashes if there is an error in the fact_table.

Description:

Here is a small program without errors:

% dic.m
wrd("cat", "catus").
wrd("dog", "canis").
wrd("horse", "equus").
wrd("person","homo sapiens").

% bug.m
:- module bug.

:- interface.
:- import_module io.
:- pred main(io::di, io::uo) is cc_multi.

:- implementation.
:- import_module string, list, char.
:- pred wrd( string::in, string::out) is nondet.
:- pragma fact_table( wrd/2, "dic.m").

main(!IO) :-
   ( wrd("horse", X) ->
     print(X,!IO), nl(!IO)
   ; true ).

The command below compiles the above program flawlessly:

> mmc --infer-all --use-subdirs --rebuild bug

However, If I introduce an error in the fact_table, the compiler freezes. For example, let us forget the comma between "horses" and "equus":

% dic.m
wrd("cat", "catus").
wrd("dog", "canis").
wrd("horse" "equus").
wrd("person","homo sapiens").

Now, instead of reporting the error, the compiler freezes.

Tags:

Steps To Reproduce:

In the description of the bug, you will find the steps to reproduce the bug. I tried it in different machines, and I always was able to reproduce the freezing of the compiler. Since I am writing large programs that requires fact_tables I would like that the compiler report errors, instead of crashing or freezing.

% Correct fact_table
% dic.m
wrd("cat", "catus").
wrd("dog", "canis").
wrd("horse", "equus").
wrd("person","homo sapiens").

% Fact_table that freezes the compiler
% dic.m
wrd("cat", "catus").
wrd("dog", "canis").
wrd("horse" "equus").
wrd("person","homo sapiens").

Additional Information:

Attached Files:

bug.m (317 bytes) 2012-12-30 05:58
https://bugs.mercurylang.org/file_download.php?file_id=166&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

266

[mercury] Bug

trivial

always

2012-11-26 13:30

2012-12-07 17:11

Reporter:

wangp

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:

--no-warn-missing-det-decls doesn't exist

Description:

The documented option --no-warn-missing-det-decls doesn't exist in the implementation.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

269

[mercury] Bug

minor

always

2012-12-07 06:27

2012-12-07 14:24

Reporter:

gloomdemon

Platform:

windows

Assigned To:

wangp

OS:

windows 32/64

Priority:

normal

OS Version:

any

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

unicode path handling in dir module

Description:

dir.recursive_foldl2 failed on directory with unicode name QQ菜单

Uncaught Mercury exception:
Software Error: string.unsafe_index: illegal sequence
Stack dump not available in this grade.

This problem is possible in dir.make_path_name function with incorrect work of function string.length or string.unsafe_index

Tags:

Steps To Reproduce:

unpack utf_dir_small.rar with rar, compile and run 'bugu' program in dir with 'yjkj' directory

Additional Information:

:- module bugu.
:- interface.

:- import_module io.

:- pred main(io::di, io::uo) is det.

:- implementation.

:- import_module require, dir, list, bool.

main(!IO) :-
    Ps = (
        pred(DN::in, BN::in, FT::in, C::out, Di::in, Do::out, !.IO::di, !:IO::uo) is det :-
            C = yes,
            io.write_strings([DN, " ", BN, "\n"], !IO),
            Do = Di
    ),
    dir.recursive_foldl2(Ps, ".", no, [], MaybeResult, !IO),
    (
        MaybeResult = error(_, Err),
        error(io.error_message(Err)) % exception
    ;
        MaybeResult = ok(_)
    ).

Attached Files:

utf_dir_small.rar (696,633 bytes) 2012-12-07 06:27
https://bugs.mercurylang.org/file_download.php?file_id=165&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

265

[mercury] Bug

minor

always

2012-11-15 00:30

2012-12-07 05:44

Reporter:

gloomdemon

Platform:

windows

Assigned To:

OS:

windows 32/64

Priority:

normal

OS Version:

any

Status:

new

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

long path handling in io module

Description:

"io.file_type" uses "_wstat" in C grade, but *stat didn't support long names on Windows OS (> 260)
http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/3c093ea9-f0aa-446d-b648-2dabe8480430
It may be fixed by using "FindFirstFileW" with "\\?\" file name prefix instead of "_wstat".

Also, other functions in io module (open_input -> mercury_open -> _wfopen) may be can't handle long path.

Tags:

Steps To Reproduce:

unpack test_dir.tar, change path to unpacked directory in bugl program, compile and run

Additional Information:

:- module bugl.
:- interface.

:- import_module io.

:- pred main(io::di, io::uo) is det.

:- implementation.

:- import_module require, dir, list, bool.

main(!IO) :-
    Ps = (
        pred(DN::in, BN::in, FT::in, C::out, Di::in, Do::out, !.IO::di, !:IO::uo) is det :-
            C = yes,
            io.write_strings([DN, " ", BN, "\n"], !IO),
            Do = Di
    ),
    dir.recursive_foldl2(Ps, "C:\\5", no, [], MaybeResult, !IO),
    (
        MaybeResult = error(_, Err),
        error(io.error_message(Err)) % exception
    ;
        MaybeResult = ok(_)
    ).

Attached Files:

test_dir.tar (16,896 bytes) 2012-11-15 00:30
https://bugs.mercurylang.org/file_download.php?file_id=162&type=bug
dir.diff (8,095 bytes) 2012-12-07 05:44
https://bugs.mercurylang.org/file_download.php?file_id=164&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

268

[mercury] Bug

crash

always

2012-12-03 20:55

2012-12-04 18:22

Reporter:

ttmrichter

Platform:

Toshiba Satellite L512

Assigned To:

juliensf

OS:

Linux Mint

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

duplicate

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Typo in :- end_module declaration leads to compiler crash.

Description:

λ junk → cat test.m
%-----------------------------------------------------------------------------%
% vi: ft=mercury ts=4 sw=4 et wm=0 tw=0
%-----------------------------------------------------------------------------%
:- module test.

:- interface.

:- import_module integer.

:- func identity(integer) = integer.

:- implementation.

identity(X) = X.

:- end_module not_test.
λ junk → mmc --make test
Making Mercury/asm_fast.gc/x86_64-unknown-linux-gnu/Mercury/cs/test.c
Uncaught Mercury exception:
Software Error: parse_tree.equiv_type: predicate `parse_tree.equiv_type.replace_in_item_list'/13: Unexpected: module start or end
Stack dump not available in this grade.
** Error making `Mercury/asm_fast.gc/x86_64-unknown-linux-gnu/Mercury/cs/test.c'.

Tags:

Steps To Reproduce:

As above.

Additional Information:

This caused me a frustrating divide-and-conquer debugging session as I tried to figure out why a re-factored module was suddenly crashing the compiler. Generally a warning/error would be preferred to crashes. ;)

System Description

Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

193

[mercury] Bug

tweak

always

2011-03-28 07:56

2012-07-06 11:19

Reporter:

colanderman

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

confirmed

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

--introduce-accumulators doesn't recognize "promise all" containing type annotation

Description:

See attached program. Accumulator introduction works with the commented-out "promise all", but not when a do-nothing type annotation is added as in the uncommented "promise all".

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

accumbug.m (302 bytes) 2011-03-28 07:56
https://bugs.mercurylang.org/file_download.php?file_id=117&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

258

[mercury] Bug

major

always

2012-06-22 14:43

2012-06-23 04:05

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:

csharp grade is broken with rotd-2012-06-19

Description:

Compilation of the library in the csharp grade fails with rotd-2012-06-19
due to:

** Error making `mer_std.dll'.
Mercury/css/exception.cs(413,98): error CS0030: Cannot convert type `int' to `object[]'
Mercury/css/exception.cs(4365,62): error CS0030: Cannot convert type `int' to
`object[]'

This occurs with both Mono and the MS C# compiler.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

255

[mercury] Bug

major

always

2012-05-19 14:32

2012-06-19 22:48

Reporter:

qu1j0t3

Platform:

PowerPC

Assigned To:

juliensf

OS:

OS X

Priority:

normal

OS Version:

10.4.11

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

build fails on OS X 10.4.11 PowerPC

Description:

  $ ./configure --disable-most-grades

pbg4:~/Downloads/mercury-compiler-11.07.1 toby$ make
MMAKE_DIR=`pwd`/scripts scripts/mmake MMAKEFLAGS= all
/tmp/mmake.8duPGY:683: warning: undefined variable `DESTDIR'
scripts/Mmake.vars:683: warning: undefined variable `DESTDIR'
Mmake.common:121: warning: undefined variable `DESTDIR'
/tmp/mmake.8duPGY:1017: warning: undefined variable `DESTDIR'
cd scripts && PATH=../scripts:../util:$PATH MMAKE_VPATH=. MMAKE_DIR=../scripts DESTDIR= ../scripts/mmake
make[2]: Nothing to be done for `default_target'.
/tmp/mmake.8duPGY:1009: warning: undefined variable `DESTDIR'
cd util && PATH=../scripts:../util:$PATH MMAKE_VPATH=. MMAKE_DIR=../scripts DESTDIR= ../scripts/mmake mfiltercc
make[2]: `mfiltercc' is up to date.
/tmp/mmake.8duPGY:1021: warning: undefined variable `DESTDIR'
gc_grade=`scripts/ml --grade reg.gc --print-gc-grade`; \
cd boehm_gc && PATH=../scripts:../util:$PATH MMAKE_VPATH=. MMAKE_DIR=../scripts DESTDIR= ../scripts/mmake GC_GRADE=$gc_grade
MAKEFLAGS=""; export MAKEFLAGS; \
make -j1 GRADE=reg.gc GC_GRADE=gc \
        libgc.a libgc.dylib \
        FINAL_INSTALL_MERC_GC_LIB_DIR=/usr/local/mercury-11.07.1/lib/mercury/lib \
        dylib
make[3]: `libgc.a' is up to date.
make[3]: `libgc.dylib' is up to date.
make[3]: Nothing to be done for `dylib'.
/tmp/mmake.8duPGY:1026: warning: undefined variable `DESTDIR'
cd runtime && PATH=../scripts:../util:$PATH MMAKE_VPATH=. MMAKE_DIR=../scripts DESTDIR= ../scripts/mmake
make[2]: Nothing to be done for `default_target'.
/tmp/mmake.8duPGY:1013: warning: undefined variable `DESTDIR'
cd util && PATH=../scripts:../util:$PATH MMAKE_VPATH=. MMAKE_DIR=../scripts DESTDIR= ../scripts/mmake
make[2]: Nothing to be done for `default_target'.
/tmp/mmake.8duPGY:1030: warning: undefined variable `DESTDIR'
cd robdd && PATH=../scripts:../util:$PATH MMAKE_VPATH=. MMAKE_DIR=../scripts DESTDIR= ../scripts/mmake
make[2]: Nothing to be done for `default_target'.
/tmp/mmake.8duPGY:1034: warning: undefined variable `DESTDIR'
cd library && PATH=../scripts:../util:$PATH MMAKE_VPATH=. MMAKE_DIR=../scripts DESTDIR= ../scripts/mmake
/tmp/mmake.8duPGY:1038: warning: undefined variable `DESTDIR'
cd mdbcomp && PATH=../scripts:../util:$PATH MMAKE_VPATH=. MMAKE_DIR=../scripts DESTDIR= ../scripts/mmake
/tmp/mmake.f0C9tK:1097: Extraneous text after `else' directive
/tmp/mmake.f0C9tK:1102: *** only one `else' per conditional. Stop.
make[1]: *** [mdbcomp] Error 2
make: *** [all] Error 2

Tags:

Steps To Reproduce:

$ ./configure --disable-most-grades
$ make

Additional Information:

mercury-compiler-11.07.1

$ gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1819)

Attached Files:

configure-log (13,747 bytes) 2012-05-19 15:22
https://bugs.mercurylang.org/file_download.php?file_id=151&type=bug
make-log (38,349 bytes) 2012-05-19 15:22
https://bugs.mercurylang.org/file_download.php?file_id=152&type=bug
patch-test.log (15,494 bytes) 2012-05-21 16:14
https://bugs.mercurylang.org/file_download.php?file_id=153&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

250

[mercury] Bug

minor

always

2012-01-12 14:34

2012-05-10 10:12

Reporter:

mgiuca

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:

GCC warnings: used but never defined

Description:

In Mercury 11.07 (grade: asm_fast.gc), all non-trivial Mercury programs are causing GCC 4.6 to spit out lots and lots of "used but never defined" warnings. These seem to be caused whenever a function or predicate is curried. The simplest complete example I can think of is this:

:- module gcc_warn.
:- interface.
:- import_module io.
:- pred main(io::di, io::uo) is det.

:- implementation.
:- import_module int.

:- pred add(int::in, int::in, int::out) is det.
add(X, Y, Z) :-
    Z = X + Y.

:- func add_wrap(int, int) = int.
add_wrap(X, Y) = Z :-
    add(X)(Y, Z).

main(!IO) :-
    io.write(add_wrap(1, 2), !IO),
    io.nl(!IO).

Running:

$ mmc gcc_warn.m

causes GCC to give the warning:

gcc_warn.c:80:1: warning: ‘mercury__gcc_warn__add_3_0’ used but never defined [enabled by default]

The warning is generated due to add_wrap, which curries the add predicate. It also happens if add is a function.

Tags:

Steps To Reproduce:

Additional Information:

$ gcc --version
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1

Using Mercury 11.07 beta 2011-11-16 / grade asm_fast.gc. This started happening when I upgraded to Mercury 11.07, but I also upgraded to Ubuntu 11.10 at the same time, so I don't know whether Mercury or GCC regressed.

The specific GCC command that caused this warning was:
gcc -I/usr/local/mercury-11.07-beta-2011-11-16/lib/mercury/lib/asm_fast.gc/inc -I/usr/local/mercury-11.07-beta-2011-11-16/lib/mercury/conf -I/usr/local/mercury-11.07-beta-2011-11-16/lib/mercury/inc -O2 -fomit-frame-pointer -fno-strict-aliasing -DMR_USE_GCC_GLOBAL_REGISTERS -DMR_USE_GCC_NONLOCAL_GOTOS -DMR_USE_ASM_LABELS -fno-builtin -fno-omit-frame-pointer -fno-defer-pop -fno-function-cse -fno-gcse -fno-move-loop-invariants -DMR_CONSERVATIVE_GC -DMR_BOEHM_GC -DMR_TAGBITS=2 -ansi -Wall -Wwrite-strings -Wshadow -Wmissing-prototypes -Wno-unused -Wno-uninitialized -Wstrict-prototypes -c gcc_warn.c -o gcc_warn.o

The line of C code in question is:
MR_decl_static(gcc_warn__add_3_0)

Attached Files:

gcc_warn.m (474 bytes) 2012-01-12 14:34
https://bugs.mercurylang.org/file_download.php?file_id=149&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

254

[mercury] Bug

minor

always

2012-03-02 13:56

2012-03-02 13:58

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:

HTTP download links for 11.07.1 return 403 forbidden error

Description:

The HTTP download links for the compiler, tests and extras tarballs of Mercury 11.07.1 return a 403 forbidden error, presumably due to incorrect permissions or ownership. The FTP links are fine, so the impact is minor.

aross@imac:~$ for dist in compiler tests extras; do wget http://www.mercury.c.unimelb.edu.au/download/files/mercury-${dist}-11.07.1.tar.gz; done
--2012-03-02 13:48:16-- http://www.mercury.csse.unimelb.edu.au/download/files/mercury-compiler-11.07.1.tar.gz
Resolving www.mercury.csse.unimelb.edu.au... 128.250.29.185
Connecting to www.mercury.csse.unimelb.edu.au|128.250.29.185|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2012-03-02 13:48:17 ERROR 403: Forbidden.

--2012-03-02 13:48:17-- http://www.mercury.csse.unimelb.edu.au/download/files/mercury-tests-11.07.1.tar.gz
Resolving www.mercury.csse.unimelb.edu.au... 128.250.29.185
Connecting to www.mercury.csse.unimelb.edu.au|128.250.29.185|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2012-03-02 13:48:17 ERROR 403: Forbidden.

--2012-03-02 13:48:17-- http://www.mercury.csse.unimelb.edu.au/download/files/mercury-extras-11.07.1.tar.gz
Resolving www.mercury.csse.unimelb.edu.au... 128.250.29.185
Connecting to www.mercury.csse.unimelb.edu.au|128.250.29.185|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2012-03-02 13:48:17 ERROR 403: Forbidden.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

174

[mercury] Bug

minor

always

2010-12-13 17:50

2012-02-13 15:28

Reporter:

juliensf

Platform:

Assigned To:

pbone

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

documentation for extras/lazy_evaluation is out-of-date

Description:

The description of the lazy_evaluation package in extras is out-of-date in various
places, e.g. extras/README.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

200

[mercury] Bug

minor

have not tried

2011-06-10 03:52

2012-02-13 13:56

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:

csharp grade does not install on Cygwin with Mono

Description:

From mercury-users:

>>> Hello. I'm trying to compile Mercury version 11.01 in cygwin inside
>>> Windows XP. ./configure and make succeed. When I enter:
>>>
>>> make install LIBGRADES=csharp
>>>
>>> I get the error:
>>>
>>> cygwin warning:
>>> MS-DOS style path detected: ..\runtime\mercury_dotnet.cs
>>> Preferred POSIX equivalent is: ../runtime/mercury_dotnet.cs
>>> Making mer_std.dll
>>> ** Error making `mer_std.dll'.
>>> error CS2001: Source file `..runtimemercur
>>> dotnet.cs' could not be found
>>>
>>> I can't find the makefile that is using \ instead of /.
>>
>> It is library/Mmakefile:378, specifically these line:
>>
>> # Don't use Unix style paths with the Microsoft C# compiler.
>> ifeq ($(CSC),csc)
>> MLOBJS += ..\runtime\mercury_dotnet.cs
>> else
>> MLOBJS += ../runtime/mercury_dotnet.cs
>>
>> The above is a workaround for the fact that --link-object does not yet
>> do any path conversion.
>
> Thanks! That worked. I set both lines to:
> MLOBJS += ../runtime/mercury_dotnet.cs
>
> cygwin uses the Mono compiler. Perhaps Mono doesn't have a problem with Unix
> style paths?

Tags:

Steps To Reproduce:

Additional Information:

It appears as though the wrong assignment to MLOBJS in library/Mmakefile
is being made when we are telling the compiler to include mercury_dotnet.cs

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

252

[mercury] Bug

minor

always

2012-02-02 10:29

2012-02-13 13:52

Reporter:

petdr

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:

mmc --make doesn't respect the -j flag when building the .cs, .javas or .css target

Description:

If you issue the command

mmc --make -j4 lib.cs

then each C/Java/C# file is built sequentially, however if you do

mmc --make -j4 liblib

then the C/Java/C# files are built in parallel

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

251

[mercury] Bug

trivial

always

2012-01-19 02:51

2012-01-30 18:31

Reporter:

colanderman

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:

eqvclass.ensure_equivalence(X, X) causes exception

Description:

Calling eqvclass.ensure_equivalence(X, X) (where X is ground) causes an exception of the following form:

Uncaught Mercury exception:
Software Error: map.det_insert: key already present
    Key Type: int
    Key Value: 0
    Value Type: int

See attached test case.

Tags:

Steps To Reproduce:

Additional Information:

Obviously the simple fix is for eqvclass.ensure_equivalence to check equality before doing anything else.

Attached Files:

eqvclass_bug.m (223 bytes) 2012-01-19 02:51
https://bugs.mercurylang.org/file_download.php?file_id=150&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

248

[mercury] Bug

tweak

N/A

2011-12-14 04:18

2012-01-18 02:50

Reporter:

colanderman

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:

Inconsistent argument ordering of singleton_set

Description:

The arguments of singleton_set in set_ordlist and set_unordlist are in reverse order of the arguments of singleton_set in set_tree234 and set_ctree234.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

249

[mercury] Bug

minor

always

2011-12-14 23:34

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:

--dump-mlds does not work for non-C grades

Description:

The --dump-mlds option causes the compiler to abort when compiling a program
in a non-C grade.

This is due to --dump-mlds being implemented by the MLDS->C code generator; the
use of non-C grades violates some of the assumptions made by that code generator.

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:

246

[mercury] Bug

major

always

2011-12-11 17:40

2011-12-14 17:44

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:

HLDS->MLDS code generator abort

Description:

The attached program causes the HLDS->MLDS code generator to abort 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(52)
        Value Type: ml_backend.ml_gen_info.ml_ground_term

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

gvs-bug.tar.gz (1,427 bytes) 2011-12-11 17:40
https://bugs.mercurylang.org/file_download.php?file_id=147&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

242

[mercury] Bug

minor

always

2011-12-05 10:21

2011-12-14 17:00

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:

filename encoding

Description:

The predicate that open files, etc. need to take into account that the file name encoding may not be UTF-8.

_wfopen looks like the way to go for Windows.

OS X enforces a decomposed UTF-8 representation.
Precomposed strings will be automatically decomposed.
The string returned by the filesystem will be decomposed and may not
match what you passed in, so that's something to be aware of.

For Linux, I'm not sure another solution is better than what we have
now.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

245

[mercury] Bug

crash

always

2011-12-07 22:19

2011-12-13 03:23

Reporter:

jfondren

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:

[Java, 11.07-beta-2011-12-06] crashes with ClassCastException

Description:

A program as simple as,

main(!IO) :- io.write_string("Hello, world!\n", !IO).

which runs fine in --grade=asm_fast.gc , or with 11.01's Java,
crashes on start with 11.07-beta-2011-12-06's java grade.

Exception in thread "main" java.lang.ExceptionInInitializerError
    at jmercury.list.MR_init_scalars_0(list.java:328)
    at jmercury.list.<clinit>(list.java:337)
    at jmercury.io.<clinit>(io.java:947)
    at jmercury.hello.main_2_p_0(hello.java:88)
    at jmercury.hello.main(hello.java:50)
Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to jmercury.runtime.PseudoTypeInfo
    at jmercury.runtime.TypeInfo_Struct.init(TypeInfo_Struct.java:84)
    at jmercury.runtime.TypeInfo_Struct.<init>(TypeInfo_Struct.java:102)
    at jmercury.pretty_printer.MR_init_scalars_0(pretty_printer.java:695)
    at jmercury.pretty_printer.<clinit>(pretty_printer.java:781)
    ... 5 more

Tags:

Steps To Reproduce:

Additional Information:

Mercury Compiler, version 11.07-beta-2011-12-06, configured for i686-pc-linux-gnu

java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.4) (fedora-60.1.10.4.fc16-i386)
OpenJDK Server VM (build 20.0-b11, mixed mode)

# failed identically with:
java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) Server VM (build 21.1-b02, mixed mode)

# 11.07-beta-2011-12-06 was built with
configured by ./configure, generated by GNU Autoconf 2.61,
with options \"'--disable-most-grades' '--enable-libgrades=java' '--with-default-grade=java'\"

Attached Files:

bug245.m (507 bytes) 2011-12-12 02:59
https://bugs.mercurylang.org/file_download.php?file_id=148&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

247

[mercury] Bug

minor

have not tried

2011-12-12 04:08

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:

declarative debugger aborts

Description:

When attempting to debug the compiler (which is attempting to compile the test case from bug 0000245),
the declarative debugger aborts with

Error: missed final event.
event 19672059
last event 19672058
Errno = 17: File exists
Mercury runtime: Aborting.
Last trace event was event #19672059.

when the "track" command is given.

This is occuring on goliath.

Tags:

Steps To Reproduce:

Additional Information:

The sequence of commands is something like:

table io_start
break -E1 mld_to_java.output_scalar_init
continue
continue
step
finish
dd
> yes
> browse
> track 3

Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

244

[mercury] Bug

minor

always

2011-12-07 07:13

2011-12-10 00:28

Reporter:

colanderman

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:

Re-entering partially memoized multi/nondet predicate causes spurious loop exception

Description:

If a memoized multi or nondet predicate is called, and after a few (but not all) results have been returned, is called again in a context which requires all of its solutions (e.g. by the solutions module or an all [] goal), then the following spurious runtime error will be produced:

Uncaught Mercury exception:
Software Error: detected need for minimal model in XXX
Stack dump not available in this grade.

See attached program for example. Comment out the memo pragma to see the expected behavior.

Tags:

Steps To Reproduce:

Additional Information:

Possibly related to bug 111.

Attached Files:

nondet_memo_bug.m (343 bytes) 2011-12-07 07:13
https://bugs.mercurylang.org/file_download.php?file_id=146&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

211

[mercury] Bug

minor

have not tried

2011-08-22 16:58

2011-12-09 10:26

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:

single-precision float grades broken on 64-bit

Description:

Both LLDS (and now high-level C grades) generate structures like this for static data.

struct foo {
  MR_Word f1;
  MR_Float f2;
  MR_Float f3;
};

which is then treated as an array of MR_Word. However, if using MR_Float==float on a 64-bit platform, the C compiler will pack the two float members into a single word.

Two possible solutions are:

1. use C compiler extensions to force any MR_Float members to be word-aligned

2. replace the MR_Float members by a union, e.g.

union MR_Float_Word {
  MR_Float f;
  MR_Word w;
};

This requires additional braces in initialiser lists.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

240

[mercury] Bug

major

always

2011-12-02 20:08

2011-12-09 10:26

Reporter:

maclarty

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:

float unboxing issue on MinGW

Description:

The attached program produces incorrect output when compiled on MinGW with rotd-2011-11-29 in grade hlc.gc at -O1 or lower:

$ mmc bug.m -O1 --grade hlc.gc
$ ./bug
0.0
123.0
$ mmc bug.m -O2 --grade hlc.gc
$ ./bug
123.0
123.0

$ uname -a
MINGW32_NT-6.1 TTT 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys

$ gcc --version
gcc.exe (GCC) 4.6.1

11.07-beta-2011-11-30 works.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug.m (474 bytes) 2011-12-02 20:08
https://bugs.mercurylang.org/file_download.php?file_id=144&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

243

[mercury] Bug

minor

always

2011-12-05 16:44

2011-12-07 22:29

Reporter:

juliensf

Platform:

Assigned To:

juliensf

OS:

Priority:

urgent

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Memory zone leak on Windows

Description:

This documents a series of problems that Ian has encountered with memory zones on Windows.

Executables built in the hlc.gc.trseg grade are leaking memory zones on Windows. The immediate
cause of the problem is that the call to VirtualFree at runtime/mercury_memory_zones.c:212 is failing
(it doesn't show because the return value is not checked). Looking closer, I think there are a whole
series of problems with the VirtualAlloc approach to allocation for memory zones:

(1) it isn't clear that we are allocating memory correctly in the first place, i.e. doesn't the call
     to VirtualAlloc at runtime/mercury_memory_zones.c:177 also have to reserve the memory
     as well as commit it.

(2) the call to VirtualFree mentioned above doesn't match the API documentation that says that if
     we call VirtualFree with MEM_RELEASE then the size argument must be 0. (Changing this value
     to 0 just resulted in a segmentation fault.) We should also check the return value of any calls
    to VirtualFree.

(3) MR_protect_pages should probably be calling VirtualProtect, *not* VirtualAlloc.

(4) When we allocate a zone using VirtualAlloc when using the Boehm GC we call GC_add_roots
on the range of memory returned. We do not call GC_remove_roots when deallocating the zone.
(Which wouldn't work on Windows since Boehm doesn't appear to implement GC_remove_roots on
Windows.)

In light of the above, I think the approach using VirtualAlloc doesn't work and we should use the
version of the zone functions that use the Boehm collector on Windows.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

235

[mercury] Bug

minor

always

2011-11-24 17:22

2011-12-05 16:44

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:

java grade does not respect --restricted-command-line

Description:

Building the Mercury compiler in the java grade under MSYS (Windows Server 2008 R2) fails
because the command line is too long. This occurs even when the Mercury compiler is
invoked with --restricted-command-line.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

239

[mercury] Bug

minor

always

2011-11-30 08:44

2011-12-05 14:18

Reporter:

colanderman

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:

Aliasing of partially instantiated structures in solutions.* predicates

Description:

If a partially instantiated structure is fully instantiated and output from the generator predicate of one of the solutions.* predicates, then each result generated will point at the same physical structure (see attached example).

This is because multi/nondet predicates do not deep copy partially instantiated structures when filling them in, and solutions.builtin_aggregate does not deep copy while generating results (except in the case of accurate garbage collection).

Since changing the former would result in pervasive ABI changes, I believe that changing solutions.builtin_aggregate to always copy generated results is the correct solution (albeit at a performance hit).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

agg_bug.m (416 bytes) 2011-11-30 08:44
https://bugs.mercurylang.org/file_download.php?file_id=142&type=bug
solutions_copy.patch (3,685 bytes) 2011-11-30 08:45
https://bugs.mercurylang.org/file_download.php?file_id=143&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

241

[mercury] Bug

trivial

always

2011-12-03 06:01

2011-12-04 00:36

Reporter:

colanderman

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:

require_semidet doesn't parse

Description:

A typo in compiler/prog_io_goal.m (grep for "require_semi") prevents require_semidet from parsing. See attached test case.

Tags:

Steps To Reproduce:

Additional Information:

library/ops.m does not have the typo.

Attached Files:

require_bug.m (276 bytes) 2011-12-03 06:01
https://bugs.mercurylang.org/file_download.php?file_id=145&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

234

[mercury] Bug

minor

always

2011-11-24 16:29

2011-12-03 04:59

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:

java grade does not compile with Java SE 7

Description:

Compilation of the the java grade with javac 1.7.0_01 causes numerous errors of the type
below. (This is with Windows Server 2008 R2 and Mercury 11.07-beta.)

Tags:

Steps To Reproduce:

Additional Information:

Mercury\javas\jmercury\exception.java:2904: error: reference to TypeInfo_Struct is ambiguous, both constructor TypeInfo_Struct(TypeInfo_Struct,int,Obj
n TypeInfo_Struct and constructor TypeInfo_Struct(TypeInfo_Struct,Object...) in TypeInfo_Struct match
        TypeInfo_25_25 = new jmercury.runtime.TypeInfo_Struct(TypeCtorInfo_23_23, ActualArity_24, TypeInfo_for_T_21, TypeCtorInfo_22_22);
                         ^
Mercury\javas\jmercury\exception.java:4631: error: reference to TypeInfo_Struct is ambiguous, both constructor TypeInfo_Struct(TypeInfo_Struct,int,Obj
n TypeInfo_Struct and constructor TypeInfo_Struct(TypeInfo_Struct,Object...) in TypeInfo_Struct match
        TypeInfo_47_47 = new jmercury.runtime.TypeInfo_Struct(TypeCtorInfo_45_45, ActualArity_46, TypeInfo_for_T_36, TypeInfo_44_44);
                         ^
Mercury\javas\jmercury\exception.java:4697: error: reference to TypeInfo_Struct is ambiguous, both constructor TypeInfo_Struct(TypeInfo_Struct,int,Obj
n TypeInfo_Struct and constructor TypeInfo_Struct(TypeInfo_Struct,Object...) in TypeInfo_Struct match
        TypeInfo_42_42 = new jmercury.runtime.TypeInfo_Struct(TypeCtorInfo_40_40, ActualArity_41, TypeInfo_for_T_36, TypeInfo_39_39);
                         ^
Mercury\javas\jmercury\bit_buffer.java:321: error: reference to TypeInfo_Struct is ambiguous, both constructor TypeInfo_Struct(TypeInfo_Struct,int,Obj
n TypeInfo_Struct and constructor TypeInfo_Struct(TypeInfo_Struct,Object...) in TypeInfo_Struct match
    MR_scalar_common_3[0] = new jmercury.runtime.TypeInfo_Struct(jmercury.runtime.TypeInfo_Struct.maybe_new(builtin.builtin__type_ctor_info_tuple_0),
                            ^
Mercury\javas\jmercury\dir.java:2352: error: reference to TypeInfo_Struct is ambiguous, both constructor TypeInfo_Struct(TypeInfo_Struct,int,Object...
Info_Struct and constructor TypeInfo_Struct(TypeInfo_Struct,Object...) in TypeInfo_Struct match
                          TypeInfo_76_76 = new jmercury.runtime.TypeInfo_Struct(TypeCtorInfo_74_74, ActualArity_75, TypeInfo_71_71, TypeCtorInfo_72_72
rInfo_73_73);
                                           ^
Mercury\javas\jmercury\erlang_rtti_implementation.java:1174: error: reference to TypeInfo_Struct is ambiguous, both constructor TypeInfo_Struct(TypeIn
,int,Object...) in TypeInfo_Struct and constructor TypeInfo_Struct(TypeInfo_Struct,Object...) in TypeInfo_Struct match
    MR_scalar_common_2[2] = new jmercury.runtime.TypeInfo_Struct(jmercury.runtime.TypeInfo_Struct.maybe_new(builtin.builtin__type_ctor_info_tuple_0),
                            ^
Mercury\javas\jmercury\erlang_rtti_implementation.java:3184: error: reference to TypeInfo_Struct is ambiguous, both constructor TypeInfo_Struct(TypeIn
,int,Object...) in TypeInfo_Struct and constructor TypeInfo_Struct(TypeInfo_Struct,Object...) in TypeInfo_Struct match
        TypeInfo_11_11 = new jmercury.runtime.TypeInfo_Struct(TypeCtorInfo_9_9, ActualArity_10, TypeCtorInfo_8_8, TypeInfo_for_T_6);

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

238

[mercury] Bug

crash

always

2011-11-28 12:39

2011-12-01 16:06

Reporter:

colanderman

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:

Unexpected: determinism errors when compiling with --constraint-propagation

Description:

Various errors relating to promise_equivalent_solutions are obscured by a compiler crash when compiling with --constraint-propagation or --local-constraint-propagation. The attached program, when compiled with no optimization, produces (as expected), the error:

pes_crash.m:015: Error: call to predicate `solutions.unsorted_solutions'/2 with
pes_crash.m:015: determinism `cc_multi' occurs in a context which requires
pes_crash.m:015: all solutions.
pes_crash.m:015: Unification of V_2 and V_5 can fail.

but when compiled with --constraint-propagation, produces the crash:

Uncaught Mercury exception:
Software Error: transform_hlds.pd_util: predicate `transform_hlds.pd_util.rerun_det_analysis'/4: Unexpected: determinism errors

Other errors (such as the one produced by bug 0000237) trigger this crash as well.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

pes_crash.m (297 bytes) 2011-11-29 12:46
https://bugs.mercurylang.org/file_download.php?file_id=141&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

227

[mercury] Bug

minor

have not tried

2011-11-09 18:18

2011-11-28 17: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:

det scope unchecked in lambda expression

Description:

The compiler does not emit an error for this code:

        (pred(C::in) is semidet :-
            require_det (
                C = 'x'
            )
        )

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

237

[mercury] Bug

minor

always

2011-11-28 12:30

2011-11-28 16:56

Reporter:

colanderman

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:

Strange interaction b/w typeclasses and promise_equivalent_solutions

Description:

promise_equivalent_solutions doesn't seem to play well with typeclasses. The attached example, when, compiled, complains that:

unif_bug2.m:016: Error: the `promise_equivalent_solutions' goal binds a
unif_bug2.m:016: variable that is not listed: PolyConst1.

This is not in a context where the typeclass implementations are not deducible at compile time (i.e. there are no existential types).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

unif_bug2.m (376 bytes) 2011-11-28 12:30
https://bugs.mercurylang.org/file_download.php?file_id=140&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

236

[mercury] Bug

text

N/A

2011-11-28 08:22

2011-11-28 10:39

Reporter:

colanderman

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:

Documentation for unsorted_aggregate incorrect (trivial)

Description:

solutions.unsorted_aggregate claims to be declaratively identical to calling list.foldl on the output of solutions.unsorted_solutions, when in fact it acts as if list.foldr is called. This is apparent from the definition of unsorted_solutions in solutions.m, which uses list.cons to build the solutions list (hence building it right-to-left).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

233

[mercury] Bug

minor

random

2011-11-24 11:19

2011-11-24 23:24

Reporter:

pbone

Platform:

Assigned To:

pbone

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Parallel run-time system crashes.

Description:

Programs compiled in parallel low-level C grades can crash with an error such as:

sem_post: Invalid argument

This happens infrequently and the cause is unknown, it's been seen on taura and mungerabah (RHEL 5).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

229

[mercury] Bug

crash

always

2011-11-15 11:22

2011-11-24 11:36

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:

problem with static data on high-level C grades

Description:

The high-level C backend crashes on the given test case. It seems to be related to constants in the arms of lookup switches. Writing the switch as if-then-else or setting --no-common-struct both work around the problem.

% mmc -s hlc.gc -C lookup_switch_const
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:

lookup_switch_const.m (551 bytes) 2011-11-15 11:22
https://bugs.mercurylang.org/file_download.php?file_id=136&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

230

[mercury] Bug

major

have not tried

2011-11-21 15:40

2011-11-23 10:08

Reporter:

juliensf

Platform:

Assigned To:

wangp

OS:

Priority:

urgent

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

submodules inconsistently compiled with direct arg functors

Description:

The attached modules exhibit a bug where the direct arg functor optimisation is applied in a submodule
but not in its parent.

(I have a change to the Mercury compiler that I will commit shortly that adds an option that
causes it to print out a summary of what ctors the daf optimisation has been applied to.)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

daf-bug.tar.gz (816 bytes) 2011-11-21 15:40
https://bugs.mercurylang.org/file_download.php?file_id=137&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

228

[mercury] Bug

major

always

2011-11-10 02:50

2011-11-14 01:36

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:

library/lexer.c cannot be compiled with MSVC

Description:

In Rotd-2011-11-10 (and for a probably a few months before) we generate C code for
library/lexer.c in the hlc.gc grade that cannot be compiled with MSVC. (The 11.07 branch is fine.)
There are two issues:

lexer.c(171) : error C2133: 'mercury__lexer__lexer__field_locns_token_0_3' : unknown size
lexer.m(2466) : error C2440: 'type cast' : cannot convert from 'MR_Float' to 'MR_Float-Dword'
etc etc

Tags:

Steps To Reproduce:

Additional Information:

For issue 1 we just need to emit the array size in the forwarding declaration:

static const MR_DuArgLocn mercury__lexer__lexer__field_locns_token_0_3[];

(Does anyone know where it's generated?)

I haven't looked into the second issue yet.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

199

[mercury] Bug

minor

always

2011-05-31 10:48

2011-11-11 13: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:

unboxed floats for high-level code

Description:

From mercury_conf_param.h:

/*
** MR_HIGHLEVEL_CODE implies MR_BOXED_FLOAT,
** since unboxed float is currently not yet implemented for the MLDS back-end.
** XXX we really ought to fix that...
*/

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:

225

[mercury] Bug

tweak

always

2011-11-03 10:20

2011-11-04 00:33

Reporter:

colanderman

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:

Module-level mutable with type "semaphore" causes hlc grade compilation to break.

Description:

Compile attached program with -H. It will produce the following error:

sema_hlc.m:6:25: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token

Compiling under asm_fast does not produce this error.

Tags:

Steps To Reproduce:

Additional Information:

Also appears with --java.

Compiler version is 11.07-beta-2011-09-30.

Attached Files:

sema_hlc.m (153 bytes) 2011-11-03 10:20
https://bugs.mercurylang.org/file_download.php?file_id=135&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

223

[mercury] Bug

minor

always

2011-10-24 08:02

2011-11-03 12:08

Reporter:

colanderman

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:

thread.mvar.init/0 and thread.semaphore.init/1 should be marked impure

Description:

thread.mvar.init/0 and thread.semaphore.init/1 are obviously impure but are not marked as such, leading to logical inconsistencies such as this:

main(!IO) :-
    M1 = init, M2 = init,
    put(M1, 1, !IO), take(M2, _, !IO).

not being equivalent to this:

main(!IO) :-
    M1 = init, M2 = M1,
    put(M1, 1, !IO), take(M2, _, !IO).

(The former will block but the latter will not.)

They should be marked impure or removed from the library.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

224

[mercury] Bug

minor

always

2011-10-24 11:59

2011-10-25 10:42

Reporter:

colanderman

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:

STM broken without --inline-compound-threshold 10 --loop-invariants

Description:

Attached is a basic mutex implementation using STM primitives. Compile with:

mmc --parallel -O0 --inline-compound-threshold 10 --loop-invariants --rebuild stm_bug

And run. Program will behave as expected (uses 200% CPU on a multiproc platform, does not terminate).

Recompile without either one (or both) of "--inline-compound-threshold 10" or "--loop-invariants":

mmc --parallel -O0 --rebuild stm_bug

And run. Program soon terminates due to failed assertion about the state of the lock.

Behavior is identical under hlc.par grade (-H flag). Building without any optimization flags fails as well, since -O2 (the default) enables "--inline-compound-threshold 10" but not "--loop-invariants".

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

stm_bug.m (1,008 bytes) 2011-10-24 11:59
https://bugs.mercurylang.org/file_download.php?file_id=133&type=bug
stm.patch (762 bytes) 2011-10-25 10:41
https://bugs.mercurylang.org/file_download.php?file_id=134&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

212

[mercury] Bug

trivial

N/A

2011-08-23 10:00

2011-10-25 01:09

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:

Documentation of --no-warn-undefined-options-variables is actually for --warn-undefined-options-variables

Description:

Both the Mercury User Guide and the output of mmc --help contain the following:

[quote]
--no-warn-undefined-options-variables
Warn about references to undefined variables in
options files with `--make'.
[/quote]

The description should start with "Disable warnings" instead of "Warn", since the warning is enabled by default and the command-line option being documented disables the warning.

Tags:

Steps To Reproduce:

Additional Information:

version-rotd-2011-08-21

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

221

[mercury] Bug

major

always

2011-10-11 10:09

2011-10-24 16:19

Reporter:

maclarty

Platform:

Assigned To:

maclarty

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

ho specialization bug

Description:

The attached program produces the wrong output when compiled with --optimize-higher-order. It should output "ho2", but instead outputs "ho1". In do_stuff it is specializing P to ho1, when it shouldn't. Here is the relevant bit of the hlds dump for stage 135:

:- mode do_stuff((builtin.in), (builtin.di), (builtin.uo)) is det.
bug.do_stuff(Maybe, STATE_VARIABLE_IO_0, STATE_VARIABLE_IO) :-
  ( % cannot_fail switch on `Maybe'
    % Maybe has functor maybe.no/0
    P = bug.ho1
  ;
    % Maybe has functor maybe.yes/1
    P = bug.get_ho2
  ),
  bug.ho1(STATE_VARIABLE_IO_0, STATE_VARIABLE_IO).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug.m (674 bytes) 2011-10-11 10:09
https://bugs.mercurylang.org/file_download.php?file_id=132&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2009-06-15 01:38

2011-10-09 03:12

Reporter:

serkho

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 command-line options for Visual Studio

Description:

I have tried to use Mercury with MSVC2005 and found some glitches:

1) there is a whitespace after /OUT: in command file for lib, lib.exe is not able to handle it
2) libcmt.lib should be linked in addition to Mercury libraries
3) also I had to specify /entry:mainCRTStartup after /link option for linker

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

220

[mercury] Bug

minor

always

2011-10-05 14:58

2011-10-05 15:39

Reporter:

colanderman

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:

Termination analysis produces spurious "termination constant of infinity" errors

Description:

For certain (not all) functions and/or predicates XXX and YYY, where YYY has :- pragma terminates set, termination analysis will report that:

"Termination of predicate XXX not proven for the following reason:
It calls predicate YYY which has a termination constant of infinity."

and that:

"Termination constant of function YYY set to infinity for the following reason:
It contains one or more predicates and/or functions imported from another module."

Expected behavior is that :- pragma terminates(YYY) causes the compiler to assume YYY terminates, regardless of its body.

This bug is not exhibited by all such predicates or functions; see attached test case.

Tags:

Steps To Reproduce:

Additional Information:

11.07-beta-2011-09-30

Attached Files:

termination.m (885 bytes) 2011-10-05 14:58
https://bugs.mercurylang.org/file_download.php?file_id=130&type=bug
termination.err (3,389 bytes) 2011-10-05 14:59
https://bugs.mercurylang.org/file_download.php?file_id=131&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

172

[mercury] Bug

minor

have not tried

2010-12-02 14:29

2011-10-05 12:16

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:

Building library in asm_fast.gc.debug aborts on FreeBSD 8.1

Description:

/home/juliensf/ws2/install_grade_dir.asm_fast.gc.debug/scripts/mgnuc --grade asm_fast.gc.debug --no-ansi -- -fPIC -DMR_PIC \
-c io.c -o io.pic_o
io.c: In function 'io_module326':
io.c:52935: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
gmake[1]: *** [io.pic_o] Error 1
gmake[1]: Leaving directory `/home/juliensf/ws2/install_grade_dir.asm_fast.gc.debug/library'
To clean up from failed install, remove /home/juliensf/ws2/install_grade_dir.asm_fast.gc.debug
gmake: *** [install_grades] Error 1
*** Error code 2

Tags:

Steps To Reproduce:

Additional Information:

gcc -v

Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719 [FreeBSD]

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

219

[mercury] Bug

minor

always

2011-09-26 10:54

2011-09-26 10:55

Reporter:

maclarty

Platform:

Assigned To:

maclarty

OS:

Priority:

low

OS Version:

Status:

assigned

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

declarative debugger abort

Description:

Running the attached program through mdb using asm_fast.gc.decldebug with the attached session results in an abort from the declarative debugger:

An internal error has occurred; diagnosis will be aborted. Debugging
message follows:
insert_new_topmost_node: couldn't find event number

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

puzzle_solver.m (14,375 bytes) 2011-09-26 10:54
https://bugs.mercurylang.org/file_download.php?file_id=128&type=bug
session (104 bytes) 2011-09-26 10:54
https://bugs.mercurylang.org/file_download.php?file_id=129&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

218

[mercury] Bug

feature

have not tried

2011-09-26 08:41

2011-09-26 09:52

Reporter:

pbone

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:

Feature request: mdb commands for working with common data structures.

Description:

Often when using the degger I'd like to know something about a data structure.

browser> print
proc_info(context("mandelbrot.m", 279),
  varset(var_supply(10),
    map([(var(1) -> "TypeInfo_for_X"), (var(2) -> "TypeInfo_for_Y"),
      (... -> ...), ...]), map([])),
  map([
    (var(1) ->
      defined_type(qualified(unqualified("private_builtin"), "type_info"), [],
        kind_star)), (var(2) -> defined_type(qualified(...), ...)),
    (var(...) -> ...), ..., ...]), [var(21), var(22), var(...), ...],
  varset(var_supply(0), map([]), map([])),
  yes([(ground(...) -> ...), ..., ...]),
  [user_defined_mode(qualified(...), ...), ..., ...], no, no, ...)
browser> cd 3
browser> print
map([
  (var(1) ->
    defined_type(qualified(unqualified("private_builtin"), "type_info"), [],
      kind_star)),
  (var(2) ->
    defined_type(qualified(unqualified("private_builtin"), "type_info"), [],
      kind_star)),
  (var(3) -> defined_type(qualified(unqualified(...), ...), [], ...)),
  (var(4) -> higher_order_type(...)), (... -> ...), ...])

What I want to know at this point is var(21) present in this map and what is it's value.

It'd be nice to have commands to work with maps, sets, lists, and perhaps other commonly-used data-structures to anwser these questions. This should be without
using the clunky compile a .m file and dynamically load it into the binary being debugged operation.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

217

[mercury] Bug

major

always

2011-09-20 01:52

2011-09-21 17:23

Reporter:

dkononenko

Platform:

Assigned To:

juliensf

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

no change required

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Can't compile simple program

Description:

cat testlist.m

:- module testlist.
:- interface.
:- import_module io.

:- pred main(io::di, io::uo) is det.

:- implementation.
:- import_module list.

main(!IO) :- L=[1,2,3], io.write_list(L, "\n", io.write_int, !IO).

--------

wc -l testlist.m
11 testlist.m

--------

mmc --make testlist
Making Mercury/os/testlist.o
testlist.m:26: error: initializer element is not constant
testlist.m:26: error: (near initialization for ‘testlist_scalar_common_1[0][1]’)
** Error making `Mercury/os/testlist.o'.

Tags:

Steps To Reproduce:

Additional Information:

uname -a
Darwin MacBook-Pro-Denis-Kononenko.local 11.1.0 Darwin Kernel Version 11.1.0: Tue Jul 26 16:07:11 PDT 2011; root:xnu-1699.22.81~1/RELEASE_X86_64 x86_64

mmc --version
Mercury Compiler, version 11.01, configured for x86_64-apple-darwin10.8.0
Copyright (C) 1993-2011 The University of Melbourne

Attached Files:

testlist.m (205 bytes) 2011-09-20 01:52
https://bugs.mercurylang.org/file_download.php?file_id=127&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

207

[mercury] Bug

major

always

2011-07-28 10:49

2011-09-06 10:23

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:

tree_bitset.difference bug

Description:

In the following test case tree_bitset.difference produces the wrong result on 32-bit platforms.

% ./tree_bitset_difference
set: [532, 32431]
tree_bitset: []

This affects the compiler since the recent representation change.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

tree_bitset_difference.m (1,212 bytes) 2011-07-28 10:49
https://bugs.mercurylang.org/file_download.php?file_id=125&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

216

[mercury] Bug

minor

always

2011-09-05 14:56

2011-09-06 10:23

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:

hlc grade generates empty structs in static data

Description:

The generated C code for library/char.m in the hlc.gc grade contains an empty struct and also an array of empty structs that is referenced anywhere else within the module. This breaks compilation with Visual C, since it doesn't support empty struct definitions. Since the definition isn't referred to it's
pointless anyway.

/* sealed */ struct mercury__char__vector_common_type_2_0_s {
};

static /* final */ const struct mercury__char__vector_common_type_2_0_s mercury__char_vector_common_2[103] = {
  /* row 0 */
  {

  },
  /* row 1 */
  {

  },
  /* row 2 */
  {

  },
  /* row 3 */
  {

  },

Tags:

Steps To Reproduce:

Additional Information:

This affects a number of other stdlib modules, char.m is just the first one that is compiled.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

215

[mercury] Bug

text

N/A

2011-09-05 14:37

2011-09-05 14:50

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:

Documentation of assoc_list.filter/4 is missing the TrueList argument

Description:

In the first line of the documentation of assoc_list.filter/4 there is a missing argument, TrueList, which should appear between List and FalseList:

    % assoc_list.filter(Pred, List, FalseList) takes a closure with one
    % input argument and for each member K - V of List X, calls the closure
    % on the key. K - V is included in TrueList iff Pred(K) is true.
    % K - V is included in FalseList iff Pred(K) is false.
    %
:- pred assoc_list.filter(pred(K)::in(pred(in) is semidet),
    assoc_list(K, V)::in, assoc_list(K, V)::out, assoc_list(K, V)::out) is det.

Tags:

Steps To Reproduce:

Additional Information:

rotd-2011-09-03

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

173

[mercury] Bug

minor

always

2010-12-06 18:18

2011-08-19 03:19

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:

man pages for 10.04.2 contain string "Error reading options file"

Description:

from mercury-isers

I've noticed that after building Mercury 10.04.2, all (?) the Unix man pages contain the string "Error reading options file". From the top of mmc.1:

.de Vb
.nf
.ne \$1
..
.de Ve

.fi
..
.TH mmc 1 "Fri Nov 19 15:36:47 GMT 2010" "" "Mercury Programmer's Manual"
.AT 3
.Vb 2
Error reading options file
.SH " `/usr/local/pkg/mercury-10.04.2-i686-1/lib/mercury/conf/Mercury.config'."

.SH "NAME "
mmc -- Melbourne Mercury Compiler, version 10.04.2, configured for i686-pc-linux-gnu

I can't find mention of this in the mailing list archive.

I'd prefer that the string wasn't there. I could edit it out from all the man page files, of course, but how can I (or you) prevent the string from being there next
time I build? The build appeared to go well, but I didn't save a log file.

John A. Murdie
Department of Computer Science
University of York
UK

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

210

[mercury] Bug

text

N/A

2011-08-17 13:26

2011-08-19 01:21

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:

Language Reference confuses maybeskel and listskel in "Insts, modes, and mode definitions"

Description:

In section 4.1 (Insts, modes, and mode definitions) of the Mercury Language Reference Manual there is the following text:

[quote]
For example, the following declaration

:- inst maybeskel(Inst) ---> no ; yes(Inst).

defines the inst ‘listskel(Inst)’ to be a list skeleton whose elements have inst ‘Inst’; you can the use insts such as ‘listskel(listskel(free))’, which represents the instantiation state of a list of lists of free variables.
[/quote]

The declared inst (maybeskel) doesn't match the description (listskel).

There is also a typo in the description: "can the use" should be "can then use".

Tags:

Steps To Reproduce:

Additional Information:

version rotd-2011-08-15

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

209

[mercury] Bug

minor

have not tried

2011-08-01 03:05

2011-08-01 13:09

Reporter:

juliensf

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:

java grade broken in rotd-2011-07-31

Description:

The library does not compile in the java grade on goliath (the ROTD host). The last
working compiler on that machine is rotd-2011-07-23. The relevant part of the build
log is reproduced below.

This appears to affect only the trunk, not the 11.07 branch.

Tags:

Steps To Reproduce:

Additional Information:

Making Mercury/javas/jmercury/thread__semaphore.java
Making Java class files
Mercury/javas/jmercury/array.java:682: incompatible types
found : jmercury.builtin.Comparison_result_0
required: int
                case builtin.Comparison_result_0.K1:
                                                ^
Mercury/javas/jmercury/array.java:735: incompatible types
found : jmercury.builtin.Comparison_result_0
required: int
                case builtin.Comparison_result_0.K0:
                                                ^
Mercury/javas/jmercury/array.java:743: incompatible types
found : jmercury.builtin.Comparison_result_0
required: int
                case builtin.Comparison_result_0.K2:
                                                ^
... error log truncated, see `mer_std.err' for the complete log.
make[1]: *** [libmer_std.install] Error 1
make[1]: Leaving directory `/home/goliath/workspaces/test_mercury_goliath/build.latest.gcc/mercury/stage2/install_grade_dir.java/library'
To clean up from failed install, remove /home/goliath/workspaces/test_mercury_goliath/build.latest.gcc/mercury/stage2/install_grade_dir.java
make: *** [install_grades] Error 1

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

205

[mercury] Bug

text

N/A

2011-07-21 16:07

2011-07-23 18:03

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:

Documentation of array.foldr2 references non-existent list.foldr2

Description:

The documentation of array.foldr2 says:

"array.foldr2(P, Array, !Acc1, !Acc2) is equivalent to list.foldr2(P, array.to_list(Array), !Acc1, !Acc2) but more efficient."

but list.foldr2 doesn't exist - there's only list.foldr and list.foldl2.

Perhaps it should instead use the description of list.foldl2 with s/list.foldl/array.foldr/g

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

206

[mercury] Bug

text

N/A

2011-07-22 09:29

2011-07-23 18:03

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:

User's guide has incorrect short option name for mtc --output-file

Description:

The "Generating trace counts" section of the Mercury User's Guide states:

‘mtc’ accepts an ‘-f’ or ‘--output-file’ option

but the short option is actually '-o'.

The mtc help/usage message (and hence the man page) lists the correct option name.

Tags:

Steps To Reproduce:

Additional Information:

This problem is present in both 11.01 and rotd-2011-07-17

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

204

[mercury] Bug

minor

always

2011-07-12 16:17

2011-07-13 10:42

Reporter:

juliensf

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:

Generated code seg faults

Description:

The attached program seg faults when compiled with the current rotd. It is fine with the 11.07-beta
compiler. I suspect this is to do with the enumeration argument packing optimization since that
is the only significant difference between the trunk and the branch. (And the test case involves
a type which has that optimization applied to it.)

Tags:

Steps To Reproduce:

Additional Information:

Bug appears on x86_64 Linux in various grades, notably hlc.gc and asm_fast.gc.
(I haven't looked at what happens on other machines.)

Attached Files:

zinc-pack-bug.tar.gz (1,383 bytes) 2011-07-12 16:17
https://bugs.mercurylang.org/file_download.php?file_id=124&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

202

[mercury] Bug

minor

always

2011-07-04 01:40

2011-07-11 14:20

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:

Test failures in profdeep grades

Description:

The following test cases are failing on goliath in the asm_fast.gc.profdeep grade:

FAILED TEST hard_coded/impl_def_literal in grade asm_fast.gc.profdeep
FAILED TEST hard_coded/special_char in grade asm_fast.gc.profdeep
FAILED TEST hard_coded/string_class in grade asm_fast.gc.profdeep
FAILED TEST hard_coded/string_codepoint in grade asm_fast.gc.profdeep
FAILED TEST hard_coded/string_first_char in grade asm_fast.gc.profdeep
FAILED TEST hard_coded/string_presuffix in grade asm_fast.gc.profdeep
FAILED TEST hard_coded/string_set_char in grade asm_fast.gc.profdeep
FAILED TEST hard_coded/string_strip in grade asm_fast.gc.profdeep
FAILED TEST hard_coded/string_sub_string_search in grade asm_fast.gc.profdeep
FAILED TEST hard_coded/test_pretty_printer in grade asm_fast.gc.profdeep
FAILED TEST hard_coded/unicode_test in grade asm_fast.gc.profdeep
FAILED TEST hard_coded/utf8_io in grade asm_fast.gc.profdeep
FAILED TEST hard_coded/words_separator in grade asm_fast.gc.profdeep

Tags:

Steps To Reproduce:

Additional Information:

This is due to the following abort in the compiler when writing out the .c file:

Software Error: string.unsafe_index: illegal sequence
Stack dump not available in this grade.

In particular, it occurs when writing out the module strings for a module.
(At a guess, we aren't handling UTF-8 encoded strings correctly here.)

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

136

[mercury] Bug

minor

always

2010-03-11 04:41

2011-07-04 13:51

Reporter:

juliensf

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

confirmed

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

hard_coded/impl_def_literal fails with -O5 --intermodule optimization

Description:

The test case hard_coded/impl_def_literal causes the following abort in the compiler:

Uncaught Mercury exception:
Software Error: pred_table.m: Unexpected: can't locate stm_from_outer_to_inner/2

To reproduce:

mmc -C --grade asm_fast.gc -O5 --intermodule-optimisation impl_def_literal.m

Tags:

Steps To Reproduce:

Additional Information:

This was with rotd-2010-03-10

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

201

[mercury] Bug

crash

random

2011-06-11 12:31

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:

tests/par_conj/cosume_wait blocks before exiting.

Description:

tests/par_conj/cosume_wait blocks before exiting.

This is repeatable (intermittently) on taura running with MERCURY_OPTIONS=-P4
The test fails sometimes during the nightly tests (the system is doing other work) and when ran in the day time while the system is relatively unused.

When this locks up it also seems to lock up gdb, making it difficult to diagnose.
Using MR_DEBUG_THREADS and some reporting from gdb I have determined that all the worker threads finish, the main thread either has finished or is ready to finish but one of Boehm's threads is still running. Therefore I think this may be a problem with the Boehm GC.

Tags:

Steps To Reproduce:

Additional Information:

It may be possible to work around this bug by executing it with GC_MARKERS=1

Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

198

[mercury] Bug

text

always

2011-05-13 01:15

2011-05-19 17:35

Reporter:

colanderman

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:

event is a keyword but not mentioned in documentation

Description:

As summary: event is a keyword (prog_io_goal.m) but not mentioned in documentation.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

197

[mercury] Bug

minor

always

2011-05-09 01:01

2011-05-16 15:01

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:

abort in state variable transformation

Description:

The attached program causes an abort in the state variable transformation instead of
a proper error message being emitted.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

svbug.m (727 bytes) 2011-05-09 01:01
https://bugs.mercurylang.org/file_download.php?file_id=121&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

194

[mercury] Bug

minor

always

2011-03-30 02:42

2011-05-13 21:54

Reporter:

xonix

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

confirmed

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Optimizations -O4 to -O6 causing wrong answer

Description:

When compiling the attached program with command line

>mmc.bat --make --infer-all -s hlc.gc aag12

The program prints correct output

1->[]
2->[]
3->[]

But when add option -O4/-O5/-O6:

>mmc.bat --make --infer-all -s hlc.gc -O5 aag12

the result is incorrect:

1->[5379551]
2->[5379551]
3->[5379551]

Tags:

Steps To Reproduce:

Additional Information:

>mmc.bat
Mercury Compiler, version 10.04.2, configured for i686-pc-mingw32
Copyright (C) 1993-2010 The University of Melbourne
Usage: mmc [<options>] <arguments>
Use `mmc --help' for more information.

Attached Files:

aag12.m (610 bytes) 2011-03-30 02:42
https://bugs.mercurylang.org/file_download.php?file_id=118&type=bug
Mercury.options (274 bytes) 2011-05-13 21:53
https://bugs.mercurylang.org/file_download.php?file_id=122&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

188

[mercury] Bug

minor

always

2011-03-11 12:28

2011-05-03 14:37

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:

structure-reuse and intermod-opt breaks type_list_subsumes

Description:

From Michael Day:

Hi,

The attached module compiles fine with --structure-reuse, but
compilation fails when --intermod-opt is also specified:

$ mmc --make reuse --intermod-opt --structure-reuse
...
Software Error: prog_type.m: Unexpected: type_list_subsumes_det:
type_list_subsumes failed

Tags:

Steps To Reproduce:

Additional Information:

Something changed after mercury-compiler-rotd-2010-10-17. I haven't tried to isolate it further.

Attached Files:

reuse1.m (365 bytes) 2011-03-11 12:28
https://bugs.mercurylang.org/file_download.php?file_id=114&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

195

[mercury] Bug

tweak

always

2011-04-01 13:18

2011-04-07 07:17

Reporter:

colanderman

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

confirmed

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

mmc --java ignores -o option

Description:

Simply put: "mmc --java -o bar foo.m" always names the executable "foo"; the executable should be named "bar".

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

192

[mercury] Bug

feature

N/A

2011-03-23 06:17

Reporter:

colanderman

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:

State variable record notation enhancement

Description:

With the coming changes to the library to better support state variable use, I believe that the following notation would be useful:

foo(..., !X ^ bar)

would be equivalent to:

foo(..., !.X ^ bar, X_bar), !X ^ bar := X_bar

Multiple uses of this notation within one predicate call should probably be disallowed.

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:

190

[mercury] Bug

minor

always

2011-03-17 12:40

2011-03-18 15:09

Reporter:

colanderman

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:

solver type constraint_store declaration has trouble unifying imported types

Description:

If a solver type constraint_store declares a mutable of an imported type (say list), it fails trying to unify the unqualified type name with the qualified version (e.g. list(int) with list.list(int)).

Tags:

Steps To Reproduce:

Additional Information:

A workaround is to prefix the type name in the mutable declaration.

The bug does not occur in normal mutable declarations.

Attached Files:

mutable_bug.m (222 bytes) 2011-03-17 12:40
https://bugs.mercurylang.org/file_download.php?file_id=115&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

189

[mercury] Bug

minor

always

2011-03-16 04:35

2011-03-16 17:10

Reporter:

colanderman

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:

foreign_enum is not 64-bit safe

Description:

The definition of MR_ForeignEnumFunctorDesc in mercury_type_info.h assumes a 32-bit word size. This causes problems with foreign enum values which have bit 31 set, as their Mercury counterparts are incorrectly sign-extended, causing matching to fail.

Tags:

Steps To Reproduce:

Additional Information:

As a workaround, one can cast foreign enum values to MR_int_least32_t before passing to Mercury.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

103

[mercury] Bug

minor

always

2009-09-14 12:17

2011-03-08 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:

bug in lcmc transformation

Description:

The compiler crashes on the given test case.

% mmc --optimize-constructor-last-call lco_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(2)
        Value Type: ll_backend.var_locn.var_state

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

lco_bug.m (1,235 bytes) 2009-09-14 12:17
https://bugs.mercurylang.org/file_download.php?file_id=79&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

186

[mercury] Bug

minor

always

2011-02-22 17:50

2011-02-22 17:58

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 when --infer-all is enabled

Description:

The attached program aborts with

Uncaught Mercury exception:
Software Error: unique_modes.m: Unexpected: call to implied mode?

when compiled with mmc --infer-all.

This was originally reported on mercury-users, see
<http://www.mercury.csse.unimelb.edu.au/mailing-lists/mercury-users/mercury-users.201102/0004.html>

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug186a.m (1,427 bytes) 2011-02-22 17:50
https://bugs.mercurylang.org/file_download.php?file_id=111&type=bug
bug186b.m (1,116 bytes) 2011-02-22 17:56
https://bugs.mercurylang.org/file_download.php?file_id=112&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

185

[mercury] Bug

major

always

2011-02-03 17:45

2011-02-16 14:00

Reporter:

mgiuca

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

confirmed

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Cannot make typeclass instance for parameterised equivalence type

Description:

It seems that it is impossible to create a typeclass instance for any type that is all of the following:
1. parameterised, and
2. declared in another module to the instance declaration, and
3. declared abstractly and defined in the "implementation" section, and
4. defined as an equivalence type (==).

Notably, this includes the 'set' type. I have created a tiny self-contained example:

In the file foo.m:

:- module foo.

:- interface.

:- type foo(T).

:- implementation.

:- type foo(T) == bar(T).

:- type bar(T) ---> bar.

In the file problem.m:

:- module problem.

:- interface.

:- typeclass myclass(T) where [
func f(T) = int
].

:- implementation.

:- import_module foo.

:- instance myclass(foo(T)) where [
f(_) = 4
].

Notice that the type 'foo' is parameterised, abstract, and defined as an equivalence to bar. In the other module, I am attempting to make foo(T) an instance of myclass. 'foo' compiles properly, but compiling 'problem' leads to this nonsensical error:

problem.m:013: In instance declaration for `problem.myclass(foo.foo(T))':
problem.m:013: the first arg contains a type variable which is used in
problem.m:013: another arg

With -E, it explains, "types in instance declarations must be functors with distinct variables as arguments". If I am reading this correctly, it is telling me that I have used the type variable `T' in multiple arguments to foo, which can't be true because it only has one argument.

For a real-world example, in 'problem', replace 'foo' with 'set'; the same error arises. I haven't found any way to make 'set' an instance of a typeclass.

Tags:

Steps To Reproduce:

Additional Information:

Can anybody suggest a workaround for this issue? I would like to make 'set' a member of a typeclass.

This isn't a problem for many other standard library types. For example, it doesn't affect 'list' because list is not defined as an equivalence type. It doesn't affect 'map' because map is not abstract (even though it doesn't appear in the documentation, map(K, V) is defined as equivalent to tree234(K, V) under a subsequent "interface" section, so it is not considered abstract).

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

182

[mercury] Bug

minor

have not tried

2011-02-02 14:00

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:

Segfaults could be reported better.

Description:

In low-level C grades it's possible to detect if a segfault is caused by a stack-overrun, in which case the runtime system can report that it is either definitely or definitely-not due to unbounded/deep recursion. There appears to be code to do this but I haven't seen it work.

If we can fix this then we should fix the default message in low-level C grades.
The default message says something like.
"...this is probably due to unbounded tail recursion...",
we shouldn't suggest this if we know the segfault is not due to a stack overrun since this only confuses users, making them blame Mercury when it's more likely to be a problem with foreign code they're linking with.

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:

177

[mercury] Bug

minor

always

2011-01-07 17:23

2011-01-19 11: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:

incorrect C# code generated when compiling extras/moose

Description:

Attempting to build moose in the C# grade (rotd-2011-01-07) results in the following:

Mercury/css/misc.cs(206,8): error CS1519: Unexpected symbol `=' in class, struct, or interface member declaration
Mercury/css/misc.cs(210,45): error CS0116: A namespace can only contain types and namespace declarations
Mercury/css/misc.cs(228,22): error CS0116: A namespace can only contain types and namespace declarations
Mercury/css/misc.cs(245,45): error CS0116: A namespace can only contain types and namespace declarations
Mercury/css/misc.cs(263,22): error CS0116: A namespace can only contain types and namespace declarations
Mercury/css/misc.cs(280,45): error CS0116: A namespace can only contain types and namespace declarations
Mercury/css/misc.cs(289,22): error CS0116: A namespace can only contain types and namespace declarations
Mercury/css/misc.cs(297,43): error CS0116: A namespace can only contain types and namespace declarations
Mercury/css/misc.cs(312,43): error CS0116: A namespace can only contain types and namespace declarations
Mercury/css/misc.cs(327,43): error CS0116: A namespace can only contain types and namespace declarations
Mercury/css/misc.cs(342,43): error CS0116: A namespace can only contain types and namespace declarations
Mercury/css/misc.cs(356,43): error CS0116: A namespace can only contain types and namespace declarations
Mercury/css/misc.cs(375,14): error CS1518: Expected `class', `delegate', `enum', `interface', or `struct'
Mercury/css/misc.cs(381,1): error CS8025: Parsing error

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

179

[mercury] Bug

minor

have not tried

2011-01-18 12:43

2011-01-18 14:54

Reporter:

juliensf

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:

csharp grade library compilation failure on MinGW / MSYS with MS C# compiler

Description:

Compilation of the standard library in the csharp grade on MinGW / MSYS using the
Microsoft C# compiler results in:

Mercury\css\array.cs(12,110: errror CS1578: Filename, single-line comment or end-of-line expected
...
(plus lots more similar messages)

This C# compiler is:

Microsoft (R) Visual C# 2010 Compiler version 4.0.30319.1

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

178

[mercury] Bug

tweak

always

2011-01-12 14:55

Reporter:

pbone

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:

browser/browser_test.m does not compile.

Description:

Executing 'mmake all' in the browser directory fails to compile browser_test.m
It loos as though browser_test.m is out of date.

Tags:

Steps To Reproduce:

Additional Information:

/home/taura/public/mercury-latest/x86_64-unknown-linux-gnu/bin/mmc --compile-to-c --grade asm_fast.gc.decldebug --profile-for-implicit-parallelism -R/home/taura/workspaces/pbone/par_test.install/lib/mercury/lib/asm_fast.gc.decldebug -R/home/taura/workspaces/pbone/par_test.install/lib/mercury/lib --flags MDB_FLAGS browse_test > browse_test.err 2>&1
make: *** [browse_test.c_date] Error 1

pbone@taura:/home/taura/workspaces/pbone/par_test/browser$ less browse_test.err
browse_test.m:049: In clause for predicate `main'/2:
browse_test.m:049: error: undefined predicate `browse.browse'/8.
browse_test.m:052: In clause for predicate `main'/2:
browse_test.m:052: error: undefined predicate `browse.browse'/8.
browse_test.m:055: In clause for predicate `main'/2:
browse_test.m:055: error: undefined predicate `browse.browse'/8.

Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

176

[mercury] Bug

minor

have not tried

2010-12-16 01:51

2010-12-20 16:01

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:

incorrect install names on Mac OS X with mmake

Description:

The invocation of ml script in a .dep file on Mac OS X is incorrect.
For libmercury_www in extras the install name is set using the following:

-install_name "/Users/<etc etc>/libmercury_www.\$(EXT_FOR_SHARED_LIB)"

The $ sign should *not* be escaped.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

175

[mercury] Bug

minor

always

2010-12-13 17:58

2010-12-16 01:47

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:

incorrect foreign_decl pragmas in ODBC binding

Description:

The ODBC binding contains function prototypes for functions with static linkage
in non-local foreign_decl pragmas and various other abuses of the foreign language
interface.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

119

[mercury] Bug

minor

sometimes

2009-12-14 11:29

2010-12-13 17:27

Reporter:

pbone

Platform:

Assigned To:

pbone

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

par_conj/consume_wait test is failing in low-level C parallel grades.

Description:

The par_conj/consume_wait test is failing in low-level C parallel grades. I've tested this on goofy using the current CVS version and gcc 3.4. I don't remember noticing this on taura or goliath.

Tags:

Steps To Reproduce:

Additional Information:

{ [ -f consume_wait.inp ] && cat consume_wait.inp; } | MERCURY_OPTIONS=-P2 ./consume_wait > consume_wait.out 2>&1 || \
{ grep . consume_wait.out /dev/null; exit 1; }
Aborted
consume_wait.out:consume_wait: par_builtin.m:150: par_builtin_module2: Assertion `Future->MR_fut_signalled' failed.
consume_wait.out:1
make[5]: *** [consume_wait.out] Error 1
make[5]: Target `consume_wait.runtest' not remade because of errors.
make[5]: Leaving directory `/mnt/g12/goofy-workspaces/pbone/clean/tests/par_conj'
FAILED TEST par_conj/consume_wait in grade asm_fast.gc.par

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

170

[mercury] Bug

minor

have not tried

2010-11-26 15:40

2010-11-30 17:24

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 ssdb build failure on goliath

Description:

Building the stage 2 ssdb library with rotd-2010-11-24 fails on goliath, ssdb.err is:

Uncaught Mercury exception:
Software Error: var_locn.m: Unexpected: clobber_lval_in_var_state_map: empty state
Stack dump not available in this grade.

This in asm_fast.gc, with -O5 and --intermodule-optimisation.

The last working compiler on goliath was rotd-2010-10-19 (between then and now the machine
was down for about a week due to memory troubles).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

169

[mercury] Bug

minor

always

2010-11-15 13:57

Reporter:

mgiuca

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:

Lambda predicates do not allow references to existing variables in the head

Description:

I am not sure if this is a bug, or intentional, and if it is not intentional, I'm not sure whether it is worth "fixing", but I'll report it anyway.

The terminology I'm using is from section 2.8 (Rules) of the Mercury reference, where a function is defined as "Head = Result :- Body" and a predicate as "Head :- Body".

There seems to be an inconsistency with the way lambda predicates treat variable scoping. The compiler seems to scope variables with the following rules (for both lambda functions and lambda predicates):
1. Any name which appears in the Result and/or Body of a lambda term but not at all in the scope outside of the lambda is scoped locally to the lambda term.
2. Any name which appears in the Head of a lambda term is also scoped locally to the lambda term (and if it also appears in the scope outside the lambda, is treated as a distinct variable, shadowing the one outside).
3. Any name which does not appear in the Head, but does appear in the scope outside, is scoped to the closure outside the lambda term.

This basically mirrors the laws of lambda abstraction in the lambda calculus: variables appearing in the head are "bound" to the abstraction (and shadow other variables with the same name outside); variables not appearing in the head are "free" in the abstraction, and depend upon the name existing in an outer scope.

It means that code like this functions as expected:

:- pred add_list(int::in, list(int)::in, list(int)::out) is det.
add_list(X, L0, L) :-
    list.map((pred(A::in, B::out) is det :- B = A + X),
             L0, L).

Note the name X, which is scoped to the add_list predicate, appears in the Body of the lambda pred, referring to the same variable X.

However, rule 0000002 above doesn't make a lot of sense considering the semantics of predicates. Any data term appearing in the body of a predicate should have the same meaning if moved to the predicate's head. So the following definition should be equivalent:

:- pred add_list(int::in, list(int)::in, list(int)::out) is det.
add_list(X, L0, L) :-
    list.map((pred(A::in, A + X::out) is det), L0, L).

All I have done is replace the Head variable B (unified with A + X in the Body) with the expression A + X, directly in the Head. This produces the following compiler error:

In clause for predicate `lambdahead.add_list2'/3:
  warning: variable `X' occurs only once in this scope.
In clause for predicate `lambdahead.add_list2'/3:
  warning: variable `X' occurs only once in this scope.
In clause for `add_list2(in, in, out)':
in call to function `int.+'/2:
mode error: arguments `A, X, V_9' have the following insts:
   ground,
   free,
   free
which does not match any of the modes for function
`int.+'/2.

Basically, the fact that X now appears in the lambda's Head makes the lambda predicate treat it as a distinct variable to the outer-scoped variable also called X (as it would in the lambda calculus). The error message tells me that the two separate variables "X" each appear only one time, and that I am trying to do arithmetic on an unbound variable.

It is difficult to see how to properly "fix" this situation, if indeed it is considered to be broken. I would recommend changing the rule for lambda predicates (but not functions) such that variables appearing in the Head have the same scoping rules as those appearing in the Body -- they do not create a new variable if one already exists in the outer scope. However, this might break some existing code, and would make a new difference between predicates and functions. (The same rule would not make sense applied to functions.) So I acknowledge that it is a pretty difficult situation.

Although it might break existing code, it would always be possible for new code to be right: simply don't shadow existing variable names in lambda predicates.

Note that it would help if the reference manual made a mention of this rule. I can't find it in "Rules", "Variable scoping" or "Creating higher-order terms", which are the obvious places to look.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

lambdahead.m (556 bytes) 2010-11-15 13:57
https://bugs.mercurylang.org/file_download.php?file_id=110&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

168

[mercury] Bug

minor

always

2010-11-08 18:25

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:

prototypes of C functions used in io module not visible

Description:

The prototypes of various C functions use in the io module are not
visible when building on goliath (x86-64, Debian 5). (We need to ensure that __USE_XOPEN
etc is defined on this platform to make them visible.)

io.m: In function ‘io_module21’:
io.m:2790: warning: implicit declaration of function ‘fileno’
io.m: In function ‘io_module175’:
io.m:9860: warning: implicit declaration of function ‘putenv’
io.m: In function ‘io_module182’:
io.m:10590: warning: implicit declaration of function ‘symlink’
io.m: In function ‘io_module183’:
io.m:10647: warning: implicit declaration of function ‘readlink’
io.m: In function ‘io_module185’:
io.m:3006: warning: implicit declaration of function ‘lstat’
io.m: In function ‘mercury_init_io’:
io.m:6289: warning: implicit declaration of function ‘fdopen’

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:

167

[mercury] Bug

minor

always

2010-11-04 17:40

Reporter:

mgiuca

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:

bimap.init could be uo

Description:

The mode of bimap.init is:
:- func bimap.init = bimap(K, V).
:- pred bimap.init(bimap(K, V)::out) is det.

Note that the mode of map.init is:
:- pred map.init(map(_, _)::uo) is det.
:- func map.init = (map(K, V)::uo) is det.

For consistency, bimap.init's mode could be upgraded to uo, which shouldn't cause any problems:
:- func bimap.init = (bimap(K, V)::uo) is det.
:- pred bimap.init(bimap(K, V)::uo) is det.

(I've tried it and it compiles fine, as does code which depends on it.)

This would be useful for programs trying to use uniqueness where possible.

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:

166

[mercury] Bug

minor

always

2010-10-27 11:11

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:

inconsistent treatment of module-specific variables

Description:

mmc --make wants:

LIBRARIES-module = somelib

mmake wants:

# for executables
EXTRA_LIBRARIES-module = somelib
# for libraries
EXTRA_LIBRARIES-libmodule.so = somelib

Neither recognise "EXTRA_MCFLAGS-module". Both require "MCFLAGS-module". This is not clear in the user's guide.

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:

150

[mercury] Bug

minor

have not tried

2010-05-25 13:37

2010-09-15 14: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:

nit in error msg

Description:

From the BUGS file

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

Subject: nit in error msg
Date: Thu, 16 May 1996 10:25:42 +1000 (EST)

Here's another small error in an error message. If you comment out
the [] clause for the functions car/1 or cdr/1, you get this message:

fntest.m:023: In `car(in) = out':
fntest.m:023: Error: determinism declaration not satisfied.
fntest.m:023: Declared `det', inferred `semidet'.
fntest.m:023: in argument 1 of clause head:
fntest.m:023: unification of `HeadVar__1' and `[X | V_4]' can fail.

It says Declared `det', inferred `semidet', but I never declared it at
all. It's a bit misleading. Certainly not a major problem, and the
later part of the message makes it quite clear what the problem is,
but I thought I'd point it out to you before I forgot it.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

128

[mercury] Bug

minor

have not tried

2010-01-14 18:19

2010-09-15 12:29

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:

merge_instmapping_delta_2: error merging var 20

Description:

(This was originally reported by Michael Day on the mercury-bugs list; responses from
zs are included below as well.)

Hi,

The attached program triggers a compiler error when building with -O5:

Making Mercury/int3s/bug.int3
Making Mercury/ints/bug.int
Making Mercury/cs/bug.c
Uncaught Mercury exception:
Software Error: instmap.m: Unexpected: merge_instmapping_delta_2: error merging var 20

It succeeds at lower optimisation levels. Tested with rotd-2009-10-08 and rotd-2008-01-30.

Michael

============
Date: Mon, 9 Nov 2009 17:43:53 +1100
From: Zoltan Somogyi <zs@csse.unimelb.edu.au>
To: Michael Day <mikeday@yeslogic.com>
Cc: mercury-bugs@csse.unimelb.edu.au
Subject: Re: merge_instmapping_delta_2: error merging var 20

On 09-Nov-2009, Michael Day <mikeday@yeslogic.com> wrote:
> The attached program triggers a compiler error when building with -O5:
>
> Making Mercury/int3s/bug.int3
> Making Mercury/ints/bug.int
> Making Mercury/cs/bug.c
> Uncaught Mercury exception:
> Software Error: instmap.m: Unexpected: merge_instmapping_delta_2: error
> merging var 20
>
> It succeeds at lower optimisation levels. Tested with rotd-2009-10-08 and
> rotd-2008-01-30.

It also succeeds with -O5 --no-loop-invariants, and the exception is thrown
*during* the loop invariants pass. I think that makes this Ralph's to fix.

Zoltan.

=======
Hi Zoltan,

> It also succeeds with -O5 --no-loop-invariants, and the exception is thrown
> *during* the loop invariants pass. I think that makes this Ralph's to fix.

Suits me! :)

The bug can be worked around by creating lots of little helper predicates, although it is a bit tedious.

We always build with -O5 rather than waiting until just before release, as it's very frustrating to suddenly be hit with an unexpected internal compiler error.

Best regards,

Michael

--
Print XML with Prince!
http://www.princexml.com

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug.m (1,078 bytes) 2010-01-14 18:20
https://bugs.mercurylang.org/file_download.php?file_id=93&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

159

[mercury] Bug

minor

have not tried

2010-08-23 12:02

2010-09-14 20:38

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:

liveness.m: Unexpected: branches of switch disagree on liveness

Description:

From mercury-bugs

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

Dear all,

having bought a new notebook (the previous one was from 2003), I've also jump-updated everything to the state of the art. The joy of recompiling old things has just
begun and here are the first fruits:

rotd-2010-07-19 fails to compile the attached file (could be surely minimized yet a bit) with the following error:

22:56 bojar-nb src$mmc --make bug.o
Making Mercury/int3s/bug.int3
Making Mercury/cs/bug.c
Uncaught Mercury exception:
Software Error: liveness.m: Unexpected: branches of switch disagree on liveness
First: L_3, STATE_VARIABLE_P_4
Rest: STATE_VARIABLE_P_4

Stack dump not available in this grade.
** Error making `Mercury/cs/bug.c'.

Could you have a look at it? Disabling memoization solves it, but memoization alone is naturally fine. I guess it's the variable L where only the type and the value
is needed.

Cheers and warm greetings to everybody!
  Ondrej.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug.m (1,005 bytes) 2010-08-23 12:03
https://bugs.mercurylang.org/file_download.php?file_id=107&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

164

[mercury] Bug

minor

have not tried

2010-09-14 15:29

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:

problem with mmake -j32

Description:

From keri@gentoo.org on mercury-users

===================

Hi folks.

I've run into a hitch when bootstrapping mercury-10.04.1 on a linux-sparc box.
I'm attempting to bootstrap with mercury-10.04 where all C files need to be
rebuilt; I'm running a parallel compile with 32 submakes (it's a fast machine
:-)). It looks like building mercury_compile is failing due to race between
mmc generating .mih files and mgnuc compiling .c files that include the .mih
files.

>From './configure':

looking for an already installed Mercury compiler to bootstrap with...
checking for mmc... /usr/bin/mmc
checking whether the above mmc works and is sufficiently recent... yes
...
checking whether any C files need to be rebuilt...
there are no existing Mercury-generated C files

>From 'make':

/usr/bin/mmc --compile-to-c --grade hlc.gc --mercury-linkage static --
flags COMP_FLAGS transform_hlds.term_constr_data >
transform_hlds.term_constr_data.err 2>&1
/usr/bin/mmc --compile-to-c --grade hlc.gc --mercury-linkage static --
flags COMP_FLAGS transform_hlds.term_constr_main >
transform_hlds.term_constr_main.err 2>&1
/usr/bin/mmc --compile-to-c --grade hlc.gc --mercury-linkage static --
flags COMP_FLAGS transform_hlds.term_errors >
transform_hlds.term_errors.err 2>&1
...
../scripts/mgnuc --grade hlc.gc -- -c analysis.c -o analysis.o
analysis.c:116:47: error: transform_hlds.term_constr_data.mih: No such file or
directory
analysis.c:118:47: error: transform_hlds.term_constr_main.mih: No such file or
directory
analysis.c:119:42: error: transform_hlds.term_errors.mih: No such file or
directory
....

Without dialing things down to -j1, is there much I can do to workaround this
problem?


Thanks

Keri

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:

109

[mercury] Bug

minor

have not tried

2009-10-09 18:28

2010-09-14 12:23

Reporter:

janicek

Platform:

Darwin

Assigned To:

OS:

Mac OS X

Priority:

normal

OS Version:

10.5.8

Status:

resolved

Product Version:

Product Build:

rotd-2009-10-05

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

rotd-2009-10-05's library install fails for grade hlc

Description:

I'm installing Mercury rotd-2009-10-05, with libgrade hlc. "make" seems to run without problems, but while in "make install", I get the following message and the install terminates:

-- BEGIN SNIPPET
...
mmc --compile-to-c --grade hlc --mercury-linkage shared --flags LIB_FLAGS --flags INTER_FLAGS -R/Users/sandius/Developer/mercury-rotd-2009-10-05/lib/mercury/lib/hlc -R/Users/sandius/Developer/mercury-rotd-2009-10-05/lib/mercury/lib bit_buffer.read > bit_buffer.read.err 2>&1
mmc --make-optimization-interface --grade hlc --mercury-linkage shared --flags LIB_FLAGS --flags INTER_FLAGS -R/Users/sandius/Developer/mercury-rotd-2009-10-05/lib/mercury/lib/hlc -R/Users/sandius/Developer/mercury-rotd-2009-10-05/lib/mercury/lib bit_buffer.write
mmc --make-transitive-optimization-interface --grade hlc --mercury-linkage shared --flags LIB_FLAGS --flags INTER_FLAGS -R/Users/sandius/Developer/mercury-rotd-2009-10-05/lib/mercury/lib/hlc -R/Users/sandius/Developer/mercury-rotd-2009-10-05/lib/mercury/lib bit_buffer.write
mmc --compile-to-c --grade hlc --mercury-linkage shared --flags LIB_FLAGS --flags INTER_FLAGS -R/Users/sandius/Developer/mercury-rotd-2009-10-05/lib/mercury/lib/hlc -R/Users/sandius/Developer/mercury-rotd-2009-10-05/lib/mercury/lib bit_buffer.write > bit_buffer.write.err 2>&1
mmc --compile-to-c --grade hlc --mercury-linkage shared --flags LIB_FLAGS --flags INTER_FLAGS -R/Users/sandius/Developer/mercury-rotd-2009-10-05/lib/mercury/lib/hlc -R/Users/sandius/Developer/mercury-rotd-2009-10-05/lib/mercury/lib --no-warn-insts-without-matching-type --no-erlang-native-code bitmap > bitmap.err 2>&1
gmake[2]: *** [bitmap.c_date] Error 1
gmake[2]: Leaving directory `/Users/sandius/tmp/mercury-compiler-rotd-2009-10-05/install_grade_dir.hlc/library'
To clean up from failed install, remove /Users/sandius/tmp/mercury-compiler-rotd-2009-10-05/install_grade_dir.hlc
gmake[1]: *** [install_grades] Error 1
gmake[1]: Leaving directory `/Users/sandius/tmp/mercury-compiler-rotd-2009-10-05'
make: *** [install] Error 2

-- END SNIPPET --

$ cat install_grade_dir.hlc/library/bitmap.err
Uncaught Mercury exception:
Software Error: ml_disj_gen.m: Unexpected: ml_gen_disj: single disjunct

$ gcc --version
i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5566)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a
Darwin dfki-guestpool8.dfki.uni-sb.de 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

Configure command:
$ ./configure --prefix=$HOME/Developer/mercury-rotd-2009-10-05 --enable-libgrades=hlc

config.log attached.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

config.log (235,981 bytes) 2009-10-09 18:28
https://bugs.mercurylang.org/file_download.php?file_id=81&type=bug
bug109.m (1,611 bytes) 2009-10-12 12:34
https://bugs.mercurylang.org/file_download.php?file_id=82&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

154

[mercury] Bug

minor

always

2010-06-29 14:06

2010-08-25 13:58

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:

compiler abort with debugging enabled

Description:

Compiler aborts on test case with debugging enabled.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

some_bug.m (3,925 bytes) 2010-06-29 14:06
https://bugs.mercurylang.org/file_download.php?file_id=101&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

158

[mercury] Bug

minor

always

2010-08-18 14:31

2010-08-19 17:36

Reporter:

colanderman

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:

char constants do not unify

Description:

For some reason, this code:

if det_from_int(255) = '\xFF\' then print("succeed\n", !IO) else print("fail\n", !IO)

prints "fail". This code however:

if 255 = to_int('\xFF\') then print("succeed\n", !IO) else print("fail\n", !IO)

prints "succeed" as expected.

Tags:

Steps To Reproduce:

Additional Information:

Mercury 10.04, Debian Linux 32-bit

Attached Files:

charbug.m (326 bytes) 2010-08-18 14:31
https://bugs.mercurylang.org/file_download.php?file_id=106&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

137

[mercury] Bug

minor

always

2010-03-11 23:41

2010-07-21 14:37

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:

failing analysis framework tests

Description:

Many of the analysis framework tests abort with:

Making Mercury/analysiss/ua_m1.analysis
Uncaught Mercury exception:
Software Error: quantification.m: Unexpected: unify_rhs_vars_no_lambda: found lambda
Stack dump not available in this grade.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-07-08 16:14

2010-07-15 16:56

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:

mprof doesn't like duplicate names

Description:

mprof aborts on duplicate names in Prof.Decl. I get the following trying to profile the compiler. Manually differentiating the duplicate mercury__do_call_closure_* names allows mprof to proceed.

% mprof
Uncaught Mercury exception:
Software Error: map.det_insert: key already present
        Key Type: string
        Key Value: "mercury__do_call_closure_3"
        Value Type: int
Stack dump not available in this grade.

Tags:

Steps To Reproduce:

Additional Information:

Sample data attached.

Attached Files:

Prof.tar.bz2 (311,649 bytes) 2008-07-08 16:14
https://bugs.mercurylang.org/file_download.php?file_id=51&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

142

[mercury] Bug

minor

always

2010-04-06 15:07

2010-07-15 15:47

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:

problem updating rtti varmaps on inlining

Description:

In the following test case, higher order specialisation creates
`or__ho1' from of `or'.

We try to inline `or__ho1' into `orr'. In the call to `or__ho1' the
same variable `TypeClassInfo_for_dcg_14' appears twice in the argument
list, corresponding to the formal arguments V_22 and
TypeClassInfo_for_dcg_18 in the callee.

Eventually we try to rename the variables in the callee rtti varmap.
We hit an assertion failure in apply_substs_to_constraint_map
(hlds_rtti.m:777) as the two callee variables holding typeclass_infos
map to the same variable in the caller, and supposedly it is for two
different constraints. They are the same, just with different type
variables.

Is the fix to relax the assertion, or something else?

Tags:

Steps To Reproduce:

Additional Information:

% mmc --inline-single-use --optimise-higher-order dcg
Uncaught Mercury exception:
Software Error: hlds_rtti.m: Unexpected: inconsistent typeclass_infos
Stack dump follows:
   0 pred exception.throw/1-0 (erroneous) (exception.m:411)
   1 pred require.error/1-0 (erroneous) (require.m:122)
   2 pred libs.compiler_util.unexpected/2-0 (erroneous) (compiler_util.m:88)
   3 pred hlds.hlds_rtti.apply_substs_to_constraint_map/7-0 (det) (hlds_rtti.m:804)
   4 pred tree234.foldl/4-0 (det) (tree234.m:2625)
   5 pred map.foldl/4-0 (det) (map.m:962)
   6 pred hlds.hlds_rtti.apply_substitutions_to_rtti_varmaps/5-0 (det) (hlds_rtti.m:679)
   7 pred transform_hlds.inlining.do_inline_call/13-0 (det) (inlining.m:774)
   8 pred transform_hlds.inlining.inlining_in_call/11-0 (det) (inlining.m:652)
   9 pred transform_hlds.inlining.inlining_in_goal/4-0 (det) (inlining.m:558)
  10 pred transform_hlds.inlining.inlining_in_conj/4-0 (det) (inlining.m:860)
  11 pred transform_hlds.inlining.inlining_in_goal/4-0 (det) (inlining.m:571)
  12 2* pred transform_hlds.inlining.inlining_in_conj/4-0 (det) (inlining.m:860 and others)
  14 pred transform_hlds.inlining.inlining_in_goal/4-0 (det) (inlining.m:571)
  15 pred transform_hlds.inlining.inline_in_proc/5-0 (det) (inlining.m:489)
  16 3* pred transform_hlds.inlining.do_inlining/6-0 (det) (inlining.m:260 and others)
  19 pred transform_hlds.inlining.inlining/2-0 (det) (inlining.m:249)
  20 pred top_level.mercury_compile_middle_passes.maybe_do_inlining/6-0 (det) (mercury_compile_middle_passes.m:941)
  21 pred top_level.mercury_compile_middle_passes.middle_pass/7-0 (det) (mercury_compile_middle_passes.m:189)
  22 pred top_level.mercury_compile.mercury_compile_after_front_end/11-0 (det) (mercury_compile.m:1650)
  23 pred top_level.mercury_compile.mercury_compile/11-0 (det) (mercury_compile.m:1582)
  24 pred top_level.mercury_compile.compile/13-0 (det) (mercury_compile.m:1507)
  25 pred list.map_foldl2/7-2 (det) (list.m:2359)
  26 pred top_level.mercury_compile.compile_all_submodules/13-0 (det) (mercury_compile.m:1296)
  27 pred top_level.mercury_compile.process_module_2/8-0 (det) (mercury_compile.m:1269)
  28 pred top_level.mercury_compile.process_module/8-0 (det) (mercury_compile.m:1186)
  29 pred top_level.mercury_compile.process_arg_2/8-0 (det) (mercury_compile.m:882)
  30 pred top_level.mercury_compile.process_arg_build/10-0 (det) (mercury_compile.m:844)
  31 pred make.util.build_with_module_options_args_invoked/12-0 (det) (make.util.m:987)
  32 pred make.util.build_with_module_options_args/11-0 (det) (make.util.m:940)
  33 pred top_level.mercury_compile.process_arg/8-0 (det) (mercury_compile.m:817)
  34 pred top_level.mercury_compile.process_arg_list/10-0 (det) (mercury_compile.m:788)
  35 pred top_level.mercury_compile.process_args/8-0 (det) (mercury_compile.m:740)
  36 pred top_level.mercury_compile.process_all_args/8-0 (det) (mercury_compile.m:546)
  37 pred top_level.mercury_compile.main_after_setup/7-0 (det) (mercury_compile.m:422)
  38 pred top_level.mercury_compile.real_main_after_expansion/3-0 (det) (mercury_compile.m:308)
  39 pred top_level.mercury_compile.real_main/2-0 (det) (mercury_compile.m:118)
  40 pred top_level.main/2-0 (det) (top_level.m:56)

Attached Files:

dcg.m (1,474 bytes) 2010-04-06 15:07
https://bugs.mercurylang.org/file_download.php?file_id=99&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

155

[mercury] Bug

major

always

2010-07-07 17:51

2010-07-07 18:01

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:

Mode error with impure code.

Description:

I'm writing a failure driven loop that uses impurity to implement a branch and bound solver. The mode checker tells me that a value is 'free' when it should be (and is) 'ground'.

I will attach two programs that exhibit this error. Note that removing the switch on BestSolutionFinal and changing the type of the predicates output makes the problem go away.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug155a.m (2,863 bytes) 2010-07-07 17:58
https://bugs.mercurylang.org/file_download.php?file_id=103&type=bug
bug155b.m (2,709 bytes) 2010-07-07 18:01
https://bugs.mercurylang.org/file_download.php?file_id=104&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

153

[mercury] Bug

minor

always

2010-06-28 14:06

2010-07-06 23:51

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:

toc in pdf user's guide is empty

Description:

The TOC in the pdf version of the user's guide is empty.
This was reported against rotd-2010-06-23.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

152

[mercury] Bug

crash

always

2010-06-08 16:59

Reporter:

pbone

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:

Test cases crash the compiler in mmos grades.

Description:

The debugger/mmos_print test crashes the compiler in mmos grades.

Tags:

Steps To Reproduce:

Additional Information:

pbone@taura:/home/taura/workspaces/pbone/stseg_test/tests/debugger$ lmc --grade asm_fast.gc.mmos -O0 -v mmos_print.m
% Parsing file `mmos_print' and imported interfaces...
% Module qualifying items...
% done.
% Expanding equivalence types...
% done.
% Converting parse tree to hlds...
% done.
% Writing auto-dependency file `mmos_print.d'... done.
% 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.
% Checking stratification...
% done.
% Transforming try goals...
% done.
% Simplifying goals...
% done.
% Transforming tabled predicates...Uncaught Mercury exception:
Software Error: map.lookup: key not found
        Key Type: int
        Key Value: 0
        Value Type: hlds.hlds_pred.proc_info
Stack dump not available in this grade.

Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

149

[mercury] Bug

minor

have not tried

2010-05-25 13:36

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:

inter-module optimization and abstract exported equivalence types.

Description:

From the BUGS file

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

Subject: inter-module optimization and abstract exported equivalence types.
Date: Thu, 19 February 1998

In some cases the compiler reports spurious ambiguity errors when compiling
with `--intermodule-optimization'. This is due to the definition of abstract
exported equivalence types being made visible by inter-module optimization.
In this example, with `--intermodule-optimization' the compiler sees the
declaration `:- type var == int' from term.m and then cannot determine whether
`Elem' has type `int' or `pair(int)'.
The work-around is to add an explicit type qualification.

:- module foo.
:- interface.
:- import_module list, term.
:- pred test(list(var)::in) is det.
:- implementation.
:- import_module int, std_util.

test(Args0) :-
        MakeIndex =
                (pred(Elem0::in, Elem::out, Index0::in, Index::out) is det :-
                        Elem = Elem0 - Index0,
                        Index is Index0 + 1
        ),
        list.map_foldl(MakeIndex, Args0, _, 0, _).

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:

147

[mercury] Bug

minor

have not tried

2010-05-25 13: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:

NaN behaviour

Description:

From the BUGS file:

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

Subject: NaN behaviour
Date: Mon, 21 Oct 2002 21:02:00 +1000

The mercury standard library tends to avoid producing NaN (e.g. throwing
an exception in many places where libc would return NaN), but it's still
possible from arithmetic functions (e.g. 0.0*Inf, Inf - Inf, Inf + -Inf,
Inf / Inf), sin,cos,tan when passed infinity, and perhaps other things (I
haven't done a full search). Presumably it can also arise from using the
foreign language interface.

When NaN does arise, we have a problem that `=' (and unification) aren't
reflexive. From a logical point of view, this is a fairly serious problem.

A lesser problem is that `<' doesn't induce a total order on floats.

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:

143

[mercury] Bug

feature

always

2010-04-09 17:29

2010-05-20 19:02

Reporter:

rafe

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:

':- initialise' directives not being respected.

Description:

Compile the attached foo.m file and run it. It should output

map([(1 -> BAZ), (2 -> BAR), (3 -> BAZ)])

but unless the call to init_foo/2 in main/2 is uncommented out you get this:

map([(1 -> baz), (2 -> bar), (3 -> baz)])

The ':- initialise init_foo/2.' directive is not being respected.

This is a problem since I was hoping to use this functionality to debug the IC solver.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

foo.m (984 bytes) 2010-04-09 17:29
https://bugs.mercurylang.org/file_download.php?file_id=100&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

145

[mercury] Bug

major

always

2010-04-20 14:56

2010-04-21 14:57

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:

loop invariants broken

Description:

I wonder how long this bug has been present.

% mmc -O0 --loop-invariants ho_solns.m (from tests/hard_coded)
% ./ho_solns
4
4
4

should be:

4
5
6

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:

140

[mercury] Bug

text

N/A

2010-03-31 12:27

2010-04-01 18:36

Reporter:

mgiuca

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

acknowledged

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Manual section 10 doesn't mention existential types

Description:

Section 11 (existential types) mentions type class constraints on a) existential type variables in predicates and functions, and b) existential type variables in data type definitions.

However, section 10, which specifically details type class constraints, does not mention these at all. I found this particularly confusing when trying to find out how to put a type class constraint on a data type definition.

Since this is a reference manual, and not intended to be read cover-to-cover, it doesn't need to hide details just because they haven't been mentioned yet. I would recommend at least adding forward references:

- adding to section 10.5 a paragraph which states "Type constraints can also be applied to existential type variables, with the syntax "=> Typeclass(Type, ...), ...". See section 11.2."
- adding to section 10 a new section (between 10.7 and 10.8) called "Type class constraints on data type definitions", which simply has the text "Type constraints may also be applied to data type definitions, which may have existentially quantified type variables. See section 11.3."

For a more substantial rework, I would recommend swapping sections 10 and 11, and moving the type class discussion from the "Existential types" section to the "Type classes" section. This is because you can cover existential types without mentioning type classes, but you can't really cover type classes without mentioning existential types.

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:

141

[mercury] Bug

feature

N/A

2010-04-01 15:37

2010-04-01 18:32

Reporter:

mgiuca

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:

integer has no method for converting to int with wraparound

Description:

The integer.int function converts an integer to an int but aborts if the integer is out of range.

It is occasionally useful to convert an integer to an int with out-of-range numbers being wrapped (truncated) just like conversion from int to short in C, for example.

I have attached a patch which adds a function integer.int_with_overflow which does this.

Tags:

Steps To Reproduce:

Additional Information:

The patch sort-of relies upon two's complement (it would probably work for one's complement or sign-bit form as well, but does make some bit-level assumptions). I have included an XXX comment to this effect. I assume this is OK since there are other such comments in the same file.

Attached Files:

integer.patch (1,243 bytes) 2010-04-01 15:37
https://bugs.mercurylang.org/file_download.php?file_id=97&type=bug
integer-2.patch (1,249 bytes) 2010-04-01 18:09
https://bugs.mercurylang.org/file_download.php?file_id=98&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

139

[mercury] Bug

minor

have not tried

2010-03-23 11:25

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:

If mercury is installed in a directly with a '+' symbol in it's name, then mkinit will not work.

Description:

Using the recent 10.04 beta release I installed Mercury into /usr/local/mercury-10.04+beta1 (or similar). It installed correctly, and I created a symlink /usr/local/mercury to the installation directory because /usr/local/mercury/bin is in my $PATH.

Tags:

Steps To Reproduce:

Additional Information:

When I went to use mmc --make to compile a program. mkinit failed to find the .init files for the standard library and runtime (IIRC). Double quotes had been put around the path at some stage, but mkinit was literally trying to open a "/usr/local/mercury-10.04+beta1/..." with the double quotes as part of the file name. The ellipsis represents the actual path which I don't recall.

Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

138

[mercury] Bug

text

always

2010-03-15 06:30

2010-03-16 04:42

Reporter:

Jurassic

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:

Mistake in Language Reference, section 2.3

Description:

In section 2.3 (Terms) of the Language Reference, paragraph 7, "optionally followed by a vertical bar (i.e. a close_list token)" should probably read "optionally followed by a vertical bar (i.e. a ht_sep token)".

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

134

[mercury] Bug

minor

always

2010-03-03 15:45

2010-03-04 12:48

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:

abort in MLDS backend with --no-static-ground-terms

Description:

The attached program causes an abort while converting the HLDS -> MLDS.
See the comments at the head of the test case for details of how to reproduce.
This is occurring with Mercury rotd-2010-03-01.

Tags:

Steps To Reproduce:

Additional Information:

The problem in the test case is masked by dead procedure elimination.

Attached Files:

bug134.m (3,073 bytes) 2010-03-03 15:45
https://bugs.mercurylang.org/file_download.php?file_id=96&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

121

[mercury] Bug

major

always

2009-12-18 11:57

2010-02-27 18:22

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:

parallel grades do not build on Mac OS 10.6

Description:

The .par grades do not build on Mac 0S 10.6 due to the GC not building.

darwin_stop_world.c: In function 'GC_push_all_stacks':
darwin_stop_world.c:105: error: 'i386_thread_state_t' has no member named 'esp'
darwin_stop_world.c:107: error: 'i386_thread_state_t' has no member named 'eax'
darwin_stop_world.c:108: error: 'i386_thread_state_t' has no member named 'ebx'
darwin_stop_world.c:109: error: 'i386_thread_state_t' has no member named 'ecx'
darwin_stop_world.c:110: error: 'i386_thread_state_t' has no member named 'edx'
darwin_stop_world.c:111: error: 'i386_thread_state_t' has no member named 'edi'
darwin_stop_world.c:112: error: 'i386_thread_state_t' has no member named 'esi'
darwin_stop_world.c:113: error: 'i386_thread_state_t' has no member named 'ebp'
make[2]: *** [darwin_stop_world.o] Error 1
make[1]: *** [submake] Error 2
make: *** [boehm_gc] Error 2

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

133

[mercury] Bug

major

always

2010-02-12 16:10

2010-02-15 12:49

Reporter:

petdr

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:

Software Error: try_expand.m: Unexpected: find_subparts: unexpected goal form

Description:

The attached program throws the exception:

Software Error: try_expand.m: Unexpected: find_subparts: unexpected goal form

The problem is something to do with the duplicate call to q(X, !IO) once outside the try goal and once inside.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

try_test.m (326 bytes) 2010-02-12 16:10
https://bugs.mercurylang.org/file_download.php?file_id=95&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-10-19 09:30

2010-02-05 15:43

Reporter:

maclarty

Platform:

Assigned To:

maclarty

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

declarative debugger going up search tree when initial node trusted.

Description:

If the declarative debugger is started on a trusted node, all of whose children are trusted too, then it will start searching up the call tree. This is because it is assuming the node must be inadmissible (the node cannot be erroneous, because it is trusted, also it cannot be correct, because then why would the user have started the declarative debugger at that node in the first place?)

This behaviour can seem unintuitive.

There is an example of this behaviour in the following test:
tests/debugger/declarative/io_read_bug

Zoltan and I discussed the issue and agreed that the fix was to allow the user to assert whether the node was erroneous or inadmissible when they enter the dd command.

I now think a better solution is simply for the declarative debugger to say that it is searching up the call tree, because the node is trusted, so it is assuming it is inadmissible. A message like:

The call to io.read/3 and all its descendents are trusted, searching up the
call tree for an untrusted node..

This way you get the behaviour you want if you start the dd at a call to error and if you accidentally start it at a trusted node, you know immediately that the node is trusted, so you can then type "quit", untrust the predicate, and start again.

Zoltan, how does this sound to you?

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

127

[mercury] Bug

minor

always

2010-01-14 13:15

2010-02-05 14:13

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:

implementation defined constants don't work with try goals

Description:

The compiler aborts if the module contains a try goal that uses an implementation defined constant:

Software Error: hlds_code_util.m: Unexpected: cons_id_to_tag: implementation_defined_const

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:

132

[mercury] Bug

text

always

2010-02-02 14:52

2010-02-02 16:30

Reporter:

mgiuca

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:

Typo in make_hlds_warn ("ccur")

Description:

Small typo in a warning message in make_hlds_warn.

It prints "warning: variables `A, B' ccur more than once in this scope."
"ccur" should read "occur".

Attached & pasted below is a tiny patch.

--- compiler/make_hlds_warn.m 2009-09-08 18:14:40.000000000 +1000
+++ compiler/make_hlds_warn.m 2010-02-02 14:49:38.000000000 +1100
@@ -386,7 +386,7 @@
                 words("occurs more than once in this scope."), nl]
         ;
             MultiPieces = [words("warning: variables"), MultiVarsPiece,
- words("ccur more than once in this scope."), nl]
+ words("occur more than once in this scope."), nl]
         ),
         MultiMsg = simple_msg(goal_info_get_context(GoalInfo),
             [option_is_set(warn_singleton_vars, yes,

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

make_hlds_warn.m.patch (567 bytes) 2010-02-02 14:52
https://bugs.mercurylang.org/file_download.php?file_id=94&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-02-01 15:15

2010-02-02 16:23

Reporter:

juliensf

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

confirmed

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

RTTI looks for the name of a solver value return repn. type name

Description:

type_name(type_of(X)) where X is a solver type returns the name of the representation type
not the solver type itself. This will occurs even if the solver type is imported from another
module.

The attached test case demonstrates this problem.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

solver_type_name.m (467 bytes) 2008-02-01 15:15
https://bugs.mercurylang.org/file_download.php?file_id=34&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

100

[mercury] Bug

minor

always

2009-06-26 16:22

2010-02-02 16:21

Reporter:

petdr

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 report that a module is unused

Description:

If you have a typeclass

:- typeclass tc(T) <= tc2(T) where [...].
:- instance tc(unit).

Then the system needs to prove that tc2(unit) holds as well.

If you import a module which holds that fact and that is all the module is used for then the system incorrectly reports that module is unused.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

interface_import_bug.tar.bz2 (407 bytes) 2009-06-26 16:22
https://bugs.mercurylang.org/file_download.php?file_id=77&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

131

[mercury] Bug

minor

sometimes

2010-01-28 16:16

Reporter:

pbone

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:

Compilation fails when the same variable is used in two trace goals but not outside the trace goals.

Description:

The following code fails to compile

        trace [compile_time(flag("debug-dep-par-conj")), io(!IO)] (
            OutInfo = init_hlds_out_info(Globals),
            proc_info_get_varset(!.ProcInfo, VarSet),
            format("Pred/Proc: %s/%s before dep-par-conj:\n",
                [s(string(PredId)), s(string(ProcId))], !IO),
            write_goal(OutInfo, !.Goal, !.ModuleInfo, VarSet,
                yes, 0, "", !IO),
            nl(!IO)
        ),
        !:SyncInfo = sync_info(!.ModuleInfo, IgnoreVars, AllowSomePathsOnly,
            !.VarSet, !.VarTypes, proc(PredId, ProcId)),
        sync_dep_par_conjs_in_goal(!Goal, InstMap0, _, !SyncInfo),
        !.SyncInfo = sync_info(_, _, _, !:VarSet, !:VarTypes, _),
        % XXX RTTI varmaps may need to be updated

        trace [compile_time(flag("debug-dep-par-conj")), io(!IO)] (
            OutInfo = init_hlds_out_info(Globals),
            proc_info_get_varset(!.ProcInfo, VarSet),
            format("Pred/Proc: %s/%s after dep-par-conj:\n",
                [s(string(PredId)), s(string(ProcId))], !IO),
            write_goal(OutInfo, !.Goal, !.ModuleInfo, VarSet,
                yes, 0, "", !IO),
            nl(!IO)
        ),

With a confusing error message because the compiler doesn't understand that VarSet in each trace goal is local to that trace goal only. The compiler complains about a variable introduced in the state variable notation of !IO - which is incorrect.

The following code works as VarSet is produced outside of both trace goals.

        OutInfo = init_hlds_out_info(Globals),
        proc_info_get_varset(!.ProcInfo, VarSet),
        trace [compile_time(flag("debug-dep-par-conj")), io(!IO)] (
            format("Pred/Proc: %s/%s before dep-par-conj:\n",
                [s(string(PredId)), s(string(ProcId))], !IO),
            write_goal(OutInfo, !.Goal, !.ModuleInfo, VarSet,
                yes, 0, "", !IO),
            nl(!IO)
        ),
        !:SyncInfo = sync_info(!.ModuleInfo, IgnoreVars, AllowSomePathsOnly,
            !.VarSet, !.VarTypes, proc(PredId, ProcId)),
        sync_dep_par_conjs_in_goal(!Goal, InstMap0, _, !SyncInfo),
        !.SyncInfo = sync_info(_, _, _, !:VarSet, !:VarTypes, _),
        % XXX RTTI varmaps may need to be updated

        trace [compile_time(flag("debug-dep-par-conj")), io(!IO)] (
            format("Pred/Proc: %s/%s after dep-par-conj:\n",
                [s(string(PredId)), s(string(ProcId))], !IO),
            write_goal(OutInfo, !.Goal, !.ModuleInfo, VarSet,
                yes, 0, "", !IO),
            nl(!IO)
        ),

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

text

always

2009-05-28 12:14

2010-01-27 17:06

Reporter:

pbone

Platform:

Assigned To:

rafe

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

some predicates parsing_utils are documented with arguments in an incorrect order.

Description:

Some documentation comments in parsing_utils don't match the actual order of the aguments of the predicate.

Tags:

Steps To Reproduce:

Additional Information:

For example:

    % keyword(Src, IdChars, Keyword, _, !PS) matches Keyword exactly (i.e., it
    % must not be followed by any character in IdChars) and any subsequent
    % whitespace.
    %
  :- pred keyword(string::in, string::in, src::in, unit::out,
       ps::in, ps::out) is semidet.

Above the src argument has the third place in the type declaration (which is correct making this easy to use as a curried higher order argument to other predicates), while the documentation places this argument in the first place.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

126

[mercury] Bug

major

always

2010-01-12 11:10

2010-01-25 17:08

Reporter:

petdr

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:

unable to build asm_fast.gc.stseg grade under cygwin

Description:

mgnuc --grade asm_fast.gc.stseg --c-debug --no-ansi -- -c mercury_stacks.c -o mercury_stacks.o
mercury_stacks.c: In function `MR_rewind_nondetstack_segments':
mercury_stacks.c:330: error: structure has no member named `MR_zone_redzone'
make[2]: *** [mercury_stacks.o] Error 1

The problem is that MR_zone_redzone is only defined if one can use mprotect to check for overflow, which one cannot do on cygwin.

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:

129

[mercury] Bug

minor

always

2010-01-18 11:50

2010-01-25 16:29

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:

java grade generates uncompilable code for some uses of typeclasses

Description:

From Max:

"For your information,
I have a bug in the Java BE of Mercury.
It all compiles at the Mercury level (it even works in the asm grade),
but the java compilers complains of:

Making Java class files
Mercury/java/x86_64-unknown-linux-gnu/Mercury/javas/jmercury/sewol.java:5471: inconvertible types
found : jmercury.runtime.TypeCtorInfo_Struct
required: java.lang.Object[]
      TypeClassInfo_for_workflow_case_238 = (/* typeclass_info */ java.lang.Object[]) unit.unit__type_ctor_info_unit_0;
                                                                                          ^
"

Tags:

Steps To Reproduce:

Additional Information:

I haven't been able to pull a small test case from our tangled web of proprietary code yet.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

122

[mercury] Bug

minor

always

2009-12-18 20:18

2010-01-18 18:33

Reporter:

mva

Platform:

Assigned To:

mark

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Functional dependency typeclass instance in module with sub-module int0 error

Description:

I experience a bug in the Mercury compiler to do with int0 and typeclass instances.

If you have an abstract typeclass instance in a module which has a sub-module, the int0 file has two instances declaration, which can lead to a self-conflicting declaration.

Mercury/int0s/tcin.int0:011: Inconsistent instance declaration for typeclass
Mercury/int0s/tcin.int0:011: `tc.tc'/2 with functional dependency `(A -> B)'.
Mercury/int0s/tcin.int0:008: Here is the conflicting instance.
** Error making `Mercury/cs/tcin.sub.c'.

While there is no conflicting typeclass instance.

You can find attached a small test case exposing this bug.

Commenting the include_module tcin.sub in tcin.m is sufficient to make it compile properly.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

tcinsub.zip (975 bytes) 2009-12-18 20:18
https://bugs.mercurylang.org/file_download.php?file_id=91&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

123

[mercury] Bug

minor

always

2009-12-18 20:25

2010-01-12 14:12

Reporter:

mva

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:

typeclass instance clause type mix.

Description:

In a typeclass instance, when the clause of a predicate is defined
directly in the instance, qualifying certain types result in the compiler mixing up types.

See the attached example, where simply adding :_ to a type makes the compiler
complain about wrong typing;
while doing the same but with the predicate defined outside the instance (via pred(...) is) works perfectly fine.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

test1.m (640 bytes) 2009-12-18 20:25
https://bugs.mercurylang.org/file_download.php?file_id=92&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

102

[mercury] Bug

minor

always

2009-07-28 13:23

2009-12-17 00:52

Reporter:

user185

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:

Inconsistent behaviour (error vs. warning) when compiling with --make

Description:

The attached source file contains a simple "hello world" application.
It specifies a module "mprojects" which is different from the name of the source file "mproject".

The following behaviour results when compiling directly:
13:17 dharabor@armitage build>mmc mproject.m
mproject.m:001: Warning: source file `mproject.m' contains module named
mproject.m:001: `mprojects'.

However, compiling with "mmc --make":
13:20 dharabor@armitage build>mmc --make mproject
Making Mercury/cs/mproject.c
Error: file `mproject.m' contains the wrong module.
Expected module `mproject', found module `mprojects'.
mproject.m:001: Warning: source file `mproject.m' contains module named
mproject.m:001: `mprojects'.
** Error making `Mercury/cs/mproject.c'.

Which is correct? Is this an error or a warning?

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

mproject.m (181 bytes) 2009-07-28 13:23
https://bugs.mercurylang.org/file_download.php?file_id=78&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

118

[mercury] Bug

minor

always

2009-12-04 17:10

2009-12-16 09:18

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:

table_reset predicates omitted in non-tabling grades

Description:

Table reset predicates are not generated in grades that don't support tabling, causing problems for code that must be portable to other grades. The solution is probably to generate dummy predicates when tabling is not supported.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

major

always

2007-10-05 13:25

2009-12-11 06:46

Reporter:

pjrm

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:

wrong variable scoping in `if ( some[X] p(X) ) then q(X) ...'

Description:

:- module ifsome.
:- interface.
:- import_module io.
:- pred main(io::di, io::uo) is det.
:- implementation.
:- import_module string.
main(!IO):-
        X = "outer",
        ( if ( some[X] X = "inner" ) then
                io.write_string(X, !IO),
                io.nl(!IO)
         else
                true
        ).

This prints "inner", but one would expect it to print "outer" (both from one's expectations from standard predicate logic notation and from the point of view of the Mercury reference manual: "some Vars Goal ... The variables in Vars are local to the goal Goal", and the definition of if-then-else says nothing to contradict that: its statement about the declarative semantics of if-then-else is false for this example, or at least (if we want an example that still compiles after the transformation) for similar examples not involving I/O in the then/else goals).

Fixing this bug is made harder by the fact that an example program in mercury_faq.texi depends on this behaviour (at least in absence of parens around the `some' goal): search for `if some'.

In the example I've given, the severity of the bug is reduced by the fact that we get an `unused variable' warning (or a `shadowed variable' warning if we add another use of X). However, it is possible to construct examples that don't produce warnings by not having X outside of the if-then-else but where the behaviour differs according to whether X is bound or free on entry to the `then' goal (e.g. if the if-then-else is in semidet context and the `then' goal is `generate(X), test(X)'; and a similar generate(X),test(X) construct in the condition to avoid appears-only-once warning/objection). (I can send a 40-line example if that's useful, it's just not as succinct as the above.)

This bug doesn't arise all that often, but is nevertheless a "psychologically" important bug, in that it results in a program that gives a wrong result rather than abort; it attacks Mercury's claim to logical consistency and ease of reasoning about program behaviour.

pjrm.

Tags:

Steps To Reproduce:

Additional Information:

I haven't checked a current ROTD.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

crash

always

2008-08-16 05:06

2009-12-01 01:57

Reporter:

michael_george_hart

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:

make install issues with mercury-compiler-rotd-2008-08-14

Description:

Since I really don't know I report this as major

make install always end in failure

on OpenSUSe 10.3

Tags:

Steps To Reproduce:

Additional Information:

[ -d /usr/local/mercury-rotd-2008-08-14/lib/mercury/conf ] || mkdir -p /usr/local/mercury-rotd-2008-08-14/lib/mercury/conf
[ -d /usr/local/mercury-rotd-2008-08-14/lib/mercury/reconf/runtime ] || \
                mkdir -p /usr/local/mercury-rotd-2008-08-14/lib/mercury/reconf/runtime
cat `vpath_find mercury.c mercury_accurate_gc.c mercury_agc_debug.c mercury_atomic_ops.c mercury_backjump.c mercury_bootstrap.c mercury_builtin_types.c mercury_bitmap.c mercury_construct.c mercury_context.c mercury_debug.c mercury_deconstruct.c mercury_deep_copy.c mercury_deep_profiling.c mercury_dlist.c mercury_dummy.c mercury_engine.c mercury_file.c mercury_float.c mercury_getopt1.c mercury_getopt.c mercury_grade.c mercury_hash_table.c mercury_heap_profile.c mercury_ho_call.c mercury_label.c mercury_layout_util.c mercury_memory.c mercury_memory_handlers.c mercury_memory_zones.c mercury_minimal_model.c mercury_misc.c mercury_mm_own_stacks.c mercury_prof.c mercury_profiling_builtin.c mercury_prof_mem.c mercury_prof_time.c mercury_region.c mercury_regs.c mercury_reg_workarounds.c mercury_runtime_util.c mercury_signal.c mercury_stacks.c mercury_stack_layout.c mercury_stack_trace.c mercury_stm.c mercury_string.c mercury_tabling.c mercury_term_size.c mercury_thread.c mercury_timing.c mercury_trace_base.c mercury_trace_term.c mercury_trail.c mercury_type_desc.c mercury_type_info.c mercury_type_tables.c mercury_wrapper.c mercury_wsdeque.c` | grep '^INIT ' > mer_rt.init
cp `vpath_find mer_rt.init` /usr/local/mercury-rotd-2008-08-14/lib/mercury/modules/hlc.gc
cp `vpath_find libmer_rt.a \
                libmer_rt.so` \
                /usr/local/mercury-rotd-2008-08-14/lib/mercury/lib/hlc.gc
ranlib /usr/local/mercury-rotd-2008-08-14/lib/mercury/lib/hlc.gc/libmer_rt.a
gmake[2]: Leaving directory `/mnt/sde/home/XMan/Projects/Mecury/mercury-compiler-rotd-2008-08-14/install_grade_dir.hlc.gc/runtime'
gmake[2]: Entering directory `/mnt/sde/home/XMan/Projects/Mecury/mercury-compiler-rotd-2008-08-14/install_grade_dir.hlc.gc/library'
../Mmake.common:455: warning: undefined variable `mer_std.mhs'
../Mmake.common:458: warning: undefined variable `mer_std.mhs'
../Mmake.common:464: warning: undefined variable `mer_std.os'
/tmp/mmake.p15309:964: warning: undefined variable `mer_std.trans_opts'
/tmp/mmake.p15309:968: warning: undefined variable `mer_std.ms'
/tmp/mmake.p15309:976: warning: undefined variable `mer_std.ms'
/tmp/mmake.p15309:996: warning: undefined variable `mer_std.os'
/tmp/mmake.p15309:997: warning: undefined variable `mer_std.cs'
/tmp/mmake.p15309:998: warning: undefined variable `mer_std.ss'
/tmp/mmake.p15309:999: warning: undefined variable `mer_std.pic_ss'
/tmp/mmake.p15309:1000: warning: undefined variable `mer_std.ils'
/tmp/mmake.p15309:1001: warning: undefined variable `mer_std.javas'
/tmp/mmake.p15309:1157: warning: undefined variable `mer_std.os'
mmc --generate-dependencies --grade hlc.gc --mercury-linkage shared --flags LIB_FLAGS --flags INTER_FLAGS -R/usr/local/mercury-rotd-2008-08-14/lib/mercury/lib/hlc.gc -R/usr/local/mercury-rotd-2008-08-14/lib/mercury/lib --no-warn-nothing-exported --no-warn-unused-imports mer_std

*** Mercury runtime: caught segmentation violation ***
cause: address not mapped to object
address involved: (nil)
This may have been caused by a stack overflow, due to unbounded recursion.
exiting from signal handler
gmake[2]: *** [mer_std.depend] Error 1
gmake[2]: Leaving directory `/mnt/sde/home/XMan/Projects/Mecury/mercury-compiler-rotd-2008-08-14/install_grade_dir.hlc.gc/library'
To clean up from failed install, remove /mnt/sde/home/XMan/Projects/Mecury/mercury-compiler-rotd-2008-08-14/install_grade_dir.hlc.gc
gmake[1]: *** [install_grades] Error 1
gmake[1]: Leaving directory `/mnt/sde/home/XMan/Projects/Mecury/mercury-compiler-rotd-2008-08-14'
make: *** [install] Error 2

Attached Files:

Notes

I did as was recommended,

./configure --with-llds-base-grade=reg --with-default-grade=hlc.gc

but this time with this time with "mercury-compiler-rotd-2008-08-16"

then I did
>make
...
>su
...
>make install
..
and got the following; which looks like what I was getting before
cp `vpath_find mer_rt.init` /usr/local/mercury-rotd-2008-08-16/lib/mercury/modules/hlc.gc
cp `vpath_find libmer_rt.a \
libmer_rt.so` \
/usr/local/mercury-rotd-2008-08-16/lib/mercury/lib/hlc.gc
ranlib /usr/local/mercury-rotd-2008-08-16/lib/mercury/lib/hlc.gc/libmer_rt.a
gmake[2]: Leaving directory `/mnt/sde/home/XMan/Projects/Mecury/mercury-compiler-rotd-2008-08-16/install_grade_dir.hlc.gc/runtime'
gmake[2]: Entering directory `/mnt/sde/home/XMan/Projects/Mecury/mercury-compiler-rotd-2008-08-16/install_grade_dir.hlc.gc/library'
../Mmake.common:455: warning: undefined variable `mer_std.mhs'
../Mmake.common:458: warning: undefined variable `mer_std.mhs'
../Mmake.common:464: warning: undefined variable `mer_std.os'
/tmp/mmake.L24133:964: warning: undefined variable `mer_std.trans_opts'
/tmp/mmake.L24133:968: warning: undefined variable `mer_std.ms'
/tmp/mmake.L24133:976: warning: undefined variable `mer_std.ms'
/tmp/mmake.L24133:996: warning: undefined variable `mer_std.os'
/tmp/mmake.L24133:997: warning: undefined variable `mer_std.cs'
/tmp/mmake.L24133:998: warning: undefined variable `mer_std.ss'
/tmp/mmake.L24133:999: warning: undefined variable `mer_std.pic_ss'
/tmp/mmake.L24133:1000: warning: undefined variable `mer_std.ils'
/tmp/mmake.L24133:1001: warning: undefined variable `mer_std.javas'
/tmp/mmake.L24133:1157: warning: undefined variable `mer_std.os'
mmc --generate-dependencies --grade hlc.gc --mercury-linkage shared --flags LIB_FLAGS --flags INTER_FLAGS -R/usr/local/mercury-rotd-2008-08-16/lib/mercury/lib/hlc.gc -R/usr/local/mercury-rotd-2008-08-16/lib/mercury/lib --no-warn-nothing-exported --no-warn-unused-imports mer_std
GC Warning: Out of Memory! Returning NIL!

*** Mercury runtime: caught segmentation violation ***
cause: address not mapped to object
address involved: (nil)
This may have been caused by a stack overflow, due to unbounded recursion.
exiting from signal handler
gmake[2]: *** [mer_std.depend] Error 1
gmake[2]: Leaving directory `/mnt/sde/home/XMan/Projects/Mecury/mercury-compiler-rotd-2008-08-16/install_grade_dir.hlc.gc/library'
To clean up from failed install, remove /mnt/sde/home/XMan/Projects/Mecury/mercury-compiler-rotd-2008-08-16/install_grade_dir.hlc.gc
gmake[1]: *** [install_grades] Error 1
gmake[1]: Leaving directory `/mnt/sde/home/XMan/Projects/Mecury/mercury-compiler-rotd-2008-08-16'
make: *** [install] Error 2

config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.59. Invocation command line was

  $ ./configure --with-llds-base-grade=reg --with-default-grade=hlc.gc

## --------- ##
## Platform. ##
## --------- ##

hostname = XMan-3
uname -m = x86_64
uname -r = 2.6.22.18-0.2-default
uname -s = Linux
uname -v = 0000001 SMP 2008-06-09 13:53:20 +0200

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch = x86_64
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown

PATH: /usr/local/mercury-rotd-2008-08-16/bin
PATH: /opt/kde3/bin
PATH: /usr/local/mercury-rotd-2008-08-14/bin
PATH: /home/XMan/bin
PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/bin/X11
PATH: /usr/X11R6/bin
PATH: /usr/games
PATH: /usr/lib/mit/bin
PATH: /usr/lib/mit/sbin
PATH: /usr/lib/qt3/bin

## ----------- ##
## Core tests. ##
## ----------- ##

configure:1489: checking build system type
configure:1507: result: x86_64-unknown-linux-gnu
configure:1515: checking host system type
configure:1529: result: x86_64-unknown-linux-gnu
configure:1579: checking for cygpath
configure:1606: result: echo
configure:1615: checking for cygpath
configure:1642: result: echo
configure:1741: checking for mmc
configure:1759: found /usr/local/mercury-rotd-2008-08-16/bin/mmc
configure:1771: result: /usr/local/mercury-rotd-2008-08-16/bin/mmc
configure:1779: checking whether the above mmc works and is sufficiently recent
/usr/local/mercury-rotd-2008-08-16/bin/mmc conftest

*** Mercury runtime: caught segmentation violation ***
cause: address not mapped to object
address involved: (nil)
This may have been caused by a stack overflow, due to unbounded recursion.
exiting from signal handler
configure:1938: result: no
configure:2009: checking whether to enable large heaps when using conservative GC
configure:2013: result: yes
configure:2045: checking whether to enable unmapping of unused pages when using Boehm GC
configure:2055: result: no
configure:2083: checking for GCC source directory
configure:2117: result: not_found
configure:2119: checking whether to enable the GCC back-end interface
configure:2162: result: no
configure:2176: checking for gmake
configure:2192: found /usr/bin/gmake
configure:2202: result: gmake
configure:2239: checking for mkfifo
configure:2257: found /usr/bin/mkfifo
configure:2269: result: /usr/bin/mkfifo
configure:2363: checking for mktemp
configure:2381: found /bin/mktemp
configure:2393: result: /bin/mktemp
configure:2422: checking for install-info
configure:2440: found /usr/bin/install-info
configure:2452: result: /usr/bin/install-info
configure:2472: checking for texi2dvi
configure:2490: found /usr/bin/texi2dvi
configure:2502: result: /usr/bin/texi2dvi
configure:2515: checking for pdftex
configure:2533: found /usr/bin/pdftex
configure:2545: result: /usr/bin/pdftex
configure:2556: checking for lynx
configure:2589: result: no
configure:2597: checking for dvips
configure:2615: found /usr/bin/dvips
configure:2627: result: /usr/bin/dvips
configure:2638: checking for makeinfo
configure:2656: found /usr/bin/makeinfo
configure:2668: result: /usr/bin/makeinfo
configure:2679: checking for info
configure:2697: found /usr/bin/info
configure:2709: result: /usr/bin/info
configure:2720: checking for perl
configure:2738: found /usr/bin/perl
configure:2750: result: /usr/bin/perl
configure:2761: checking for hostname
configure:2779: found /bin/hostname
configure:2791: result: /bin/hostname
configure:2866: checking for gcc
configure:2882: found /usr/bin/gcc
configure:2892: result: gcc
configure:3136: checking for C compiler version
configure:3139: gcc --version </dev/null >&5
gcc (GCC) 4.2.1 (SUSE Linux)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3142: $? = 0
configure:3144: gcc -v </dev/null >&5
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.2 --enable-version-specific-runtime-libs --without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Thread model: posix
gcc version 4.2.1 (SUSE Linux)
configure:3147: $? = 0
configure:3149: gcc -V </dev/null >&5
gcc: '-V' option must have argument
configure:3152: $? = 1
configure:3175: checking for C compiler default output file name
configure:3178: gcc conftest.c >&5
configure:3181: $? = 0
configure:3227: result: a.out
configure:3232: checking whether the C compiler works
configure:3238: ./a.out
configure:3241: $? = 0
configure:3258: result: yes
configure:3265: checking whether we are cross compiling
configure:3267: result: no
configure:3270: checking for suffix of executables
configure:3272: gcc -o conftest conftest.c >&5
configure:3275: $? = 0
configure:3300: result:
configure:3306: checking for suffix of object files
configure:3327: gcc -c conftest.c >&5
configure:3330: $? = 0
configure:3352: result: o
configure:3356: checking whether we are using the GNU C compiler
configure:3380: gcc -c conftest.c >&5
configure:3386: $? = 0
configure:3389: test -z || test ! -s conftest.err
configure:3392: $? = 0
configure:3395: test -s conftest.o
configure:3398: $? = 0
configure:3411: result: yes
configure:3417: checking whether gcc accepts -g
configure:3438: gcc -c -g conftest.c >&5
configure:3444: $? = 0
configure:3447: test -z || test ! -s conftest.err
configure:3450: $? = 0
configure:3453: test -s conftest.o
configure:3456: $? = 0
configure:3467: result: yes
configure:3484: checking for gcc option to accept ANSI C
configure:3554: gcc -c -g -O2 conftest.c >&5
configure:3560: $? = 0
configure:3563: test -z || test ! -s conftest.err
configure:3566: $? = 0
configure:3569: test -s conftest.o
configure:3572: $? = 0
configure:3590: result: none needed
configure:3608: gcc -c -g -O2 conftest.c >&5
conftest.c:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'me'
configure:3614: $? = 1
configure: failed program was:
| #ifndef __cplusplus
| choke me
| #endif
configure:3746: checking whether C compiler needs -no-cpp-precomp
configure:3764: result: no
configure:3871: checking whether we can use -fno-strict-aliasing
configure:3876: result: yes
configure:3879: checking whether we need to use -fno-strict-aliasing
configure:3890: result: yes
configure:3916: checking whether to pass -I/usr/local/include to C compiler
configure:3925: result: no
configure:3945: checking whether to pass -L/usr/local/lib to the linker
configure:3955: result: no
configure:3975: checking how to run the C preprocessor
configure:4010: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:4016: $? = 0
configure:4048: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
conftest.c:13:28: error: ac_nonexistent.h: No such file or directory
configure:4054: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define MR_FULLARCH "x86_64-unknown-linux-gnu"
| #define MR_VERSION "rotd-2008-08-16"
| #define MR_MKFIFO "/usr/bin/mkfifo"
| #define MR_HOSTNAMECMD "/bin/hostname -f"
| /* end confdefs.h. */
| #include <ac_nonexistent.h>
configure:4093: result: gcc -E
configure:4117: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:4123: $? = 0
configure:4155: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
conftest.c:13:28: error: ac_nonexistent.h: No such file or directory
configure:4161: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define MR_FULLARCH "x86_64-unknown-linux-gnu"
| #define MR_VERSION "rotd-2008-08-16"
| #define MR_MKFIFO "/usr/bin/mkfifo"
| #define MR_HOSTNAMECMD "/bin/hostname -f"
| /* end confdefs.h. */
| #include <ac_nonexistent.h>
configure:4207: checking for egrep
configure:4217: result: grep -E
configure:4222: checking for use of a Microsoft C compiler
configure:4252: result: no
configure:4388: checking for ranlib
configure:4404: found /usr/bin/ranlib
configure:4415: result: ranlib
configure:4466: checking for sin in -lm
configure:4496: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c -lm >&5
conftest.c:20: warning: conflicting types for built-in function 'sin'
configure:4502: $? = 0
configure:4505: test -z || test ! -s conftest.err
configure:4508: $? = 0
configure:4511: test -s conftest
configure:4514: $? = 0
configure:4527: result: yes
configure:4584: checking for ilasm
configure:4602: found /usr/bin/ilasm
configure:4614: result: /usr/bin/ilasm
configure:4623: checking for gacutil
configure:4641: found /usr/bin/gacutil
configure:4653: result: /usr/bin/gacutil
configure:4661: checking for Microsoft.NET Framework SDK
configure:4679: result: yes
configure:4690: checking for csc
configure:4723: result: no
configure:4690: checking for cscc
configure:4723: result: no
configure:4783: checking for al
configure:4801: found /usr/bin/al
configure:4813: result: /usr/bin/al
configure:4846: checking for jikes
configure:4879: result: no
configure:4846: checking for javac
configure:4864: found /usr/bin/javac
configure:4876: result: /usr/bin/javac
configure:4891: checking for java
configure:4924: result: no
configure:4930: checking for jar
configure:4948: found /usr/bin/jar
configure:4960: result: /usr/bin/jar
configure:5096: checking for erlc
configure:5129: result: no
configure:5191: checking for erl
configure:5224: result: no
configure:5253: checking for sysconf
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for getpagesize
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for gethostname
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for mprotect
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for memalign
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for posix_memalign
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for memmove
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
conftest.c:43: warning: conflicting types for built-in function 'memmove'
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for sigaction
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for siginterrupt
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for setitimer
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for snprintf
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
conftest.c:47: warning: conflicting types for built-in function 'snprintf'
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for _snprintf
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
/tmp/cce9PdSY.o: In function `main':
conftest.c:(.text+0x7): undefined reference to `_snprintf'
/tmp/cce9PdSY.o:(.data+0x0): undefined reference to `_snprintf'
collect2: ld returned 1 exit status
configure:5316: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define MR_FULLARCH "x86_64-unknown-linux-gnu"
| #define MR_VERSION "rotd-2008-08-16"
| #define MR_MKFIFO "/usr/bin/mkfifo"
| #define MR_HOSTNAMECMD "/bin/hostname -f"
| #define MR_HAVE_SYSCONF 1
| #define MR_HAVE_GETPAGESIZE 1
| #define MR_HAVE_GETHOSTNAME 1
| #define MR_HAVE_MPROTECT 1
| #define MR_HAVE_MEMALIGN 1
| #define MR_HAVE_POSIX_MEMALIGN 1
| #define MR_HAVE_MEMMOVE 1
| #define MR_HAVE_SIGACTION 1
| #define MR_HAVE_SIGINTERRUPT 1
| #define MR_HAVE_SETITIMER 1
| #define MR_HAVE_SNPRINTF 1
| /* end confdefs.h. */
| /* Define _snprintf to an innocuous variant, in case <limits.h> declares _snprintf.
| For example, HP-UX 11i <limits.h> declares gettimeofday. */
| #define _snprintf innocuous__snprintf
|
| /* System header to define __stub macros and hopefully few prototypes,
| which can conflict with char _snprintf (); below.
| Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
| <limits.h> exists even on freestanding compilers. */
|
| #ifdef __STDC__
| # include <limits.h>
| #else
| # include <assert.h>
| #endif
|
| #undef _snprintf
|
| /* Override any gcc2 internal prototype to avoid an error. */
| #ifdef __cplusplus
| extern "C"
| {
| #endif
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char _snprintf ();
| /* The GNU C library defines this for functions which it implements
| to always fail with ENOSYS. Some functions are actually named
| something starting with __ and the normal name is an alias. */
| #if defined (__stub__snprintf) || defined (__stub____snprintf)
| choke me
| #else
| char (*f) () = _snprintf;
| #endif
| #ifdef __cplusplus
| }
| #endif
|
| int
| main ()
| {
| return f != _snprintf;
| ;
| return 0;
| }
configure:5340: result: no
configure:5253: checking for vsnprintf
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
conftest.c:48: warning: conflicting types for built-in function 'vsnprintf'
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for _vsnprintf
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
/tmp/ccCZIMib.o: In function `main':
conftest.c:(.text+0x7): undefined reference to `_vsnprintf'
/tmp/ccCZIMib.o:(.data+0x0): undefined reference to `_vsnprintf'
collect2: ld returned 1 exit status
configure:5316: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define MR_FULLARCH "x86_64-unknown-linux-gnu"
| #define MR_VERSION "rotd-2008-08-16"
| #define MR_MKFIFO "/usr/bin/mkfifo"
| #define MR_HOSTNAMECMD "/bin/hostname -f"
| #define MR_HAVE_SYSCONF 1
| #define MR_HAVE_GETPAGESIZE 1
| #define MR_HAVE_GETHOSTNAME 1
| #define MR_HAVE_MPROTECT 1
| #define MR_HAVE_MEMALIGN 1
| #define MR_HAVE_POSIX_MEMALIGN 1
| #define MR_HAVE_MEMMOVE 1
| #define MR_HAVE_SIGACTION 1
| #define MR_HAVE_SIGINTERRUPT 1
| #define MR_HAVE_SETITIMER 1
| #define MR_HAVE_SNPRINTF 1
| #define MR_HAVE_VSNPRINTF 1
| /* end confdefs.h. */
| /* Define _vsnprintf to an innocuous variant, in case <limits.h> declares _vsnprintf.
| For example, HP-UX 11i <limits.h> declares gettimeofday. */
| #define _vsnprintf innocuous__vsnprintf
|
| /* System header to define __stub macros and hopefully few prototypes,
| which can conflict with char _vsnprintf (); below.
| Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
| <limits.h> exists even on freestanding compilers. */
|
| #ifdef __STDC__
| # include <limits.h>
| #else
| # include <assert.h>
| #endif
|
| #undef _vsnprintf
|
| /* Override any gcc2 internal prototype to avoid an error. */
| #ifdef __cplusplus
| extern "C"
| {
| #endif
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char _vsnprintf ();
| /* The GNU C library defines this for functions which it implements
| to always fail with ENOSYS. Some functions are actually named
| something starting with __ and the normal name is an alias. */
| #if defined (__stub__vsnprintf) || defined (__stub____vsnprintf)
| choke me
| #else
| char (*f) () = _vsnprintf;
| #endif
| #ifdef __cplusplus
| }
| #endif
|
| int
| main ()
| {
| return f != _vsnprintf;
| ;
| return 0;
| }
configure:5340: result: no
configure:5253: checking for strerror
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for open
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for close
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for dup
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for dup2
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for fdopen
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for fileno
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for fstat
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for stat
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for lstat
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for isatty
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for getpid
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for setpgid
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for fork
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
conftest.c:62: warning: conflicting types for built-in function 'fork'
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for execlp
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
conftest.c:63: warning: conflicting types for built-in function 'execlp'
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for wait
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for kill
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for grantpt
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for unlockpt
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for ptsname
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for tcgetattr
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for tcsetattr
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for ioctl
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for access
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for sleep
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for opendir
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for readdir
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for closedir
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for mkdir
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for symlink
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for readlink
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for gettimeofday
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for setenv
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for putenv
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5253: checking for _putenv
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
/tmp/ccs20b76.o: In function `main':
conftest.c:(.text+0x7): undefined reference to `_putenv'
/tmp/ccs20b76.o:(.data+0x0): undefined reference to `_putenv'
collect2: ld returned 1 exit status
configure:5316: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define MR_FULLARCH "x86_64-unknown-linux-gnu"
| #define MR_VERSION "rotd-2008-08-16"
| #define MR_MKFIFO "/usr/bin/mkfifo"
| #define MR_HOSTNAMECMD "/bin/hostname -f"
| #define MR_HAVE_SYSCONF 1
| #define MR_HAVE_GETPAGESIZE 1
| #define MR_HAVE_GETHOSTNAME 1
| #define MR_HAVE_MPROTECT 1
| #define MR_HAVE_MEMALIGN 1
| #define MR_HAVE_POSIX_MEMALIGN 1
| #define MR_HAVE_MEMMOVE 1
| #define MR_HAVE_SIGACTION 1
| #define MR_HAVE_SIGINTERRUPT 1
| #define MR_HAVE_SETITIMER 1
| #define MR_HAVE_SNPRINTF 1
| #define MR_HAVE_VSNPRINTF 1
| #define MR_HAVE_STRERROR 1
| #define MR_HAVE_OPEN 1
| #define MR_HAVE_CLOSE 1
| #define MR_HAVE_DUP 1
| #define MR_HAVE_DUP2 1
| #define MR_HAVE_FDOPEN 1
| #define MR_HAVE_FILENO 1
| #define MR_HAVE_FSTAT 1
| #define MR_HAVE_STAT 1
| #define MR_HAVE_LSTAT 1
| #define MR_HAVE_ISATTY 1
| #define MR_HAVE_GETPID 1
| #define MR_HAVE_SETPGID 1
| #define MR_HAVE_FORK 1
| #define MR_HAVE_EXECLP 1
| #define MR_HAVE_WAIT 1
| #define MR_HAVE_KILL 1
| #define MR_HAVE_GRANTPT 1
| #define MR_HAVE_UNLOCKPT 1
| #define MR_HAVE_PTSNAME 1
| #define MR_HAVE_TCGETATTR 1
| #define MR_HAVE_TCSETATTR 1
| #define MR_HAVE_IOCTL 1
| #define MR_HAVE_ACCESS 1
| #define MR_HAVE_SLEEP 1
| #define MR_HAVE_OPENDIR 1
| #define MR_HAVE_READDIR 1
| #define MR_HAVE_CLOSEDIR 1
| #define MR_HAVE_MKDIR 1
| #define MR_HAVE_SYMLINK 1
| #define MR_HAVE_READLINK 1
| #define MR_HAVE_GETTIMEOFDAY 1
| #define MR_HAVE_SETENV 1
| #define MR_HAVE_PUTENV 1
| /* end confdefs.h. */
| /* Define _putenv to an innocuous variant, in case <limits.h> declares _putenv.
| For example, HP-UX 11i <limits.h> declares gettimeofday. */
| #define _putenv innocuous__putenv
|
| /* System header to define __stub macros and hopefully few prototypes,
| which can conflict with char _putenv (); below.
| Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
| <limits.h> exists even on freestanding compilers. */
|
| #ifdef __STDC__
| # include <limits.h>
| #else
| # include <assert.h>
| #endif
|
| #undef _putenv
|
| /* Override any gcc2 internal prototype to avoid an error. */
| #ifdef __cplusplus
| extern "C"
| {
| #endif
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char _putenv ();
| /* The GNU C library defines this for functions which it implements
| to always fail with ENOSYS. Some functions are actually named
| something starting with __ and the normal name is an alias. */
| #if defined (__stub__putenv) || defined (__stub____putenv)
| choke me
| #else
| char (*f) () = _putenv;
| #endif
| #ifdef __cplusplus
| }
| #endif
|
| int
| main ()
| {
| return f != _putenv;
| ;
| return 0;
| }
configure:5340: result: no
configure:5253: checking for posix_spawn
configure:5310: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5316: $? = 0
configure:5319: test -z || test ! -s conftest.err
configure:5322: $? = 0
configure:5325: test -s conftest
configure:5328: $? = 0
configure:5340: result: yes
configure:5378: checking for ANSI C header files
configure:5403: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5409: $? = 0
configure:5412: test -z || test ! -s conftest.err
configure:5415: $? = 0
configure:5418: test -s conftest.o
configure:5421: $? = 0
configure:5510: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
conftest.c: In function 'main':
conftest.c:77: warning: incompatible implicit declaration of built-in function 'exit'
configure:5513: $? = 0
configure:5515: ./conftest
configure:5518: $? = 0
configure:5533: result: yes
configure:5557: checking for sys/types.h
configure:5573: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5579: $? = 0
configure:5582: test -z || test ! -s conftest.err
configure:5585: $? = 0
configure:5588: test -s conftest.o
configure:5591: $? = 0
configure:5602: result: yes
configure:5557: checking for sys/stat.h
configure:5573: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5579: $? = 0
configure:5582: test -z || test ! -s conftest.err
configure:5585: $? = 0
configure:5588: test -s conftest.o
configure:5591: $? = 0
configure:5602: result: yes
configure:5557: checking for stdlib.h
configure:5573: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5579: $? = 0
configure:5582: test -z || test ! -s conftest.err
configure:5585: $? = 0
configure:5588: test -s conftest.o
configure:5591: $? = 0
configure:5602: result: yes
configure:5557: checking for string.h
configure:5573: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5579: $? = 0
configure:5582: test -z || test ! -s conftest.err
configure:5585: $? = 0
configure:5588: test -s conftest.o
configure:5591: $? = 0
configure:5602: result: yes
configure:5557: checking for memory.h
configure:5573: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5579: $? = 0
configure:5582: test -z || test ! -s conftest.err
configure:5585: $? = 0
configure:5588: test -s conftest.o
configure:5591: $? = 0
configure:5602: result: yes
configure:5557: checking for strings.h
configure:5573: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5579: $? = 0
configure:5582: test -z || test ! -s conftest.err
configure:5585: $? = 0
configure:5588: test -s conftest.o
configure:5591: $? = 0
configure:5602: result: yes
configure:5557: checking for inttypes.h
configure:5573: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5579: $? = 0
configure:5582: test -z || test ! -s conftest.err
configure:5585: $? = 0
configure:5588: test -s conftest.o
configure:5591: $? = 0
configure:5602: result: yes
configure:5557: checking for stdint.h
configure:5573: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5579: $? = 0
configure:5582: test -z || test ! -s conftest.err
configure:5585: $? = 0
configure:5588: test -s conftest.o
configure:5591: $? = 0
configure:5602: result: yes
configure:5557: checking for unistd.h
configure:5573: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5579: $? = 0
configure:5582: test -z || test ! -s conftest.err
configure:5585: $? = 0
configure:5588: test -s conftest.o
configure:5591: $? = 0
configure:5602: result: yes
configure:5625: checking for unistd.h
configure:5630: result: yes
configure:5634: checking sys/wait.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking sys/wait.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for sys/wait.h
configure:5756: result: yes
configure:5634: checking sys/siginfo.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
conftest.c:106:25: error: sys/siginfo.h: No such file or directory
configure:5652: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define MR_FULLARCH "x86_64-unknown-linux-gnu"
| #define MR_VERSION "rotd-2008-08-16"
| #define MR_MKFIFO "/usr/bin/mkfifo"
| #define MR_HOSTNAMECMD "/bin/hostname -f"
| #define MR_HAVE_SYSCONF 1
| #define MR_HAVE_GETPAGESIZE 1
| #define MR_HAVE_GETHOSTNAME 1
| #define MR_HAVE_MPROTECT 1
| #define MR_HAVE_MEMALIGN 1
| #define MR_HAVE_POSIX_MEMALIGN 1
| #define MR_HAVE_MEMMOVE 1
| #define MR_HAVE_SIGACTION 1
| #define MR_HAVE_SIGINTERRUPT 1
| #define MR_HAVE_SETITIMER 1
| #define MR_HAVE_SNPRINTF 1
| #define MR_HAVE_VSNPRINTF 1
| #define MR_HAVE_STRERROR 1
| #define MR_HAVE_OPEN 1
| #define MR_HAVE_CLOSE 1
| #define MR_HAVE_DUP 1
| #define MR_HAVE_DUP2 1
| #define MR_HAVE_FDOPEN 1
| #define MR_HAVE_FILENO 1
| #define MR_HAVE_FSTAT 1
| #define MR_HAVE_STAT 1
| #define MR_HAVE_LSTAT 1
| #define MR_HAVE_ISATTY 1
| #define MR_HAVE_GETPID 1
| #define MR_HAVE_SETPGID 1
| #define MR_HAVE_FORK 1
| #define MR_HAVE_EXECLP 1
| #define MR_HAVE_WAIT 1
| #define MR_HAVE_KILL 1
| #define MR_HAVE_GRANTPT 1
| #define MR_HAVE_UNLOCKPT 1
| #define MR_HAVE_PTSNAME 1
| #define MR_HAVE_TCGETATTR 1
| #define MR_HAVE_TCSETATTR 1
| #define MR_HAVE_IOCTL 1
| #define MR_HAVE_ACCESS 1
| #define MR_HAVE_SLEEP 1
| #define MR_HAVE_OPENDIR 1
| #define MR_HAVE_READDIR 1
| #define MR_HAVE_CLOSEDIR 1
| #define MR_HAVE_MKDIR 1
| #define MR_HAVE_SYMLINK 1
| #define MR_HAVE_READLINK 1
| #define MR_HAVE_GETTIMEOFDAY 1
| #define MR_HAVE_SETENV 1
| #define MR_HAVE_PUTENV 1
| #define MR_HAVE_POSIX_SPAWN 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define MR_HAVE_UNISTD_H 1
| #define MR_HAVE_SYS_WAIT_H 1
| /* end confdefs.h. */
| #include <stdio.h>
| #if HAVE_SYS_TYPES_H
| # include <sys/types.h>
| #endif
| #if HAVE_SYS_STAT_H
| # include <sys/stat.h>
| #endif
| #if STDC_HEADERS
| # include <stdlib.h>
| # include <stddef.h>
| #else
| # if HAVE_STDLIB_H
| # include <stdlib.h>
| # endif
| #endif
| #if HAVE_STRING_H
| # if !STDC_HEADERS && HAVE_MEMORY_H
| # include <memory.h>
| # endif
| # include <string.h>
| #endif
| #if HAVE_STRINGS_H
| # include <strings.h>
| #endif
| #if HAVE_INTTYPES_H
| # include <inttypes.h>
| #else
| # if HAVE_STDINT_H
| # include <stdint.h>
| # endif
| #endif
| #if HAVE_UNISTD_H
| # include <unistd.h>
| #endif
| #include <sys/siginfo.h>
configure:5674: result: no
configure:5678: checking sys/siginfo.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
conftest.c:72:25: error: sys/siginfo.h: No such file or directory
configure:5694: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define MR_FULLARCH "x86_64-unknown-linux-gnu"
| #define MR_VERSION "rotd-2008-08-16"
| #define MR_MKFIFO "/usr/bin/mkfifo"
| #define MR_HOSTNAMECMD "/bin/hostname -f"
| #define MR_HAVE_SYSCONF 1
| #define MR_HAVE_GETPAGESIZE 1
| #define MR_HAVE_GETHOSTNAME 1
| #define MR_HAVE_MPROTECT 1
| #define MR_HAVE_MEMALIGN 1
| #define MR_HAVE_POSIX_MEMALIGN 1
| #define MR_HAVE_MEMMOVE 1
| #define MR_HAVE_SIGACTION 1
| #define MR_HAVE_SIGINTERRUPT 1
| #define MR_HAVE_SETITIMER 1
| #define MR_HAVE_SNPRINTF 1
| #define MR_HAVE_VSNPRINTF 1
| #define MR_HAVE_STRERROR 1
| #define MR_HAVE_OPEN 1
| #define MR_HAVE_CLOSE 1
| #define MR_HAVE_DUP 1
| #define MR_HAVE_DUP2 1
| #define MR_HAVE_FDOPEN 1
| #define MR_HAVE_FILENO 1
| #define MR_HAVE_FSTAT 1
| #define MR_HAVE_STAT 1
| #define MR_HAVE_LSTAT 1
| #define MR_HAVE_ISATTY 1
| #define MR_HAVE_GETPID 1
| #define MR_HAVE_SETPGID 1
| #define MR_HAVE_FORK 1
| #define MR_HAVE_EXECLP 1
| #define MR_HAVE_WAIT 1
| #define MR_HAVE_KILL 1
| #define MR_HAVE_GRANTPT 1
| #define MR_HAVE_UNLOCKPT 1
| #define MR_HAVE_PTSNAME 1
| #define MR_HAVE_TCGETATTR 1
| #define MR_HAVE_TCSETATTR 1
| #define MR_HAVE_IOCTL 1
| #define MR_HAVE_ACCESS 1
| #define MR_HAVE_SLEEP 1
| #define MR_HAVE_OPENDIR 1
| #define MR_HAVE_READDIR 1
| #define MR_HAVE_CLOSEDIR 1
| #define MR_HAVE_MKDIR 1
| #define MR_HAVE_SYMLINK 1
| #define MR_HAVE_READLINK 1
| #define MR_HAVE_GETTIMEOFDAY 1
| #define MR_HAVE_SETENV 1
| #define MR_HAVE_PUTENV 1
| #define MR_HAVE_POSIX_SPAWN 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define MR_HAVE_UNISTD_H 1
| #define MR_HAVE_SYS_WAIT_H 1
| /* end confdefs.h. */
| #include <sys/siginfo.h>
configure:5714: result: no
configure:5749: checking for sys/siginfo.h
configure:5756: result: no
configure:5634: checking sys/signal.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking sys/signal.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for sys/signal.h
configure:5756: result: yes
configure:5634: checking ucontext.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking ucontext.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for ucontext.h
configure:5756: result: yes
configure:5634: checking asm/sigcontext.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking asm/sigcontext.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for asm/sigcontext.h
configure:5756: result: yes
configure:5634: checking sys/param.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking sys/param.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for sys/param.h
configure:5756: result: yes
configure:5634: checking sys/time.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking sys/time.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for sys/time.h
configure:5756: result: yes
configure:5634: checking sys/times.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking sys/times.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for sys/times.h
configure:5756: result: yes
configure:5625: checking for sys/types.h
configure:5630: result: yes
configure:5625: checking for sys/stat.h
configure:5630: result: yes
configure:5634: checking fcntl.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking fcntl.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for fcntl.h
configure:5756: result: yes
configure:5634: checking termios.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking termios.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for termios.h
configure:5756: result: yes
configure:5634: checking sys/ioctl.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking sys/ioctl.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for sys/ioctl.h
configure:5756: result: yes
configure:5634: checking sys/stropts.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking sys/stropts.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for sys/stropts.h
configure:5756: result: yes
configure:5634: checking windows.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
conftest.c:118:21: error: windows.h: No such file or directory
configure:5652: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define MR_FULLARCH "x86_64-unknown-linux-gnu"
| #define MR_VERSION "rotd-2008-08-16"
| #define MR_MKFIFO "/usr/bin/mkfifo"
| #define MR_HOSTNAMECMD "/bin/hostname -f"
| #define MR_HAVE_SYSCONF 1
| #define MR_HAVE_GETPAGESIZE 1
| #define MR_HAVE_GETHOSTNAME 1
| #define MR_HAVE_MPROTECT 1
| #define MR_HAVE_MEMALIGN 1
| #define MR_HAVE_POSIX_MEMALIGN 1
| #define MR_HAVE_MEMMOVE 1
| #define MR_HAVE_SIGACTION 1
| #define MR_HAVE_SIGINTERRUPT 1
| #define MR_HAVE_SETITIMER 1
| #define MR_HAVE_SNPRINTF 1
| #define MR_HAVE_VSNPRINTF 1
| #define MR_HAVE_STRERROR 1
| #define MR_HAVE_OPEN 1
| #define MR_HAVE_CLOSE 1
| #define MR_HAVE_DUP 1
| #define MR_HAVE_DUP2 1
| #define MR_HAVE_FDOPEN 1
| #define MR_HAVE_FILENO 1
| #define MR_HAVE_FSTAT 1
| #define MR_HAVE_STAT 1
| #define MR_HAVE_LSTAT 1
| #define MR_HAVE_ISATTY 1
| #define MR_HAVE_GETPID 1
| #define MR_HAVE_SETPGID 1
| #define MR_HAVE_FORK 1
| #define MR_HAVE_EXECLP 1
| #define MR_HAVE_WAIT 1
| #define MR_HAVE_KILL 1
| #define MR_HAVE_GRANTPT 1
| #define MR_HAVE_UNLOCKPT 1
| #define MR_HAVE_PTSNAME 1
| #define MR_HAVE_TCGETATTR 1
| #define MR_HAVE_TCSETATTR 1
| #define MR_HAVE_IOCTL 1
| #define MR_HAVE_ACCESS 1
| #define MR_HAVE_SLEEP 1
| #define MR_HAVE_OPENDIR 1
| #define MR_HAVE_READDIR 1
| #define MR_HAVE_CLOSEDIR 1
| #define MR_HAVE_MKDIR 1
| #define MR_HAVE_SYMLINK 1
| #define MR_HAVE_READLINK 1
| #define MR_HAVE_GETTIMEOFDAY 1
| #define MR_HAVE_SETENV 1
| #define MR_HAVE_PUTENV 1
| #define MR_HAVE_POSIX_SPAWN 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define MR_HAVE_UNISTD_H 1
| #define MR_HAVE_SYS_WAIT_H 1
| #define MR_HAVE_SYS_SIGNAL_H 1
| #define MR_HAVE_UCONTEXT_H 1
| #define MR_HAVE_ASM_SIGCONTEXT_H 1
| #define MR_HAVE_SYS_PARAM_H 1
| #define MR_HAVE_SYS_TIME_H 1
| #define MR_HAVE_SYS_TIMES_H 1
| #define MR_HAVE_SYS_TYPES_H 1
| #define MR_HAVE_SYS_STAT_H 1
| #define MR_HAVE_FCNTL_H 1
| #define MR_HAVE_TERMIOS_H 1
| #define MR_HAVE_SYS_IOCTL_H 1
| #define MR_HAVE_SYS_STROPTS_H 1
| /* end confdefs.h. */
| #include <stdio.h>
| #if HAVE_SYS_TYPES_H
| # include <sys/types.h>
| #endif
| #if HAVE_SYS_STAT_H
| # include <sys/stat.h>
| #endif
| #if STDC_HEADERS
| # include <stdlib.h>
| # include <stddef.h>
| #else
| # if HAVE_STDLIB_H
| # include <stdlib.h>
| # endif
| #endif
| #if HAVE_STRING_H
| # if !STDC_HEADERS && HAVE_MEMORY_H
| # include <memory.h>
| # endif
| # include <string.h>
| #endif
| #if HAVE_STRINGS_H
| # include <strings.h>
| #endif
| #if HAVE_INTTYPES_H
| # include <inttypes.h>
| #else
| # if HAVE_STDINT_H
| # include <stdint.h>
| # endif
| #endif
| #if HAVE_UNISTD_H
| # include <unistd.h>
| #endif
| #include <windows.h>
configure:5674: result: no
configure:5678: checking windows.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
conftest.c:84:21: error: windows.h: No such file or directory
configure:5694: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define MR_FULLARCH "x86_64-unknown-linux-gnu"
| #define MR_VERSION "rotd-2008-08-16"
| #define MR_MKFIFO "/usr/bin/mkfifo"
| #define MR_HOSTNAMECMD "/bin/hostname -f"
| #define MR_HAVE_SYSCONF 1
| #define MR_HAVE_GETPAGESIZE 1
| #define MR_HAVE_GETHOSTNAME 1
| #define MR_HAVE_MPROTECT 1
| #define MR_HAVE_MEMALIGN 1
| #define MR_HAVE_POSIX_MEMALIGN 1
| #define MR_HAVE_MEMMOVE 1
| #define MR_HAVE_SIGACTION 1
| #define MR_HAVE_SIGINTERRUPT 1
| #define MR_HAVE_SETITIMER 1
| #define MR_HAVE_SNPRINTF 1
| #define MR_HAVE_VSNPRINTF 1
| #define MR_HAVE_STRERROR 1
| #define MR_HAVE_OPEN 1
| #define MR_HAVE_CLOSE 1
| #define MR_HAVE_DUP 1
| #define MR_HAVE_DUP2 1
| #define MR_HAVE_FDOPEN 1
| #define MR_HAVE_FILENO 1
| #define MR_HAVE_FSTAT 1
| #define MR_HAVE_STAT 1
| #define MR_HAVE_LSTAT 1
| #define MR_HAVE_ISATTY 1
| #define MR_HAVE_GETPID 1
| #define MR_HAVE_SETPGID 1
| #define MR_HAVE_FORK 1
| #define MR_HAVE_EXECLP 1
| #define MR_HAVE_WAIT 1
| #define MR_HAVE_KILL 1
| #define MR_HAVE_GRANTPT 1
| #define MR_HAVE_UNLOCKPT 1
| #define MR_HAVE_PTSNAME 1
| #define MR_HAVE_TCGETATTR 1
| #define MR_HAVE_TCSETATTR 1
| #define MR_HAVE_IOCTL 1
| #define MR_HAVE_ACCESS 1
| #define MR_HAVE_SLEEP 1
| #define MR_HAVE_OPENDIR 1
| #define MR_HAVE_READDIR 1
| #define MR_HAVE_CLOSEDIR 1
| #define MR_HAVE_MKDIR 1
| #define MR_HAVE_SYMLINK 1
| #define MR_HAVE_READLINK 1
| #define MR_HAVE_GETTIMEOFDAY 1
| #define MR_HAVE_SETENV 1
| #define MR_HAVE_PUTENV 1
| #define MR_HAVE_POSIX_SPAWN 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define MR_HAVE_UNISTD_H 1
| #define MR_HAVE_SYS_WAIT_H 1
| #define MR_HAVE_SYS_SIGNAL_H 1
| #define MR_HAVE_UCONTEXT_H 1
| #define MR_HAVE_ASM_SIGCONTEXT_H 1
| #define MR_HAVE_SYS_PARAM_H 1
| #define MR_HAVE_SYS_TIME_H 1
| #define MR_HAVE_SYS_TIMES_H 1
| #define MR_HAVE_SYS_TYPES_H 1
| #define MR_HAVE_SYS_STAT_H 1
| #define MR_HAVE_FCNTL_H 1
| #define MR_HAVE_TERMIOS_H 1
| #define MR_HAVE_SYS_IOCTL_H 1
| #define MR_HAVE_SYS_STROPTS_H 1
| /* end confdefs.h. */
| #include <windows.h>
configure:5714: result: no
configure:5749: checking for windows.h
configure:5756: result: no
configure:5634: checking dirent.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking dirent.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for dirent.h
configure:5756: result: yes
configure:5634: checking getopt.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking getopt.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for getopt.h
configure:5756: result: yes
configure:5634: checking malloc.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking malloc.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for malloc.h
configure:5756: result: yes
configure:5634: checking semaphore.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking semaphore.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for semaphore.h
configure:5756: result: yes
configure:5634: checking pthread.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking pthread.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for pthread.h
configure:5756: result: yes
configure:5634: checking time.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking time.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for time.h
configure:5756: result: yes
configure:5634: checking spawn.h usability
configure:5646: gcc -c -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5652: $? = 0
configure:5655: test -z || test ! -s conftest.err
configure:5658: $? = 0
configure:5661: test -s conftest.o
configure:5664: $? = 0
configure:5674: result: yes
configure:5678: checking spawn.h presence
configure:5688: gcc -E -Iruntime -Iruntime/machdeps -Itrace conftest.c
configure:5694: $? = 0
configure:5714: result: yes
configure:5749: checking for spawn.h
configure:5756: result: yes
configure:5944: checking for `sigaction' field name
configure:5993: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
configure:5996: $? = 0
configure:5998: ./conftest
configure:6001: $? = 0
configure:6016: result: sa_sigaction
configure:6035: checking for working `sigcontext_struct' in second arg
configure:6091: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
In file included from /usr/include/asm/sigcontext.h:5,
                 from conftest.c:103:
/usr/include/asm-x86_64/sigcontext.h:9: error: redefinition of 'struct _fpstate'
/usr/include/asm-x86_64/sigcontext.h:23: error: redefinition of 'struct sigcontext'
conftest.c: In function 'main':
conftest.c:120: warning: incompatible implicit declaration of built-in function 'exit'
conftest.c: In function 'handler':
conftest.c:125: warning: cast to pointer from integer of different size
conftest.c:127: warning: incompatible implicit declaration of built-in function 'exit'
conftest.c:129: warning: incompatible implicit declaration of built-in function 'exit'
configure:6094: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define MR_FULLARCH "x86_64-unknown-linux-gnu"
| #define MR_VERSION "rotd-2008-08-16"
| #define MR_MKFIFO "/usr/bin/mkfifo"
| #define MR_HOSTNAMECMD "/bin/hostname -f"
| #define MR_HAVE_SYSCONF 1
| #define MR_HAVE_GETPAGESIZE 1
| #define MR_HAVE_GETHOSTNAME 1
| #define MR_HAVE_MPROTECT 1
| #define MR_HAVE_MEMALIGN 1
| #define MR_HAVE_POSIX_MEMALIGN 1
| #define MR_HAVE_MEMMOVE 1
| #define MR_HAVE_SIGACTION 1
| #define MR_HAVE_SIGINTERRUPT 1
| #define MR_HAVE_SETITIMER 1
| #define MR_HAVE_SNPRINTF 1
| #define MR_HAVE_VSNPRINTF 1
| #define MR_HAVE_STRERROR 1
| #define MR_HAVE_OPEN 1
| #define MR_HAVE_CLOSE 1
| #define MR_HAVE_DUP 1
| #define MR_HAVE_DUP2 1
| #define MR_HAVE_FDOPEN 1
| #define MR_HAVE_FILENO 1
| #define MR_HAVE_FSTAT 1
| #define MR_HAVE_STAT 1
| #define MR_HAVE_LSTAT 1
| #define MR_HAVE_ISATTY 1
| #define MR_HAVE_GETPID 1
| #define MR_HAVE_SETPGID 1
| #define MR_HAVE_FORK 1
| #define MR_HAVE_EXECLP 1
| #define MR_HAVE_WAIT 1
| #define MR_HAVE_KILL 1
| #define MR_HAVE_GRANTPT 1
| #define MR_HAVE_UNLOCKPT 1
| #define MR_HAVE_PTSNAME 1
| #define MR_HAVE_TCGETATTR 1
| #define MR_HAVE_TCSETATTR 1
| #define MR_HAVE_IOCTL 1
| #define MR_HAVE_ACCESS 1
| #define MR_HAVE_SLEEP 1
| #define MR_HAVE_OPENDIR 1
| #define MR_HAVE_READDIR 1
| #define MR_HAVE_CLOSEDIR 1
| #define MR_HAVE_MKDIR 1
| #define MR_HAVE_SYMLINK 1
| #define MR_HAVE_READLINK 1
| #define MR_HAVE_GETTIMEOFDAY 1
| #define MR_HAVE_SETENV 1
| #define MR_HAVE_PUTENV 1
| #define MR_HAVE_POSIX_SPAWN 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define MR_HAVE_UNISTD_H 1
| #define MR_HAVE_SYS_WAIT_H 1
| #define MR_HAVE_SYS_SIGNAL_H 1
| #define MR_HAVE_UCONTEXT_H 1
| #define MR_HAVE_ASM_SIGCONTEXT_H 1
| #define MR_HAVE_SYS_PARAM_H 1
| #define MR_HAVE_SYS_TIME_H 1
| #define MR_HAVE_SYS_TIMES_H 1
| #define MR_HAVE_SYS_TYPES_H 1
| #define MR_HAVE_SYS_STAT_H 1
| #define MR_HAVE_FCNTL_H 1
| #define MR_HAVE_TERMIOS_H 1
| #define MR_HAVE_SYS_IOCTL_H 1
| #define MR_HAVE_SYS_STROPTS_H 1
| #define MR_HAVE_DIRENT_H 1
| #define MR_HAVE_GETOPT_H 1
| #define MR_HAVE_MALLOC_H 1
| #define MR_HAVE_SEMAPHORE_H 1
| #define MR_HAVE_PTHREAD_H 1
| #define MR_HAVE_TIME_H 1
| #define MR_HAVE_SPAWN_H 1
| #define MR_SIGACTION_FIELD sa_sigaction
| #define MR_HAVE_SIGINFO 1
| /* end confdefs.h. */
|
| /* see runtime/mercury_signal.h for documentation of this code */
|
| #define sigcontext_struct sigcontext
|
| #define __KERNEL__
| #include <signal.h>
| #undef __KERNEL__
|
| #ifdef MR_HAVE_ASM_SIGCONTEXT_H
| #include <asm/sigcontext.h>
| #endif
|
| #include "mercury_faultaddr.h"
|
| #include <stdio.h>
|
| extern void handler(int signum, struct sigcontext_struct info);
|
| #define FAULT_ADDRESS ((int *)112)
|
| int main() {
| signal(SIGSEGV, (void (*)(int))handler);
|
| /* provoke a SIGSEGV */
| (*FAULT_ADDRESS)++;
|
| exit(1);
| }
|
| void handler(int signum, struct sigcontext_struct context) {
| int *addr;
| addr = (int *) MR_GET_FAULT_ADDR(context);
| if (signum == SIGSEGV && addr == FAULT_ADDRESS) {
| exit(0);
| } else {
| exit(1);
| }
| }
configure:6114: result: no
configure:6120: checking for working `sigcontext_struct' in third arg
configure:6178: gcc -o conftest -O -Iruntime -Iruntime/machdeps -Itrace conftest.c >&5
In file included from /usr/include/asm/sigcontext.h:5,
                 from conftest.c:103:
/usr/include/asm-x86_64/sigcontext.h:9: error: redefinition of 'struct _fpstate'
/usr/include/asm-x86_64/sigcontext.h:23: error: redefinition of 'struct sigcontext'
conftest.c: In function 'main':
conftest.c:121: warning: incompatible implicit declaration of built-in function 'exit'
conftest.c: In function 'handler':
conftest.c:126: warning: cast to pointer from integer of different size
conftest.c:128: warning: incompatible implicit declaration of built-in function 'exit'
conftest.c:130:

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-01-22 17:48

2009-11-27 02:03

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:

gcc 4.1.2 on x86-64 miscompiles computed gotos

Description:

In compiler/purity.m we needed a work around to avoid a segfault while purity checking invalid/purity/purity.m.
We get a segfault when jumping to the `unnecessary_promise_pure' branch.

Happens with gcc 4.1.2 on x86-64, at gcc -O1 and above.

Tags:

Steps To Reproduce:

Additional Information:

This also works around the problem. Note the volatile.

#define MR_COMPUTED_GOTO(val, labels) \
        { \
                static MR_Code *jump_table[] = { \
                        labels \
                }; \
                volatile int val1 = (val); \
                MR_GOTO(jump_table[val1]); \
        }

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-08-20 16:54

2009-11-27 00:56

Reporter:

juliensf

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:

make install fails on Fedora 9 with gcc 4.3

Description:

Building the source distribution on Fedora 9 fails due to segmentation fault during
the install_grades step.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-07-07 14:47

2009-11-25 21:29

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:

gcc 4.2 incompatibility

Description:

gcc 4.2.3 on my x86-64 machine doesn't compile the Mercury compiler properly.
This is in asm_fast.gc grade.

% ./mercury_compile
Mercury.options:085: Warning: variable `GCC_SRC_DIR' is undefined.
mercury_compile: unrecognized option `-O'
Mercury Compiler, version DEV, configured for x86_64-unknown-linux-gnu
Copyright (C) 1993-2008 The University of Melbourne
Usage: mmc [<options>] <arguments>
Use `mmc --help' for more information.

Note the "unrecognized option" message even when there are no arguments.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

108

[mercury] Bug

minor

N/A

2009-09-28 11:38

2009-11-23 22:11

Reporter:

gloomdemon

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:

invalid java path with mercury and mingw

Description:

Mercury Compiler, version rotd-2009-09-15
mingw with gcc4.4 on windows vista

while compiling java grade, mercury compiler uses invalid path:
$ mmc --java -v --make family
...
% Invoking system command `/c/Java/jdk1.6.0_12/bin/javac -classpath :c:/mingw/me
rcury/lib/mercury/lib/java/mer_rt.jar:c:/mingw/mercury/lib/mercury/lib/java/mer_
std.jar:c:/mingw/mercury/lib/mercury/lib/java/mer_mdbcomp.jar:c:/mingw/mercury/l
ib/mercury/lib/java/mer_browser.jar:c:/mingw/mercury/lib/mercury/lib/java/mer_ss
db.jar -sourcepath Mercury\javas -d Mercury\classs -J-Xmx256m Mercury\javas\jmer
cury\family.java'...
...
Error: system command received signal 1.

,must be:

% Invoking system command `c:/Java/jdk1.6.0_12/bin/javac -classpath c:/mingw/...
with c:\ and no : after -classpath or dot before :

% Invoking system command `c:/Java/jdk1.6.0_12/bin/javac -classpath .:c:/mingw/...

=== ===

after compiling and linking created sh file incorrect.

#!/bin/sh
DIR=${0%/*}
CLASSPATH=$DIR/Mercury\classs:$CLASSPATH:c:/mingw/mercury/lib/mercury/lib/java/mer_rt.jar:c:/mingw/mercury/lib/mercury/lib/java/mer_std.jar:c:/mingw/mercury/lib/mercury/lib/java/mer_mdbcomp.jar:c:/mingw/mercury/lib/mercury/lib/java/mer_browser.jar:c:/mingw/mercury/lib/mercury/lib/java/mer_ssdb.jar
export CLASSPATH
JAVA=${JAVA:-/c/Windows/system32/java}
exec $JAVA jmercury.family "$@"

,must be:

CLASSPATH=$DIR/Mercury/classs:

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

114

[mercury] Bug

minor

have not tried

2009-10-19 19:19

2009-10-30 09:45

Reporter:

janicek

Platform:

Darwin

Assigned To:

OS:

Mac OS X

Priority:

normal

OS Version:

10.5.8

Status:

acknowledged

Product Version:

Product Build:

rotd-2009-10-05

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

rotd-2009-10-05's library install fails for grade hlc.agc

Description:

Trying to install Mercury library with grade hlc.agc fails in "make install" ends with an error:

-- BEGIN SNIPPET --

mmc --compile-to-c --grade hlc.agc --mercury-linkage shared --flags LIB_FLAGS --flags INTER_FLAGS -R/Users/sandius/Developer/mercury-rotd-2009-10-05-agc/lib/mercury/lib/hlc.agc -R/Users/sandius/Develop
er/mercury-rotd-2009-10-05-agc/l
ib/mercury/lib version_hash_table > version_hash_table.err 2>&1
mmc --compile-to-c --grade hlc.agc --mercury-linkage shared --flags LIB_FLAGS --flags INTER_FLAGS -R/Users/sandius/Developer/mercury-rotd-2009-10-05-agc/lib/mercury/lib/hlc.agc -R/Users/sandius/Develop
er/mercury-rotd-2009-10-05-agc/lib/mercury/lib version_store > version_store.err 2>&1
mmc --compile-to-c --grade hlc.agc --mercury-linkage shared --flags LIB_FLAGS --flags INTER_FLAGS -R/Users/sandius/Developer/mercury-rotd-2009-10-05-agc/lib/mercury/lib/hlc.agc -R/Users/sandius/Develop
er/mercury-rotd-2009-10-05-agc/lib/mercury/lib version_types > version_types.err 2>&1
/Users/sandius/tmp/mercury-compiler-rotd-2009-10-05/install_grade_dir.hlc.agc/scripts/mgnuc --grade hlc.agc -- -c array.c -o array.o
array.c: In function ‘mercury__array__f_84_121_112_101_83_112_101_99_79_102_95_95_112_114_101_100_95_111_114_95_102_117_110_99_95_95_115_111_114_116_95_95_91_84_32_61_32_105_110_116_93_95_48_95_49_1_f_0’:
array.c:1369: error: ‘mercury__array__frame_ptr’ undeclared (first use in this function)
array.c:1369: error: (Each undeclared identifier is reported only once
array.c:1369: error: for each function it appears in.)
array.c: In function ‘mercury__array__f_84_121_112_101_83_112_101_99_79_102_95_95_112_114_101_100_95_111_114_95_102_117_110_99_95_95_115_111_114_116_95_95_91_84_32_61_32_115_116_114_105_110_103_93_95_48_95_49
_1_f_0’:
array.c:1469: error: ‘mercury__array__frame_ptr’ undeclared (first use in this function)
array.c: In function ‘mercury__array__f_84_121_112_101_83_112_101_99_79_102_95_95_112_114_101_100_95_111_114_95_102_117_110_99_95_95_115_97_109_115_111_114_116_95_115_117_98_97_114_114_97_121_95_95_91_84_32_6
1_32_105_110_116_93_95_48_95_49_3_f_0’:
array.c:1569: error: ‘mercury__array__frame_ptr’ undeclared (first use in this function)
array.c: In function ‘mercury__array__f_84_121_112_101_83_112_101_99_79_102_95_95_112_114_101_100_95_111_114_95_102_117_110_99_95_95_115_97_109_115_111_114_116_95_115_117_98_97_114_114_97_121_95_95_91_84_32_6
1_32_115_116_114_105_110_103_93_95_48_95_49_3_f_0’:
array.c:1626: error: ‘mercury__array__frame_ptr’ undeclared (first use in this function)
array.m: In function ‘mercury__array__f_84_121_112_101_83_112_101_99_79_102_95_95_112_114_101_100_95_111_114_95_102_117_110_99_95_95_115_97_109_115_111_114_116_95_117_112_95_95_91_84_32_61_32_105_110_116_93_9
5_48_95_49_8_p_0’:
array.m:1715: error: ‘mercury__array__frame_ptr’ undeclared (first use in this function)
array.m: In function ‘mercury__array__f_84_121_112_101_83_112_101_99_79_102_95_95_112_114_101_100_95_111_114_95_102_117_110_99_95_95_115_97_109_115_111_114_116_95_117_112_95_95_91_84_32_61_32_115_116_114_105_
110_103_93_95_48_95_49_8_p_0’:
array.m:1715: error: ‘mercury__array__frame_ptr’ undeclared (first use in this function)
array.m: In function ‘mercury__array__f_84_121_112_101_83_112_101_99_79_102_95_95_112_114_101_100_95_111_114_95_102_117_110_99_95_95_115_97_109_115_111_114_116_95_100_111_119_110_95_95_91_84_32_61_32_105_110_
116_93_95_48_95_49_8_p_0’:
array.m:1747: error: ‘mercury__array__frame_ptr’ undeclared (first use in this function)
array.m: In function ‘mercury__array__f_84_121_112_101_83_112_101_99_79_102_95_95_112_114_101_100_95_111_114_95_102_117_110_99_95_95_115_97_109_115_111_114_116_95_100_111_119_110_95_95_91_84_32_61_32_115_116_
114_105_110_103_93_95_48_95_49_8_p_0’:
array.m:1747: error: ‘mercury__array__frame_ptr’ undeclared (first use in this function)
array.c: In function ‘mercury__array__f_84_121_112_101_83_112_101_99_79_102_95_95_112_114_101_100_95_111_114_95_102_117_110_99_95_95_99_111_112_121_95_114_117_110_95_97_115_99_101_110_100_105_110_103_95_95_91
_84_32_61_32_105_110_116_93_95_48_95_49_6_p_0’:
array.c:2343: error: ‘mercury__array__frame_ptr’ undeclared (first use in this function)
array.c: In function ‘mercury__array__f_84_121_112_101_83_112_101_99_79_102_95_95_112_114_101_100_95_111_114_95_102_117_110_99_95_95_99_111_112_121_95_114_117_110_95_97_115_99_101_110_100_105_110_103_95_95_91
_84_32_61_32_115_116_114_105_110_103_93_95_48_95_49_6_p_0’:

-- END SNIPPET --

Configured with

$ ./configure --prefix=$HOME/Developer/mercury-rotd-2009-10-05-agc --enable-libgrades=hlc.gc,hlc.agc

$ gcc --version
i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5566)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a
Darwin freya.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

config.log attached.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

config.log (235,898 bytes) 2009-10-19 19:19
https://bugs.mercurylang.org/file_download.php?file_id=86&type=bug
make_install.nohup (387,005 bytes) 2009-10-19 19:21
https://bugs.mercurylang.org/file_download.php?file_id=87&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

112

[mercury] Bug

feature

always

2009-10-12 23:18

2009-10-17 06:10

Reporter:

colanderman

Platform:

Assigned To:

juliensf

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

no change required

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

set_* modules inconsistent

Description:

set_bbbtree, set_ordlist, and set_unordlist all have a predicate member(T, set(T)) with modes semidet and nondet, and a predicate contains(set(T), T) with mode semidet.

set_tree234 reverses the order of the arguments of member relative to these three modules, and set_ctree234 drops member and provides instead one_member(set(T), T) with only mode nondet.

At the very least the order of arguments to set_tree234.member should be reversed, or the predicate renamed.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

113

[mercury] Bug

minor

always

2009-10-13 02:33

2009-10-17 03: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:

abort during purity checking.

Description:

The attached program results in a compiler abort.
It looks as though the compiler should not be proceeding to purity checking
in the presence of earlier errors.

The output from mmc -V is below.

Tags:

Steps To Reproduce:

Additional Information:

% Parsing file `bug113' and imported interfaces...
% Reading file `bug113'... successful parse.
% Reading interface for module `builtin.int'... successful parse.
% Reading interface for module `bool.int'... successful parse.
% Reading interface for module `list.int'... successful parse.
% Reading interface for module `exception.int'... successful parse.
% Reading interface for module `int.int'... successful parse.
% Reading interface for module `string.int'... successful parse.
% Reading interface for module `private_builtin.int'... successful parse.
% Reading short interface for module `enum.int2'... successful parse.
% Reading short interface for module `pretty_printer.int2'... successful parse.
% Reading short interface for module `term.int2'... successful parse.
% Reading short interface for module `io.int2'... successful parse.
% Reading short interface for module `deconstruct.int2'... successful parse.
% Reading short interface for module `stream.int2'... successful parse.
% Reading short interface for module `type_desc.int2'... successful parse.
% Reading short interface for module `univ.int2'... successful parse.
% Reading short interface for module `map.int2'... successful parse.
% Reading short interface for module `bitmap.int2'... successful parse.
% Reading short interface for module `char.int2'... successful parse.
% Reading short interface for module `maybe.int2'... successful parse.
% Reading short interface for module `ops.int2'... successful parse.
% Reading short interface for module `time.int2'... successful parse.
% Reading short interface for module `construct.int2'... successful parse.
% Reading short interface for module `rtti_implementation.int2'... successful parse.
% Reading short interface for module `assoc_list.int2'... successful parse.
% Reading short interface for module `set.int2'... successful parse.
% Reading short interface for module `tree234.int2'... successful parse.
% Reading short interface for module `pair.int2'... successful parse.
% Reading short interface for module `stm_builtin.int2'... successful parse.
% Reading short interface for module `store.int2'... successful parse.
% Reading short interface for module `array.int2'... successful parse.
% Reading short interface for module `random.int2'... successful parse.
% Reading short interface for module `set_ordlist.int2'... successful parse.
% Module qualifying items...
bug113.m:001: In module `bug113':
bug113.m:001: warning: module `list' is imported in the interface, but is not
bug113.m:001: used in the interface.
% done.
% Expanding equivalence types...
% done.
% Converting parse tree to hlds...
% Processing clause 1 for function `bug113.new/1'...
% Processing clause 1 for function `bug113.new/2'...
bug113.m:036: Error: clause for function `bug113.new'/1
bug113.m:036: without preceding `func' declaration.
bug113.m:038: Error: clause for function `bug113.new'/2
bug113.m:038: without preceding `func' declaration.
% done.
% Writing auto-dependency file `bug113.d'... done.
% 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 typeclass constraints on unification predicate for type bug113.bitmap
% Checking typeclass constraints on comparison predicate for type bug113.bitmap
% Checking typeclass constraints on unification predicate for type bug113.foo
% Checking typeclass constraints on comparison predicate for type bug113.foo
% Checking typeclass constraints on function `bug113.new'/1
% Checking typeclass constraints on function `bug113.new'/2
% Checking that insts have matching types... done.
% Type-checking...
% Type-checking clauses...
% Type-checking unification predicate for type deconstruct.maybe_arg
% Inferring type of function `bug113.new'/1
% Inferring type of function `bug113.new'/2
% Type-checking predicate `list.TypeSpecOf__pred__member__[T = var(V_2)]'/2
% Type-checking predicate `list.TypeSpecOf__pred__merge__[T = var(V_2)]'/3
% Type-checking predicate `list.TypeSpecOf__pred__merge_and_remove_dups__[T = var(V_2)]'/3
% Type-checking function `list.TypeSpecOf__pred_or_func__merge_and_remove_dups__[T = var(V_2)]'/2
% Type-checking function `list.TypeSpecOf__pred_or_func__remove_adjacent_dups__[T = var(V_2)]'/1
% Type-checking predicate `list.TypeSpecOf__pred_or_func__remove_adjacent_dups__[T = var(V_2)]'/2
% Type-checking predicate `list.TypeSpecOf__pred__sort__[T = var(V_2)]'/2
% Type-checking function `list.TypeSpecOf__pred_or_func__sort__[T = var(V_2)]'/1
% Type-checking function `list.TypeSpecOf__pred_or_func__sort_and_remove_dups__[T = var(V_2)]'/1
% Type-checking predicate `list.TypeSpecOf__pred_or_func__sort_and_remove_dups__[T = var(V_2)]'/2
bug113.m:036: Inferred :- func new(T1) = T2.
bug113.m:040: In clause for function `new'/2:
bug113.m:040: error: undefined symbol `throw_bitmap_error/1'.
bug113.m:042: In clause for function `new'/2:
bug113.m:042: error: undefined symbol `initializer/1'.
bug113.m:043: In clause for function `new'/2:
bug113.m:043: error: undefined symbol `initialize_bitmap/3'.
bug113.m:043: In clause for function `new'/2:
bug113.m:043: in argument 1 of functor `initialize_bitmap/3':
bug113.m:043: error: undefined symbol `allocate_bitmap/1'.
bug113.m:044: In clause for function `new'/2:
bug113.m:044: error: undefined symbol `clear_filler_bits/1'.
% Program contains type error(s).
% Purity-checking clauses...
% Purity-checking unification predicate for type bug113.bitmap
% Purity-checking comparison predicate for type bug113.bitmap
% Purity-checking unification predicate for type bug113.foo
% Purity-checking comparison predicate for type bug113.foo
% Purity-checking function `bug113.new'/1
Uncaught Mercury exception:
Software Error: prog_type.m: Unexpected: type_to_ctor_and_args_det: type_to_ctor_and_args failed
Stack dump not available in this grade.

Attached Files:

bug113.m (1,504 bytes) 2009-10-13 02:33
https://bugs.mercurylang.org/file_download.php?file_id=84&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

111

[mercury] Bug

minor

always

2009-10-12 15:03

Reporter:

colanderman

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:

Throwing exception in tabled predicate causes table entry to remain active

Description:

If a memoized function or predicate throws an exception, then the call remains "active" in the memo table, and subsequent calls trigger a spurious loop check exception.

Tags:

Steps To Reproduce:

Additional Information:

Expected output of attached test should be "exn" printed twice. The second call however produces an infinite loop exception.

Attached Files:

table_exn_test.m (503 bytes) 2009-10-12 15:03
https://bugs.mercurylang.org/file_download.php?file_id=83&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

104

[mercury] Bug

minor

always

2009-09-14 13:55

2009-10-06 08:40

Reporter:

colanderman

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

feedback

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Static linking doesn't properly track dependencies

Description:

Let there be two libraries, a and b, and one program, c. Let b use a (in Mercury.options: EXTRA_LIBRARIES = a) and c use b (EXTRA_LIBRARIES = b). Compile a with "mmc --generate-mmc-deps -m liba.install", b with "mmc --generate-mmc-deps -m libb.install", and c with "mmc --linkage static -m c". Linking c will fail, since only libb.a is linked, and it doesn't contain symbols from liba.a which are necessary to produce the final executable.

Tags:

Steps To Reproduce:

Additional Information:

Normally this isn't a problem with shared linking, because shared objects (at least on Linux) track this sort of dependency information for you. Nonetheless I have ran into this problem once with shared linking under 0.13.1: the asm_fast.gc.mmsc.debug grade of a library failed to build because its .c file directly referenced a constructor which the .m file could not see (it was nested two levels deep). (Linking would have succeeded, but compilation failed.) The problem was "resolved" by changing the definition of the type which was "leaking" from an alias to a constructor -- clearly not something that should have any effect. I have been unable to reproduce this error with a small test case but if I am able to I will supply it.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

105

[mercury] Bug

minor

always

2009-09-16 10:43

2009-10-06 02:45

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:

hl.gc grade is broken

Description:

Trying to install the standard library in the hl.gc grade results in these kinds of messages:

io.m: In function `mercury__io__compare_file_id_2_3_p_0':
io.m:3829: error: conversion to non-scalar type requested
io.m:3830: error: conversion to non-scalar type requested
...
lexer.m:925: warning: missing braces around initializer
lexer.m:925: warning: (near initialization for `mercury__lexer__const_var_22.mercury__lexer__token_0__error_1__base_1')
...

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

107

[mercury] Bug

minor

N/A

2009-09-24 05:56

2009-09-24 22:30

Reporter:

gloomdemon

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 kill function while link mercury compiler under mingw

Description:

error while link compiler under mingw with gcc 3.4 (4.4)
file compiler/libs.process_util.c, line 644, function send_signal
calling kill(Pid, Signal) not wrapped with #ifdef MC_CAN_FORK

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2009-04-08 13:27

2009-09-22 17:35

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:

large ground terms optimisation and unique modes

Description:

The optimised handling of large ground terms (23 Dec) breaks mode checking when the term being constructed is declared to be unique. When the term is large enough for the optimisation to kick in, the term is assumed to be non-unique.

I tracked this as far as "TermInst = bound(shared, [BoundInst])," in modecheck_ground_term_construct_goal_loop.

Tags:

Steps To Reproduce:

Additional Information:

On the attached example the error message is:

uo_regression1.m:035: In clause for `init_message = uo':
uo_regression1.m:035: mode error: argument 1 had the wrong instantiatedness.
uo_regression1.m:035: Final instantiatedness of `HeadVar__1' was
uo_regression1.m:035: `bound(uo_regression1.response(bound((uo_regression1.status_ok)),
uo_regression1.m:035: bound((maybe.no)), bound((maybe.no)),
uo_regression1.m:035: bound((maybe.no)), bound((maybe.no))))',
uo_regression1.m:035: expected final instantiatedness was `unique'.

Attached Files:

uo_regression1.m (1,195 bytes) 2009-04-08 13:27
https://bugs.mercurylang.org/file_download.php?file_id=73&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

106

[mercury] Bug

major

always

2009-09-22 01:07

2009-09-22 02:09

Reporter:

janicek

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:

Linking with multiple C++ files yields a "duplicate symbol" error

Description:

Linking a Mercury main module with two (or more) C++ files that utilise some Mercury code through pragma foreign_export fails with the linker reporting the following:

** Error making `mercury_main'.
ld: duplicate symbol _MR_trace_tailrec_have_reused_frames in CPlusPlus2.o and CPlusPlus1.o
collect2: ld returned 1 exit status

(See the attachment for a minimal example.)

The platform is Darwin (Mac OS X 10.5.8), using Apple's GCC 4.1.2 which is shipped with Xcode 3.1.2.

$ uname -a
Darwin dfki-guestpool3.dfki.uni-sb.de 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

$ g++ --version
i686-apple-darwin9-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5566)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ mmc --version
Mercury Compiler, version rotd-2008-11-30, configured for i686-apple-darwin9.6.0
Copyright (C) 1993-2008 The University of Melbourne

Tags:

Steps To Reproduce:

Additional Information:

Adding the keyword "extern" to variables

MR_trace_tailrec_have_reused_frames
and
MR_trace_tailrec_num_reused_frames

in `mercury_trace_base.h'

seems to resolve the issue, i.e. the program links and seems to run fine.

Attached Files:

duplicate-symbol-error.tar.gz (1,794 bytes) 2009-09-22 01:07
https://bugs.mercurylang.org/file_download.php?file_id=80&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

101

[mercury] Bug

major

always

2009-07-23 17:58

2009-07-28 16:45

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:

Deep profiling of programs compiled against G12 creates currupt Deep.data files.

Description:

When running even trivial programs such as "hello world" against the G12 libraries the Mercury runtime cannot correctly write out the proc statics to the Deep.data file.

Tags:

Steps To Reproduce:

Additional Information:

pbone@goliath:/home/goliath/pbone/rect_pack$ ./hello
Hello world!
Mercury runtime: MR_write_out_proc_static: seen ps
pbone@goliath:/home/goliath/pbone/rect_pack$ echo $?
1

The minimal set of G12 libraries required to trigger this problem can be linked against if Mercury.options contains:

include "/home/goliath/pbone/g12/install/G12.options"
MCFLAGS = $(G12_LIBFLAGS_ZINC_RT) $(G12_LIBFLAGS_ZINC_GENERIC_PROP) $(G12_LIBFLAGS_LAZYFD) $(G12_LIBFLAGS_COMMON)

This occurs regardless of optimization level.

mmc --grade asm_fast.gc.trseg.profdeep --rebuild hello

Note that G12 requires trailing so this cannot be tested in a non-trailed grade.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

tweak

always

2009-05-28 12:07

2009-06-16 15:27

Reporter:

pbone

Platform:

Assigned To:

rafe

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

no change required

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

svset module descriptions don't match declarations.

Description:

In the svset module descriptions of predicates don't match their declarations.

Tags:

Steps To Reproduce:

Additional Information:

For example:

     % `svset.insert(X, Set0, Set)' is true iff `Set' is the union of
     % `Set0' and the set containing only `X'.
     %
  :- pred svset.insert(T::in, set(T)::in, set(T)::out) is det.

The description says insert/3 is *true iff* however the predicate is deterministic. As a user I'm not sure if this will throw an exception if the key already exists or just ignore it.

It may be best to adjust the declaration to match the description.

  paul@tarrango:~/code/edsnap/src$ mmc -V
  Mercury Compiler, version rotd-2009-03-13, configured for i686-pc-linux-gnu
  Copyright (C) 1993-2009 The University of Melbourne
  Usage: mmc [<options>] <arguments>
  Use `mmc --help' for more information.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2009-06-03 00:17

2009-06-12 15:13

Reporter:

juliensf

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:

rotd-2009-06-02 generates invalid Erlang code

Description:

When compiled in the erlang grade the attached test case results in an
error message from the Erlang compiler.

$ mmc --grade erlang --make zf_erlang_bug

Making Mercury/beams/zf_erlang_bug.beam
Mercury/erls/zf_erlang_bug.erl:64: variable 'STATE_VARIABLE_IO_1_12' unsafe in 'case' (line 43)
** Error making `Mercury/beams/zf_erlang_bug.beam'.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

zf_erlang_bug.m (1,703 bytes) 2009-06-03 00:17
https://bugs.mercurylang.org/file_download.php?file_id=75&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-09-11 12:36

2009-04-06 02:49

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:

ambiguous names in foreign_export

Description:

The compiler does the wrong thing if the predicate in a foreign_export is
ambiguous. e.g. for the attached test case

% mmc -C fe
fe.m:018: Error: `:- pragma foreign_export' declaration for `make_io_error'/2
fe.m:018: without corresponding `pred' or `func' declaration.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

fe.m (844 bytes) 2008-09-11 12:36
https://bugs.mercurylang.org/file_download.php?file_id=66&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-07-14 10:44

2009-03-26 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:

version_hash_table.delete is buggy

Description:

version_hash_table.delete doesn't always delete the element. See the test case.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

vht_delete.m (1,341 bytes) 2008-07-14 10:44
https://bugs.mercurylang.org/file_download.php?file_id=52&type=bug
ht_delete.m (1,564 bytes) 2008-08-07 15:57
https://bugs.mercurylang.org/file_download.php?file_id=62&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2009-03-09 23:43

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:

generated C code contains a block that defines a variable that shadows a headvar in hlc.gc

Description:

Compiling the C code generated for the attached module in the hlc.gc grade results in:

shadowed_headvar.m: In function 'shadowed_headvar__type_defined_in_runtime_1_p_0':
shadowed_headvar.m:64: warning: declaration of 'shadowed_headvar__HeadVar__1_1' shadows a parameter
shadowed_headvar.m:38: warning: shadowed declaration is here

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

shadowed_headvar.m (2,455 bytes) 2009-03-09 23:43
https://bugs.mercurylang.org/file_download.php?file_id=71&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

block

always

2008-11-17 07:42

Reporter:

psnively

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_odbc hangs on call to SQLConnect()

Description:

I'm running Mac OS X 10.5.5 on a PowerPC box. I have EnterpriseDB's "Postgres Plus" distro 8.3.5 installed. This means that my iODBC driver manager version is 03.52.0406.1211 and my PostgreSQL ODBC driver (psqlodbcw.so) version is 08.03.0200, both as reported by iodbctest. I've created a database called "test" with a table called "test" and populated the table with some simple sample data. I've also created an ODBC DSN called "test" referring to the test DB. I've confirmed that I can access the DSN with iodbctest and select data from the "test" table that way.

I've done a complete build of all available grades of the 2008-10-19 release of Mercury on this box, as excruciating as that was. I'm now attempting to get the ODBC interface working. In my Mmakefile, I have MODBC_DRIVER=MODBC_IODBC, MODBC_DB = MODBC_SQL_SERVER (because there isn't explicit support for PostgreSQL but the MySQL support seems quite limited relative to SQL Server and PostgreSQL is more likely to be as featureful as SQL Server than as limited as MySQL), and MLLIBS=-liodbc -lpthread -ldl. At the top of the file, I've also added:

GRADEFLAGS = --debug
CFLAGS = -DMR_DEBUG_ON=1

in order to be able to use mdb and get logging output from C functions that generate it, which, thankfully, the C functions in odbc.m do.

With this configuration, odbc_test builds fine, and I can run it under mdb and step through it. I see the list of datasources on my box:

Available data source names:
source_desc("test", "Postgres Plus ODBC Driver")

and the expected log output up to and including:

SQLAllocEnv status: 0
SQLAllocConnect status: 0
manual commit status: 0

from do_open_connection(). However, I never see a "connect status:" log entry at all, leading me to believe that SQLConnect() is never returning.

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

major

sometimes

2008-10-29 11:48

2008-11-03 14:09

Reporter:

pbone

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:

Programs compiled in profdeep grade create currupt Deep.data files.

Description:

Programs compiled in the asm_fast.gc.profdeep grade exit with a message similar to
"Not all nodes written out, Deep.data file corrupted".

Programs tasted: mercury compiler, mdprof_dump, hello world, and the test suite, they all show the same symptom.

Tags:

Steps To Reproduce:

Additional Information:

This occurs when using a compiler from roughly 2008-10-27. But not when using a compiler from 2008-10-12. (Tested on taura)

The bug has probably existed for a while but has only surfaced recently due to some seemingly-unrelated change.

When I have spare time I'll continue to bisect time to track down when exactly this surfaced.

Attached Files:

Notes

I don't know why the problem only surfaced recently, but it seems that its
underlying cause is a misunderstanding about the import_status of predicates.

In integer.m in the library, the predicate integer.to_string calls the function
string.++.

(a) String.++ is marked (correctly) as opt_imported.
(b) The test predicate pred_info_is_imported FAILS for opt_imported predicates.
(c) This causes make_rtti_proc_label to put "no" into the pred_is_imported
    field of the rtti_proc_label for string.++.
(d) This rtti_proc_label is put into the element of the call_site_static_data
    list for integer.to_string that corresponds to the call to string.++
    as the rtti_proc_label of the callee.
(e) When the time comes to write out the call_site_static structures,
    layout_out.m invokes make_proc_label_from_rtti to convert this
    rtti_proc_label in the call_site_static_data to a plain, non-RTTI
    proc_label. However, since the current module name ("integer") does not
    match the name of the module that defines the function ("string") AND
    the function is not marked as imported, make_user_proc_label (invoked
    from make_proc_label_from_rtti) believes that this means that this module
    generates code for the callee (as we do for some opt_imported procedures).
(f) For procedures for which we generate target code in a different module
    than their defining module, we generate different labels for them
    than the label for the code for the procedure in its own module.
    We derive the name of a procedure's proc_static structure directly from
    its label, so this difference holds for the names of proc_static structures
    as well as for labels.
(g) This lead to the problem, which was that the call_site_static for this call
    site referred to the proc_static for string.++ defined in integer.c
    (as opposed to string.++ defined in string.c), since integer.c did not
    actually generate code for string.++, there was no such proc_static.
    This should be a link error, but it isn't, due to the requirement on unix
    linkers of being compatible with Fortran's ancient semantics (specifically,
    Fortran's common areas). Instead, the C compiler happily allocates memory
    for the undefined symbol and fills it with zeros as if it were a
    proc_static structure.
(h) The assertion violation in mercury_deep_profiling.c occurs because the
    call_site_static refers to this bogus proc_static, but of course no module
    writes out this proc_static.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-02-04 11:01

2008-10-22 15:35

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:

bug with LCMC in hlc grades

Description:

In the attached test case, a list is converted to a bag then back again.
The input is [1,1,1,2,3,3,4]. The output should be the same.
When the module is compiled with

mmc -s hlc.gc --optimize-constructor-last-call --no-inlining

the output is just "[1]".

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bag_to_list.m (665 bytes) 2008-02-04 11:01
https://bugs.mercurylang.org/file_download.php?file_id=35&type=bug

Notes

The reason that the compiler no longer performs LCMC optimisation is a change in the
behaviour of common structure optimisation:

Compiling with: -O2 --optimize-constructor-last-call --nolining --no-common-struct
gives me the following at stage 135 (which is the last pass that does something meaningful
before the LCMC pass) for the predicate to_list_2.

bag_to_list.to_list_2(TypeInfo_for_T, HeadVar__1, HeadVar__2) :-
  ( % cannot_fail switch on `HeadVar__1'
    % HeadVar__1 has functor list.[]/0
    HeadVar__2 = list.[]
  ;
    % HeadVar__1 has functor list.[|]/2
    HeadVar__1 = list.[V_9 | Xs],
    V_9 = pair.(X - Int),
    (if
      V_10 = 0,
      int.(Int =< V_10)
    then
      bag_to_list.to_list_2(TypeInfo_for_T, Xs, HeadVar__2)
    else
      V_11 = 1,
      NewInt = int.(Int - V_11),
      V_13 = pair.(X - NewInt),
      V_12 = list.[V_13 | Xs],
      bag_to_list.to_list_2(TypeInfo_for_T, V_12, Out0),
      HeadVar__2 = list.[X | Out0]
    )
  ).

Enabling common structure optimisation gives the following:

bag_to_list.to_list_2(TypeInfo_for_T, HeadVar__1, HeadVar__2) :-
  ( % cannot_fail switch on `HeadVar__1'
    % HeadVar__1 has functor list.[]/0
    HeadVar__2 = list.[]
  ;
    % HeadVar__1 has functor list.[|]/2
    HeadVar__1 = list.[V_9 | Xs],
    V_9 = pair.(X - Int),
    (if
      V_10 = 0,
      int.(Int =< V_10)
    then
      bag_to_list.to_list_2(TypeInfo_for_T, Xs, Out)
    else
      V_11 = 1,
      NewInt = int.(Int - V_11),
      V_13 = pair.(X - NewInt),
      V_12 = list.[V_13 | Xs],
      bag_to_list.to_list_2(TypeInfo_for_T, V_12, Out0),
      Out = list.[X | Out0]
    ),
    HeadVar__2 = Out
  ).

The unification HeadVar__2 = Out is introduced in stage 65 by common structure optimisation
and it inhibits LCMC. Compiling with --no-common-struct causes the program to exhibit
the original buggy behaviour reported by Peter Wang.

Since there is no advantage gained by adding the new assignment unification and given
that it inhibits other optimisations this behaviour from --common-struct is also a bug.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-09-23 09:44

2008-09-23 18:45

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:

stage 1 compiler aborts when compiled with -O5 --intermodule-optimization

Description:

Compilation of compiler/deep_profiling.m fails in grade asm_fast.gc with
-O5 --intermodule-optimization using ROTD 2008-09-19 (on taura, although
this is occurring on all machines that use the above optimization settings).

The abort message is:

Uncaught Mercury exception:
Software Error: code_gen.m: Unexpected: nondet model in det/semidet context
Stack dump not available in this grade.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug85.m (5,854 bytes) 2008-09-23 16:14
https://bugs.mercurylang.org/file_download.php?file_id=67&type=bug

Notes

The body of the affected predicate has two switches followed by an if-then-else. Deforestation pushes the second switch and the if-then-else into each arm of the first switch, and then specializes the if-then-else. The problem is that in the process of specialization, it sets the determinism of the condition to nondet, when it should be semidet. The cause could be fact that, after propagating CoverageAfterKnown0 = CoverageAfterKnown1, it replaces the original test in the condition (CoverageAfterKnown1 = coverage_after_known) with a test on CoverageAfterKnown0, and thus updates the nonlocals set. It may think that this affects the determinism of the disjunction that is the condition, but in this case it doesn't.

The problem part of the HLDS dump is the following.

   ( % cannot_fail switch on `MaybeDPCoverageInfo'
      % MaybeDPCoverageInfo has functor maybe.no/0
      % nonlocals: CoverageAfterKnown0, GoalExpr0, CPOptions, IsMDProfInst, CoverageAfterKnown
      % determinism: multi
      ( % conjunction
        % nonlocals: GoalTrivial
        % determinism: det
        GoalTrivial = bug85.goal_is_nontrivial
        ,
        % nonlocals: CoverageAfterKnown0, GoalExpr0, CPOptions, IsMDProfInst, GoalTrivial, CoverageAfterKnown
        % determinism: multi
        (if
          % nonlocals: CoverageAfterKnown0, GoalExpr0, IsMDProfInst, GoalTrivial
          % determinism: nondet
          ( % disjunction
            % nonlocals: IsMDProfInst
            % determinism: semidet
            IsMDProfInst = bug85.goal_is_mdprof_inst
          ;
            % nonlocals: CoverageAfterKnown0
            % determinism: semidet
            CoverageAfterKnown0 = bug85.coverage_after_known
          ;
            % nonlocals: GoalTrivial
            % determinism: semidet
            GoalTrivial = bug85.goal_is_trivial
          ;
            % nonlocals: GoalExpr0
            % determinism: semidet
            ( % conjunction
              % nonlocals: GoalExpr0, V_42
              % determinism: semidet
              GoalExpr0 = bug85.conj(V_42, V_25)
              ,
              % nonlocals: V_42
              % determinism: semidet
              V_42 = bug85.plain_conj
            )
          )

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-08-02 18:16

2008-09-17 08:33

Reporter:

iamphet

Platform:

Assigned To:

petdr

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Erroneous reference to snprintf when compiling mercury_wrapper.c with MSVC

Description:

There are several several references to snprintf in mercury_wrapper.c without autoconf checks.

It seems the correct way is to add lines below at the top of the file

#if defined(MR_HAVE__SNPRINTF) && ! defined(MR_HAVE_SNPRINTF)
#define snprintf _snprintf
#endif

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

crash

always

2008-08-07 02:32

2008-09-02 04:42

Reporter:

obo

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

confirmed

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

abstract data types in type classes get garbled on x64

Description:

The attached code is a reduced version of bug 0000073 (please close bug 0000073).

What happens is that the method recombine/1 of typeclass stackable/3 instantiated by the predicate myrecombine/1 gets called with a bad type information on 64-bit machines (rotd-2008-08-03):

18:15 tauri4 nano-nano$./bug_x64_typeclass
insprune calls recombine: bug_x64_typeclass.h(string, string)
Recombining: bug_x64_typeclass.h(bug_x64_typeclass.h(string, string), bug_x64_typeclass.h(string, string))
Uncaught Mercury exception:
Software Error: type screwed up

On 32-bit machines (rotd-2007-08-13, I don't have a fresher version, sorry), the code works.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug_x64_typeclass.m (1,940 bytes) 2008-08-07 02:32
https://bugs.mercurylang.org/file_download.php?file_id=61&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

major

always

2008-08-25 14:38

2008-08-27 14:05

Reporter:

maclarty

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:

Functions returning a wrapped dummy type cause invalid c code to be generated in grade hlc.gc

Description:

Compiling the attached code yields:

$ mmc --make --grade hlc.gc main
Making Mercury/int3s/main.int3
Making Mercury/int3s/mod1.int3
Making Mercury/ints/main.int
Making Mercury/ints/mod1.int
Making Mercury/cs/main.c
Making Mercury/cs/mod1.c
Making Mercury/os/main.o
main.m: In function `main_2_p_0':
main.m:14: error: void value not ignored as it ought to be
** Error making `Mercury/os/main.o'.

$ mmc --version
Mercury Compiler, version rotd-2008-08-20, configured for i686-pc-linux-gnu

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

main.m (186 bytes) 2008-08-25 14:38
https://bugs.mercurylang.org/file_download.php?file_id=64&type=bug
mod1.m (192 bytes) 2008-08-25 14:39
https://bugs.mercurylang.org/file_download.php?file_id=65&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-08-22 16:00

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:

failure of hard_coded/tl_backjump_test with --intermodule-optimization

Description:

This is failing because the compiler is not adding a foreign_import_module declaration
to thread.opt for the thread module.

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-08-14 15:13

2008-08-22 13:12

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:

--make-opt-int incorrectly handles existentially typed methods

Description:

The compiler aborts when making a .opt file if the module contains a
typeclass instance which implements a method with existentially typed
arguments, but the predicate which implements the method is not itself
existentially typed, e.g.

    :- typeclass dynamic_block(T) where [
    some [Q] pred generate_block(T::in, Q::out) is det
    ].

    :- instance dynamic_block(simple_dynamic_block) where [
    pred(generate_block/2) is do_generate_block
    ].

    :- pred do_generate_block(simple_dynamic_block::in, string::out) is det.

% mmc --make-opt-int intermod_typeclass_exist
Uncaught Mercury exception:
Software Error: pred_table.m: Unexpected: type error in pred call: no matching pred
Stack dump follows:
   0 pred exception.throw/1-0 (erroneous) (exception.m:388)
   1 pred require.error/1-0 (erroneous) (require.m:122)
   2 pred libs.compiler_util.unexpected/2-0 (erroneous) (compiler_util.m:87)
   3 pred hlds.pred_table.resolve_pred_overloading/7-0 (det) (pred_table.m:983)
   4 pred transform_hlds.intermod.qualify_instance_method/5-0 (det) (intermod.m:907)
   5 pred list.map_foldl/5-1 (det) (list.m:2292)
   6 pred transform_hlds.intermod.gather_instances_3/5-0 (det) (intermod.m:822)
   7 pred list.foldl/4-1 (det) (list.m:2164)
   8 pred transform_hlds.intermod.gather_instances_2/5-0 (det) (intermod.m:786)
   9 2* pred tree234.foldl/4-0 (det) (tree234.m:2506 and others)
  11 pred map.foldl/4-0 (det) (map.m:863)
  12 pred transform_hlds.intermod.gather_instances/2-0 (det) (intermod.m:779)
  13 pred transform_hlds.intermod.write_opt_file/4-0 (det) (intermod.m:171)
  14 pred top_level.mercury_compile.maybe_write_optfile/7-0 (det) (mercury_compile.m:2287)
  15 pred top_level.mercury_compile.frontend_pass_no_type_error/9-0 (det) (mercury_compile.m:2238)
  16 pred top_level.mercury_compile.frontend_pass/11-0 (det) (mercury_compile.m:2110)
  17 pred top_level.mercury_compile.mercury_compile/8-0 (det) (mercury_compile.m:1499)
  18 pred top_level.mercury_compile.compile/10-0 (det) (mercury_compile.m:1478)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

intermod_typeclass_exist.m (1,037 bytes) 2008-08-14 15:13
https://bugs.mercurylang.org/file_download.php?file_id=63&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-07-03 15:22

2008-08-07 11:20

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:

probable bug in .stseg grades

Description:

We can't bootcheck in asm_fast.gc.decldebug.stseg. This is on saturn. The
compiler crashes when trying to make the stage 2 dependencies:

% MERCURY_OPTIONS= mmake depend
...
make[1]: *** [mer_std.depend] Illegal instruction
make[1]: Leaving directory `/home/saturn/wangp/ws_try_debug_stseg_bootcheck/stage2/library'

The crash goes away if you bump up the nondet stack size (e.g. --nondetstack-size 8192).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

nondet_stseg.m (1,413 bytes) 2008-07-18 17:09
https://bugs.mercurylang.org/file_download.php?file_id=53&type=bug
nondetstseg2.diff (15,373 bytes) 2008-08-01 14:53
https://bugs.mercurylang.org/file_download.php?file_id=57&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-07-23 20:02

2008-07-23 21:06

Reporter:

pbone

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:

Deep profiling tools can have integer overflows.

Description:

The deep profiler and it's tools use machine word sized integers. (the int type in mercury). On 32 bit machines these values can be overflowed by a long-enough profiling run. Since the int type is a signed integer this can result in negative numbers.

This can be seen with the icfp2000 program in the 'bytes allocated' statistic of the float.+ and float.* functions.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-06-26 10:52

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:

mdprof_cgi gets confused about the webserver's port number.

Description:

When running mdprof_cgi through apache as normal. And accessing it both directly and with ssh port-forwarding from a remote host (via a different TCP port) it places the wrong port number in URLs.

Tags:

Steps To Reproduce:

Additional Information:

It seems that the first use of mdprof_cgi causing it to start the backend server sets the port number (and probably hostname and path to cgi executable). for future sessions.

To work-around this issue when accessing mdprof_cgi via a different url than used earlier, kill the background process. This doesn't scale to allow concurrent access.

Attached Files:

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

have not tried

2008-06-06 13:01

2008-06-06 18:33

Reporter:

pbone

Platform:

Assigned To:

juliensf

OS:

Priority:

low

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

duplicate

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Compiler crashes at bad end_module declaration.

Description:

When i mis-spell the end_module declaration differently to the module declaration, the complier crashes. This seems reproducible but I have not written a test case.

Tags:

Steps To Reproduce:

Additional Information:

pbone@plum:~/mercury/mdprof_data_structure/deep_profiler$ mmake
/usr/local/mercury/bin/mmc --make-interface --grade asm_fast.gc --mercury-linkage static --flags DEEP_FLAGS percent_adt
Uncaught Mercury exception:
Software Error: modules.m: Unexpected: standardize_impl_items: unexpected items
Stack dump not available in this grade.
make: *** [percent_adt.date] Error 1

pbone@plum:~/mercury/mdprof_data_structure/deep_profiler$ /usr/local/mercury/bin/mmc --version
Mercury Compiler, version rotd-2008-02-11, configured for i686-pc-linux-gnu
Copyright (C) 1993-2008 The University of Melbourne

pbone@plum:~/mercury/mdprof_data_structure/deep_profiler$ gcc --version
gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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-06-03 18:40

2008-06-03 18:41

Reporter:

maclarty

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:

problem with _init suffix in module names

Description:

If the main predicate is defined in module 'test', and module 'test' imports module 'test_init', then running mmc --make results in the following link error:

** Error making `test'.
Mercury/os/test_init.o: In function `<predicate 'test_init.p'/2 mode 0>':
test_init.c:(.text+0x14): multiple definition of `<predicate 'test_init.p'/2 mod
e 0>'
Mercury/os/test_init.o:test_init.c:(.text+0x14): first defined here
Mercury/os/test_init.o: In function `mercury__test_init__init_debugger':
test_init.c:(.text+0x20): multiple definition of `mercury__test_init__init_debug
ger'
Mercury/os/test_init.o:test_init.c:(.text+0x20): first defined here
Mercury/os/test_init.o: In function `mercury__test_init__init':
test_init.c:(.text+0x40): multiple definition of `mercury__test_init__init'
Mercury/os/test_init.o:test_init.c:(.text+0x40): first defined here
Mercury/os/test_init.o: In function `mercury__test_init__init_type_tables':
test_init.c:(.text+0x70): multiple definition of `mercury__test_init__init_type_
tables'
Mercury/os/test_init.o:test_init.c:(.text+0x70): first defined here
/usr/lib/gcc/i486-linux-gnu/3.4.6/../../../../lib/crt1.o: In function `_start':
../sysdeps/i386/elf/start.S:115: undefined reference to `main'
collect2: ld returned 1 exit status

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

test.m (162 bytes) 2008-06-03 18:40
https://bugs.mercurylang.org/file_download.php?file_id=49&type=bug
test_init.m (122 bytes) 2008-06-03 18:41
https://bugs.mercurylang.org/file_download.php?file_id=50&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

major

always

2008-03-29 02:38

2008-06-02 15:06

Reporter:

obo

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

confirmed

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

typeclass instances for e.g. bag(T) no longer work

Description:

with rotd-2008-03-27, the attached file bug.m gives the following error:

bug.m:001: Warning: interface for module `bug' does not export anything.
bug.m:011: In instance declaration for `bug.fooable((bag.bag(V)))':
bug.m:011: the first arg contains a type variable which is used in another
bug.m:011: arg

with rotd-2007-08-13, the same code was compilable and worked as expected.

When I tried to avoid the type variable by instantiating the typeclass for eg. bag(string) specifically, the recent ROTD gives me this error:

testhugemap.m:047: In instance declaration for
testhugemap.m:047: `pickle.tc_picklable((bag.bag(string)))':
testhugemap.m:047: the first arg is a type whose first arg is not a variable

What is the correct way of instantiating such typeclasses?

Thanks, Ondrej.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug.m (206 bytes) 2008-03-29 02:38
https://bugs.mercurylang.org/file_download.php?file_id=47&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

major

always

2008-04-09 12:52

2008-05-26 13:13

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:

compiler crashes in decldebug grade

Description:

The stage1 compiler crashes in decldebug grades. The workaround is:

MCFLAGS-check_hlds.polymorphism = --no-common-struct
MCFLAGS-transform_hlds.lambda = --no-common-struct

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-04-29 13:51

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:

inconsistent type_infos after type specialisation?

Description:

The following test case the compiler aborts with the message:

% mmc my
Uncaught Mercury exception:
Software Error: hlds_rtti.m: Unexpected: inconsistent type_infos
Stack dump follows:
   0 pred exception.throw_impl/1-0 (erroneous) (exception.m:817)
   1 pred exception.throw/1-0 (erroneous) (exception.m:388)
   2 pred require.error/1-0 (erroneous) (require.m:122)
   3 pred libs.compiler_util.unexpected/2-0 (erroneous) (compiler_util.m:87)
   4 pred hlds.hlds_rtti.apply_substs_to_type_map/7-0 (det) (hlds_rtti.m:642)
   5 2* pred tree234.foldl/4-0 (det) (tree234.m:2492 and others)
   7 pred map.foldl/4-0 (det) (map.m:871)
   8 pred hlds.hlds_rtti.apply_substitutions_to_rtti_varmaps/5-0 (det) (hlds_rtti.m:565)
   9 pred check_hlds.simplify.excess_assigns_in_conj/5-0 (det) (simplify.m:2919)
  10 pred check_hlds.simplify.simplify_goal_2_plain_conj/6-0 (det) (simplify.m:889)
  11 pred check_hlds.simplify.simplify_goal_2/6-0 (det) (simplify.m:836)
  12 pred check_hlds.simplify.simplify_goal/4-0 (det) (simplify.m:766)
  13 pred check_hlds.simplify.do_process_clause_body_goal/4-0 (det) (simplify.m:541)
  14 pred check_hlds.simplify.simplify_process_clause_body_goal/4-0 (det) (simplify.m:526)
  15 pred transform_hlds.pd_util.pd_simplify_goal/5-0 (det) (pd_util.m:254)
  16 pred transform_hlds.deforest.deforest_proc_2/7-0 (det) (deforest.m:212)
  17 pred transform_hlds.deforest.deforest_proc/5-0 (det) (deforest.m:193)
  18 17* pred list.foldl2/6-5 (det) (list.m:2056 and others)
  35 pred transform_hlds.deforest.deforestation/4-0 (det) (deforest.m:121)
  36 pred top_level.mercury_compile.maybe_deforestation/6-0 (det) (mercury_compile.m:3942)
  37 pred top_level.mercury_compile.middle_pass/7-0 (det) (mercury_compile.m:2668)
  38 pred top_level.mercury_compile.mercury_compile_after_front_end/10-0 (det) (mercury_compile.m:1588)
  39 pred top_level.mercury_compile.mercury_compile/8-0 (det) (mercury_compile.m:1531)
  40 pred top_level.mercury_compile.compile/10-0 (det) (mercury_compile.m:1464)
  ...

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug.tar.gz (724 bytes) 2008-04-29 13:51
https://bugs.mercurylang.org/file_download.php?file_id=48&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-04-10 11:51

Reporter:

juliensf

Platform:

Assigned To:

mark

OS:

Priority:

normal

OS Version:

Status:

assigned

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

--common-struct inhibits tail call optimisation

Description:

In some cases --common-struct is introducing extra assignment unifications after
recursive calls. This is inhibiting tail call recursion.

The test case for bug 0000042 exhibits this problem (see the notes for that problem.)

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-03-13 17:07

2008-03-27 23:42

Reporter:

maclarty

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:

rebuilding a program with a mutable in a different grade causes invalid c to be generated

Description:

Compile the attached program in hlc.gc and then rebuild in asm_fast.gc and the c compiler gives an error:

jupiter:/home/jupiter/maclarty/mut> mmc --make mut --grade hlc.gc
Making Mercury/int3s/mut.int3
Making Mercury/ints/mut.int
Making Mercury/cs/mut.c
Making Mercury/os/mut.o
Making mut
jupiter:/home/jupiter/maclarty/mut> ./mut
1
jupiter:/home/jupiter/maclarty/mut> mmc --make mut --grade asm_fast.gc
Making mut
** Error making `mut'.
Mercury/os/mut_init.o(.text+0x458): In function `mercury_init':
: undefined reference to `<predicate 'main'/2 mode 0>'
Mercury/os/mut.o(.text+0x1a): In function `<predicate 'main'/2 mode 0>':
: undefined reference to `<predicate 'io.write_int'/3 mode 0>'
Mercury/os/mut.o(.text+0x22): In function `<predicate 'main'/2 mode 0>':
: undefined reference to `<predicate 'io.nl'/2 mode 0>'
collect2: ld returned 1 exit status

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

mut.m (247 bytes) 2008-03-13 17:07
https://bugs.mercurylang.org/file_download.php?file_id=46&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

major

always

2007-12-20 15:54

2008-03-26 15:36

Reporter:

maclarty

Platform:

Assigned To:

mark

OS:

Priority:

normal

OS Version:

Status:

assigned

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Compiler abort when generating low level code

Description:

Running "mmc --make bug" on the attached source files results in the following abort from the compiler:

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

The abort happens after:
% Generating low-level (LLDS) code for predicate `bug.test'/4 mode 0

Turning off all optimisations makes no difference.

I trimmed the test case down as much as I could, but any further changes seem to make the bug go away.

I'm using rotd-2007-12-19 on jupiter.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-02-28 02:55

2008-03-26 15:32

Reporter:

juliensf

Platform:

Assigned To:

mark

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 in .decldebug grade

Description:

Compiling compiler/analysis.m in asm_fast.gc.decldebug on pluto (linux-x86_64) results in

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

This Mercury compiler used was rotd-2008-02-27.
Compiling the affected module with -O0 makes the problem go away.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

DIFF.55_65 (11,818 bytes) 2008-02-28 16:27
https://bugs.mercurylang.org/file_download.php?file_id=41&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-03-26 15:28

Reporter:

mark

Platform:

Assigned To:

mark

OS:

Priority:

normal

OS Version:

Status:

assigned

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

rtti_varmaps not updated by follow_code

Description:

The rtti_varmaps data structure keeps track of which program
variables hold which type(class)_infos. When follow_code migrates
an existentially typed deconstruction into the branches of a
branched goal, a type(class)_info that was accessed from one
location is now accessed from multiple locations -- none of
which is correct in all cases.

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-02-28 18:36

2008-03-17 17:21

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:

loop invariant hoisting causes MLDS backend to abort

Description:

The attached program causes the MLDS backend to abort when compiled in a hl or hlc grade
with:

mmc -C -O0 --common-struct --loop-invariants

The problem seems to be related to the fact that calls to array.init/1 are being incorrectly
hoisted (presumably because they arrays are not unique at the moment.)

The LLDS backend compiles this code down to what is invalid C code (at least on eris).

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

colgen_dw.m (1,777 bytes) 2008-02-28 18:36
https://bugs.mercurylang.org/file_download.php?file_id=42&type=bug
str_loopinv.m (2,913 bytes) 2008-03-05 17:17
https://bugs.mercurylang.org/file_download.php?file_id=45&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-02-04 17:14

2008-03-05 18: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:

intermod unused args analysis and typeclass constraints

Description:

The compiler aborts on the following module, when performing unused argument
analysis while making the intermodule optimisation file, i.e.

mmc --intermod-unused-args --make-optimisation-interface bug

The seems to require these conditions:

a function f has a typeclass constraint, and
f is type specialised, and
the type that f is specialised for is polymorphic

Tags:

Steps To Reproduce:

Additional Information:

Here's a stack trace.

Uncaught Mercury exception:
Software Error: map.lookup: key not found
        Key Type: term.var(parse_tree.prog_data.tvar_type)
        Key Value: var(1)
        Value Type: hlds.hlds_rtti.type_info_locn
Stack dump follows:
   0 pred exception.throw_impl/1-0 (erroneous) (exception.m:816)
   1 pred exception.throw/1-0 (erroneous) (exception.m:388)
   2 pred require.error/1-0 (erroneous) (require.m:122)
   3 pred require.report_lookup_error/3-0 (erroneous) (require.m:98)
   4 pred map.lookup/3-0 (det) (map.m:612)
   5 pred hlds.hlds_rtti.rtti_lookup_type_info_locn/3-0 (det) (hlds_rtti.m:438)
   6 pred transform_hlds.unused_args.lambda_unused_args_m_553/3-0 (det) (unused_args.m:554)
   7 pred list.map/3-0 (det) (list.m:1890)
   8 pred transform_hlds.unused_args.setup_typeinfo_dep/6-0 (det) (unused_args.m:553)
   9 pred transform_hlds.unused_args.setup_typeinfo_deps/6-0 (det) (unused_args.m:544)
  10 pred transform_hlds.unused_args.setup_proc_args/12-0 (det) (unused_args.m:503)
  11 pred transform_hlds.unused_args.setup_pred_args/12-0 (det) (unused_args.m:379)
  12 pred transform_hlds.unused_args.maybe_setup_pred_args/11-0 (det) (unused_args.m:365)
  13 91* pred transform_hlds.unused_args.setup_local_var_usage/11-0 (det) (unused_args.m:336 and others)
104 pred transform_hlds.unused_args.init_var_usage/7-0 (det) (unused_args.m:323)
105 pred transform_hlds.unused_args.process_module/6-0 (det) (unused_args.m:224)
106 pred top_level.mercury_compile.maybe_unused_args/6-0 (det) (mercury_compile.m:4004)
107 pred top_level.mercury_compile.maybe_write_optfile/7-0 (det) (mercury_compile.m:2336)
108 pred top_level.mercury_compile.frontend_pass_no_type_error/9-0 (det) (mercury_compile.m:2242)
109 pred top_level.mercury_compile.frontend_pass/11-0 (det) (mercury_compile.m:2120)
110 pred top_level.mercury_compile.mercury_compile/8-0 (det) (mercury_compile.m:1518)
111 pred top_level.mercury_compile.compile/10-0 (det) (mercury_compile.m:1497)

Attached Files:

bug.m (252 bytes) 2008-02-04 17:14
https://bugs.mercurylang.org/file_download.php?file_id=36&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-02-25 11:43

2008-02-25 13:29

Reporter:

user57

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:

mutable dependency problem

Description:

The program (attached) contains two mutables `a' and `b' whose initialisation mutually depends on each other. Thus to initialise `a' we need the value of `b' and vice versa. Mercury does not detect this problem, and happily compiles the program, which (unsurprisingly) seg. faults when you try and run it.

Note that non-mutual dependencies may also be a problem, depending on the order the mutables are initialised. This is how the bug was discovered.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

crash.m (485 bytes) 2008-02-25 11:43
https://bugs.mercurylang.org/file_download.php?file_id=40&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

major

always

2008-02-07 16:44

2008-02-20 14:05

Reporter:

juliensf

Platform:

Assigned To:

OS:

Priority:

high

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

compiler abort in debug grades

Description:

The attached program causes the compiler to abort in (decl)debug grades with the
following error:

Uncaught Mercury exception:
Software Error: llds_out.m: Unexpected: stack var out of range

Compile with:

mmc --grade asm_fast.gc.tr.debug -C fzn_debug_abort.m

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

fzn_debug_abort.m (2,638 bytes) 2008-02-07 16:44
https://bugs.mercurylang.org/file_download.php?file_id=37&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-02-19 15:26

2008-02-20 14:03

Reporter:

maclarty

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:

mdb not using format params from .mdbrc

Description:

Compile the attached mdb.m in a debug grade.

Put the attached .mdbrc file in the same directory as the executable.

Run:

mdb ./mdb
Melbourne Mercury Debugger, mdb version rotd-2008-01-16.
Copyright 1998-2008 The University of Melbourne, Australia.
mdb is free software, covered by the GNU General Public License.
There is absolutely no warranty for mdb.
       1: 1 1 CALL pred mdb.main/2-0 (det) mdb.m:13
mdb> step
       2: 2 2 CALL func list.../2-0 (det) list.m:2561 (mdb.m:14)
mdb> finish
     817: 2 2 EXIT func list.../2-0 (det) list.m:2561 (mdb.m:14)
mdb> p 3
       List (arg 3)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, ...]
mdb> source .mdbrc
mdb> p 3
       List (arg 3)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21,
22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40,
41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59,
60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78,
79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97,
98, 99, 100]
mdb>

The source command should not be necessary for the format_param commands in .mdbrc to take effect.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

.mdbrc (50 bytes) 2008-02-19 15:26
https://bugs.mercurylang.org/file_download.php?file_id=38&type=bug
mdb.m (190 bytes) 2008-02-19 15:26
https://bugs.mercurylang.org/file_download.php?file_id=39&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-02-19 18:40

2008-02-20 13:44

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:

regression of general/det_complicated_unify in grade asm_fast.gc.profdeep

Description:

The test case general/det_complicated_unify causes the compiler to abort in
grade asm_fast.gc.profdeep with the following:

Uncaught Mercury exception:
Software Error: llds_out.m: Unexpected: stack var out of range

The test case passes in non .profdeep grades.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-11-28 15:29

2008-01-23 12:49

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:

break promise_equivalent_solutions

Description:

Inlining can cause the insts of variables to change from any to ground
and this, in turn, can cause erroneous error messages about promise_equivalent_solutions scopes that contain inst any variables in the scope head.

The attached test case is a cut-down version of the optimised version
of flatzinc_backend.m from the FlatZinc interpreter. This illustrates
the problem.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

equiv_solns_ia.m (1,278 bytes) 2007-11-28 15:29
https://bugs.mercurylang.org/file_download.php?file_id=23&type=bug
equiv_solns_ia.m.new (1,624 bytes) 2007-11-28 16:50
https://bugs.mercurylang.org/file_download.php?file_id=24&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-01-15 11:39

2008-01-17 00:30

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:

high-level C backend produces invalid C code

Description:

The attached test case causes the high-level C backend tries to initialise static data using
a function call (in order to box a float). The program compiles succesfully with the low-level
backend.

Tags:

Steps To Reproduce:

Additional Information:

This test case was derived from code generated by the experimental Zinc-to-Mercury
compiler.

Attached Files:

bad_static_data.m (1,195 bytes) 2008-01-15 11:39
https://bugs.mercurylang.org/file_download.php?file_id=33&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2008-01-16 14:02

Reporter:

rafe

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 aborts in detism analysis with inst any case in negated context

Description:

Try compiling this module:

===
:- module negctxtbug.
:- interface.
:- import_module bool, list.

:- pred any_square(list(list(T))::ia, bool::out) is det.

:- implementation.
:- import_module int.

any_square(Xss, YN) :-
        N = any_length(Xss),
        promise_pure
        ( if all [Xs] (any_member(Xs, Xss) => any_length(Xs) = N)
          then YN = yes
          else YN = no
        ).

:- func any_length(list(T)::ia) = (int::out) is det.

any_length([]) = 0.
any_length([_ | Xs]) = 1 + any_length(Xs).

:- pred any_member(T::oa, list(T)::ia) is nondet.

any_member(X, [X | _ ]).
any_member(X, [_ | Xs]) :- any_member(X, Xs).
===
The if-then-else condition causes the compiler to abort with:
Making Mercury/int3s/negctxtbug.int3
Making Mercury/ints/negctxtbug.int
Making Mercury/hlc.gc.tr/x86_64-unknown-linux-gnu/Mercury/cs/negctxtbug.c
Uncaught Mercury exception:
Software Error: det_analysis.m: Unexpected: inappropriate determinism inside a negation
Stack dump follows:
   0 pred exception.throw/1-0 (erroneous) (exception.m:388)
   1 pred require.error/1-0 (erroneous) (require.m:122)
   2 pred libs.compiler_util.unexpected/2-0 (erroneous) (compiler_util.m:87)
   3 pred check_hlds.det_analysis.det_infer_not/10-0 (det) (det_analysis.m:1305)
   4 pred check_hlds.det_analysis.det_infer_goal_2/12-0 (det) (det_analysis.m:607)
   5 pred check_hlds.det_analysis.det_infer_goal/11-0 (det) (det_analysis.m:434)
   6 pred check_hlds.det_analysis.det_infer_if_then_else/15-0 (det) (det_analysis.m:1238)
...

If you change s/ia/in/;s/oa/out/ then the bug does not manifest itself.

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-01-03 04:52

Reporter:

obo

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:

confusing error message in lambda function (but good message in predicate version)

Description:

The attached code has two routines, both exhibit the same error (unsatisfied uniqueness). However, only the 'pred' closure reports a reasonable error message. The 'func' version is just confusing:

confusing_message.m:001: Warning: interface for module `confusing_message' does
confusing_message.m:001: not export anything.
confusing_message.m:012: In clause for `nice_message(out)':
confusing_message.m:012: in argument 1 of call to predicate
confusing_message.m:012: `confusing_message.read_outcome'/3:
confusing_message.m:012: mode error: variable `COutcomes' has
confusing_message.m:012: instantiatedness `ground',
confusing_message.m:012: expected instantiatedness was `unique'.
confusing_message.m:020: In clause for `confusing_message(out)':
confusing_message.m:020: in argument 1 of call to function `int.fold_down'/4:
confusing_message.m:020: mode error: variable `V_7' has instantiatedness
confusing_message.m:020: `free',
confusing_message.m:020: expected instantiatedness was `(func((ground >>
confusing_message.m:020: ground), (ground >> ground)) = (free >> ground) is
confusing_message.m:020: det)'.

Best wishes in the new year,
yours Ondrej.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

confusing_message.m (1,766 bytes) 2008-01-03 04:52
https://bugs.mercurylang.org/file_download.php?file_id=30&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-12-14 18:37

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:

loop invariant optimization generates invalid HLDS

Description:

The bug can be reproduced by
mmc -Cv check_typeclass.m -Dmost -d145 -d150 -O5
The stage 150 HLDS dump shows that the loop invariant predicate for the is_valid_instance_type predicate has the argument HeadVar__6 in the argument list *twice*, in both cases with the mode unique>>unique, even though the right thing for loop_inv to do would have been not to pass it at all (it is computed *before* the loop is entered).

I think loop_inv might be confused by the fact that the sixth position in the "loop" call is an unwanted output.

Tags:

Steps To Reproduce:

Additional Information:

This bug occurs with version 1.117 of check_typeclass.m. I have a diff to make is_valid_instance_type look nicer, but the version with the change does not tickle this bug.

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

2007-12-09 03:36

2007-12-10 18:00

Reporter:

ony

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:

modules compilation on 64-bit platform eats too much memory

Description:

During building process of v0.13.1 on amd64-compatible platform there is stage with building modules (Internals) and at that moment there is huge memory usage which finally produce out of memory (tried at 2 GB ram + 4 GB swap).
As contrary to that 32-bit version is built normally on the same platform.

Tags:

Steps To Reproduce:

Additional Information:

CPU: Intel Core 2 Duo E6600
RAM: 2 GB
OS: GNU/Linux 2.6.23-gentoo-r2 0000002 SMP
Distribution: Gentoo Linux amd64 (default-linux/amd64/2007.0 profile)
GCC: gcc version 4.2.2 (Gentoo 4.2.2 p1.0)

Attached Files:

build.log.bz2 (16,040 bytes) 2007-12-09 04:16
https://bugs.mercurylang.org/file_download.php?file_id=25&type=bug
emerge_start.log.bz2 (818 bytes) 2007-12-09 04:16
https://bugs.mercurylang.org/file_download.php?file_id=26&type=bug
environment.bz2 (21,463 bytes) 2007-12-09 04:16
https://bugs.mercurylang.org/file_download.php?file_id=27&type=bug
config.log.bz2 (17,395 bytes) 2007-12-09 04:22
https://bugs.mercurylang.org/file_download.php?file_id=28&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-09-27 23:36

2007-12-09 03:45

Reporter:

anonymous

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:

change in --runtime-flags should rebuild <main>_init.o

Description:

From bojar@csse.unimelb.edu.au Fri Aug 17 14:47:53 2007
Date: Fri, 17 Aug 2007 14:49:19 +1000
From: Ondrej Bojar <bojar@csse.unimelb.edu.au>
To: mercury-bugs@csse.unimelb.edu.au
Subject: change in --runtime-flags should rebuild <main>_init.o

Hi.

If 'mmc --make' is used with --runtime-flags, it is not sufficient to touch the
source file of the main module after I change the flags.

If the correct behaviour (i.e. dependency of <main>_init.o on the actual string
of --runtime-flags) is difficult to implement, the user's manual/manpage should
probably remind users to delete the _init.o file.

Thanks, O.

--
Ondrej Bojar (mailto:obo@cuni.cz / bojar@ufal.mff.cuni.cz)
http://www.cuni.cz/~obo

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug-runtime-flags.tgz (577 bytes) 2007-11-19 14:38
https://bugs.mercurylang.org/file_download.php?file_id=22&type=bug

Notes

It failed now even without --use-subdirs.
My guess is that Mercury/os/test_init.o is not being recompiled, though Mercury/cs/test_init.c is correctly updated:

...
make test-w-stacksize.1000
make[1]: Entering directory `/home/obo/bug-runtime-flags'
rm -f test
mmc -V --make test --runtime-flags "--detstack-size 1000"
% Creating initialization file...
% Invoking system command `mkinit -g asm_fast.gc -r "--detstack-size 1000" -o Mercury/cs/test_init.c.tmp -I /home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/modules/asm_fast.gc /home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/modules/asm_fast.gc/mer_rt.init /home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/modules/asm_fast.gc/mer_std.init Mercury/cs/test.c'...
% done.
% Updating interface:
% `Mercury/cs/test_init.c' has CHANGED.
% Invoking system command `cp Mercury/cs/test_init.c.tmp Mercury/cs/test_init.c'...
% done.
Making test
% Linking...
% Invoking system command `gcc -s -o test Mercury/os/test_init.o Mercury/os/test.o -L/home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib -L/home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib/asm_fast.gc -Wl,-rpath,/home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib -Wl,-rpath,/home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib/asm_fast.gc /home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib/asm_fast.gc/libmer_std.a /home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib/asm_fast.gc/libmer_rt.a /home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib/libgc.a -lm '...
% done.
% done.
cp -L test test-w-stacksize.1000
make[1]: Leaving directory `/home/obo/bug-runtime-flags'
if diff test-w-stacksize.400000 test-w-stacksize.1000; then \
          echo "Files don't differ!"; \
          exit 1; \
        fi
Files don't differ!
make: *** [all] Error 1

When I run the two first lines of 'all' manually one by one, mmc -V log for the second run looks differently:

...
% `Mercury/cs/test_init.c' has CHANGED.
% Invoking system command `cp Mercury/cs/test_init.c.tmp Mercury/cs/test_init.c'...
% done.
% Compiling initialization file...
% Compiling `Mercury/cs/test_init.c':
% Invoking system command `gcc -I. -I. -I./Mercury/mihs -I/home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/lib/asm_fast.gc/inc -I/home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/conf -I/home/obo/opt/mercury-compiler-rotd-2007-09-22/lib/mercury/inc -O2 -fomit-frame-pointer -fno-strict-aliasing -DMR_USE_GCC_GLOBAL_REGISTERS -DMR_USE_GCC_NONLOCAL_GOTOS -DMR_USE_ASM_LABELS -fno-builtin -fno-omit-frame-pointer -fno-defer-pop -fno-function-cse -fno-gcse -DMR_CONSERVATIVE_GC -DMR_BOEHM_GC -DMR_TAGBITS=2 -ansi -Wall -Wwrite-strings -Wshadow -Wmissing-prototypes -Wno-unused -Wno-uninitialized -Wstrict-prototypes -c Mercury/cs/test_init.c -o Mercury/os/test_init.o'...
% done.
Making test
% Linking...
...

Could it be a slight time-stamping bug/hack between
  - % Invoking system command `cp Mercury/cs/test_init.c.tmp Mercury/cs/test_init.c'...
and
  - Making test
?

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

major

always

2007-11-15 12:28

2007-11-19 17:37

Reporter:

obo

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:

Unexpected: adjust_livevals

Description:

Hi,

I've come across a bug in tail recursion optimization (my guess) if foreign code is involved.

Typing 'make' in the testcase provided, mmc dies with this message:

Uncaught Mercury exception:
Software Error: jumpopt.m: Unexpected: adjust_livevals: BetweenLivevals and PrevLivevals differ
Stack dump not available in this grade.

If you explicitly prevent tail recursion by uncommenting the line:

% io.write_string("", !IO), % prevent tail recursion

at the end of testxmlreader.m, the code compiles, runs (and wastes quite some time, performance is 10x worse than same xmlreader demo implemented in C). I'm not sure if I can attribute all the performance loss to stack management and the extra boxing and unboxing.

If I fake all the calls to xmlreader, as in:

testxmlreader.m-no-C-code (to replace testxmlreader.m)

the jumpopt exception goes away.

Thanks, Ondrej.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

bug.tgz (1,939 bytes) 2007-11-15 12:28
https://bugs.mercurylang.org/file_download.php?file_id=20&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

crash

always

2007-11-12 15:35

2007-11-14 15:02

Reporter:

rafe

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:

Type var in instance declaration can cause compiler to crash

Description:

The compiler crashes when compiling the following code:

:- module instance_var_bug.
:- interface.
:- typeclass tc(T) where [ pred p(T::in) is semidet ].
:- implementation.
:- instance tc(V) where [ p(_) :- semidet_true ].

The bug is that the instance argument is a variable, but this is not being caught.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-10-12 12:57

2007-11-08 16:01

Reporter:

maclarty

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:

inconsistent treatment of true goals with no outputs.

Description:

Even with the --fully-strict option, mmc will optimise away a goal like the following:

    promise_pure(
        impure set_m(I) % m is a mutable.
    ).

However it will not optimise away the following goal under --fully-strict:

    p("hello")

where

p(I) :-
    trace [io(!IO)] (
        io.write(I, !IO)
    ).

(even with --no-inlining)

Either the semantics of --fully-strict needs to be further refined, or the compiler needs to behave the same in both of these cases.

Tags:

Steps To Reproduce:

Additional Information:

Attached is an example.

With mmc fs --fully-strict the call to p gets optimised away.
With mmc fs --fully-strict --no-inling it doesn't.

Attached Files:

fs.m (452 bytes) 2007-10-12 12:57
https://bugs.mercurylang.org/file_download.php?file_id=10&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

crash

always

2007-11-01 14:24

2007-11-01 14:29

Reporter:

petdr

Platform:

Assigned To:

OS:

Priority:

high

OS Version:

Status:

confirmed

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

tabling of predicates with type class constraints causes an internal compiler error

Description:

$ mmc --make table_tc
Making Mercury/int3s/table_tc.int3
Making Mercury/ints/table_tc.int
Making Mercury/cs/table_tc.c
Uncaught Mercury exception:
Software Error: table_gen.m: Unexpected: gen_lookup_call_for_type: typeclass_info_type
Stack dump not available in this grade.
** Error making `Mercury/cs/table_tc.c'.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

table_tc.m (369 bytes) 2007-11-01 14:24
https://bugs.mercurylang.org/file_download.php?file_id=17&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-10-22 14:54

2007-11-01 02:05

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:

equivalences for solver types lead to badly typed initialisation predicates

Description:

The attached code fragment exhibits a bug with solver types and
equivalence types that causes the compiler to report that an
initialisation predicate is badly typed. (The fragment compiles
without error if the equivalence type definition is commented out.)

(At a cursory glance, it looks like expansion of equivalence types is
not happening somewhere.)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

fz_conf.m (945 bytes) 2007-10-22 14:54
https://bugs.mercurylang.org/file_download.php?file_id=14&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

have not tried

2007-10-31 15:56

2007-10-31 17:45

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:

Debugger commands inconsistant with help message.

Description:

During a debugging session the "help forwards" information message describes a command called "fail" which dosn't appear to be supported. I don't know if it's supposed to work or not.

Tags:

Steps To Reproduce:

Additional Information:

mdb> help forward
forward - Commands that move execution forward.
             The forward commands are `step', `goto', `next', `finish',
             `fail', `exception', `return', `user, `forward',
             `mindepth', `maxdepth' and `continue'.

mdb> fail
Unknown command `fail'. Give the command `help' for help.

The command 'help fail' returns the main help page.

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-09-27 23:53

2007-10-26 15:48

Reporter:

anonymous

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

feedback

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

Type ctor module name bug

Description:

Date: Wed, 1 Aug 2007 17:45:29 +1000
From: Ralph Becket <rafe@csse.unimelb.edu.au>
To: Julien Fischer <juliensf@csse.unimelb.edu.au>
Subject: Type ctor module name bug

Unpack the attached tar file and build and run foo1 and foo2.
They give different answers, which I think is wrong.

-- Ralph

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

foobar.tgz (585 bytes) 2007-09-27 23:53
https://bugs.mercurylang.org/file_download.php?file_id=5&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-10-23 18: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:

compiler abort with memoing, dead proc. elimination and the hlc backend

Description:

The attached program causes a compiler abort during the HLDS->MLDS pass if
dead procedure elimination is enabled.

(This is similar, if not identical, to the recently fixed problems with
the low-level backend.)

(Curiously, the compiler also aborts if --high-level-data is enabled, even
though tabling is supposed to be disabled in that grade.)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

fzn_table_bug.m (553 bytes) 2007-10-23 18:13
https://bugs.mercurylang.org/file_download.php?file_id=15&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-09-28 13:14

2007-10-22 15:18

Reporter:

anonymous

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:

instance declarations for unknown types accepted in interface

Description:

The compiler accepts instance declarations in the interface of a module on types which don't appear in the interface, if the type is later defined in the module.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

instance_no_type.m (612 bytes) 2007-09-28 13:14
https://bugs.mercurylang.org/file_download.php?file_id=8&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-09-27 23:49

2007-10-19 16:07

Reporter:

anonymous

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:

compiler abort

Description:

From rafe@csse.unimelb.edu.au Sun Aug 5 09:55:55 2007
Date: Sun, 5 Aug 2007 09:55:53 +1000
From: Ralph Becket <rafe@csse.unimelb.edu.au>
To: Mercury Bugs <mercury-bugs@csse.unimelb.edu.au>
Subject: Compiler abort

Unpack the small tar file and run Make in the BUG directory to get:

$ make
mmc --make endo
Making Mercury/int3s/endo.int3
Making Mercury/int3s/dna.int3
Making Mercury/ints/dna.int
Making Mercury/ints/endo.int
Making Mercury/cs/dna.c
Making Mercury/cs/endo.c
Uncaught Mercury exception:
Software Error: jumpopt.m: Unexpected: adjust_livevals: BetweenLivevals
and PrevLivevals differ
Stack dump not available in this grade.
** Error making `Mercury/cs/endo.c'.
make: *** [all] Error 1

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

BUG.tgz (2,672 bytes) 2007-09-27 23:49
https://bugs.mercurylang.org/file_download.php?file_id=4&type=bug
endo2.m (833 bytes) 2007-10-16 18:17
https://bugs.mercurylang.org/file_download.php?file_id=13&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-09-27 23:39

2007-10-19 15:11

Reporter:

anonymous

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:

bad error message for state vars

Description:

From bojar@csse.unimelb.edu.au Wed Aug 15 16:50:01 2007
Date: Wed, 15 Aug 2007 16:51:13 +1000
From: Ondrej Bojar <bojar@csse.unimelb.edu.au>
To: mercury-bugs@csse.unimelb.edu.au
Subject: bad error message for state vars

Hi.

Here is an error message that wrongly reports the variable name:

oc_tree.m:015: Error: !FTFileName cannot appear as a unification argument.
oc_tree.m:015: You probably meant !.FTFileName or !:FTFileName.

where the actual error I made on that particular line was related to !D:

!D = svg.new,

See the source code attached. (Other errors are correct.)

Thanks, Ondrej.

--
Ondrej Bojar (mailto:obo@cuni.cz / bojar@ufal.mff.cuni.cz)
http://www.cuni.cz/~obo

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

oc_tree.m (571 bytes) 2007-09-27 23:39
https://bugs.mercurylang.org/file_download.php?file_id=3&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

text

always

2007-10-05 16:26

2007-10-18 16:20

Reporter:

pjrm

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:

doc: description of float token wrong

Description:

According to the current definition of the float token in the Mercury Reference manual, 1.0E-3 is not a float token (unless `-' is considered a "decimal digit"; which it isn't according to every authority I can think of):

  @item float
  A floating point literal consists of a sequence of decimal digits,
  a decimal point and a sequence of digits (the fraction part), and
  the letter @samp{E} and another sequence of decimal digits (the exponent).
  The fraction part or the exponent (but not both) may be omitted.

Please insert

  and an optional sign (@samp{+} or @samp{-})

after {E}. Please also consider inserting

  (or @samp{e})

Thanks,

pjrm.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-10-16 16:24

2007-10-16 17:37

Reporter:

wangp

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

confirmed

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

foreign type mutables don't work in high-level C grades

Description:

In hlc grades, a mutable of a foreign type FT in a module M will result in a variable declaration in M.mih that refers to FT before the #inclusion of the header that defines FT.

Tags:

Steps To Reproduce:

Additional Information:

For the given modules:

% mmc -m aa -s hlc.gc
Making Mercury/os/aa.o
In file included from Mercury/cs/aa.c:26:
aa.m:17: error: syntax error before '*' token
aa.m:17: warning: type defaults to `int' in declaration of `aa__mutable_variable_my_bb'
aa.m:17: warning: data definition has no type or storage class
aa.m:17: error: conflicting types for 'aa__mutable_variable_my_bb'
aa.m:17: error: previous declaration of 'aa__mutable_variable_my_bb' was here
** Error making `Mercury/os/aa.o'.

The same thing works in asm_fast.gc

Attached Files:

aa.m (606 bytes) 2007-10-16 16:24
https://bugs.mercurylang.org/file_download.php?file_id=11&type=bug
bb.m (840 bytes) 2007-10-16 16:25
https://bugs.mercurylang.org/file_download.php?file_id=12&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-09-28 00:13

2007-10-13 22:39

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:

spurious error message when testing equivalence of equal things

Description:

From bojar@csse.unimelb.edu.au Fri May 18 19:03:54 2007
Date: Fri, 18 May 2007 19:06:43 +1000
From: Ondrej Bojar <bojar@csse.unimelb.edu.au>
To: mercury-bugs@csse.unimelb.edu.au
Subject: spurious error message when testing equivalence of equal things

Hi.

When compiling this code:

:- module testbug.
:- interface.
:- import_module io.
:- pred main(io::di, io::uo) is det.
:- implementation.

:- import_module list, int.

main(!IO) :-
   A = [1,2,3],
   B = [1,2,3],
   (
   if A = B
   % if same(A, B) % use this to compile seamlessly
   then io.write_string("yes\n", !IO)
   else io.write_string("no\n", !IO)
   ).

:- pred same(T::in, T::in) is semidet.
same(A, B) :- A = B.

The compiler emits a lengthy message:

testbug.m:013: In clause for `'__Unify__'(in, (unique(list.'[|]'(unique(1),
testbug.m:013: unique(list.'[|]'(unique(2), unique(list.'[|]'(unique(3),
testbug.m:013: unique((list.[])))))))) >> unique(list.'[|]'(unique(1),
testbug.m:013: unique(list.'[|]'(unique(2), unique(list.'[|]'(unique(3),
testbug.m:013: unique((list.[]))))))))), (unique(list.'[|]'(unique(1),
testbug.m:013: unique(list.'[|]'(unique(2), unique(list.'[|]'(unique(3),
testbug.m:013: unique((list.[])))))))) >> unique(list.'[|]'(unique(1),
testbug.m:013: unique(list.'[|]'(unique(2), unique(list.'[|]'(unique(3),
testbug.m:013: unique((list.[]))))))))))':
testbug.m:013: mode error: argument 2 did not get sufficiently instantiated.
testbug.m:013: Final instantiatedness of `HeadVar__1' was
testbug.m:013: `unique(list.'[|]'(bound(1), bound(list.'[|]'(bound(2),
testbug.m:013: bound(list.'[|]'(bound(3), bound((list.[]))))))))',
testbug.m:013: expected final instantiatedness was
testbug.m:013: `unique(list.'[|]'(unique(1), unique(list.'[|]'(unique(2),
testbug.m:013: unique(list.'[|]'(unique(3), unique((list.[]))))))))'.
testbug.m:016: Warning: the condition of this if-then-else cannot fail.

The code seamlessly compiles if I test for the equivalence using an extra
predicate call to same/2.

The issue does not arise with primitive types, e.g. A=1, B=1.

Thanks, O.

--
Ondrej Bojar (mailto:obo@cuni.cz / bojar@ufal.mff.cuni.cz)
http://www.cuni.cz/~obo

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

testbug.m (397 bytes) 2007-09-28 00:13
https://bugs.mercurylang.org/file_download.php?file_id=6&type=bug

There are no notes attached to this issue.

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-10-03 14:27

2007-10-12 21:15

Reporter:

wangp

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:

builtin types inconsistently module qualified

Description:

The compiler seems to be inconsistent in its treatment of builtin types. In some cases they are module qualified with "builtin.", in other cases they are not, and it's not clear when.

This is related to a workaround for a compiler abort I committed on 2007-10-03.

(Julien asked me to file this report so he would remember to look into it.)

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-10-03 17:40

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:

mmc --make install should not touch unmodified files

Description:

Installing a library with mmc --make will update the timestamps of all files it installs, even if their contents are unchanged.

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

2007-09-21 15:48

2007-10-03 14:17

Reporter:

wangp

Platform:

Assigned To:

petdr

OS:

Priority:

normal

OS Version:

Status:

resolved

Product Version:

Product Build:

Resolution:

fixed

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

equivalence types in instance declarations

Description:

mmc accepts the LHS of an equivalence type in an instance declaration even when it would not accept the type on the RHS, e.g.

:- type list_int == list(int).
:- instance tc(list_int) where [].

If that's not actually a bug, then there is a bug when intermodule optimisation is enabled. ":- instance tc(list(int))." is written to the .opt file and produces an error message when that .opt file is used for another module.

Tags:

Steps To Reproduce:

Additional Information:

Attached Files:

eqv_instance.m (180 bytes) 2007-09-21 15:48
https://bugs.mercurylang.org/file_download.php?file_id=2&type=bug

Notes

View Issue Details

ID:

Category:

Severity:

Reproducibility:

Date Submitted:

Last Update:

[mercury] Bug

minor

always

2007-09-17 11:18

2007-09-25 11:54

Reporter:

obo

Platform:

Assigned To:

OS:

Priority:

normal

OS Version:

Status:

acknowledged

Product Version:

Product Build:

Resolution:

open

Projection:

none

ETA:

none

Fixed in Version:

Target Version:

Summary:

non-instructive error message: 'unused' mode requires explicit lambda expression

Description:

Hi.

the attached code demonstrates a not quite instructive error message.

While the predicate main2/2 compiles fine, main/2 does not, because I try to directly pass/curry an argument in 'unused' mode.

One solution is to automatically infer the correct mode when currying, another is to make the error message more specific.

Thanks, O.

Tags:

Steps To Reproduce:

Additional Information:

bug.m:019: In clause for `main(in, out)':
bug.m:019: in argument 1 of call to predicate `call_int_modifier'/3:
bug.m:019: mode error: variable `V_7' has instantiatedness `free',
bug.m:019: expected instantiatedness for non-local variables of lambda goals
bug.m:019: is `ground'.

Attached Files:

bug.m (615 bytes) 2007-09-17 11:18
https://bugs.mercurylang.org/file_download.php?file_id=1&type=bug

Notes