View Issue Details
526 [mercury] Bug minor always 2020-11-11 11:34 2020-11-30 13:35
wangp  
 
normal  
new  
open  
none    
none  
   
unused imports affected by opt-imported typeclass instances
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.
 
Notes
(0001124)
zs   
2020-11-12 03:13   
The obvious fix is to add a field to each entry to the const_struct_db
that says "does this entry come from the current module, or not?",
and then ignore the fields with "no" answers when it comes to computing
the set of used modules. The only nontrivial aspect I see is when
two or more const structs use a smaller const struct; the smaller
const struct should say "for this module" if any of its users also say so.

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

(Sorry for the late response; the notification was caught by GMail's spam filter.)




View Issue Details
512 [mercury] Bug minor always 2020-07-02 11:38 2020-10-29 19:36
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
branches of if-then-else disagree on liveness
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
liveness_test_case.m (628 bytes) 2020-07-02 11:38
https://bugs.mercurylang.org/file_download.php?file_id=301&type=bug
 
Notes
(0001123)
zs   
2020-10-29 19:36   
Fix committed 2020 oct 23.




View Issue Details
525 [mercury] Bug minor have not tried 2020-10-29 19:35 2020-10-29 19:35
zs  
 
normal  
new  
open  
none    
none  
   
compiler should detect missing included module
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
 
There are no notes attached to this issue.




View Issue Details
524 [mercury] Bug block always 2020-10-14 20:21 2020-10-16 07:16
dirkz Mac  
zs macOS Catalina  
normal 10.15.7  
resolved  
fixed  
none    
none  
   
Installing rotd-2020-10-13 aborts with error
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
sh configure --disable-most-grades
make PARALLEL=-j8
$ 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
config.log (362,768 bytes) 2020-10-14 22:45
https://bugs.mercurylang.org/file_download.php?file_id=308&type=bug
 
Notes
(0001113)
juliensf   
2020-10-14 21:07   
Hi Dirk,

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

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

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

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

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

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

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

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




View Issue Details
522 [mercury] Bug minor have not tried 2020-10-08 21:55 2020-10-16 07:15
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Compiler not building in Java grade with rotd-2020-09-29 onwards
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
 
Notes
(0001109)
zs   
2020-10-08 22:04   
The obvious fix is to make each arm of the switch
its own predicate. I can do that, if you like.

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

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




View Issue Details
508 [mercury] Bug minor have not tried 2020-05-17 01:31 2020-10-16 07:11
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Type constructors that are also Mercury operators result in invalid .int3 files
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?)



 
Notes
(0001120)
zs   
2020-10-16 07:11   
Fix was committed 2020 may 17.




View Issue Details
515 [mercury] Bug minor always 2020-07-31 01:34 2020-10-16 07:06
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Library not building in deep profiling grades with rotd-2020-07-26
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)
PATCH.2020_07_31_exception (1,036 bytes) 2020-07-31 14:27
https://bugs.mercurylang.org/file_download.php?file_id=304&type=bug
 
Notes
(0001101)
zs   
2020-07-31 14:27   
I have fix for the linking issue (attached). However, a bootstrap in the deep
profiling grade now gets a SIGSEGV when making the stage 3 dependencies,
even when if I undo the commit that fixed Mantis bug 514 (commit c5b35aca...),
which was the previous change that directly affected deep profiling.
So this needs further investigation.
(0001119)
zs   
2020-10-16 07:06   
The fix was committed 2020 aug 1.




View Issue Details
523 [mercury] Bug minor have not tried 2020-10-13 00:47 2020-10-13 11:27
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Compiler abort with rotd-2020-10-{11,12}
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
 
Notes
(0001112)
zs   
2020-10-13 11:27   
Fix committed 2020 oct 13.




View Issue Details
521 [mercury] Bug minor always 2020-09-29 17:23 2020-10-12 05:15
dirkz Mercury 20.06  
zs macOS Catalina  
normal 10.15.7  
assigned  
open  
none    
none  
   
Missing error message about an 'undefined type'; misleading error message instead
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'.
mmc --make main
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.
example.tgz (434 bytes) 2020-09-29 17:23
https://bugs.mercurylang.org/file_download.php?file_id=307&type=bug
 
Notes
(0001108)
zs   
2020-10-08 16:10   
I just added code to compiler to complain about the missing import. It should
be in the next ROTD. You still get the misleading error message, but you
also get a non-misleading pointer to where the error is.

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

I just performed a successful test with rotd-2020-10-09 on MacOS High Sierra 10.13.6.




View Issue Details
495 [mercury] Bug minor always 2020-02-04 14:02 2020-10-06 21:33
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
-O<n> options not additive
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
 
Notes
(0001107)
zs   
2020-10-06 21:33   
Feature implemented by 2020 september 29.




View Issue Details
520 [mercury] Bug minor always 2020-09-18 02:23 2020-10-02 17:46
keri  
 
normal  
new  
open  
none    
none  
   
possible GCC ICE when compiling library/int.m in asm_fast.gc.tr.debug.stseg grade with -O1
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
 
Notes
(0001104)
juliensf   
2020-09-18 16:28   
It's a Mercury bug to the extent that we would ideally apply workarounds to avoid the bugs in the affected versions of GCC.
(0001106)
juliensf   
2020-10-02 17:46   
This is the issue from bug 0000492. The compiler already has a workaround for the problem, but by setting EXTRA_CFLAGS=-O1 you are overriding that workaround.

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




View Issue Details
519 [mercury] Bug minor always 2020-09-17 05:14 2020-10-01 23:08
keri  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
extras/graphics/mercury_tcltk library may contain reference to unknown matherr symbol
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
 
Notes
(0001105)
juliensf   
2020-10-01 23:08   
I've deleted it; I'm pretty sure we don't care about versions of Tcl from before 1999 any more.




View Issue Details
518 [mercury] Bug minor have not tried 2020-09-17 00:07 2020-09-17 07:18
keri  
zs  
normal  
resolved  
fixed  
none    
none  
   
Typo in extras/odbc.m
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]
Attached is a diff to resolve this.
mercury-extras-odbc.patch (455 bytes) 2020-09-17 00:07
https://bugs.mercurylang.org/file_download.php?file_id=306&type=bug
 
Notes
(0001103)
zs   
2020-09-17 07:18   
The supplied patch has been committed. Thank you.




View Issue Details
517 [mercury] Bug minor always 2020-09-16 23:51 2020-09-16 23:51
keri  
 
normal  
new  
open  
none    
none  
   
extras/mopenssl fails to compile in a par grade with libressl
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'.
* 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
The attached diff adds function prototype declarations which allows mopenssl to compile.
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
516 [mercury] Bug minor have not tried 2020-08-04 11:34 2020-08-09 20:39
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Failure of tests/general/mode_inference_reorder with recent ROTDs.
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.
 
Notes
(0001102)
zs   
2020-08-09 20:39   
A fix for this symptom was committed 2020 aug 8.

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




View Issue Details
513 [mercury] Bug minor have not tried 2020-07-15 20:16 2020-07-29 01:56
maoko  
zs  
normal  
resolved  
fixed  
none    
none  
   
higher-order terms in freebsd bug.
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.
a.m (481 bytes) 2020-07-15 20:16
https://bugs.mercurylang.org/file_download.php?file_id=302&type=bug
bug513.c (1,189 bytes) 2020-07-15 23:38
https://bugs.mercurylang.org/file_download.php?file_id=303&type=bug
 
Notes
(0001094)
zs   
2020-07-15 22:38   
On my Mac, the test case works in hlc, but fails in none.gc.
(0001095)
juliensf   
2020-07-15 22:47   
On my Linux system it fails (producing [take(0)]) on asm_fast.gc with the current rotd and 20.01.
(It does work with Mercuy 14.01.1.)

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

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

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




View Issue Details
514 [mercury] Bug minor always 2020-07-23 00:53 2020-07-28 19:19
keri  
zs  
normal  
resolved  
fixed  
none    
none  
   
asm_fast.gc.profdeep.stseg grade fails to compile with GCC 10
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.
 
Notes
(0001097)
juliensf   
2020-07-24 01:04   
Placing proc layouts in common blocks is deliberate -- see the coment at the head of runtime/mercury_builtin_types_proc_layouts.h; we will need to arrange for -fcommon to be passed to GCC 10 and above.
(0001098)
zs   
2020-07-24 13:09   
I read that comment differently. To me, it says that the symbols of the *declarations*
of the proc layout structures will end up in a common block whether we them to or not,
and that we put those declarations into a separate .h file so that

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

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

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




View Issue Details
511 [mercury] Bug minor always 2020-06-19 18:22 2020-06-19 18:22
zs  
zs  
normal  
assigned  
open  
none    
none  
   
missing warning with --warn-unused-imports
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.
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
510 [mercury] Bug crash always 2020-06-19 17:33 2020-06-19 17:33
zs  
zs  
normal  
assigned  
open  
none    
none  
   
compiler crash due to missing type definition
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.
 
There are no notes attached to this issue.




View Issue Details
509 [mercury] Bug minor have not tried 2020-06-16 02:47 2020-06-16 02:47
zs  
zs  
normal  
assigned  
open  
none    
none  
   
higher_order.m optimizes soon-to-be-dead procedures
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.
 
There are no notes attached to this issue.




View Issue Details
502 [mercury] Feature Request minor have not tried 2020-04-28 23:25 2020-06-09 11:37
zs  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
print unsigned numbers
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.
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.

 
Notes
(0001090)
juliensf   
2020-04-29 17:42   
It was always intended that the format predicates be extended to support all of the new integer types (not just uint). The first thing that needs to be decided is which conversion specifiers apply to which types (in particular should format support printing out unsigned integers as signed values).

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

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

2. in the implementation of the format predicates

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




View Issue Details
507 [mercury] Feature Request minor have not tried 2020-05-01 17:52 2020-05-01 17:52
zs  
 
normal  
new  
open  
none    
none  
   
detect missing foreign_procs
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?
 
There are no notes attached to this issue.




View Issue Details
505 [mercury] Feature Request minor have not tried 2020-05-01 16:46 2020-05-01 17:23
zs  
zs  
normal  
assigned  
open  
none    
none  
   
allow reference only to explicitly imported modules
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.
 
There are no notes attached to this issue.




View Issue Details
506 [mercury] Feature Request minor have not tried 2020-05-01 17:22 2020-05-01 17:23
zs  
zs  
normal  
assigned  
open  
none    
none  
   
--recommend-order
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.
 
There are no notes attached to this issue.




View Issue Details
503 [mercury] Feature Request minor have not tried 2020-04-28 23:51 2020-04-29 17:25
zs  
 
normal  
new  
open  
none    
none  
   
unsigned shift amounts
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?
 
Notes
(0001085)
wangp   
2020-04-29 16:26   
The two checks are supposed to be performed using a single unsigned comparison on the shift amount, so is there anything to gain?

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

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

:- func uint << uint = uint.

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


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

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




View Issue Details
504 [mercury] Feature Request minor have not tried 2020-04-28 23:58 2020-04-28 23:58
zs  
zs  
normal  
assigned  
open  
none    
none  
   
make checked shifts builtins
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.
 
There are no notes attached to this issue.




View Issue Details
497 [mercury] Feature Request minor always 2020-04-03 15:13 2020-04-20 15:09
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
make disable_warning forwards compatible
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.
 
Notes
(0001077)
zs   
2020-04-04 02:43   
Feature implemented 2020 april 4.
(0001078)
wangp   
2020-04-04 13:07   
Thanks for taking a look.

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

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




