[m-dev.] Compilation error

[Quan Phan]

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 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.
Yes, that's definitely the next step, after I commit the region runtime.
(But we have always been serious in this matter ;) ).

Thanks,
Quan.
> 
> 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
> --------------------------------------------------------------------------
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------