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

[Simon Taylor]

On 23-Sep-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 23-Sep-2003, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > 
> > Fix a bug which caused `mmc --make foo.o' to fail.
> > 
> > compiler/make.m:
> > compiler/make.util.m:
> > 	Avoid returning multiple possible file types for object files.
> > 
> > compiler/compile_target_code.m:
> > 	For the (in, out, in) mode of maybe_pic_object_file_extension,
> > 	always return `non_pic' if the platform doesn't need special
> > 	handling for PIC.
> > 
> > tests/mmc_make/Mmakefile:
> > tests/mmc_make/build_object:
> > 	Test case.
> > 
> > Index: compiler/compile_target_code.m
> > ===================================================================
> > RCS file: /home/mercury1/repository/mercury/compiler/compile_target_code.m,v
> > retrieving revision 1.46
> > diff -u -u -r1.46 compile_target_code.m
> > --- compiler/compile_target_code.m	6 Aug 2003 12:38:08 -0000	1.46
> > +++ compiler/compile_target_code.m	23 Sep 2003 02:22:19 -0000
> > @@ -156,7 +156,7 @@
> >  	% to the value of P.
> >  :- pred maybe_pic_object_file_extension(globals, pic, string).
> >  :- mode maybe_pic_object_file_extension(in, in, out) is det.
> > -:- mode maybe_pic_object_file_extension(in, out, in) is nondet.
> > +:- mode maybe_pic_object_file_extension(in, out, in) is semidet.
> >  
> >  	% Same as above except the globals, G, are obtained from the io__state.
> >  :- pred maybe_pic_object_file_extension(pic::in, string::out,
> > @@ -1727,13 +1727,40 @@
> >  
> >  %-----------------------------------------------------------------------------%
> >  
> > -maybe_pic_object_file_extension(Globals, pic, Ext) :-
> > -	globals__lookup_string_option(Globals, pic_object_file_extension, Ext).
> > -maybe_pic_object_file_extension(Globals, link_with_pic, ObjExt) :-
> > -	globals__lookup_string_option(Globals,
> > -		link_with_pic_object_file_extension, ObjExt).
> > -maybe_pic_object_file_extension(Globals, non_pic, Ext) :-
> > -	globals__lookup_string_option(Globals, object_file_extension, Ext).
> > +:- pragma promise_pure(maybe_pic_object_file_extension/3).
> 
> 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.

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

I'm not really happy with this.  A better solution would be to change
module_name_to_file_name so that it takes a file type rather than
a raw extension.  This would remove a lot of the distributed cruft
dealing with foreign_code files, fact tables and libraries.

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