View Issue Details
461 [mercury] Bug minor sometimes 2018-05-17 11:15 2020-04-20 15:06
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
MR_verify_final_engine_sleep_sync assertion failure (parallel conjunction)
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.)
 
Notes
(0001081)
wangp   
2020-04-17 13:40   
I found that I can reproduce this without parallel conjunction. The following command fails reliably on my machine. (parallel is GNU parallel; closeable_channel_test is from tests/hard_coded)

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

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

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

Then the call sequence goes:

action_shutdown_ws_engine -> MR_finalize_thread_engine -> MR_shutdown_engine_for_threads -> MR_verify_final_engine_sleep_sync

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

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


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




View Issue Details
480 [mercury] Bug minor always 2019-08-05 17:09 2020-04-15 12:58
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
regression in cse_detection.m
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.
    
cse_detection_regression.m (503 bytes) 2019-08-05 17:09
https://bugs.mercurylang.org/file_download.php?file_id=288&type=bug
bug480b.m (470 bytes) 2019-08-19 13:48
https://bugs.mercurylang.org/file_download.php?file_id=290&type=bug
 
Notes
(0001042)
zs   
2019-08-05 21:11   
Commit 9fab528bba40d614fb5b715a350330a5f346da9f should fix
most occurrences of this bug.
(0001043)
wangp   
2019-08-19 13:48   
Attaching a test case. (I previously posted it to the reviews list but it belongs here.)
(0001044)
zs   
2019-08-19 19:07   
It seems that with the current mode analysis system, there can't
really be a simple satisfactory fix for the root cause of this problem.
This is due to the fact that replacing "X = f(Y1, Y2)" with
"X = f(A1, A2), A1 = Y1, A2 = Y2", which is the basic transformation
on which cse is built, makes it lose track of any uniqueness in
X's arguments.

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

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

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

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

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

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




View Issue Details
496 [mercury] Bug minor have not tried 2020-02-05 10:20 2020-04-15 12:56
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Determinism error in 20.01 for code that compiles successfully in 14.01.1
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.)
bug496.m (1,807 bytes) 2020-02-05 10:20
https://bugs.mercurylang.org/file_download.php?file_id=296&type=bug
 
Notes
(0001074)
zs   
2020-02-05 11:04   
The cause of this bug is the fix for another bug: github 64.
That fix did come with an announcement that reqressions like this
would happen.

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

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

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

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

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

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

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

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

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

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




View Issue Details
499 [mercury] Bug minor always 2020-04-06 13:08 2020-04-06 14:19
wangp  
zs  
normal  
assigned  
open  
none    
none  
   
unqualified type encountered assertion
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
bug.m (91 bytes) 2020-04-06 13:08
https://bugs.mercurylang.org/file_download.php?file_id=297&type=bug
 
There are no notes attached to this issue.




View Issue Details
498 [mercury] Feature Request minor have not tried 2020-04-04 21:01 2020-04-04 21:01
zs  
zs  
normal  
assigned  
open  
none    
none  
   
handle misalignment of arguments in type errors better.
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.
 
There are no notes attached to this issue.




View Issue Details
120 [mercury] Bug minor have not tried 2009-12-18 10:51 2020-02-04 17:24
juliensf  
juliensf  
normal  
resolved  
won't fix  
none    
none  
   
bootchecking in reg.gc fails on Mac OS 10.6
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.
 
Notes
(0000253)
juliensf   
2010-02-27 18:23   
This still fails even with the Boehm GC upgrade (to 7.2alpha4).
(0001073)
juliensf   
2020-02-04 17:24   
There's not much use fixing this; Apple no longer support OS 10.6, so there's no point in us supporting it.




View Issue Details
494 [mercury] Bug minor have not tried 2020-01-23 11:41 2020-01-27 04:13
juliensf  
 
normal  
new  
open  
none    
none  
   
hard_coded/nonascii fails on Windows
hard_coded/nonascii fails on Windows (mingw64-{32,64},MSVC); it outputs "premature EOF" for most of the output.
 
Notes
(0001072)
juliensf   
2020-01-27 04:13   
The reason for failure is that text mode in Windows treats the byte 0x1a (i.e. Ctrl-Z) as EOF. (There's not much we can do about this, short of switching files to binary mode on Windows.)




View Issue Details
484 [mercury] Feature Request minor N/A 2019-09-18 23:00 2020-01-24 17:56
zs  
zs  
normal  
resolved  
fixed  
none    
none  
   
error message could be more specific
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.
bug484.m (485 bytes) 2019-09-18 23:00
https://bugs.mercurylang.org/file_download.php?file_id=292&type=bug
 
Notes
(0001071)
zs   
2020-01-24 17:56   
Error message improved on 2020 jan 24.




View Issue Details
493 [mercury] Bug minor always 2020-01-22 14:50 2020-01-23 11:46
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
MLDS ground terms bug
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
mlds_ground_term_bug.tar.gz (10,240 bytes) 2020-01-22 14:50
https://bugs.mercurylang.org/file_download.php?file_id=295&type=bug
 
Notes
(0001070)
zs   
2020-01-23 11:46   
Fix committed 2020 Jan 22.




View Issue Details
492 [mercury] Bug minor always 2020-01-13 18:41 2020-01-18 22:23
juliensf x86_64  
juliensf Fedora  
normal 31  
resolved  
fixed  
none    
none  
   
make install fails with GCC internal error on Fedora 31
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
 
Notes
(0001065)
wangp   
2020-01-13 19:54   
I previously reported it here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91430
(0001066)
juliensf   
2020-01-13 20:05   
Do you know if there is a workaround we can use for it?
(0001067)
wangp   
2020-01-13 20:52   
Unfortunately, no.
(0001068)
juliensf   
2020-01-15 14:42   
Also, occurs with Alpine Linux 3.11 (GCC 9.2). I think we will just need to force GCC to use -O0 in debug grades with GCC 9.1 and 9.2. (The bug only seems to be triggered in debug grades.)
(0001069)
juliensf   
2020-01-18 22:23   
We now force the use of gcc -O0 in debug grades with GCC 9.
(Confirmed that installation of the source distribution works with
both Fedora 31 and Alpine Linux 3.11 out of the box.)




View Issue Details
489 [mercury] Bug minor always 2020-01-09 14:31 2020-01-15 19:54
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
mmc --make gets confused by source files with same name as standard library module
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'.
mmc_make_source_filename_confusion.tar.gz (10,240 bytes) 2020-01-09 14:31
https://bugs.mercurylang.org/file_download.php?file_id=294&type=bug
 
Notes
(0001056)
wangp   
2020-01-09 16:23   
Notes:

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

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

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

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

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

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

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

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

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

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

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

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

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

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




View Issue Details
491 [mercury] Feature Request minor have not tried 2020-01-12 22:32 2020-01-12 22:32
zs  
zs  
normal  
assigned  
open  
none    
none  
   
implicit imports in interface files
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.
 
There are no notes attached to this issue.




View Issue Details
490 [mercury] Feature Request minor N/A 2020-01-11 18:18 2020-01-11 18:18
zs  
zs  
normal  
assigned  
open  
none    
none  
   
when importing A.B, do not require importing A
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.
 
There are no notes attached to this issue.




View Issue Details
488 [mercury] Bug minor have not tried 2019-10-27 17:14 2019-10-28 05:02
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Variable as pred name in predmode decl causes generates incorrect error message
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.


 
Notes
(0001055)
zs   
2019-10-28 05:02   
Fix committed 2019 10 28.




View Issue Details
487 [mercury] Bug minor always 2019-10-08 17:04 2019-10-08 21:06
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Incomplete and confusing error message
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?
bug487.m (1,537 bytes) 2019-10-08 17:04
https://bugs.mercurylang.org/file_download.php?file_id=293&type=bug
 
Notes
(0001054)
zs   
2019-10-08 21:06   
Fix committed 2019 oct 8.




View Issue Details
486 [mercury] Bug minor have not tried 2019-09-29 04:00 2019-09-29 14:06
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Partially qualified types in foreign_enum pragmas not working with rotd-2019-09-28
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.)



 
Notes
(0001053)
zs   
2019-09-29 14:06   
Fix committed 2019 sep 29.




View Issue Details
485 [mercury] Bug minor have not tried 2019-09-29 03:54 2019-09-29 14:05
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Various bits of extras not building with rotd-2019-09-28
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.

 
Notes
(0001048)
zs   
2019-09-29 04:04   
I think the bugs in each extra should be fixed by whoever understands that program
the best.
(0001049)
juliensf   
2019-09-29 04:18   
Why does the compiler think that quad_boolean_state/0 is not an enumeration? Because it's a dummy type? If so, that's wrong, because the presence of a foreign_enum pragma should suppress the dummyness of the type.
(0001050)
zs   
2019-09-29 04:31   
The Mercury definition is a dummy type, and the type as a whole is a dummy type
on every platform on which that foreign_enum is not applicable.

The crux here is that

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

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

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

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

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

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

Both the code in extras and not treating foreign_enums as dummy types is intentional.

(0001052)
zs   
2019-09-29 14:05   
Fix committed 2019 sep 29.




View Issue Details
483 [mercury] Bug minor always 2019-09-02 16:17 2019-09-02 18:27
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Spurious warning about unused module import
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.
bug483.m (227 bytes) 2019-09-02 16:17
https://bugs.mercurylang.org/file_download.php?file_id=291&type=bug
 
Notes
(0001047)
zs   
2019-09-02 18:27   
Fix committed 2019 sep 2.




View Issue Details
482 [mercury] Bug minor have not tried 2019-08-25 16:23 2019-08-25 16:23
pbone x86_64  
Linux  
normal  
new  
open  
none    
none  
   
Deep profiler "Restart" menu option doesn't restart the mdprof_cgi server
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).
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.
 
There are no notes attached to this issue.




View Issue Details
481 [mercury] Bug minor always 2019-08-19 13:38 2019-08-20 11:34
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
abort in MLDS code generator with --static-ground-terms
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
mlds_ground_term.m (329 bytes) 2019-08-19 13:38
https://bugs.mercurylang.org/file_download.php?file_id=289&type=bug
 
Notes
(0001046)
zs   
2019-08-20 11:34   
Fixed by commit 1afe0df4e95cf65f9e32a4f60caad2ea4d1c81cf.




View Issue Details
401 [mercury] Bug minor always 2015-12-17 18:00 2019-08-04 09:39
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
different module import styles in interface and implementation
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).
int_impl_imports.m (175 bytes) 2015-12-17 18:00
https://bugs.mercurylang.org/file_download.php?file_id=253&type=bug
int_impl_imports_2.m (65 bytes) 2015-12-17 18:01
https://bugs.mercurylang.org/file_download.php?file_id=254&type=bug
 
Notes
(0000872)
zs   
2015-12-17 23:38   
The bug is caused by process_module_long_interfaces in modules.m.
In int_impl_imports.m, the submodule int_impl_imports_2 is referenced twice:
it is used in the interface, and imported in the implementation.
grab_imported_modules process the import in the implementation first.
This reads the _2 module's .int file, and (since the import is NOT
in the interface) records that type bar is NOT available in the interface.
So far, so good. But when grab_imported_modules calls process_module_long_interfaces for the use in the interface,
it does not process the .int file again, since it has seen it before.

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

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

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

In tests/valid_seq:

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




View Issue Details
479 [mercury] Bug minor always 2019-07-07 06:31 2019-07-07 11:51
user411 Linux  
Debian  
normal 9  
resolved  
fixed  
none    
none  
   
warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE when compiling mercury code
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.
Any mercury code gives me the same error.
 
Notes
(0001039)
user411   
2019-07-07 07:03   
It seems that compiling mercury code with :

--cflags -D_DEFAULT_SOURCE

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




View Issue Details
477 [mercury] Feature Request minor have not tried 2019-04-17 16:51 2019-04-20 14:58
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Infinite recursion through exception handlers
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
    ).
bug477.m (871 bytes) 2019-04-18 00:37
https://bugs.mercurylang.org/file_download.php?file_id=287&type=bug
 
Notes
(0001023)
zs   
2019-04-17 22:28   
Can you please add a full test case?
(0001029)
juliensf   
2019-04-18 00:37   
There's a cut-down version that exhibits the behaviour attached. The current check carried out by simplify for recursive calls with the same input arguments doesn't look through higher-order calls since in general it cannot. I suspect it may be worth making a special case of try/2 (and its syntax sugared form) since wrapping an exception handler around the entry point to a Mercury program that is called from a foreign language application (which is the original setting for this) is not uncommon. Nor unfortunately is forgetting to use the correct predicate name inside the try goal which is what I did :-(
(0001038)
zs   
2019-04-20 14:58   
Feature implemented 2019 April 20.




View Issue Details
478 [mercury] Bug minor have not tried 2019-04-17 23:06 2019-04-18 05:27
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
ssdb directory does not build in csharp grade with commit 0d667a7
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
 
Notes
(0001024)
juliensf   
2019-04-17 23:20   
Ditto for the Java grade. The issue is not present in rotd-2019-04-16.
(0001025)
zs   
2019-04-17 23:23   
The problem was probably triggered by commit df47de186bf59c8c97010455c29c7ad765bfa3da,
but that was on March 31. So two things that may be
worth looking into are (a) why hasn't been a problem
in the last two weeks, and (b) why isn't this a problem
in other grades?
(0001026)
zs   
2019-04-17 23:25   
It seems our notes crossed paths. If the problem was not present
in rotd-2019-04-16, then the March 31 commit could not have been
the cause.

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

The obvious point of difference between the csharp / java grades and the others is that the former
are compiled using --use-mmc-make.

(0001028)
zs   
2019-04-17 23:54   
There has been only one commit since, and that was a refactoring that should have had
only one change that could cause a change in behavior: the addition of this sanity test
in modules.m:

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

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

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

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

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

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

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

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




View Issue Details
476 [mercury] Bug minor have not tried 2019-04-07 15:20 2019-04-08 03:16
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Compiler aborts during typeclass check
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.

Compile with: mmc -C
bug476.m (1,694 bytes) 2019-04-07 15:20
https://bugs.mercurylang.org/file_download.php?file_id=286&type=bug
 
Notes
(0001022)
zs   
2019-04-08 03:16   
Fix committed 2019 april 8.




View Issue Details
475 [mercury] Feature Request minor N/A 2019-02-04 01:14 2019-02-04 01:14
zs  
zs  
normal  
assigned  
open  
none    
none  
   
flatten maybe output args across calls
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.
 
There are no notes attached to this issue.




View Issue Details
473 [mercury] Bug minor always 2018-11-17 22:37 2018-11-19 11:46
pbone  
wangp  
normal  
resolved  
fixed  
none    
none  
   
JS sources should be included for minified files in scripts/
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.
 
Notes
(0001019)
zs   
2018-11-17 22:48   
I presume you are talking about jstree.min.js and jquery.slim.min.js.
They were added in the same commit in 2017, and not touched since.
The log message says they are from jstree.com and jquery.com respectively.
See whether those sites contain their nonminimized versions.
(0001020)
wangp   
2018-11-18 10:35   
There's no need to build the minified sources from the non-minified sources, just using the code in the original form is enough. I'll take care of it.




View Issue Details
474 [mercury] Bug major always 2018-11-18 23:01 2018-11-18 23:23
pbone i386  
Linux  
normal Debian 9  
new  
open  
none    
none  
   
Mercury cannot be installed, compiler crashes
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?
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.
 
Notes
(0001021)
juliensf   
2018-11-18 23:23   
It's not likely to be argument packing since that's currently not enabled by default.

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

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




View Issue Details
472 [mercury] Bug minor have not tried 2018-11-09 23:24 2018-11-17 22:40
pbone x86_64  
zs Linux  
normal 4.something  
resolved  
fixed  
none    
none  
   
Touching a .m file does not rebuild other modules that may depend on C foreign code that is opt-exported from that module
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.
Mercury 14.01.1
 
Notes
(0001016)
pbone   
2018-11-09 23:38   
Here's the workaround in Plasma's Makefile:

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

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




View Issue Details
458 [mercury] Feature Request minor N/A 2018-05-03 07:24 2018-10-03 09:23
zs  
zs  
normal  
resolved  
fixed  
none    
none  
   
optimize unify and compare for packed arguments
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.
 
Notes
(0001015)
zs   
2018-10-03 09:23   
The diff implementing this feature request was committed 2018 oct 3.




View Issue Details
471 [mercury] Bug minor always 2018-09-22 14:01 2018-09-22 14:01
wangp  
 
normal  
new  
open  
none    
none  
   
float rounding
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.
 
There are no notes attached to this issue.




View Issue Details
408 [mercury] Feature Request minor always 2016-04-18 11:00 2018-09-22 12:19
wangp  
 
normal  
resolved  
fixed  
none    
none  
   
make_temp and make_temp_directory should not throw exceptions
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.
 
Notes
(0000885)
pbone   
2016-04-18 11:20   
I agree with this change and I'm happy to do it since I'm working on this code anyway.
(0000978)
pbone   
2018-03-13 14:38   
Unassigned things from me.
(0001014)
wangp   
2018-09-22 12:19   
make_temp is deprecated and its replacements don't throw exceptions.




View Issue Details
435 [mercury] Bug minor have not tried 2017-03-29 10:00 2018-09-22 12:16
juliensf x86_64-pc-linux-gnu  
wangp Alpine Linux  
normal 3.5  
resolved  
fixed  
none    
none  
   
Old workaround in runtime causes compilation warnings
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.
 
Notes
(0001013)
wangp   
2018-09-22 12:16   
Fixed by commit 58345256f




View Issue Details
469 [mercury] Bug major always 2018-09-16 12:25 2018-09-19 11:19
taigua  
wangp  
normal  
resolved  
fixed  
none    
none  
   
mercury-srcdist-rotd-2018-09-11 compile failed on MinGW64 (Win10 64bit)
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]
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]
 
Notes
(0001012)
wangp   
2018-09-19 11:19   
Should be fixed in commit 90c29e772




View Issue Details
470 [mercury] Bug major always 2018-09-16 15:07 2018-09-16 17:18
taigua  
wangp  
normal  
resolved  
fixed  
none    
none  
   
mercury-srcdist-rotd-2018-09-11 compile failed on Linux (Ubuntu and Archlinux)
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
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
 
Notes
(0001011)
wangp   
2018-09-16 17:18   
Thanks for the report. The problem is probably only with low-level C memprof grades, fixed now in commit bb35de8b3.




View Issue Details
467 [mercury] Feature Request minor always 2018-08-18 16:15 2018-09-07 10:23
wangp  
 
normal  
new  
open  
none    
none  
   
compiling with -Wuninitialized or -Wmaybe-uninitialized
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.
 
Notes
(0001007)
juliensf   
2018-08-19 15:21   
No objections from me to using MR_NO_RETURN on erroneous procedures. (We probably can't rely on C11 just yet, although MR_NO_RETURN could be updated to use _Noreturn if the C implementation is C11.)
(0001010)
zs   
2018-09-07 10:23   
I started work on adding a new function flag that will tell mlds_to_c_func.m
whether it should emit MR_NO_RETURN for a function being declared or defined.




View Issue Details
468 [mercury] Bug minor always 2018-08-19 13:05 2018-09-03 12:29
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
free argument packed with other argument uses uninitialised variable
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.
 
Notes
(0001008)
zs   
2018-08-19 15:24   
I am working on a change that involves that code anyway.
(0001009)
zs   
2018-09-03 12:29   
Fix committed 2018 sep 3.




View Issue Details
464 [mercury] Bug minor N/A 2018-07-25 15:12 2018-08-19 17:02
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
MR_fatal_error should not read errno
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.
 
Notes
(0001003)
zs   
2018-07-27 14:07   
The obvious solution is to add an enum arg to MR_fatal_error, with two
values: PRINT_ERRNO_MSG and DONT_PRINT_ERRNO_MSG, and fix
all the C compiler errors that result by specifying one or the other
at all the complained-about call sites.




View Issue Details
460 [mercury] Bug minor random 2018-05-17 11:04 2018-08-09 22:07
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
failure of hard_coded/thread_barrier_test in asm_fast.par.gc
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
 
There are no notes attached to this issue.




View Issue Details
426 [mercury] Bug minor always 2016-10-21 15:47 2018-08-09 22:05
juliensf  
 
normal  
new  
open  
none    
none  
   
Tabling broken on 32-bit Cygwin
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?)




     

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

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

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

where f0587db0 is an address seen earlier:

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




View Issue Details
281 [mercury] Bug minor always 2013-05-06 13:15 2018-08-08 13:12
juliensf x86_64  
Mac OS X  
normal 10.8.3  
resolved  
fixed  
none    
none  
   
Tabling test case failures
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.)
 
Notes
(0001004)
wangp   
2018-08-08 12:32   
In the final set of trials, vp_ll_fib, the "faster" predicate vp_ll_fib is not that much faster (consistently) over the "slower" predicate vv_ll_fib for the heuristics in perform_trials.

These parameters just happen to work on my machine:

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

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

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


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




View Issue Details
466 [mercury] Bug minor have not tried 2018-07-29 04:50 2018-07-29 04:50
juliensf  
 
normal  
new  
open  
none    
none  
   
Test failures in asm_fast.par.gc.stseg
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




 
There are no notes attached to this issue.




View Issue Details
465 [mercury] Bug trivial always 2018-07-27 10:05 2018-07-27 10:05
yuan MS-VisualC2010  
Windows  
normal 10  
new  
open  
none    
none  
   
link lib error when compiling hello.m
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
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
 
There are no notes attached to this issue.




View Issue Details
463 [mercury] Bug minor always 2018-07-17 19:54 2018-07-20 16:51
keri  
juliensf Linux  
normal  
resolved  
fixed  
none    
none  
   
build failure on Linux when mono 5 is installed
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
after installing mono 5:

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




View Issue Details
462 [mercury] Feature Request minor N/A 2018-06-08 22:40 2018-06-08 22:41
zs  
zs  
normal  
assigned  
open  
none    
none  
   
packing notag arguments
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.
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
451 [mercury] Feature Request minor N/A 2018-02-20 16:41 2018-06-08 22:19
zs  
zs  
normal  
assigned  
open  
none    
none  
   
unpack packed args only as necessary in field updates
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.
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.
y.m (788 bytes) 2018-02-20 16:41
https://bugs.mercurylang.org/file_download.php?file_id=275&type=bug
 
Notes
(0001000)
zs   
2018-06-08 22:19   
Implemented for hlc grades in a diff committed on 2018 June 2.

Not yet implemented for LLDS grades.




View Issue Details
459 [mercury] Bug minor always 2018-05-07 02:08 2018-05-07 07:45
zs  
zs  
normal  
resolved  
fixed  
none    
none  
   
bootcheck applies stage 2 settings to stage 1
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.
 
Notes
(0000999)
zs   
2018-05-07 07:45   
Fix committed 2018 may 6.




