[m-dev.] Compilation error

[Julien Fischer]

On Tue, 2 Oct 2007, Quan Phan wrote:

> On Tue, Oct 02, 2007 at 11:02:12PM +1000, Julien Fischer wrote:
>>
>> 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.)
>>
> Yes, you are right. With the current status of the region analysis we
> may need to re-add the option --region-analysis.
>
>>> 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?
>>
> Yes, but anyway it came from my misunderstanding about grade, so just
> ignore it. Sorry about that.
>
>>> 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.)
>>
> I know my problem now ;). There are two things, the region analysis in
> Mercury code and the region runtime in C code. Before the removal of
> --region-analysis, the region analysis is enabled by --region-analysis,
> while the region runtime is enabled by --use-regions (which is added by
> you and I use MR_USE_REGIONS flag in the region runtime code). The .rbmm
> grade implies only --use-regions, not --region-analysis. The installed
> compiler I used at my site before has its region analysis controlled by
> --region-analysis. (I installed it before the change I made to remove
> --region-analysis.) That's why before the recent reinstallation I did
> not get the error from the region analysis when building a compiler with
> .rbmm grade, the .rbmm grade helps the region runtime code get compiled.
> Even after the removal of --region-analysis, the built compiler has its
> region analysis controlled by --use-regions, but it doesn't cause
> problems because it is only used to compile small programs.
>
>>> 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.
> As I said above I would still need .rbmm to imply --use-regions so that
> the region runtime code gets compiled. So I think a temporary solution
> should be re-adding the --region-analysis option. What do you think, can
> I go ahead with it?

I think that would be best for now.

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
--------------------------------------------------------------------------