[m-dev.] Compilation error

[Julien Fischer]

On Tue, 2 Oct 2007, Quan Phan wrote:

> On Tue, Oct 02, 2007 at 11:08:24AM +1000, Julien Fischer wrote:
>>
>> On Mon, 1 Oct 2007, Quan Phan wrote:
>>
>>> Hi,
>>>
>>> I compiled the most recent compiler code into asm_fast.gc.rbmm grade using
>>> the rotd 27/09 compiler and got the following error.
>>>
>>> /cw/dtailocal/quan/mmcrotd/bin//mmc --compile-to-c --grade
>>> asm_fast.gc.rbmm  --mercury-linkage shared --flags LIB_FLAGS   --flags
>>> INTER_FLAGS  --inline-vars-threshold 10000
>>> --optimize-constructor-last-call   tree234 > tree234.err 2>&1
>>> gmake[1]: *** [tree234.c_date] Error 1
>>> gmake[1]: Leaving directory
>>> `/localhost/NoCsBack/dtai/quan/ws_1001/library'
>>> gmake: *** [library] Error 2
>>>
>>> In tree234.err:
>>> Uncaught Mercury exception:
>>> Software Error: rbmm.points_to_analysis.m: Sorry, not implemented:
>>> inter_analyse_goal_expr: generic_call not handled
>>> Stack dump not available in this grade.
>>>
>>> The error shows that the region points-to analysis has been run while
>>> compiling tree234.m, which is strange because it shouldn't.
>>>
>>> Could any one suggest what might be the cause and solution?
>>
>> The grade component .rbmm implies the option `--use-regions' which
>> in turn enables the region points-to analysis.  You may need to add
>> an option that disables the region analysis and disable it for modules
>> for which it won't yet work, or handle generic calls in a more
>> robust fashion.
>>
> Before (the last rotd I used was on 29 Aug) to compile a program to use
> region-based memory management I 1) use a rotd Mercury compiler (normally in
> asm_fast.gc grade) to compile another compiler in asm_fast.gc.rbmm
> grade, 2) use the compiler in asm_fast.gc.rbmm to compile the program
> with the command line option --use-regions (i.e., explicitly specified,
> even in *.rbmm grade).

The .rbmm grade component has *always* implied --use-regions.
The code that does this is in compiler/handle_options.m - it was added
in r1.301 of that file (by me.)

Are you sure you are not confusing the --use-regions option with the
--analyse-regions that you removed in the following change:

<http://www.mercury.csse.unimelb.edu.au/mailing-lists/mercury-reviews/mercury-reviews.200708/0060.html>

That change made whether region analysis is run depend upon
--use-regions.  (I'm fairly certain that this is the change in 
behaviour you are encountering.)

> Now (1) fails due to the above ERROR. wHat has been changed causing it?
> I think we do not expect the region analysis will run when using a
> compiler not in *.rbmm.

Do you mean when we are not compiling a non .rbmm grade there?

> Moreover, at the current status of rbmm, there
> is no point running region stuff when compiling the whole compiler
> because it will fail due to several reasons (generic calls, foreign
> code, high-order terms, modules ...). I would expect that the region
> stuff is carried out only for a program's source code.

We should probably handle those constructs better than we do.  Even
if we don't build the compiler in a .rbmm grades we will need to
compile the standard library in a .rbmm grade (as you are attempting
to do above.)

> It seems naive but I ask anyway, is this "before" a correct way to go,
> if yes, what has changed it? Can we make everything work as "before"? I
> do not understand what is going on in (1) with the .rbmm grade very
> much. For me, it just produces a compiler which has been prepared
> "somehow" so that when we specify --use-regions in (2) it runs the
> region analysis and transformation and links the region runtime to make
> an executable which uses rbmm. Could you explain more to me?

A short term solution would be to comment out the bit in handle_options.m
that make .rbmm imply --use-regions.  I think we need to seriously
consider how to make the analysis work with the constructs that
currently cause assertion failures; I don't see how we can do much in 
the way of non-trivial benchmarking without at least some of the
standard library compiled in a .rbmm grade.

Cheers,
Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------