View Issue Details
457 [mercury] Bug minor always 2018-04-29 12:19 2018-04-30 18:49
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
abort on construct_statically in var_locn
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.
construct_statically_abort.m (623 bytes) 2018-04-29 12:19
https://bugs.mercurylang.org/file_download.php?file_id=283&type=bug
 
Notes
(0000998)
wangp   
2018-04-30 18:49   
Fixed in commit 72bc36afc




View Issue Details
456 [mercury] Feature Request minor N/A 2018-04-26 10:47 2018-04-26 10:47
wangp  
 
normal  
new  
open  
none    
none  
   
structured concurrency
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.
 
There are no notes attached to this issue.




View Issue Details
455 [mercury] Bug minor always 2018-04-21 13:01 2018-04-21 21:16
wangp  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
intermodule optimisation with fixed sized integer modules
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
mod_a.m (389 bytes) 2018-04-21 13:01
https://bugs.mercurylang.org/file_download.php?file_id=281&type=bug
mod_b.m (280 bytes) 2018-04-21 13:02
https://bugs.mercurylang.org/file_download.php?file_id=282&type=bug
 
Notes
(0000996)
juliensf   
2018-04-21 17:43   
The problem is that the simplification pass can introduce calls to unchecked_left_shift, but that
dead predicate elimination hasn't been updated correctly to tell it not to delete the clauses
for that predicate; I'll post a fix for this later this evening.
(0000997)
juliensf   
2018-04-21 21:16   
Fixed in commit bb55d65.




View Issue Details
445 [mercury] Bug minor N/A 2018-01-24 16:57 2018-03-19 15:19
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
__builtin_bswap16/32 support
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.
 
Notes
(0000962)
juliensf   
2018-01-24 17:54   
(Last edited: 2018-01-24 17:56)
bswap32 and bswap64 first appeared in GCC 4.3.
bswap16 first appeared in GCC 4.8.

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





View Issue Details
453 [mercury] Bug crash always 2018-03-09 15:57 2018-03-16 15:15
wangp  
 
normal  
new  
open  
none    
none  
   
asm_fast does not work with gcc 5.4
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)
 
Notes
(0000976)
wangp   
2018-03-13 14:23   
The previous configuration (gcc 5.4.0, asm_fast.gc, x86) passes bootcheck if the Mercury libraries are statically linked, i.e. ./configure --disable-dynamic-link
(0000988)
wangp   
2018-03-15 12:57   
I can reproduce a crash more simply with a call to string.count_codepoints/2. I've copied that predicate to a separate module for ease of debugging, and generated the assembly with mmake string2.pic_s. Then we can edit the assembly and create libmer_std.so with: as -g string2.pic_s -o string2.pic_o && mmake libmer_std.so


This is the start of string2.count_codepoints:

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

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

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

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

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

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


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




View Issue Details
433 [mercury] Bug minor have not tried 2017-03-23 15:04 2018-03-13 14:38
pbone amd64  
pbone Linux Mint  
normal  
acknowledged  
open  
none    
none  
   
mmc --make calls programs without full path
if you have multiple installations of Mercury then calling tools like mkinit without the full path can lead to problems.

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.
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.
 
Notes
(0000946)
pbone   
2017-04-05 11:02   
I've been looking at this issue.

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

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

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

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

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

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

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

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

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

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

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

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




View Issue Details
406 [mercury] Bug minor have not tried 2016-03-06 01:18 2018-03-13 14:38
juliensf x86_64  
pbone OS X  
normal 10.9.5  
acknowledged  
open  
none    
none  
   
parallelism in standalone java example aborts
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.
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)
 
Notes
(0000979)
pbone   
2018-03-13 14:38   
Unassigned things from me.




View Issue Details
336 [mercury] Bug minor always 2014-06-20 10:30 2018-03-13 14:38
wangp  
pbone  
low  
acknowledged  
open  
none    
none  
  15.11  
java programs do not wait for all threads to finish
The program terminates soon after the main thread exits, even if other threads are running.
 
Notes
(0000702)
pbone   
2014-06-20 11:49   
Hi Peter,

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

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

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

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

Yes. It just sets a global variable.

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

I think so.

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

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

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

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

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

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

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

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

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




View Issue Details
335 [mercury] Bug minor always 2014-06-17 15:42 2018-03-13 14:38
wangp  
pbone  
normal  
acknowledged  
open  
none    
none  
   
