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
480 [mercury] Bug minor always 2019-08-05 17:09 2019-08-20 10:35
wangp  
zs  
normal  
assigned  
open  
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.




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
joan 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)
joan   
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
461 [mercury] Bug minor sometimes 2018-05-17 11:15 2018-05-17 11:15
wangp  
 
normal  
new  
open  
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.)
 
There are no notes attached to this issue.




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.
(0000647)
juliensf   
2014-02-13 19:31   
Actually, there's another solution to this, we could allow foreign_type pragmas to act as type declarations.
(0000653)
zs   
2014-03-03 14:13   
I think the right solution is to away with the notion of "passes" over the item list altogether.

I think the one and only pass over the item list should construct a set of cords; one cord for type declarations, one for inst declarations, one for mode declarations, one for pred declarations and so on. Once those cords have been converted to lists, the rest of the code should then process those lists
in the order that their dependencies dictate. One of those dictates would be the need to process type declarations before processing foreign type pragmas.

The main complication is that at the moment, the import status of each item is effectively implicit in the position of the item with respect to status markers in the item list, and the exact details of that dependence are not well documented. Most of those details are obvious, but some are not.
(0000857)
zs   
2015-10-29 15:23   
Fix committed 2015 oct 29.




View Issue Details
278 [mercury] Bug minor always 2013-04-04 23:16 2015-10-29 14:47
pbone x86_64  
zs Debian Linux  
normal 7.0  
resolved  
fixed  
none    
none  
  15.11  
Compiler crash from bad state variable use.
If I refer to the wrong state variable in the head of a lambda expression, I can reliably crash the compiler. I have a test case.
Attached in the testcase It crashes when I compile it with 'mmc --make' It also crashes in the Java grade.

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

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

I'm using the 12.08 beta (The release MCit is using)
bug278.m (841 bytes) 2013-04-04 23:19
https://bugs.mercurylang.org/file_download.php?file_id=173&type=bug
 
Notes
(0000502)
juliensf   
2013-04-10 16:06   
In principle this is easy to fix, just replace the relevant call to unexpected/2 in compiler/state_var.m
with something that generates a proper error message. The issue is: what should that error message
be? (Probably, before zs rewrote the state var transformation this would have been picked up
later by mode checking ...)
(0000503)
juliensf   
2013-04-10 16:07   
It (hopefully) goes without saying, that this has nothing do with what backend is being used!
(0000532)
juliensf   
2013-05-29 00:43   
Actually, with Mercury 10.04.2, lots of phases picked up the error:


bug278.m:023: In clause for predicate `build_map'/5:
bug278.m:023: in argument 1 of call to predicate `list.foldl2'/6:
bug278.m:023: type error: argument has type `pred(tree234.tree234(K, V), V,
bug278.m:023: tree234.tree234(K, V), V_11, V_9)',
bug278.m:023: expected type was `pred(L, A, A, Z, Z)'.
bug278.m:023: In clause for predicate `bug278.build_map'/5:
bug278.m:023: warning: variable `STATE_VARIABLE_MemoTable' occurs only once
bug278.m:023: in this scope.
bug278.m:028: In clause for predicate `build_map'/5:
bug278.m:028: in argument 1 (i.e. the predicate term) of higher-order
bug278.m:028: predicate call:
bug278.m:028: type error: variable `KeyToValue' has type `(some [K, V]
bug278.m:028: pred(K, V))',
bug278.m:028: expected type was `pred(V_13, V_12, V_11, V_10)'.
bug278.m:030: In clause for predicate `build_map'/5:
bug278.m:030: in implicit state variable unification:
bug278.m:030: type error in unification of variable `STATE_VARIABLE_M_1'
bug278.m:030: and variable `STATE_VARIABLE_M_0'.
bug278.m:030: `STATE_VARIABLE_M_1' has type `tree234.tree234(K, V)',
bug278.m:030: `STATE_VARIABLE_M_0' has type `V'.

The issue here is: what is an appropriate error message to generate during the state var transformation?
(0000856)
zs   
2015-10-22 06:49   
fix committed 2015 oct 22.




View Issue Details
397 [mercury] Bug minor always 2015-10-13 17:43 2015-10-20 18:00
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
Clang fails to deal with -R command line parameter
Not necessarily our bug, but clang 3.4 does not like -R/foo:

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

https://llvm.org/bugs/show_bug.cgi?id=18164
 
Notes
(0000851)
juliensf   
2015-10-14 10:08   
Presumably it is happy with -Wl,-rpath though? We may need to make the definitions of SHLIB_RPATH_OPT etc in the configure script dependent on the C compiler type on the affected platforms.
(0000853)
wangp   
2015-10-14 12:38   
Yes, all of these work. The linker is GNU ld.

-Wl,-R
-Wl,-rpath
-rpath

so we can probably just remove lines in configure.ac that force "-R" for FreeBSD.
(0000854)
juliensf   
2015-10-14 15:14   
Yep, that would work for GCC as well. I assume you have a FreeBSD system set up to test this on?




View Issue Details
395 [mercury] Bug minor have not tried 2015-10-12 14:46 2015-10-20 18:00
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
non tail recursion in lexer.m
In lexer.m, execute_get_token_action calls skip_to_eol which calls get_token_2 which calls execute_get_token_action.

I believe this is the cause of a C stack overflow on FreeBSD/i386/gcc48/hlc.gc.
 
There are no notes attached to this issue.




View Issue Details
396 [mercury] Bug minor always 2015-10-12 15:44 2015-10-20 18:00
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
non tail recursion in prog_io.m
read_items_loop calls read_items_loop_2 which calls read_items_loop

In high-level C grades this can overflow the C stack when reading a module with a large number of items.
 
Notes
(0000855)
wangp   
2015-10-20 18:00   
This particular problem was already fixed on the master branch when I submitted the report. There were some other similar problems, which have now been fixed.




View Issue Details
394 [mercury] Bug minor have not tried 2015-09-20 01:43 2015-10-14 10:12
juliensf  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
Building compiler with --use-mmc-make broken (rotd-2015-09-18)
Building the compiler in the hlc.gc or java grade using rotd-2015-09-18 and --use-mmc-make results in the following error:

Making Mercury/cs/hlds.passes_aux.c
Making Mercury/cs/hlds.pred_table.c
Making Mercury/cs/hlds.quantification.c
Error opening file `Mercury/opts/hlds.quantification.opt.tmp' for output: can't append to file: No such file or directory** Error making `Mercury/cs/hlds.quantification.c'.
/var/folders/pd/5lypc6_j3vnf65q9x5y9s3p40000gn/T//mmake.D1F8M2:1421: recipe for target 'top_level' failed
gmake[1]: *** [top_level] Error 1
gmake[1]: Leaving directory '/Users/jfischer/Mercury-Workspaces/mercury.local-5/compiler'
/var/folders/pd/5lypc6_j3vnf65q9x5y9s3p40000gn/T//mmake.cjoMVE:1073: recipe for target 'compiler' failed
gmake: *** [compiler] Error 2
Commenting the line that enables --optimize-unused-args for the hlds.quantification module in compiler/Mercury.options is a workaround.
 
