[m-rev.] diff: fix `mmc --make' bug

[Fergus Henderson]

On 23-Sep-2003, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> On 23-Sep-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > 
> > Isn't this `promise_pure' declaration invalid?
> > The different codes for the two different modes will
> > return different sets of solutions, won't they?
> 
> In theory, yes, but maybe_pic_object_file_extension is only ever
> called with the second argument 'non_pic' if the architecture
> doesn't need special handling for PIC code (see
> compile_target_code.get_object_code_type), so in practice
> the solution sets will be the same.

Hmm.  That still doesn't seem like a very nice or robust solution.

At a minimum, if there is an implicit requirement that the second argument
can be `non_pic' only if the architecture doesn't need special handling
for PIC code, then this requirement should be documented in the interface.

But I think it would be cleaner to define two separate functions.
(Perhaps avoiding code duplication by having the second one be defined
by calling all_solutions on the nondet reverse mode of the first one,
and the extracting the first solution from the head of the solution list.
This would require making sure that the elements of the `pic' type are
declared in the appropriate order so that the first solution in the
ordering will be the one that we want.)

> > > Index: compiler/make.util.m
> > > ===================================================================
> > > RCS file: /home/mercury1/repository/mercury/compiler/make.util.m,v
> > > retrieving revision 1.15
> > > diff -u -u -r1.15 make.util.m
> > > --- compiler/make.util.m	15 Mar 2003 03:08:56 -0000	1.15
> > > +++ compiler/make.util.m	23 Sep 2003 00:40:03 -0000
> > > @@ -672,11 +672,15 @@
> > >  target_extension(_, asm_code(pic)) = ".pic_s".
> > >  target_extension(Globals, object_code(PIC)) = Ext :-
> > >  	maybe_pic_object_file_extension(Globals, PIC, Ext).
> > > -target_extension(Globals, foreign_object(PIC, c)) = Ext :-
> > > -	maybe_pic_object_file_extension(Globals, PIC, Ext).
> > >  
> > >  		% Note we use the bogus extension "bogus ext" so that
> > >  		% the reverse mode of this function remains nondet.
> > > +target_extension(_, foreign_object(PIC, c)) = "bogus ext" :-
> > > +	( PIC = pic
> > > +	; PIC = link_with_pic
> > > +	; PIC = non_pic
> > > +	),
> > > +	unexpected(this_file, "C foreign_object").
> > 
> > Will that change break things for `--target asm'?
> > When compiling to assembler, C foreign_procs will get put into a C file
> > which then gets compiled to an object file.
> 
> I don't think so.  This is consistent with how C#, MC++, IL and Java
> foreign code files are handled.

Hmm.  I see.

If all these cases are the same, then why not replace the five lines
above and the lines for the other language cases with a single clause?

	target_extension(_Globals, foreign_object(_PIC, _Lang)) = "bogus ext" :-
		unexpected(this_file, "target_extension: foreign_object").

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------