assertion failure in MR_do_sleep
    /*
    ** 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);
 
Notes
(0000701)
wangp   
2014-06-17 15:44   
Sorry, I hit enter which submitted the issue prematurely.

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




View Issue Details
333 [mercury] Bug minor always 2014-06-16 11:41 2018-03-13 14:38
wangp  
pbone  
normal  
acknowledged  
open  
none    
none  
   
MR_num_idle_engines count goes wrong
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
fib_par_plain.m (435 bytes) 2014-06-16 11:41
https://bugs.mercurylang.org/file_download.php?file_id=216&type=bug
 
Notes
(0000700)
pbone   
2014-06-16 12:14   
It looks very odd where MR_num_idle_engines is -2. I'll take a look but I think 0000334 should be done first and might even help with this bug.

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




View Issue Details
295 [mercury] Bug minor always 2013-07-27 02:03 2018-03-13 14:38
juliensf  
pbone  
normal  
acknowledged  
open  
none    
none  
   
io.read_line_as_string/3 and CRLF line endings on Windows
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).
 
Notes
(0000557)
juliensf   
2013-07-27 02:06   
Same for io.read_line/3.
(0000983)
pbone   
2018-03-13 14:38   
Unassigned things from me.




View Issue Details
274 [mercury] Bug minor always 2013-01-08 12:34 2018-03-13 14:38
juliensf  
pbone  
normal  
acknowledged  
open  
none    
none  
   
possibly incorrect purity cast in deep profiler
The purity cast in predicate build_var_use_lists in deep_profiler/autopar_types.m is possibly
in the wrong spot.
 
Notes
(0000984)
pbone   
2018-03-13 14:38   
Unassigned things from me.




View Issue Details
163 [mercury] Bug major sometimes 2010-09-10 11:14 2018-03-13 14:38
pbone  
pbone  
low  
acknowledged  
unable to reproduce  
none    
none  
   
mdprof_cgi (deep profiler webserver) seems to lock up and leave processes running that should have timed out.
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.
 
Notes
(0000286)
pbone   
2010-09-10 11:16   
I think that if the mdprof_cgi daemon processes dies due to an exception that the CGI process that is waiting for it fails to time-out/report the exception.
(0000303)
pbone   
2011-02-02 13:10   
I've lowered the priority and reproducibility of this bug. I haven't seen it for a while - it may exist but I'm not sure.
(0000374)
pbone   
2011-11-02 14:22   
This bug has stuck again, the problem with fixing it is that we don't really know how to cause it to happen.
(0000985)
pbone   
2018-03-13 14:38   
Unassigned things from me.




View Issue Details
157 [mercury] Bug minor always 2010-07-14 13:46 2018-03-13 14:38
wangp  
pbone  
normal  
acknowledged  
open  
none    
none  
   
mtags uninitialised value warnings
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.
 
Notes
(0000307)
pbone   
2011-02-05 13:43   
I can reproduce this by running mtags against tests/valid/constr_inst_syntax.m
(0000987)
pbone   
2018-03-13 14:38   
Unassigned things from me.




View Issue Details
156 [mercury] Bug text have not tried 2010-07-11 12:02 2018-03-13 14:38
pbone  
pbone  
normal  
acknowledged  
open  
none    
none  
   
Headers in deep profiler clique report are incorrect.
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.
mdprof_cgi.html (27,376 bytes) 2010-07-11 12:02
https://bugs.mercurylang.org/file_download.php?file_id=105&type=bug
 
Notes
(0000986)
pbone   
2018-03-13 14:38   
Unassigned things from me.




View Issue Details
454 [mercury] Bug minor always 2018-03-09 16:25 2018-03-13 14:19
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
arith_int64 failure
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 '+' ***
 
sgt_int64.m (276 bytes) 2018-03-09 18:02
https://bugs.mercurylang.org/file_download.php?file_id=279&type=bug
bar_baz.m (759 bytes) 2018-03-13 06:14
https://bugs.mercurylang.org/file_download.php?file_id=280&type=bug
 
Notes
(0000968)
wangp   
2018-03-09 16:56   
For this program:

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

the compiler is producing:

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

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

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




View Issue Details
409 [mercury] Bug minor have not tried 2016-06-16 13:04 2018-03-09 17:04
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
functor_ho_inst failing on 32-bit
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
 
Notes
(0000969)
wangp   
2018-03-09 17:04   
Fixed by commit ac3891136




View Issue Details
359 [mercury] Bug minor always 2014-09-05 17:31 2018-03-06 15:45
wangp  
 
normal  
new  
open  
none    
none  
   
constrained polymorphic modes
Saving test cases to fix some other time.
lambda.m (548 bytes) 2014-09-05 17:31
https://bugs.mercurylang.org/file_download.php?file_id=223&type=bug
ho_constrained_poly_inst.m (269 bytes) 2018-03-06 15:24
https://bugs.mercurylang.org/file_download.php?file_id=277&type=bug
create_test_unification.m (393 bytes) 2018-03-06 15:41
https://bugs.mercurylang.org/file_download.php?file_id=278&type=bug
 
Notes
(0000793)
wangp   
2014-10-09 11:44   
The problem in lambda.m:
http://www.mercurylang.org/list-archives/users/2002-August/001921.html
(0000843)
mark   
2015-07-15 11:37   
A workaround for this is to use an explicit pred expression. For the lambda.m example, write:

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

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

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

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

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

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

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




View Issue Details
432 [mercury] Feature Request minor always 2017-03-21 13:12 2018-02-22 14:06
wangp  
zs  
normal  
assigned  
open  
none    
none  
   
pack constructor arguments in same word as primary tag
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.
 
Notes
(0000944)
zs   
2017-03-21 15:48   
That is a good idea.

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

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




View Issue Details
452 [mercury] Bug minor always 2018-02-21 15:16 2018-02-22 14:05
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
model_det need_bit_vec_check
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.)
ml_lookup_switch_test.m (725 bytes) 2018-02-21 15:16
https://bugs.mercurylang.org/file_download.php?file_id=276&type=bug
 
Notes
(0000965)
zs   
2018-02-22 14:05   
Fix committed feb 22.




View Issue Details
449 [mercury] Bug minor have not tried 2018-02-09 10:23 2018-02-13 12:55
juliensf  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
Switches on uint64s not working in java grade
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.
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.
 
Notes
(0000963)
juliensf   
2018-02-09 10:30   
Not a limitation shared by C#, so this only affects the Java grade.
(0000964)
juliensf   
2018-02-13 12:55   
Fixed in commit 63572bc.




View Issue Details
450 [mercury] Bug minor sometimes 2018-02-13 10:17 2018-02-13 10:17
juliensf  
 
normal  
new  
open  
none    
none  
   
tests/invalid/sub_c failing when running tests with -j8
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'
 
There are no notes attached to this issue.




View Issue Details
448 [mercury] Bug minor always 2018-02-07 05:30 2018-02-07 05:30
zs  
zs  
normal  
assigned  
open  
none    
none  
   
singleton warning generation ignores variables in quantifications
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 ... )
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.
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.
 
There are no notes attached to this issue.




View Issue Details
447 [mercury] Feature Request feature N/A 2018-02-06 18:16 2018-02-06 18:16
zs  
zs  
normal  
assigned  
open  
none    
none  
   
direct_arg_switch type representation
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.
 
There are no notes attached to this issue.




View Issue Details
446 [mercury] Feature Request feature N/A 2018-01-30 02:32 2018-01-30 02:32
zs  
zs  
low  
assigned  
open  
none    
none  
   
smarter comparisons of structures
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.
We should test whether, and if so how well, the stack_opt optimization can do this task already.
 
There are no notes attached to this issue.




View Issue Details
444 [mercury] Bug crash always 2018-01-11 12:34 2018-01-12 17:33
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
static linking with musl crashes
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.
 
Notes
(0000960)
wangp   
2018-01-11 12:50   
Without "-Wl,-defsym -Wl,_DYNAMIC=0", the binary DOES have a symbol _DYNAMIC but with a non-zero address:

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

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




View Issue Details
434 [mercury] Bug minor always 2017-03-29 09:55 2018-01-09 10:42
juliensf x86_64-pc-linux-gnu  
wangp Alpine Linux  
normal 3.5  
resolved  
fixed  
none    
none  
   
Alpine Linux / musl libc / x86_64 support
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.
 
Notes
(0000945)
FlyingJester   
2017-03-30 18:46   
I can confirm the same issue on VoidLinux for amd64, using musl.

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

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

- need to compile bdwgc with -DNO_GETCONTEXT -DHAVE_DL_ITERATE_PHDR

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

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




View Issue Details
443 [mercury] Bug minor always 2017-11-15 16:30 2017-11-15 16:30
juliensf  
 
normal  
new  
open  
none    
none  
   
Segmentation fault in high-level C .par.trseg grades
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).
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
442 [mercury] Bug minor always 2017-11-13 14:04 2017-11-13 14:04
juliensf x86_64  
Linux  
normal Oracle 7  
new  
open  
none    
none  
   
Building compiler with -j4 and --use-mmc-make fails
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.
 
There are no notes attached to this issue.




View Issue Details
441 [mercury] Bug minor always 2017-10-18 22:47 2017-10-18 23:42
juliensf  
zs  
normal  
assigned  
open  
none    
none  
   
Invalid C code for program in hlc.gc grade
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).
vfm2_bug.tar.gz (702 bytes) 2017-10-18 22:47
https://bugs.mercurylang.org/file_download.php?file_id=273&type=bug
 
Notes
(0000958)
zs   
2017-10-18 23:42   
The problem is NOT we generate the line that the error message is for.
The problem is that vfm2.m knows that fio is a dummy type, and makes
the return type of vfm2__printline_2_f_0 void accordingly, even though it keeps
the definition of fio(T) *private*. This means that fio is NOT known to be a dummy
type anywhere but inside the vfm2 module.

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




View Issue Details
411 [mercury] Bug major always 2016-06-22 14:03 2017-08-22 10:38
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
abstract type not hidden
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
mmc -m bar.m
foo.m (426 bytes) 2016-06-22 14:03
https://bugs.mercurylang.org/file_download.php?file_id=257&type=bug
bar.m (410 bytes) 2016-06-22 14:04
https://bugs.mercurylang.org/file_download.php?file_id=258&type=bug
 
Notes
(0000886)
wangp   
2016-06-22 14:08   
Oops, the step to reproduce is obviously "mmc -m bar" without the .m suffix.
(0000954)
wangp   
2017-06-22 15:38   
I nearly filed this bug again, having forgotten about it. Strange coincidence!
(0000957)
wangp   
2017-08-22 10:38   
Fix committed.




View Issue Details
440 [mercury] Feature Request minor N/A 2017-08-10 11:08 2017-08-10 11:08
wangp  
 
normal  
new  
open  
none    
none  
   
mdb: tab completion for function symbols
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
 
There are no notes attached to this issue.




View Issue Details
439 [mercury] Bug minor always 2017-08-06 13:09 2017-08-06 13:09
wangp  
 
low  
new  
open  
none    
none  
   
cannot build module which imports empty nested sub-module
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.
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
437 [mercury] Bug minor always 2017-08-05 12:35 2017-08-06 02:50
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
abort on empty nested sub-module
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
parent.m (169 bytes) 2017-08-05 12:35
https://bugs.mercurylang.org/file_download.php?file_id=270&type=bug
 
Notes
(0000956)
zs   
2017-08-06 02:50   
Fix committed 5 aug 2017.




View Issue Details
438 [mercury] Bug minor always 2017-08-05 14:55 2017-08-05 14:55
wangp  
 
normal  
new  
open  
none    
none  
   
partial module qualification of use_module imported entity
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).
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
410 [mercury] Bug minor always 2016-06-17 10:29 2017-06-17 11:00
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Syntax error causes compiler abort
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.
Mercury 14.01 correctly reports the syntax error:
bug410.m (2,810 bytes) 2016-06-17 10:29
https://bugs.mercurylang.org/file_download.php?file_id=256&type=bug
 
Notes
(0000953)
zs   
2017-06-17 11:00   
Fix committed 17 june 2017.




View Issue Details
436 [mercury] Bug minor always 2017-04-28 16:38 2017-05-03 10:42
wangp  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
unknown constructor in foreign_enum
The compiler silently allows a constructor in a pragma foreign_enum that do not correspond a constructor of the type.
foreign_enum_unknown_ctor.m (207 bytes) 2017-04-28 16:38
https://bugs.mercurylang.org/file_download.php?file_id=269&type=bug
 
Notes
(0000951)
juliensf   
2017-04-28 16:45   
That's a bit naughty of it -- I'll take a look it.
(0000952)
juliensf   
2017-05-03 10:42   
Fixed in commit c40f4300f.




View Issue Details
431 [mercury] Bug minor have not tried 2017-03-05 23:52 2017-03-06 15:45
dirkz Mac  
juliensf OS X Yosemite  
normal 10.10.5  
resolved  
fixed  
none    
none  
   
Install fails during make install of java grade in rotd-2017-02-22
The installation of Mercury with the default set of grades fails on Mac OS X during installation of the Java grade.
1. sh configure (OK)
2. make PARALLEL=-j6 (OK)
3. make PARALLEL=-j6 install (ERROR; see attached mer_std.err)
mer_std.err (4,090 bytes) 2017-03-05 23:52
https://bugs.mercurylang.org/file_download.php?file_id=268&type=bug
 
Notes
(0000940)
juliensf   
2017-03-06 01:15   
What are the versions of OS X and Java are you using?
(0000941)
dirkz   
2017-03-06 04:45   
I'm using Mac OS X Yosemite 10.10.5

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

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




View Issue Details
430 [mercury] Bug minor always 2017-01-28 17:47 2017-01-29 14:39
wangp  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
optional underscores in numeric literals
The parser does not accept these literals:

0_0
0_0.0
 
Notes
(0000939)
juliensf   
2017-01-29 14:39   
Fixed in commit b3835dd.




View Issue Details
429 [mercury] Bug minor always 2017-01-19 18:47 2017-01-20 04:24
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
cse causes switch to be reported as non-switch
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)
        )
      )
    )
  ).
switch_scope.m (425 bytes) 2017-01-19 18:47
https://bugs.mercurylang.org/file_download.php?file_id=267&type=bug
 
Notes
(0000938)
zs   
2017-01-20 04:24   
Fix committed 2017 jan 20.




View Issue Details
428 [mercury] Bug major always 2016-10-25 06:14 2016-10-25 06:14
lpimmes Dell Precision laptop  
Ubuntu  
urgent 16.04  
new  
open  
none    
none  
   
standalone_c complains about return value 0 (OK) from main/2.
Modified mercury_lib.m to output "STANDALONE" on console.

Any help would be appreciated.
Thanks.
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$
mmc: 14.01
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
427 [mercury] Bug minor have not tried 2016-10-23 01:54 2016-10-23 01:54
juliensf  
juliensf  
normal  
assigned  
open  
none    
none  
   
Use of long and unsigned long in C runtime code
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.
 
There are no notes attached to this issue.




View Issue Details
425 [mercury] Bug minor always 2016-10-06 13:23 2016-10-10 20:42
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
mmc --make loop on wrongly named module
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).
 
Notes
(0000937)
zs   
2016-10-10 20:42   
Fix committed 2016 oct 10.




View Issue Details
424 [mercury] Bug minor always 2016-10-04 12:13 2016-10-07 15:28
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
error creating temporary file with --restricted-command-line
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'.
 
Notes
(0000932)
pbone   
2016-10-04 12:28   
Hi Peter.

I think I broke this and have a guess about what went wrong. I can take a look at it this afternoon.

Cheers.
(0000936)
wangp   
2016-10-07 15:28   
Fixed in commit 4bf82f6




View Issue Details
418 [mercury] Bug minor always 2016-09-07 13:57 2016-10-07 14:34
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
io error exceptions not working
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
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
(0000912)
wangp   
2016-09-19 17:53   
Nothing to do with io.m.

Note (to self) about throw_from_foreign.m in low-level C grades:

The Mercury procedure dothrow/1 is foreign_exported, so we create a C wrapper function dothrow() which uses MR_call_engine() to enter the Mercury code. MR_call_engine() itself uses setjmp(). When dothrow/1 throws an exception it calls longjmp, but that sends us back to the setjmp point in the MR_call_engine call for the dothrow() wrapper function instead of the exception handler.
(0000913)
wangp   
2016-09-20 11:57   
The previous comment was wrong.

try_io/builtin_catch creates a Mercury exception handler entry on the nondet stack.
Then we enter the foreign proc `chucker',
which calls the C wrapper `dothrow',
which calls the C function `MR_call_engine' (with catch_exceptions=FALSE),
which runs the Mercury proc `dothrow',
which calls `throw'.

throw/builtin_throw finds the Mercury exception handler on the nondet stack. It does NOT longjmp back to the MR_call_engine, but calls the Mercury exception handler. The C stack is not unwound, so some time later we end up returning into MR_call_engine.

Anyone have suggestions for how builtin_throw should unwind the C stack?

One way might be for builtin_catch to call setjmp so that builtin_throw always calls longjmp to unwind the C stack (like high-level C grades).

Another way might for MR_call_engine to always intercept exceptions and rethrow them. e.g. if catch_exceptions=FALSE, it still needs to create an exception handler entry of type MR_C_LONGJMP_HANDLER on the nondet stack, so it can catch any exception and rethrow it.
(0000914)
juliensf   
2016-09-20 12:19   
With regard to throw_from_foreign.m, throwing exceptions across the C interface like that is currently documented as being undefined behaviour, it's not surprising that it doesn't work. Are you suggesting that it needs to work? (I could reproduce the issue with test.m on my machine; which grade are you using?)
(0000915)
wangp   
2016-09-20 12:37   
I couldn't find where it is documented.

io.m does throw exceptions across the C interface. ML_throw_io_error is C wrapper for Mercury proc throw_io_error, and is called indirectly from many foreign_procs.

I think I would not mind if throwing exceptions across the C interface is not supported (with better documentation, and perhaps runtime checks). I think a better way for io.m or any other module to handle errors is to return error codes from foreign_procs up to Mercury code, then for the Mercury code to throw exceptions.

I'm testing with asm_fast.gc and none.gc.
(0000916)
juliensf   
2016-09-20 13:51   
It's documented in the comment at the head of library/exception.m.

The ODBC library does it as well. I think ML_throw_io_error (probably) worked well enough once upon a time, but I suspect that various runtime changes may have contributed to it not working. it would be preferable if we didn't throw exceptions over the C interface (certainly in the standard library at least).

We could insert runtime checks in the foreign_export wrappers, but there are probably performance implications with doings so (such checks could obviously be omitted in the case where we know the Mercury code is not going to throw an exception).

I tried with none.gc.debug.trseg.stseg.
(0000917)
wangp   
2016-09-20 15:58   
It's very easy to write a Mercury predicate that may throw exceptions without meaning to. It would be preferable to support throwing exceptions across the C interface, perhaps even if there is some performance impact. The majority of foreign_exported predicates in extras might fall afoul of the rule.

I will try to fix io.m.
(0000918)
juliensf   
2016-09-20 18:20   
If there are any proposals in this area, then I suggest we discuss them on the developers list.
(0000935)
wangp   
2016-10-07 14:34   
Fixed, io.m does not throw past the C interface any more.




View Issue Details
346 [mercury] Bug minor always 2014-07-11 17:41 2016-10-06 20:27
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
non-ANSI functions in header files
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.
 
Notes
(0000739)
juliensf   
2014-07-11 20:08   
It might be worth adding the dir module to the list of files in library/Mercury.options that are compiled with --no-ansi.

OTOH, we should probably just not use -ansi at all -- IIRC, it (still) puts GCC into C90 mode (annoyingly it puts clang into C89 or GNU89 mode, which is slightly different).
(0000743)
wangp   
2014-07-14 10:26   
Yes, I don't understand why dir.m hasn't required --no-ansi yet.

The bigger problem is that the non-ANSI stuff leaks into the header files generated for dir.m and ends up being included into almost everything else. That stuff should be hidden away, and only appear in `local' foreign_decls, foreign_codes, and foreign_procs marked `may_not_duplicate'.
(0000744)
juliensf   
2014-07-14 10:31   
I'd perfectly happy simply to not use -ansi with GCC. (I had to disable its use with clang recently anyway.)
Another problem with it is that it affects the compilation of user foreign_procs. Most of the systems we
support these days support POSIX / C99 well enough that disabling it isn't going to be a problem.
The one major system that doesn't, Windows, already requires special treatment everywhere anyway.
(0000745)
juliensf   
2014-07-14 10:33   
All that said, restricting the stuff in the dir module to appear in 'local' foreign pragmas is also a worthwhile
change IMO.
(0000934)
wangp   
2016-10-06 20:27   
Fixed as part of commit 1fbcfe3 (for dir.m anyway)




View Issue Details
422 [mercury] Bug minor always 2016-10-03 12:40 2016-10-04 21:11
juliensf x86_64  
OS X  
normal 10.9.5  
new  
open  
none    
none  
   
Intermittent runtime aborts in parallel conjunction tests
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.
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
 
Notes
(0000933)
juliensf   
2016-10-04 21:11   
The problem does *not* occur with GCC 5 in the asm_fast.par.gc.stseg grade on OS X.




View Issue Details
404 [mercury] Bug minor always 2016-02-09 10:05 2016-10-03 13:42
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
mmc --rebuild not working
mmc --rebuild is no longer causing anything to be rebuild. (Presumably caused by commit 1fcdc4c)
 
Notes
(0000904)
wangp   
2016-08-28 13:22   
This is indeed due to commit 1fcdc4c which changed the internal representation of --rebuild as opm_top_make(opmm_must_rebuild). The problem is that the op_mode for sub-steps is not opm_top_make(opmm_must_rebuild) but opm_top_args(blah) so that check_dependency_timestamps has lost the indicator that --rebuild is in effect.

I think we should change --rebuild back to a normal option that implies --make (opm_top_make).
(0000906)
zs   
2016-08-29 07:20   
Could either one of you add a test case for this bug? The reason I haven't looked at this bug when it was first filed is that I have no way of reproducing it, since I don't use --make myself.
(0000907)
juliensf   
2016-08-29 09:32   
Any valid Mercury program is a test case for this bug, samples/hello.m for instance.

     samples jfischer$ mmc --make hello
     Making Mercury/int3s/hello.int3
     Making Mercury/ints/hello.int
     Making Mercury/cs/hello.c
     Making Mercury/os/hello.o
     Making hello

    samples jfischer$ mmc --rebuild hello
    ** Nothing to be done for `hello'.
(0000926)
zs   
2016-10-03 13:42   
Fixed in commit 3485884 on 2016 oct 3.




View Issue Details
357 [mercury] Bug minor always 2014-09-02 16:05 2016-10-03 10:58
juliensf x86_64  
juliensf OS X  
normal 10.9  
resolved  
fixed  
none    
none  
  15.11  
Parallel conjunction broken on OS X
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.)
 
Notes
(0000779)
wangp   
2014-09-02 16:24   
Or just condition variables, though presumably they perform worse so we would want to stick to semaphores on better platforms.
(0000780)
juliensf   
2014-09-02 16:25   
This would have shown up more obviously had the return value of sem_init been checked!

There are also a bunch of calls to various pthread_* functions in the runtime, for example pthread_mutex_init and pthread_attr_init, where the return values are not checked.
(0000921)
pbone   
2016-09-29 14:04   
I remember some things about writing this code but not others.

In particular I remember choosing semaphores for a very good reason, but I don't remember what that reason was :-(

I'm not sure what should be used instead on OS X. Except that if we want to use GCD, then we should essentially write a different implementation for the N:M threading on OS X, as GCD will (and should) handle this for us. I suspect windows is a similar case as it supports fibers. However that's about all I know of either platform/API.

So I'd recommend trying to replace this with named semaphores, if those are supported/work, or maybe condition variables - again there's a good reason why I didn't use those but I don't know what it is. And in the longer term consider writing an alternative implementation of all this code (maybe keep the work stealing) for OS X.
(0000922)
juliensf   
2016-09-29 14:13   
Hi Paul,

Using GCD to do the N:M threading is a separate issue; the semaphore implementation in libdispatch is close enough to POSIX unnamed semaphores that it should be easy enough to use as a drop-in replacement. Using GCD in general on OS X is a much larger change.
(0000923)
pbone   
2016-09-29 14:24   
Agreed, which is why I said that's a longer term change, and by implication not really part of this bug. However I wasn't aware of the primitives provided by libdispatch so I didn't know that's what you meant when you said GCD. It sounds reasonable to me.
(0000925)
juliensf   
2016-10-03 10:58   
Fixed in commit 1fc495c.




View Issue Details
421 [mercury] Bug minor always 2016-10-01 22:59 2016-10-02 11:12
juliensf  
zs  
normal  
assigned  
open  
none    
none  
   
Code generator aborts in parallel conjunction tests
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

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


   $ mmc -C --grade asm_fast.par.gc consume_wait
 
Notes
(0000924)
zs   
2016-10-02 11:11   
I noticed this a couple of months ago. I worked out a partial fix then; it fixes
the test failures above, but introduces a couple of others to replace them.
I didn't have time at the time to look into those, but still, I think I am best placed
to look into this.




View Issue Details
398 [mercury] Bug minor have not tried 2015-12-09 16:00 2016-09-28 16:04
juliensf  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
mercury_compile.exe fails to link on Cygwin64 / MinGW64 with GCC 4.9.X
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__'
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.)
 
Notes
(0000902)
juliensf   
2016-08-16 14:13   
The same issue occurs with GCC 5.4.0 on 64-bit Cygwin.
(0000903)
juliensf   
2016-08-17 09:22   
The issue has been fixed in Boehm upstream.
<https://github.com/ivmai/bdwgc/commit/4e24d219d29abb2b111bb9a9ccb13c3f149a855a>
We will need to backport that change (or upgrade our version of the collector).
(0000920)
juliensf   
2016-09-28 16:03   
(Last edited: 2016-09-28 16:04)
This has been resolved by upgrading the Boehm GC to version 7.6. I have tested it with rotd 2016-09-27.





View Issue Details
419 [mercury] Feature Request minor always 2016-09-14 12:15 2016-09-21 04:57
wangp  
 
normal  
new  
open  
none    
none  
   
cannot write floats in break point conditions
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
 
Notes
(0000909)
zs   
2016-09-14 17:56   
The main problem I see is that equality with floats is not precisely defined in general.
There is exactly one float x for which x = 1.0 should work, but there is no one float
for which x = 1.1 should work, since 1.1 is not exactly representable in binary.
One would have to pick either a relative or absolute epsilon, and have x = 1.1 succeed
for all x for which |x - 1.1| < epsilon (absolute) or all x for which |x - 1.1|/1.1 < epsilon
(relative).

To support float tests in breakpoint conditions, one would either have to provide
a means for users to specify their desired epsilon (with a default, of course),
or enrich the condition language to allow the epsilon to be specified in the test
itself. I think we need one or more specific use cases to guide our choice in
fixing this issue. Does anyone have one?
(0000911)
wangp   
2016-09-19 14:44   
I only expected equality and inequality to work, like = and \= on floats in Mercury.

I can see uses for an epsilon or specifying values in a range. That might be useful for int tests as well, e.g. stop only when this argument is negative.

When I reported this bug, that was probably the first time that I've tried to use a float in a break point condition, so take that as you will.
(0000919)
zs   
2016-09-21 04:57   
A long time ago, I did a subject on numerical analysis. One of the first things mentioned
was that floats should not be compared for equality, because their approximate nature
makes such comparisons inherently unreliable. I expect well-written programs that handle
floats, in Mercury or in other languages, to follow that advice.

For the programs that ignore the advice, the right fix is probably to generate a compiler
warning whenever two floats are compared for equality, to get the programmer to fix
the equality test itself.

This is why, for programs that follow the advice, the treatment of float equality during
normal execution should not be the semantics one should strive to implement
for breakpoint conditions in the debugger.

Note that at the moment, the debugger treats the literal values in breakpoint conditions
as uninterpreted and untyped terms. Adding a mechanism for comparisons would require
effectively reimplementing breakpoint conditions in a type-aware manner.




View Issue Details
420 [mercury] Bug major always 2016-09-14 16:06 2016-09-19 14:31
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
try goals lost in .opt files
`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
      )
    ).
try_goal_opt.m (403 bytes) 2016-09-14 16:06
https://bugs.mercurylang.org/file_download.php?file_id=264&type=bug
 
Notes
(0000910)
wangp   
2016-09-19 14:31   
Fixed by commit 1e0025b




View Issue Details
417 [mercury] Bug minor have not tried 2016-09-06 16:06 2016-09-06 16:06
wangp  
 
normal  
new  
open  
none    
none  
   
new_arg_ref may return interior pointer
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)
 
There are no notes attached to this issue.




View Issue Details
416 [mercury] Bug crash always 2016-08-31 17:04 2016-08-31 17:04
maxime Java backend  
 
normal  
new  
open  
none    
none  
   
mutable thread_local java backend missing initialValue()
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.
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.

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>;}
};
 
There are no notes attached to this issue.




View Issue Details
415 [mercury] Bug minor have not tried 2016-08-30 00:50 2016-08-30 18:39
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Segmentation fault during mode checking
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.)
ip_chunk.m (1,831 bytes) 2016-08-30 00:50
https://bugs.mercurylang.org/file_download.php?file_id=262&type=bug
 
Notes
(0000908)
zs   
2016-08-30 18:39   
Fix committed 2016 aug 30.




View Issue Details
75 [mercury] Bug minor always 2008-08-12 15:57 2016-08-28 13:31
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
better treatment of absolute pathnames
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.
 
Notes
(0000905)
wangp   
2016-08-28 13:31   
Can't reproduce any more, probably fixed.




View Issue Details
414 [mercury] Bug minor always 2016-07-25 16:53 2016-07-29 03:42
pbone x86_64  
zs Linux Mint  
normal 18  
resolved  
fixed  
none    
none  
   
The switch detection fails to detect this switch
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.
$ 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'.
Mercury ROTD 2016-07-18
GCC 5.4.0 20160609
testb.m (888 bytes) 2016-07-25 16:53
https://bugs.mercurylang.org/file_download.php?file_id=261&type=bug
 
Notes
(0000899)
zs   
2016-07-25 19:33   
The reason why this happens is that this code exhibits a rare
combination of properties. (a) Both disjuncts of the outer disjunction
contain deconstruction unifications with both Loader and Prefix.
(b) Since Loader's first occurrence in the clause comes *before*
Prefix's first occurrence, it gets the lower variable number,
so switch detection tests whether the disjunction is a switch on
Loader first. (c) Because of point a, it finds that the answer is yes,
with no disjuncts left over. It therefore commits to convertion the
disjunction into a switch on Loader, not even looking to see whether
the disjunction is a switch on any other variable.

Switch detection is inherently incomplete: there will always be switches
that it cannot find, for the same kinds of reasons why determinism
analysis (say of a Turing machine simulator) cannot ever prove that
all det predicates are actually det. Therefore stopping the search
after we find an apparently-satisfactory switch configuration (such as
the switch on Loader appears to be in this case) is justifiable, and
it definitely was the right thing to do in in the 1990s, when this code
was written. Now that we have computer power to burn, we can choose
to keep looking. I will look into that.
(0000900)
pbone   
2016-07-25 21:31   
That's an interesting combination of properties, more complex than I expected, but I did wonder if it had something to do with Loader, and that due to the field access code it is deconstructed in 3 places.

Anyway, it's pretty rare and also easy enough to work around so there's no hurry at all.

Cheers.
(0000901)
zs   
2016-07-29 03:42   
Fix committed 2016 july 27.




View Issue Details
196 [mercury] Bug minor sometimes 2011-04-13 23:10 2016-07-17 20:56
pbone  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
Binary compatibility checks in C grades don't work.
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.
 
Notes
(0000327)
juliensf   
2011-04-13 23:25   
Does the variable appear amongst the list of exported symbols?

What version of gcc are you using? (Recent ones do perform some LTO, so maybe
that's the problem?)
(0000892)
juliensf   
2016-07-07 19:56   
The problem is that the static variable MR_grade that we emit at the end of every generated .c file is being optimised away (since it is not referenced by anything else). GCC and clang seem quite happy to do this even if the variable is also declared to be volatile. The will however retain the variable if it is declared with
the variable attribute __attribute__((used)). For other C compilers I'm not yet sure what to do (or even if this is a problem).
(0000893)
zs   
2016-07-07 20:27   
We could generate an exported function that returns the value of MR_grade.
Since it could be called from somewhere else, the compiler wouldn't be able
to optimize away the reference. This should be more portable than __attribute__.
(0000894)
juliensf   
2016-07-07 20:48   
We can hide __attribute__ behind a macro, just as we already do with other such attributes, e.g.

  #if defined(MR_GNUC) || defined(MR_CLANG)
      #define MR_CONSIDER_USED __attribute__((used))
  #else
      #define MR_CONSIDER_USED volatile /* .. and hope for the best! */
  #endif