Notes
(0000852)
juliensf   
2015-10-14 10:12   
This was fixed by commit 4eab5db.




View Issue Details
389 [mercury] Feature Request minor have not tried 2015-07-21 10:45 2015-09-30 15:31
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
aligned_pointer foreign type assertion
This is a proposal for a foreign type assertion. The user promises that values of this type would be clear in the tag bits (most likely a word-aligned pointer). The compiler would therefore be able to apply the direct arg optimisation to functors with a single argument of that foreign type.

(just writing it down for now, I won't be implementing it soon)
 
Notes
(0000850)
wangp   
2015-09-30 15:31   
Added in commit 62db25b




View Issue Details
391 [mercury] Bug minor always 2015-08-14 16:56 2015-09-18 17:33
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
trace conditions lost in .opt files
Conditions on trace goals are not written out to .opt files, thus trace goals may be executed when their conditions are not met.

The .opt file for the attached module includes:

require_lt.require_lt(A_3, B_4) :-
    (
      % trace
      % compiletime(flag(checks))
      % quantified vars
      require_lt.require_lt0(A_3, B_4)
    ).
require_lt.m (398 bytes) 2015-08-14 16:56
https://bugs.mercurylang.org/file_download.php?file_id=248&type=bug
 
Notes
(0000849)
zs   
2015-09-18 17:33   
Fix was committed 14 aug 2015.




View Issue Details
393 [mercury] Bug minor always 2015-09-15 10:40 2015-09-18 06:57
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
#line directives in .mh cause unnecessary recompilations
This is a source of mysterious recompilations that I was experiencing in debug grades. I had a mutable declaration near the *end* of a file:

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

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

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

Adding or removing blank lines would be enough to triggering recompilation of seemingly unrelated .c files.
 
Notes
(0000848)
zs   
2015-09-18 06:57   
Fixed 18 sep 2015 by commit 410c75c81f47d0a1f5620f1f41f4e7afe87c665d.




View Issue Details
363 [mercury] Bug minor always 2014-09-17 17:22 2015-08-23 14:50
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
misleading error message for missing comma in foreign_proc attribute list
The attached program causes the following error message.

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

The invalid argument is the *third* argument, not the second.
foo.m (249 bytes) 2014-09-17 17:22
https://bugs.mercurylang.org/file_download.php?file_id=227&type=bug
 
Notes
(0000847)
zs   
2015-08-23 14:50   
Fix committed 2015 aug 23.




View Issue Details
392 [mercury] Bug minor always 2015-08-17 14:13 2015-08-17 15:38
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
compiler abort with deforestation
Reproduceable with 14.01 and master.

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

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




View Issue Details
390 [mercury] Bug minor always 2015-08-05 17:11 2015-08-05 17:11
wangp  
 
normal  
new  
open  
none    
none  
   
MR_ALLOC_ID visibility
In non-memprof grades a MR_ALLOC_ID symbol is visible outside foreign_proc bodies, unlike in memprof grades. It is easy to move code from a foreign_proc to a foreign_code block and have it compile, only to find out much later that it is broken in memprof grades.
 
There are no notes attached to this issue.




View Issue Details
385 [mercury] Bug minor always 2015-04-06 18:47 2015-07-22 09:08
dirkz MinGW/MSYS 32bit rotd-2015-03-10  
juliensf Windows 7 Professional 64 bit  
normal Win 7 64 bit  
resolved  
fixed  
none    
none  
   
mercury_compile.exe crashes during compilation of large fact table on MinGW/MSYS
mercury_compile.exe crashes without giving any error message at all.

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

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

Mercury-Version: rotd-2015-03-10
mmc --make --grade none.gc contextOfDataPoints
As a workaround, I can use pragma fact_table.
contextOfDataPoints.m.gz (138,275 bytes) 2015-04-06 18:47
https://bugs.mercurylang.org/file_download.php?file_id=243&type=bug
 
Notes
(0000824)
juliensf   
2015-04-07 13:56   
The compiler built from the source distribution (for 32-bit MinGW/MSYS) is aborting with error status
0XC0000FD (i.e. STATUS_STACK_OVERFLOW).
(0000845)
zs   
2015-07-22 09:08   
As discussed on the mailing list, the problem was stack exhaustion while parsing a very long item list.

Fixed by commit f2043fc9bd58b084701fc8e7618e0a5ccbf83d7f. It should be in the next release of the day. (It is NOT in the rotd for july 20.)




View Issue Details
381 [mercury] Bug major always 2015-03-01 00:09 2015-07-15 12:07
ttmrichter Some Lenovo i5 laptop or other  
Linux Mint  
normal 15  
new  
open  
none    
none  
   
Compiler deals poorly with '.' character constants.
Unifying variables with '.' causes compiler to fail with "operator precedence error".
Compile attached code. If line 10 is not commented out (as uploaded) the compiler will explode. If line 10 is commented out, the compiler is happy.
Mercury Compiler, version rotd-2015-02-20, on x86_64-unknown-linux-gnu
bug.m (401 bytes) 2015-03-01 00:09
https://bugs.mercurylang.org/file_download.php?file_id=238&type=bug
 
Notes
(0000844)
mark   
2015-07-15 12:07   
Mercury has no specific lexical syntax for character literals - they are just terms with arity 0, whose identifiers have length 1.

Single lower case characters are valid identifiers, and so are all operators defined in the operator table. Any other character needs to be enclosed in single-quotes to be a valid identifier, otherwise it won't be treated as a character literal.

Single-character operators in the operator table don't need the quotes, as they are already valid identifiers. However, operators in this table never have arity zero, so they won't be treated as character literals anyway, unless parentheses are used to override the operator table in the usual way. That is the problem in bug.m.

Hence this issue is not a bug, it is intended behaviour. However, it is a common problem for users, and if Mercury had specific syntax for character literals this common problem would be avoided. So perhaps this issue should be considered a feature request for character literal syntax?




View Issue Details
339 [mercury] Bug major always 2014-06-22 07:19 2015-07-14 17:30
sebgod Windows NT 6.3 x86_64  
juliensf Windows  
normal 8.1  
resolved  
fixed  
none    
none  
   
mmc --java with Oracle Java 1.8.0 fails on Windows
Making Java class files
An exception has occurred in the compiler (1.8.0). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you.
java.lang.AssertionError: the -J flag should be caught by the launcher.
        at com.sun.tools.javac.main.Option$20.process(Option.java:330)
        at com.sun.tools.javac.main.Main.processArgs(Main.java:260)
        at com.sun.tools.javac.main.Main.compile(Main.java:414)
        at com.sun.tools.javac.main.Main.compile(Main.java:381)
        at com.sun.tools.javac.main.Main.compile(Main.java:370)
        at com.sun.tools.javac.main.Main.compile(Main.java:361)
        at com.sun.tools.javac.Main.compile(Main.java:56)
        at com.sun.tools.javac.Main.main(Main.java:42)
Compile any program using the Java grade
Break resulted only from installation of the Java JDK 8.0;
recompilation of the Mercury compiler did work but did not change the given output.
Using the latest MinGW with gcc 4.7 for 32bit
Java 1.8.0
.NET 4.5.1
Bootstrapped (with ROTD from June 2014) Mercury-dev
fix-java8-flag-reorder.diff (1,247 bytes) 2014-12-16 02:54
https://bugs.mercurylang.org/file_download.php?file_id=229&type=bug
 
Notes
(0000711)
juliensf   
2014-06-25 16:59   
Do you know if this occurred / occurs with older versions of Java on the same system?
(0000713)
sebgod   
2014-06-26 23:46   
On the same machine, I had Java 1.7.5x installed,
Mercury was working fine with that version.
Then I upgraded Java to 1.8.0_05,
When using the command line:
mercury --use-grade-subdirs -s java -m libmercury_misc (e.g.)
then I received the aforementioned error.
Rebuilding the compiler did not resolve that issue.
I could reproduce the error with Mercury 14_01 MinGW32 on Windows XP SP3
with Java 1.8.0 (okay that is not supported but still I got the same error)
(0000717)
wangp   
2014-06-27 11:13   
(Last edited: 2014-06-27 11:13)
Can you try editing your lib/mercury/conf/Mercury.config file

This line has the wrong quoting

--java-flags "-J"-Xmx1024m""

Try fixing the quoting to

--java-flags "-J-Xmx1024m"

Or perhaps removing the line completely. It may not be needed any more.

(0000719)
sebgod   
2014-06-27 17:21   
Fixing the quoting to --java-flags "-J-Xmx1024m"
still resulted to the complain from the Java compiler,
removing on the other hand resulted in a successful compilation.
(0000720)
juliensf   
2014-06-27 17:29   
I believe that the quoting on Windows needs to be something like:

   --java-flags "-J\"-Xmx1024m\""

That seems to be what I've done in the binary packages for Windows at any rate.
(0000721)
sebgod   
2014-06-28 04:00   
Using (in the .config)
--java-flags "-J\"-Xmx1024m\""
yields the same error, I suppose this is a JDK bug.
I'll have to do some tests with "normal" Java programs
and will check the http://java.sun.com/webapps/bugreport
the javac compiler kindly provides.
(0000735)
sebgod   
2014-07-05 21:09   
(Last edited: 2014-07-05 21:11)
I've tracked down the bug,
Using the mmc -V option I received the content of the "javac @tempfile"
% Args placed in @C:\Users\SEBAST~1\AppData\Local\Temp\mtmp000.3D2: `-classpath <snip> -sourcepath <snip> -d <snip> -J-Xmx1024m Mercury\\java\\i686-pc-mingw32\\Mercury\\javas\\jmercury\\fmt_bug.java'
When invoking javac + the arg string directly on the command line, the compilation is successful.
On a side note, the -J flag is correctly escaped.

Now if I create that @tempfile manually, and running javac @tempfile myself,
I do get the original error with the -J flag not being captured.
Checking the Oracle online documentation for javac:
http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javac.html
revleas that:
  @argfiles One or more files that lists options and source files.
The -J options are not allowed in these files.

I suspect that the assertion in the javac compiler was added in Java 8.0,
such that the -J flag passed via the @options-file was previously unnoticed (and most probably dysfunctional)

(0000823)
juliensf   
2015-04-05 15:18   
This was fixed in commit 9c85673.
(0000825)
juliensf   
2015-04-08 13:51   
Actually, commit 9c85673 only fixed the quoting issue. I'll look into fixing the issue with the -J
option being placed in the @options file.
(0000842)
juliensf   
2015-07-14 17:30   
Fixed (hopefully, for good) in commit d7857cf.




View Issue Details
293 [mercury] Bug minor always 2013-07-10 13:55 2015-07-08 13:19
juliensf x86-64  
juliensf Linux  
normal Fedora 19  
resolved  
fixed  
none    
none  
   
asm_fast grades do not work with GCC 4.8
The asm_fast grades do not work with GCC 4.8 on Fedora 19 x86-64 (and probably elsewhere).
(The configure test for gcc labels is failing due to a segmentation fault on my system.)
This was with Mercury 13.05.

 
Notes
(0000551)
juliensf   
2013-07-10 16:19   
This seems to be caused by the option -ftree-dominator-opts.
(0000555)
juliensf   
2013-07-12 01:37   
I've committed a fix for this (i.e. compile with -fno-tree-dominator-opts). I would also not that
compiling with -fno-omit-frame-pointer is also a possible fix. I'll keep this bug open until I've decided
what the best fix is.
(0000839)
juliensf   
2015-07-08 13:19   
We compile with -fno-tree-dominator-opts in this case. (Also affects GCC 4.9 and 5.)




View Issue Details
348 [mercury] Bug minor have not tried 2014-07-18 15:07 2015-07-08 13:15
juliensf  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
Failure of tests/general/string_format_special_floats with MSVC
When using MSVC as a C compiler, the test case tests/general/string_format_special_float fails as the MS libc doesn't appear to
implement the C99 behaviour for printing nan, inf etc.

With VS2012 we get:

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

We should probably check for special float values before calling sprintf
and just handle them directly using Mercury. (This would also avoid some
inconsistencies in the output of these tests due to do differences in C
libraries.)
 
Notes
(0000747)
juliensf   
2014-07-18 15:46   
The same problem also affects tests/hard_coded/write_float_special.
(0000748)
wangp   
2014-07-18 16:23   
For what it's worth, NaNs were printed on AIX as "NaNQ", where 'Q' stands for quiet.
(0000750)
juliensf   
2014-07-18 17:01   
C99 says they should be printed as: nan, -nan, nan(...) or -nan(...) where "..." is an implementation-defined sequence of letters, digits or underscores. (Or in uppercase if %F is used.)
(0000755)
juliensf   
2014-08-06 10:37   
I intend to address this one by checking for, and handling, inf and nan (although nan should really cause an exception to be thrown) in Mercury rather than relying on sprintf. Even with C99 there are too many annoying little differences in how inf and nan are handled. Dealing with Java and C# just complicates things further.
(0000838)
juliensf   
2015-07-08 13:15   
Fixed in commit 4e15777.




View Issue Details
280 [mercury] Bug minor always 2013-04-11 14:06 2015-07-07 15:23
juliensf  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
Parser stack overflow with MSVC
Attempting to compile compiler/options.c (from the rote-2012-04-10 srcdist) with MSVC
results in:

    fatal error C1026: parser stack overflow, program too complex

It looks as though the C code we generate for the predicate long_option/2 is too
heavily nested; I'll try to separate it out a bit and see if that avoids the limitation.
 
Notes
(0000505)
juliensf   
2013-04-11 14:09   
Actually, the problem may be that the source distribution is built with --no-smart-indexing.
(The other approaches for string switches shouldn't bump into these sort of limitations.)
(0000506)
juliensf   
2013-04-11 16:34   
It's fine if you rebuild the .c files with --smart-indexing. In the long term, I would like to be able
to compile the MSVC version of Mercury directly from the source distribution. Some options here are:

(1) Work out whether --smart-indexing is still causing problems with the source distribution.

(2) Manually, break long_options/2 into smaller chunks.

(3) If compiling with --no-smart-indexing then change the MLDS code generator so that
it breaks deeply nested if-then-else chains into separate C functions -- i.e. get the code generator
to do (2).
(0000837)
juliensf   
2015-07-07 15:23   
The source distribution C files are now built with --smart-indexing enabled (option 1 above).




View Issue Details
387 [mercury] Bug major always 2015-07-06 12:50 2015-07-07 14:58
pbone x86_64  
Debian  
normal stretch  
new  
open  
none    
none  
   
Polymorphism pass miscompiles some try goals.
I get the following error:

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

My predicate contains a try goal with a catch_any block. The TypeInfo in question is the type info for the exception, which passed out of the try goal in a maybe_error type and named-appart.
mmc --use-grade-subdirs -O3 --allow-stubs --no-warn-stubs --compile-to-c test_bdd_bug.m
polymorphism_try_bug.m (1,608 bytes) 2015-07-06 12:50
https://bugs.mercurylang.org/file_download.php?file_id=244&type=bug
bug387.m (597 bytes) 2015-07-06 17:30
https://bugs.mercurylang.org/file_download.php?file_id=245&type=bug
 
Notes
(0000831)
mark   
2015-07-06 17:28   
How do you think this ought to be compiled? What type should MaybeBDD have, for example?

The error message can be improved: you had to figure out what TypeInfo_25 was, and both line numbers refer to the containing disjunction instead of the disjuncts. Also, it's a try goal not a disjunction. But I think the general idea is right, in that the type was bound in one branch and not in another.

This issue applies to an existential type escaping from any form of disjunct. I'll upload a simplified case.
(0000832)
pbone   
2015-07-06 19:28   
I think that this can be compiled correctly, if unintuitive. If MaybeBDD is typed as some [E] maybe_error(bdd(V), {string, E}).

It will become unintuitive if the exception type appears in the head of the clause, that will require the predicate to be existentially typed.
(0000833)
mark   
2015-07-06 23:42   
To put the question another way, what would be the output of calling io.write(type_desc.type_of(MaybeBDD), !IO)? What's in the type_desc for E?

For the error branch, the type_desc is obviously meant to be whatever type_desc the exception value had. But for the ok branch, the type_desc is not provided anywhere. That's more or less what the compiler error message is trying to say.

Note that a similar idiom to those documented in the Existential Types chapter also applies here, namely, wrap ExpPrime in a univ:

catch_any ExpPrime ->
    MaybeBDD = error({"My message", univ(ExpPrime)})
(0000834)
pbone   
2015-07-07 10:29   
I tried breaking the predicate into two parts so that I can put the try goal in a predicate that explicitly returns an existential type. (My idea is that the types should be named apart and the type of the exception should be set when MaybeBDD is unified with error and deconstructed.

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

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

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

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

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

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

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

We can make it a type error for the type of an exception to escape the catch_any branch. Or indeed any branching structure, this will allow us to produce a better error message. Do you agree? is a type error the way to go here? (My reasoning is that the program is incorrectly typed.)
(0000835)
pbone   
2015-07-07 10:29   
Thank you.
(0000836)
mark   
2015-07-07 14:58   
Breaking it into two parts better illustrates why this is a program error, not just a compiler bug. The signature says that there is "some" type, which means that this predicate is responsible for producing that type (see "Semantics of type quantifiers" in the reference manual). But the programmer only provides that type in the catch_any clause, not in the then clause, hence the "mode" mismatch.

The compiler could fill in the type as 'void', like in other circumstances, but this doesn't seem a good idea. If the programmer has provided a type in at least one branch of a branched structure, they ought to do so in all branches. In any case the compiler's use of 'void' would generate a warning.

Which brings us to a different problem: there is no way to give different types in different branches anyway, because that would be a type error. So the following won't work:

    ( X = 1 ; X = "foo" ), io.write(X, !IO)

Instead you must push the polymorphic calls inside the branches:

    ( X = 1, io.write(X, !IO) ; X = "foo", io.write(X, !IO) )

or else you can "box" the existential type:

    ( X = 1, UX = univ(X) ; X = "foo", UX = univ(X) ),
    io.write(univ_value(UX), !IO)

So, regarding your last question, if the programmer does address the "mode" error by providing a type for every branch (or none), then with the current language they will already necessarily receive a "type" error, as the existential type in one branch is opaque and cannot be referred to in the other branches.

I don't think it matters much whether these are called mode errors or type errors. Given that the type quantifier determines where a type is produced, the two concepts amount to the same thing as far as checking the quantifiers is concerned.




View Issue Details
386 [mercury] Bug major always 2015-06-29 01:37 2015-07-01 01:36
juliensf  
juliensf  
normal  
resolved  
fixed  
none    
none  
   
rotd-2015-03-24 and following broken
rotd-2015-03-24 and the following rotds break when installing from the source distribution.
During the install_grades step, compiling library/array.m to C results in:

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

 
Notes
(0000826)
juliensf   
2015-06-29 01:41   
This has been confirmed on x86_64 Linux (gcc 4.7 and 4.9) and x86_64 Darwin (gcc 4.9).
It occurs with both --no-smart-indexing and --smart-indexing.
(0000827)
juliensf   
2015-06-29 11:05   
Also, on x86_64 Darwin while building array.c in none.gc (Apple clang 600.0.56).
(0000828)
juliensf   
2015-06-29 11:46   
On i686 Darwin systems things are fine.
(0000829)
juliensf   
2015-06-29 15:25   
The problem was introduced in commit 6e3e60f.
https://github.com/Mercury-Language/mercury/commit/6e3e60fae083d9c216dfa4249fae0f3fee33ebd6
(0000830)
juliensf   
2015-07-01 01:36   
Fix in commit b915b25.




View Issue Details
384 [mercury] Bug minor always 2015-03-31 11:22 2015-04-02 12:13
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Stage 1 compiler directory fails in hlc.gc grade with syntax errors in optimisation interfaces
Build the current git HEAD with rotd-2015-03-30 in hlc.gc with -O5 --intermodule-optimization
fails in the compiler directory due to:

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

The contents of analysis.err are:

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

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

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

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


 
Notes
(0000821)
zs   
2015-03-31 14:08   
I am pretty sure the change that lead to this is the change I committed on march 5, which pre-propagated types into the insts of the inst table. However, the right fix is not to undo that, but to fix the code that outputs insts so that it doesn't output typed insts into interface files. (We do still want to output them for debugging.)

I will fix this later today.
(0000822)
zs   
2015-04-02 12:13   
Fix committed 2 april 2015.




View Issue Details
383 [mercury] Bug minor always 2015-03-25 13:59 2015-03-25 19:53
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Program behaviour changes when trie string switches are used
The behaviour of the attached program with the attached input differs depending on
whether the predicate cadmium_op_table/2 is compiled into a trie string switch or not.
  $ mmc --make bug
  $ ./bug < bug.inp

yields:

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

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

yields:

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

The latter is the expected output for this program.

The problem did not exist in rotd-2015-02-20. It exists in rotd-2015-02-27 onwards.
(The change that added trie string switches was committed on 2015-02-24; the next
rotd build was 2015-02-27.)
bug.m (7,737 bytes) 2015-03-25 14:00
https://bugs.mercurylang.org/file_download.php?file_id=241&type=bug
bug.inp (435 bytes) 2015-03-25 14:00
https://bugs.mercurylang.org/file_download.php?file_id=242&type=bug
 
Notes
(0000820)
zs   
2015-03-25 19:53   
Fix committed in commit c1e0499140ec5c38369b0cacb546618f56061ed2.




View Issue Details
382 [mercury] Bug crash always 2015-03-15 00:22 2015-03-16 03:15
pbone x86_64  
zs Debian  
normal 8.0  
resolved  
fixed  
none    
none  
   
arg-pack-bits optimisation broken with foreign_enums.

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

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

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

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

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

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

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

The error goes away when I set --arg-pack-bits=0
Note that the solution will need to be aware of cases where the foreign enum is in the implementation section of a different module.
bug_pack_bits.m (2,542 bytes) 2015-03-15 00:22
https://bugs.mercurylang.org/file_download.php?file_id=239&type=bug
 
Notes
(0000817)
zs   
2015-03-15 04:31   
I know what is causing the problem. The code in du_type_layout.m that decides on whether
and how the arguments in a memory cell will be packed is invoked at the end of pass 2
in the making of the HLDS, but the foreign_enum pragma is processed only in pass 3.
This means that while du_type_layout.m does the right thing, it is given wrong data.
Since it thinks that family and socktype are Mercury enums that are NOT exported to
other languages, it believes it is safe to compress them in fields.

I am working on a change to move the processing of those pragmas to pass 2.
Getting rid of the pass system would be even better, but that would conflict with
my work on the item list structure.
(0000818)
pbone   
2015-03-15 10:06   
Thanks Zoltan.

Just a quick note regarding "Mercury enums that are NOT exported to
other languages," These enums aren't exported from Mercury, they're imported to Mercury.

Cheers.
(0000819)
zs   
2015-03-16 03:15   
Fixed in commit 6dd74cad6471b9c1db11575034d7a866c8429a87, 2015 march 16.




View Issue Details
380 [mercury] Bug minor always 2015-02-25 15:55 2015-02-28 14:18
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
mercury_string.h not always included in high-level C grades
mercury_string.h is not always included by the generated C file unless the module imports the string module, but the compiler may generate references to macros defined in that file. The easiest fix would be to include mercury_string.h in mercury.h

% mmc -s hlc.gc -c words
words.m: In function ‘words__word_1_p_0’:
words.m:12:7: warning: implicit declaration of function ‘MR_nth_code_unit’ [-Wimplicit-function-declaration]
 word("aback").
       ^
words.m:12:17: warning: implicit declaration of function ‘MR_offset_streq’ [-Wimplicit-function-declaration]
 word("aback").
words.m (603 bytes) 2015-02-25 15:55
https://bugs.mercurylang.org/file_download.php?file_id=237&type=bug
 
Notes
(0000816)
zs   
2015-02-28 14:18   
Fix committed 2015 feb 27.




View Issue Details
366 [mercury] Bug minor always 2014-10-27 16:15 2015-02-20 15:20
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
enable inst_matches_final_bug and ho_default_func_4
The aforementioned test cases can now be enabled after the hack in inst_matches_final was removed.
 
There are no notes attached to this issue.




View Issue Details
377 [mercury] Bug minor always 2015-02-18 01:46 2015-02-19 01:46
mvd23jsdf4 x86_64  
juliensf Fedora  
normal 21  
feedback  
open  
none    
none  
   
Debugger doesn't have help installed.
After building and installing the debugger, mdb doesn't have any help files.
./configure --prefix=$HOME/.local --enable-minimal-install --enable-additional-libgrades=asm_fast.gc.debug,asm_fast.gc.decldebug
make PARALLEL=-j2
make PARALLEL=-j2 install
 
Notes
(0000815)
juliensf   
2015-02-19 01:46   
Do you mean that the 'help' command in mdb is not displaying anything, or something different?
Can you please check that the file $HOME/.local/lib/mercury/mdb/mdb_doc is present and non-empty.
(That file should contain the help documentation for mdb.)




View Issue Details
378 [mercury] Bug minor have not tried 2015-02-18 01:52 2015-02-19 01:42
mvd23jsdf4 x86_64  
Fedora  
normal 21  
new  
open  
none    
none  
   
Cannot access library source files when debugging
When debugging an application and the code enters a library file, you are unable to view that source. see attached source file.
./configure --prefix=$HOME/.local --disable-most-grades --enable-additional-libgrades=reg.gc.debug,reg.gc.decldebug
make PARALLEL=-j2
make PARALLEL=-j2 install
mmc --make --debug fib2
mdb ./fib2

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

       4: 1 1 COND pred fib2.main/2-0 (det) c2;?; fib2.m:19
mdb> list
       io.read_line_as_string(Result, !IO),
       (if
> Result = ok(String),
           string.to_int(string.strip(String), N)
        then
mdb> step
       5: 3 2 CALL func string.strip/1-0 (det) string.m:6331 (fib2.m:20)
mdb> list
mdb: cannot find file string.m
mdb>
fib2.m (546 bytes) 2015-02-18 01:52
https://bugs.mercurylang.org/file_download.php?file_id=235&type=bug
 
Notes
(0000814)
juliensf   
2015-02-19 01:42   
You need to point the debugger to wherever the library source files are using the 'list_path' command.




View Issue Details
379 [mercury] Bug minor always 2015-02-18 02:06 2015-02-19 01:38
mvd23jsdf4 x86_64  
juliensf Fedora  
normal 21  
resolved  
fixed  
none    
none  
   
GCC 4.9.2 Giving Error
The GCC (version 4.9.2) on Fedora 21 is showing warnings on compile. See the attached file crypt.m.
    [mercuryuser@localhost crypt]$ mmc --make --debug crypt
    Making Mercury/int3s/crypt.int3
    Making Mercury/ints/crypt.int
    Making Mercury/cs/crypt.c
    Making Mercury/os/crypt.o
    Making crypt
    In file included from /usr/include/stdlib.h:24:0,
                     from /home/mercuryuser/local/lib/mercury/inc/mercury_std.h:23,
                     from /home/mercuryuser/local/lib/mercury/inc/mercury_goto.h:13,
                     from /home/mercuryuser/local/lib/mercury/inc/mercury_init.h:84,
                     from Mercury/cs/crypt_init.c:18:
    /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
     # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
       ^
    In file included from /usr/include/stdlib.h:24:0,
                     from /home/mercuryuser/local/lib/mercury/inc/mercury_std.h:23,
                     from /home/mercuryuser/local/lib/mercury/inc/mercury_goto.h:13,
                     from /home/mercuryuser/local/lib/mercury/inc/mercury_init.h:84,
                     from Mercury/cs/crypt_init.c:18:
    /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
     # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
    ... error log truncated, see `crypt.err' for the complete log.

crypt.m (1,147 bytes) 2015-02-18 02:06
https://bugs.mercurylang.org/file_download.php?file_id=236&type=bug
 
Notes
(0000812)
juliensf   
2015-02-19 01:18   
The generated _init.c files define _BSD_SOURCE for some reason.
(0000813)
juliensf   
2015-02-19 01:38   
Fixed in commit b70619d.




View Issue Details
376 [mercury] Bug minor always 2015-02-06 15:25 2015-02-17 12:35
wangp  
wangp  
normal  
resolved  
fixed  
none    
none  
   
base_string_to_int ignores overflow unless base 10
base_string_to_int should always check for under/overflow despite the faulty reasoning in commit 51b8f76. The fix should be easy enough but I will leave this bug report for a bit in case there are dissenting opinions.
 
Notes
(0000807)
zs   
2015-02-06 15:51   
No dissent from me.
(0000809)
wangp   
2015-02-10 15:03   
Does anyone require the undocumented behaviour of allowing (and truncating) oversized binary/octal/hexadecimal literals in Mercury source? Maintaining the behaviour requires more work and potentially breaking changes in the library.
(0000810)
juliensf   
2015-02-10 15:30   
No and given that the behaviour is undocumented you should feel free to break it.
(0000811)
wangp   
2015-02-17 12:35   
Fixed in commit 6a267a8




View Issue Details
368 [mercury] Bug minor always 2014-12-02 22:19 2015-02-08 12:18
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Table reset predicates not generated in Erlang grade
The module compiler/ctgc.selector contains a number of predicates that are the subject of memo pragmas and that have the reset attribute specified. The reset predicates are called by other predicates
in this module. Although tabling is not supported by the Erlang backend, we still need to generate
dummy versions of the reset predicates where there are references to them. This is the cause
of the errors from the Erlang compiler about undefined functions in the build output below.
Build the Mercury compiler in the erlang grade.
Making Mercury/int3s/transform_hlds.ctgc.selector.int3
Making Mercury/ints/transform_hlds.ctgc.selector.int
Making Mercury/erls/transform_hlds__ctgc__selector.erl
ctgc.selector.m:066: Ignoring the pragma memo for predicate
ctgc.selector.m:066: `transform_hlds.ctgc.selector.normalize_selector_with_type_information'/4
ctgc.selector.m:066: mode 0 due to lack of support on this back end.
ctgc.selector.m:288: Ignoring the pragma memo for predicate
ctgc.selector.m:288: `transform_hlds.ctgc.selector.type_contains_subtype_1'/4
ctgc.selector.m:288: mode 0 due to lack of support on this back end.
ctgc.selector.m:330: Ignoring the pragma memo for predicate
ctgc.selector.m:330: `transform_hlds.ctgc.selector.type_arg_types'/3 mode 0
ctgc.selector.m:330: due to lack of support on this back end.
Making Mercury/beams/transform_hlds__ctgc__selector.beam
ctgc.selector.m:295: syntax error before: ','
ctgc.selector.m:334: syntax error before: ','
Mercury/erls/transform_hlds__ctgc__selector.erl:354: function table_reset_for_type_contains_subtype_1_4_2_p_0/0 undefined
Mercury/erls/transform_hlds__ctgc__selector.erl:355: function table_reset_for_type_arg_types_3_2_p_0/0 undefined
** Error making `Mercury/beams/transform_hlds__ctgc__selector.beam'.
/var/folders/pd/5lypc6_j3vnf65q9x5y9s3p40000gn/T//mmake.YQsUfH:1400: recipe for target 'top_level' failed
gmake[1]: *** [top_level] Error 1
gmake[1]: Leaving directory '/Users/jfischer/Mercury-Workspaces/mercury.local-4/compiler'
/var/folders/pd/5lypc6_j3vnf65q9x5y9s3p40000gn/T//mmake.nCDJA5:1066: recipe for target 'compiler' failed
gmake: *** [compiler] Error 2
 
Notes
(0000808)
zs   
2015-02-08 12:18   
Fix committed 2015 feb 5.




View Issue Details
375 [mercury] Bug major always 2015-01-19 14:52 2015-01-21 01:07
lpimmes OSx 10.9  
 
urgent  
new  
open  
none    
none  
   
io.seek_binary_output(Stream, set, 32, Out3, Out4), % rec1 NOT working
Seeking to an offset, the second record, in binTest file and then writing new results only writes a single record.
Initially three records present; now only a single record remains.
Any ideas? Thanks.
This invites the question: overwrite record at position, versus insert new record at seek position.
Change true/false switches in main/2 to achieve results for test:
1 write binTest, true, false
2 false, true read binTest at offset, record 2, OK
3 false, false write to binTest at offset, record 2; fails.

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

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

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

                % Not working, just record output; first and third one removed.
                % false, false; default last term in if / then / else
                % ioBinFile 521>./ioBinFile
                % Opened 'binTest' successfully for seek writing.
                % Stream name: binTest; seek to position: 32.
                % ioBinFile 521>cat binTest
                % rec("Dr. Smith", 3).
ioBinFile.m (4,993 bytes) 2015-01-19 14:52
https://bugs.mercurylang.org/file_download.php?file_id=234&type=bug
 
Notes
(0000805)
juliensf   
2015-01-20 12:33   
The call to io.open_binary_output/4 in the predicate writeSeek/3 will truncate the file.
You probably meant to call io.open_binary_append/4.
(0000806)
lpimmes   
2015-01-21 01:07   
Yes, I agree, and testing shows that o.open_binary_append/4 in writeSeek/3 will (not surprisingly)
append new text to end of existing text. Code and example shown below.
But, how do overwrite/insert at a particular seek position in this file?
Reading from a position after seek works fine.
Thanks.

:- pred writeSeek(string::in, io::di, io::uo) is det.
writeSeek(Fname, In, Out) :-
    io.open_binary_append(Fname, Result, In, Out2), % file may / may not exist

    (if Result = ok(Stream)
                % Offsets rec0: 0, rec1: 32, rec2: 62.
    then
    io.format("Opened '%s' successfully for seek writing.\n", [s(Fname) ], Out2, Out3),
     io.seek_binary_output(Stream, set, 32, Out3, Out4), % rec1
     io.binary_output_stream_offset(Stream, Offset, Out4, Out5),
     io.binary_output_stream_name(Stream, Name, Out5, Out6),
     io.format("Stream name: %s; seek to position: %i.\n",
           [s(Name), i(Offset) ], Out6, Out7), % should be 32, OK
     Rec0 = rec("Dr. Smith", 3),
     io.write_binary(Stream, Rec0, Out7, Out8),
     io.close_binary_output(Stream, Out8, Out)
    
    else if
    Result = io.error(Code)
    
    then
    io.format("Failed to open %s because of: %s.\n",
          [ s(Fname), s(io.error_message(Code)) ], Out2, Out)
    
    else
    io.format( "Fail to unify io.error(Code).\n", [], Out2, Out)
    ).

-----
ioBinFile 508>./ioBinFile
Opened 'binTest' successfully for seek writing.
Stream name: binTest; seek to position: 32.

ioBinFile 509>cat binTest
rec("The man ran home.", 3092).
rec("The girl saw me.", 312).
rec("Each person saw you.", 532).
rec("Dr. Smith", 3).




View Issue Details
374 [mercury] Bug crash always 2015-01-14 15:34 2015-01-15 14:04
juliensf x86_64-w64-mingw32  
juliensf Windows  
normal 7  
assigned  
open  
none    
none  
   
rotd-2015-01-13 fails to install with mingw64
Building from the source distribution with the mingw-builds x86_64-4.9.2-posix-rseh t_v3-rev1 compiler
aborts during 'make install' when building the optimisation interface for library.m in grade asm_fast.gc.
The abort occurs during expansion of equivalence types. I strongly suspect this is down to C stack
exhaustion but haven't confirmed this yet.
The same occurs with the mingw-builds x86_4.8.1-posix-seh-rev5 compiler.

32-bit builds of the same rotd using the standard mingw32 compiler are unaffected.
 
Notes
(0000804)
juliensf   
2015-01-15 14:04   
Actually, the stack overflow occurs during the conversion of clauses during the initial construction
of the HLDS. The actual problem here is that I forgot to pass --host=x86_64-w64-mingw32 to configure
and so the stack limit on mercury_compile.exe was ridiculously small.

This *is* all documented in README.MinGW, but I think we need a better way of ensuring that *if* we
are using a MinGW64 under msys or cygwin that the host architecture is set correctly. I'll keep this
bug open until I find a better way ...




View Issue Details
372 [mercury] Bug minor have not tried 2015-01-05 13:16 2015-01-05 13:16
pbone x86_64  
Debian Linux  
normal  
new  
open  
none    
none  
   
Finalisers run after main/2 throws an exception.
We have decided that module finalisers should not run if main/2 throws an exception. The C# backend always runs finalisers. It does not implement the correct behaviour.
 
There are no notes attached to this issue.




View Issue Details
370 [mercury] Bug minor always 2014-12-22 11:54 2015-01-03 21:07
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
unused module imports and string.format
The compiler reports unused module import warnings after string.format is specialised.

% lmc --warn-unused-imports f.m
f.m:001: In module `f':
f.m:001: warning: modules `stream', `string.format' and `string.parse_util'
f.m:001: are imported, but are not used.
f.m (275 bytes) 2014-12-22 11:54
https://bugs.mercurylang.org/file_download.php?file_id=232&type=bug
 
Notes
(0000802)
zs   
2015-01-03 21:07   
Fix f0a1701bc8afb70f5133a11a0e75ab88a735fdd5 committed 2014 dec 30.




View Issue Details
371 [mercury] Bug major always 2014-12-22 12:18 2014-12-23 00:45
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
can't locate string.format.format_signed_int_component_nowidth_noprec/3
% mmc -C f2.m
Uncaught Mercury exception:
Software Error: hlds.pred_table: predicate `hlds.pred_table.lookup_builtin_pred_proc_id'/8: Unexpected: can't locate string.format.format_signed_int_component_nowidth_noprec/3
f2.m (391 bytes) 2014-12-22 12:18
https://bugs.mercurylang.org/file_download.php?file_id=233&type=bug
 
Notes
(0000801)
zs   
2014-12-23 00:45   
Fix committed in change ebc10c087efa453357590053303c8082af28cc13
on 23 dec 2014.




View Issue Details
369 [mercury] Bug crash always 2014-12-16 03:17 2014-12-16 10:18
sebgod Windows NT 6.3 x86_64  
zs Windows  
normal 8.1  
resolved  
fixed  
none    
none  
   
Software Error: hlds.pred_table: predicate `hlds.pred_table.lookup_builtin_pred_proc_id'/8: Unexpected: can't locate put/5
Using the latest Mercury compiler (git commit fd822d712a8f1170a9fab3d9a1d05dd5e404106b)
Compiling the attached example module yields following exception:
Making Mercury\int3s\stream_put5_bug.int3
Making Mercury\ints\stream_put5_bug.int
Making Mercury\asm_fast.gc\i686-pc-mingw32\Mercury\cs\stream_put5_bug.c
Uncaught Mercury exception:
Software Error: hlds.pred_table: predicate `hlds.pred_table.lookup_builtin_pred_proc_id'/8: Unexpected: can't locate stream.put/5
Stack dump not available in this grade.
Error: system command received signal 1.
** Error making `Mercury\asm_fast.gc\i686-pc-mingw32\Mercury\cs\stream_put5_bug.c'.
mmc -m stream_put5_bug
Unfortunately I'm not sure when this bug exactly appeared (the program I used to compile was working fine for a while).
An educated guess is that this appeared after the string.format changes in the compiler.
Using the latest MinGW with gcc 4.7 for 32bit
Java 1.8.0
.NET 4.5.1
Bootstrapped (with ROTD from June 2014) Mercury-dev
stream_put5_bug.m (352 bytes) 2014-12-16 03:17
https://bugs.mercurylang.org/file_download.php?file_id=230&type=bug
pred_table_fix_lookup_builtin_pred_proc_id.diff (1,552 bytes) 2014-12-16 03:18
https://bugs.mercurylang.org/file_download.php?file_id=231&type=bug
 
Notes
(0000799)
sebgod   
2014-12-16 03:20   
(Last edited: 2014-12-16 03:21)
To pinpoint the bug, I've modified the hlds.pred_table.lookup_builtin_pred_proc_id/8 procedure (see attached diff) to also output the module name in the error message, not sure if that is generally useful.
Just thought that put/5 was a little bit too generic.

(0000800)
zs   
2014-12-16 10:18   
Fix add253af9fa0d396034004bef2e36a4512eb8b1a committed 2014 dec 16.




View Issue Details
367 [mercury] Bug minor have not tried 2014-11-27 14:27 2014-12-03 18:23
wangp  
zs  
normal  
resolved  
fixed  
none    
none  
   
array binary search predicates use builtin.compare
approx_binary_search_2 implicitly calls builtin.compare (@<) instead of the supplied ordering function.
 
Notes
(0000798)
zs   
2014-12-03 18:23   
Fixed by commit 35fe4814ce28699f79c98b757d545ee7faac48d8 on 2014 dec 3.




View Issue Details
181 [mercury] Bug minor always 2011-02-02 13:49 2014-12-02 22:20
pbone  
pbone  
normal  
resolved  
fixed  
none    
none  
   
Feedback framework uses partial instationation which is not well supported.
mdbcomp/feedback.m uses partial instantiation to retrieve feedback information from the feedback_info structure. This is not well supported in all grades, for instance it prevents the erlang grade from building the compiler.
 
Notes
(0000797)
juliensf   
2014-12-02 22:20   
This issue was resolved by commit f7237359ae7281168fa19b321c2b2881a405a05e which
removed the use of partial instantiation from the feedback framework.




View Issue Details
365 [mercury] Bug minor sometimes 2014-10-20 11:40 2014-10-20 11:40
pbone x86_64  
Linux  
low Debian testing  
new  
open  
none    
none  
   
hard_coded/parse test failes in asm_fast.gc.par.stseg with libhwloc
The hard_coded/parse test failes in asm_fast.gc.par.stseg. The test fails to compile because it cannot find libnuma during linking. This test unlike others uses static linking and lubnuma is a dependency of libhwloc. It looks like a static version of libnuma is not provided on Debian. The fix is pretty clear, configure should test if we can use libhwloc is usable for dynamic and static linking and if it fails in either it should be disabled in that case.
 
There are no notes attached to this issue.




View Issue Details
231 [mercury] Bug trivial always 2011-11-22 16:30 2014-10-09 12:48
colanderman  
 
normal  
new  
open  
none    
none  
   
No way to specify instantiatedness of char type
There is currently no way to specify the instantiatedness of a char type, e.g.:

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

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

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

Attached is a patch which fixes this bug.
char_inst.m (222 bytes) 2011-11-22 16:30
https://bugs.mercurylang.org/file_download.php?file_id=138&type=bug
mercury-compiler-char-inst.patch (1,974 bytes) 2011-11-22 16:31
https://bugs.mercurylang.org/file_download.php?file_id=139&type=bug
 
Notes
(0000795)
wangp   
2014-10-09 12:48   
Applying the patch as-is would be unsafe. If you try to switch on the variable following the call to is_whitespace, e.g.

is_whitespace(C),
( C = (' '), ...
; C = ('\t'), ...
; C = ('\n'), ...
)

The inst of C is represented as a list of cons/3 functors and the cases as `char_const' functors. Switch detection does not see them as equivalent so replaces the disjunction by `fail'. I assume other parts of the compiler may have similar problems.




View Issue Details
364 [mercury] Bug minor sometimes 2014-10-01 16:25 2014-10-07 11:37
pbone x86_64  
pbone Linux  
normal Debian jessie  
resolved  
fixed  
none    
none  
   
Autoparallelisation analysis crashes on nondet disjunctions.
Matthias Guedemann submitted this bug via e-mail users@mercurylang.org in September 2014.

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

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

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

The autoparallelisation analysis scans your whole program for places where
parallelism could help (it skips parts of the program where it's obvious
that it won't help). It crashes when it looks in
euler_81_82_83_problem_set.euler_edge_81/4 which is nondeterminisic. It
tries to calculate the cost of every goal including the disjunction as a
whole, however it assumes that the disjunction is either a switch or a
"semidet disjunction" which is another special case. This incorrect
assumption causes the analysis to crash (because a consistency check fails).
It might be possible to comment out the consistency check, but then I'd be
concerned that something else would crash because of the same faulty
assumption. I'll see if I can fix the bug in the next week or so.
euler.tgz (1,145,111 bytes) 2014-10-01 16:25
https://bugs.mercurylang.org/file_download.php?file_id=228&type=bug
 
Notes
(0000792)
pbone   
2014-10-07 11:37   
Fixed in revision: 4a431556b5b63e2f04de272684dd5abca18e86e0

https://github.com/Mercury-Language/mercury/commit/4a431556b5b63e2f04de272684dd5abca18e86e0




View Issue Details
296 [mercury] Bug minor always 2013-07-31 12:58 2014-10-05 17:33
wangp  
 
normal  
new  
open  
none    
none  
   
ui mode and multiple clauses
from Michael:

This code triggers a mode error:

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

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

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

get_text_content0(Nodes, Texts, IO) :-
     (
         Nodes = [],
         Texts = []
     ;
         Nodes = [Node|Nodes0],
         get_text_content_from_node(Node, Text, IO),
         get_text_content0(Nodes0, Texts0, IO),
         Texts = [Text|Texts0]
     ).
 
Notes
(0000791)
mark   
2014-10-05 17:33   
The explanation for this is that the introduction of HeadVars introduces extra unifications, and these cause the ui term to lose its uniqueness according to the mode analyser.

HeadVars are always introduced, but in some cases (such as when a predicate is defined in a single clause) this introduction is reversed in order to retain meaningful variables names in the debugger. A side effect of this reversal is that the mode analyser no longer always chokes.

Using a single clause seems to be an effective workaround for the real bug, which is that the mode analyser doesn't properly keep track of uniqueness.




View Issue Details
361 [mercury] Bug minor always 2014-09-15 14:59 2014-09-16 13:22
juliensf  
zs  
normal  
resolved  
fixed  
none    
none  
   
Compiler abort with loose determinism decl. and pragma loop_check
The attached program causes a compiler abort in both C backends.

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

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


bug361.m (793 bytes) 2014-09-15 14:59
https://bugs.mercurylang.org/file_download.php?file_id=225&type=bug
 
Notes
(0000788)
zs   
2014-09-16 13:22   
Fix committed sep 16.




View Issue Details
362 [mercury] Bug minor always 2014-09-15 15:10 2014-09-16 11:10
juliensf  
 
normal  
new  
open  
none    
none  
   
Program cause compiler to abort in mmos grades (but not mmsc)
The attached program causes the following abort in the compiler when compiled with:

   $ mmc --grade asm_fast.gc.mmos

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

The program compiles and works correctly in the mmsc grades.