I've implemented this and tested it with clang. (I'm not even sure that this is an issue with
MSVC; I'll take a look tomorrow when I have access to a machine with that compiler installed.)
Given that C compilers used with Mercury are nearly always GCC or clang I think this is probably
good enough.
(0000898)
juliensf   
2016-07-17 20:56   
Fix in commit 10c210d.




View Issue Details
412 [mercury] Bug minor always 2016-07-03 21:12 2016-07-17 18:25
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
compiler does not report some unused imported modules
The compiler does not report as unused any of the standard library modules imported in the implementation section of the test file.
unused_imports.m (2,782 bytes) 2016-07-03 21:12
https://bugs.mercurylang.org/file_download.php?file_id=259&type=bug
 
Notes
(0000897)
zs   
2016-07-17 18:25   
Fix committed 2016 July 17.




View Issue Details
91 [mercury] Bug major always 2009-03-09 22:32 2016-07-01 10:11
maclarty  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
compiler throws exception in hlc.gc
$ 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.
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
(0000161)
maclarty   
2009-03-11 17:59   
The problem here seems to be that the type interpreter.value/0 is not exported to interpreter.int. It is not exported, because it is only defined in the implementation. It is however used in the interface as the argument of another type's functor. One would expect this to cause an error when compiling interpreter.m.

I've attached a simpler test case that triggers this bug. In bug2.m type a uses type b in the interface, but type b is only defined in the implementation. This module compiles without error (mmc -C bug2.m).
(0000162)
maclarty   
2009-03-11 18:02   
Of course this doesn't explain why the original program compiles in asm_fast.gc.
(0000891)
juliensf   
2016-07-01 10:11   
The fix for 0000017 also resolves this one. The larger of the two test cases still causes an abort in the compiler
but that's only because the supplied .int files are invalid -- newer versions of the compiler won't allow them to be generated in the first place.




View Issue Details
214 [mercury] Bug minor always 2011-09-02 03:41 2016-06-30 17:32
juliensf  
juliensf  
normal  
resolved  
fixed  
none    
none  
  15.11  
confusing type error
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.
bug.m (4,718 bytes) 2011-09-02 03:41
https://bugs.mercurylang.org/file_download.php?file_id=126&type=bug
 
Notes
(0000890)
juliensf   
2016-06-30 17:32   
Fixed in commit ced4134. (We could still do a better job of localising the error though.)




View Issue Details
184 [mercury] Bug crash always 2011-02-03 17:28 2016-06-30 11:46
mgiuca  
juliensf  
normal  
resolved  
fixed  
none    
none  
  15.11  
Unresolved polymorphism in typeclass crashes mmc
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.
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)
 
Notes
(0000889)
juliensf   
2016-06-30 11:46   
Fixed in commit ced4134.




View Issue Details
36 [mercury] Bug major always 2008-01-14 17:15 2016-06-23 14:48
juliensf  
 
high  
new  
open  
none    
none  
   
another tabling bug with the high-level C backend
The attached module causes an assertion failure in the compiler when compiled with

mmc -C --grade hlc.gc -O0 --no-optimize-dead-procs
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.
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
(0000888)
juliensf   
2016-06-23 14:48   
This is working with rotd-2016-06-23**; there have been a lot of changes over the past eight years, so it isn't clear if the "fix" is intentional or not. I have added the attached test case to the test suite (tests/valid/bug36.m).


** it seems to have been passing as far back as 14.01.1.




View Issue Details
407 [mercury] Bug minor have not tried 2016-04-12 15:17 2016-06-22 15:41
wangp  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
Exception.getMessage can return null
io.m assumes java.lang.Exception.getMessage will not return null, but it can.
 
Notes
(0000887)
juliensf   
2016-06-22 15:41   
Fix in commit d038639.




View Issue Details
326 [mercury] Feature Request feature always 2014-04-23 11:45 2016-04-04 12:07
wangp  
wangp  
low  
resolved  
fixed  
none    
none  
   
disable rpath
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.
 
Notes
(0000672)
juliensf   
2014-05-01 10:31   
I have no objections to adding an option --no-use-rpath to the compiler to achieve this.
(Additionally, if it's possible to switch it off completely on Mac OS X, then that would be useful too.)
(0000698)
juliensf   
2014-05-29 13:55   
Sorry, I accidently closed this one.
(0000884)
wangp   
2016-04-04 12:07   
Fixed with --no-default-runtime-library-directory.




View Issue Details
373 [mercury] Bug minor always 2015-01-13 17:40 2016-02-24 09:44
wangp  
 
normal  
new  
open  
none    
none  
  15.11  
string.to_float imprecisely specified
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"
 
Notes
(0000803)
juliensf   
2015-01-13 18:12   
There is no "may" about it. It *is* backend dependent.
(0000883)
juliensf   
2016-02-24 09:44   
A fix for this issue should also address the question of whether string.to_float("-0") is equal to 0.0 or -0.0?
The C back-ends** and C#/Java back-ends currently disagree on this.

** at least on OS X, with clang and BSD libc etc.




View Issue Details
405 [mercury] Bug minor always 2016-02-20 03:04 2016-02-23 03:24
FlyingJester amd64  
Windows  
normal 8.1  
confirmed  
open  
none    
none  
   
Compiler Software Exception in Certain Projects
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.
Download the MEdit sources from https://github.com/FlyingJester/medit
Run either just `make` (which requires yasm) or `make medit_mercury`
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.
 
Notes
(0000878)
mark   
2016-02-20 10:50   
(Last edited: 2016-02-20 13:00)
The code relies on nested unique modes, which are not supported. This is a known limitation. In this case it seems to be compounded by another mode error in your code, in the use of SizeIn+0 as an input parameter. (Edit: disregard that last sentence.)

The compiler fails to report the problem accurately.

What is the purpose of writing SizeIn+0 instead of just SizeIn?

(0000879)
FlyingJester   
2016-02-20 11:06   
(Last edited: 2016-02-20 11:07)
The purpose is to allow a unique output which is partially composed of a non-unique integer input.

What do you mean by nested unique modes?

(0000880)
mark   
2016-02-20 12:58   
By nested unique modes I mean modes for structured terms in which the uniqueness of the subterms is significant. That includes being partially composed of a non-unique term, as is the case in what you are attempting.

Is the bug report just that the compiler throws an exception instead of giving a spurious mode error, as it says in the reference manual?
(0000881)
FlyingJester   
2016-02-20 13:51   
(Last edited: 2016-02-23 03:24)
This bug report is simply that the compiler throws an exception.

(0000882)
mark   
2016-02-20 15:23   
Confirm that this is a bug. The compiler should give a proper error message when attempting to use nested unique modes.

Note that the feature itself is officially NYI.




View Issue Details
403 [mercury] Bug minor always 2016-02-09 10:02 2016-02-18 14:36
juliensf  
juliensf  
normal  
assigned  
open  
none    
none  
   
Normal termination of a program in the Java grade does not flush stdout
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.)
 
Notes
(0000877)
juliensf   
2016-02-18 14:36   
(Last edited: 2016-02-18 14:36)
Workaround committed in commit f56b11d. The workaround inserts calls to flush stdout and stderr
before System.exit() is called. The affected test cases all now pass (or fail for other non-related reasons).





View Issue Details
402 [mercury] Bug minor always 2016-01-02 03:51 2016-01-10 01:00
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
state variables not supported in require_complete_switch scope heads
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)'.

bug402.m (370 bytes) 2016-01-02 03:51
https://bugs.mercurylang.org/file_download.php?file_id=255&type=bug
 
Notes
(0000874)
zs   
2016-01-10 01:00   
Fixed 2016 jan 2.




View Issue Details
400 [mercury] Bug minor always 2015-12-16 23:13 2015-12-16 23:13
juliensf  
 
normal  
new  
open  
none    
none  
   
ROTDs can no longer compile extras/trailed_update
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.
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
388 [mercury] Bug minor have not tried 2015-07-10 13:50 2015-12-14 10:31
juliensf  
juliensf  
normal  
resolved  
fixed  
none    
none  
  15.11  
Inconsistent permissions on library jar files
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.)
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
(0000840)
juliensf   
2015-07-10 14:07   
This is occurring on a CentOS 7 system. Thing are ok on OS X system.
(0000841)
sebgod   
2015-07-10 14:15   
Hello Julien. I have the same problem on Fedora as well. This is a problem introduced by Java 7+, where temporary files get only 0600 permissions.
This happens when the Mercury compiler invokes the Java index option, which is currently used in a wrong fashion any way, since the jar index only works for multiple referenced jar files, but Mercury only references the jar file itself, which is not needed.
I've added a patch to make that point clearer.
(0000871)
juliensf   
2015-12-14 10:31   
Fixed in commit 2d01e41. (The race condition on Windows has been moved into bug 0000399.)




View Issue Details
399 [mercury] Bug minor have not tried 2015-12-14 10:27 2015-12-14 10:28
juliensf  
juliensf  
normal  
assigned  
open  
none    
none  
   
race condition on Windows when comparing a file to itself.
The attached patch fixes a race condition on Windows when comparing a file to itself.
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
(0000870)
juliensf   
2015-12-14 10:28   
The parts of the patch that deal with 0000388 have been handled separately.




View Issue Details
115 [mercury] Bug minor always 2009-11-05 21:50 2015-11-30 16:50
petdr  
juliensf  
low  
resolved  
fixed  
none    
none  
   
segfault for predicate names containing multibyte utf8 char
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.
test.m (98 bytes) 2009-11-05 21:50
https://bugs.mercurylang.org/file_download.php?file_id=88&type=bug
 
Notes
(0000227)
wangp   
2009-12-03 11:19   
This is "only" a problem on 64-bit machines installing from the generated .c files targeted at 32-bit architectures. It has something to do with the number of tag bits. A stage2 compiler does not crash.
(0000270)
juliensf   
2010-06-29 18:27   
Building the source distribution with --no-smart-indexing makes this problem go away.
I strongly suspect that some of the code generation approaches we use for switches
are not respecting the --cross-compiling option. (Most probably, it is the ones that
call int.bits_per_int/0 somewhere along the way.)
(0000869)
juliensf   
2015-11-30 16:50   
Fixed when we transitioned to Unicode.




View Issue Details
10 [mercury] Bug minor always 2007-09-28 11:31 2015-11-29 16:08
maclarty  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
:- pragma source_file ignored for warnings about unused imports in the interface.
A :- pragma source_file directive at the top of a mercury file is ignored for warnings about unused imports in the interface.

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.
sc.m (200 bytes) 2007-09-28 11:31
https://bugs.mercurylang.org/file_download.php?file_id=7&type=bug
 
Notes
(0000007)
juliensf   
2007-10-01 12:19   
I don't think there is any point in dealing with this one until the
parse tree is restructured.
(0000868)
juliensf   
2015-11-29 16:08   
Fixed, although I'm not sure when, presumably as part of the parse tree restructure.
Regression test has been added.




View Issue Details
50 [mercury] Bug minor always 2008-03-04 01:48 2015-11-15 23:15
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
another compiler abort when using debug grades
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.
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
(0000867)
zs   
2015-11-15 23:15   
Fix committed 2015 nov 15.




View Issue Details
17 [mercury] Bug minor always 2007-10-11 12:18 2015-11-11 19:00
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
  15.11  
no error for unknown types in interface if defined in implementation
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.
not_abstract.m (138 bytes) 2007-10-11 12:18
https://bugs.mercurylang.org/file_download.php?file_id=9&type=bug
 
Notes
(0000866)
zs   
2015-11-11 19:00   
Fix committed 2015 nov 11.




View Issue Details
264 [mercury] Bug minor always 2012-10-02 22:55 2015-11-02 16:55
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
function mode lost without warning
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
default_ho_inst.m (482 bytes) 2012-10-02 22:55
https://bugs.mercurylang.org/file_download.php?file_id=161&type=bug
 
Notes
(0000865)
zs   
2015-11-02 16:55   
Fix committed 2015 nov 2.




View Issue Details
232 [mercury] Bug minor always 2011-11-24 11:16 2015-11-02 16:07
pbone  
pbone  
normal  
resolved  
won't fix  
none    
none  
   
The thread pinning code in the parallel runtime doesn't work on older Linux systems.

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.
 
There are no notes attached to this issue.




View Issue Details
86 [mercury] Bug minor always 2008-09-29 11:05 2015-11-02 13:08
user90  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
Uncaught mode error leads to crash in codegen.m
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.
 
Notes
(0000860)
juliensf   
2015-11-02 13:08   
This was fixed in commit 491bb0a.




View Issue Details
191 [mercury] Bug minor always 2011-03-22 13:52 2015-11-02 11:10
colanderman  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
indirect instance implementations ignore special insts
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.
Software Error: code_gen.m: Unexpected: semidet model in det context
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
(0000321)
colanderman   
2011-03-22 14:18   
(Last edited: 2011-03-22 14:25)
This seems to be part of a more general problem of complex insts not being propagated through predicate calls. Am I misunderstanding the semantics of the language?

Edit: seems to be related to bugs # 86 and 117.

(0000322)
colanderman   
2011-04-05 12:22   
Squashed it, was a one-line fix in compiler/inst_match.m. Also fixes bugs 86 and 117. See attached patch.
(0000323)
juliensf   
2011-04-07 03:22   
The above patch breaks compilation of the stage 2 standard library. (That doesn't necessarily
mean it is incorrect, since at least some the library code that breaks looks suspicious -- we
will need to look into this further before applying the above patch.)
(0000326)
colanderman   
2011-04-07 13:41   
That's what I get for being sneaky and skipping the install phase :)

Attached is a (much larger) patch that fixes *most* of the library issues. It involved some mode additions to the list module (there really should be lots more), generalizing the mode of cc_multi_equal, and specializing cc_multi_equal in exception.m (this is due to the fact that the compiler chooses the di/uo mode of cc_multi_equal as "best" and doesn't try the other mode when it fails).

term_to_xml.m still doesn't compile, and I believe it is due to a possible bug I mentioned on the users mailing list, concerning predicates which refine nested insts. The error I'm getting is:

term_to_xml.m:1348: In clause for `'__Unify__'(in, (unique(list.'[|]'(free,
term_to_xml.m:1348: unique((list.[])))) >> bound(list.'[|]'(ground,
term_to_xml.m:1348: bound((list.[]))))), (ground >>
bound(list.'[|]'(ground,
term_to_xml.m:1348: bound((list.[]))))))':
term_to_xml.m:1348: mode error: argument 3 did not get sufficiently
term_to_xml.m:1348: instantiated.
term_to_xml.m:1348: Final instantiatedness of `HeadVar__2' was
term_to_xml.m:1348: `bound(list.'[|]'(ground, ground))',
term_to_xml.m:1348: expected final instantiatedness was
term_to_xml.m:1348: `bound(list.'[|]'(ground, bound((list.[]))))'.

which looks suspiciously similar to the issue I mentioned. I will focus my efforts on trying to track down that bug, and will hope that it's as simple as this one was to fix.
(0000859)
juliensf   
2015-11-02 11:10   
This was fixed in commit 491bb0a.




View Issue Details
187 [mercury] Bug minor always 2011-03-06 17:12 2015-10-31 21:00
colanderman  
juliensf  
normal  
confirmed  
open  
none    
none  
  15.11  
Strange error with disjunctive definitions returning existential typeclass instance
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.
test.m (265 bytes) 2011-03-06 17:12
https://bugs.mercurylang.org/file_download.php?file_id=113&type=bug
 
Notes
(0000546)
juliensf   
2013-06-28 14:55   
(Last edited: 2013-06-28 14:57)
The problem here is that polymorphism transforms the multi-clause version into the following:

% Clause 1.
test.f(TypeClassInfo_for_foo_3, HeadVar__1_1) = HeadVar__2_2 :-
  (
    ( HeadVar__1_1 = test.x,
      HeadVar__2_2 = test.a
    ),
    TypeClassInfo_for_foo_4 = typeclass_info_const(0),
    TypeClassInfo_for_foo_3 = TypeClassInfo_for_foo_4
  ).

% Clause 2
test.f(TypeClassInfo_for_foo_3, HeadVar__1_1) = HeadVar__2_2 :-
  (
    (
      HeadVar__1_1 = test.y,
      HeadVar__2_2 = test.b
    ),
    TypeClassInfo_for_foo_3 = TypeClassInfo_for_foo_4
  ).

In the second clause TypeClassInfo_for_foo_4 is free. It should presumably have been pointed
at typeclass_info_const(0) as in the first clause, but that hasn't happened for some reason.
(Possibly, the mapping of typeclass_infos to static data is being maintained across clauses, so it thinks
that it has already introduced the unification with the constant when it processes the second clause.)

(A workaround here is to re-write the predicate with a single clause -- as mentioned in the original bug report -- since polymorphism will process that in one go and the issue won't arise.)

(0000548)
pbone   
2013-06-28 15:45   
Possibly related to bug 0000271. When fixing this consider the fix for 0000271 and also retest 0000271.




View Issue Details
117 [mercury] Bug minor always 2009-11-28 02:36 2015-10-31 19:04
pjrm  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
No error message for false non_empty_list declaration; runtime segfault
(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.
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
(0000220)
wangp   
2009-12-01 01:53   
Can you post a test case?
(0000222)
pjrm   
2009-12-01 03:13   
I've attached two files, nonempty12.m and call_nonempty12.m. The first is the one of interest, in that it compiles without error. The second is the obvious corresponding `main' predicate that segfaults when trying to access the first element of the list.

The test case is remarkably simple, not at all the highly specific circumstances I'd usually have for a Mercury compiler bug; I suppose then that it must be related to one of the several already-known limitations in the current mode system implementation.

I've tested with rotd-2009-02-26 on i686-pc-linux-gnu (Debian), with mgnuc=gcc-3.4.6, with both
`mmc --make --debug call_nonempty12 && ./call_nonempty12' and
`mmc --make --grade=hlc.gc call_nonempty12 && ./call_nonempty12'.
(Also tested with rotd-2007-12-16, so it's fairly long-standing.)
(0000223)
wangp   
2009-12-01 21:35   
The problem is the following XXX.

inst_matches_final_3(ground(UniqA, HOInstInfoA), bound(UniqB, ListB),
        MaybeType, !Info) :-
    ModuleInfo = !.Info ^ imi_module_info,
    \+ ho_inst_info_is_nonstandard_func_mode(ModuleInfo, HOInstInfoA),
    unique_matches_final(UniqA, UniqB),
    bound_inst_list_is_ground(ListB, MaybeType, ModuleInfo),
    uniq_matches_bound_inst_list(UniqA, ListB, ModuleInfo),
    (
        MaybeType = yes(Type),
        % We can only do this check if the type is known.
        bound_inst_list_is_complete_for_type(set.init, ModuleInfo, ListB, Type)
    ;
        true
        % XXX enabling the check for bound_inst_list_is_complete
        % for type makes the mode checker too conservative in
        % the absence of alias tracking, so we currently always
        % succeed, even if this check fails.
    ).
(0000858)
juliensf   
2015-10-31 19:04   
This was fixed in commit 491bb0a.
(I have added a test case for it.)




View Issue Details
318 [mercury] Bug minor always 2014-02-13 11:31 2015-10-29 15:23
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
pragma foreign_type depends on item order
An error is reported for a pragma foreign_type if the type name is not declared earlier.
foreign.m (135 bytes) 2014-02-13 11:31
https://bugs.mercurylang.org/file_download.php?file_id=203&type=bug
 
Notes
(0000646)
juliensf   
2014-02-13 14:41   
That happens because type declarations and pragmas are added to the HLDS during the same pass.
One solution would be to add all the type declarations before adding all the pragmas; the disadvantage of that approach is that it would require another traversal of the parse tree during parse tree -> hlds conversion.