[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:
> > 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.)

It needs to be one function because it is used by the multi-moded
function make_util.target_extension.

Relying on the order of solutions isn't particularly nice or robust either.

Simon.

Index: compile_target_code.m
===================================================================
RCS file: /home/mercury1/repository/mercury/compiler/compile_target_code.m,v
retrieving revision 1.47
diff -u -u -r1.47 compile_target_code.m
--- compile_target_code.m	23 Sep 2003 02:33:10 -0000	1.47
+++ compile_target_code.m	24 Sep 2003 06:43:16 -0000
@@ -151,14 +151,19 @@
 
 %-----------------------------------------------------------------------------%
 
-	% maybe_pic_object_file_extension(G, P, E) is true iff
-	% E is the extension which should be used on object files according
-	% to the value of P.
+	% maybe_pic_object_file_extension(Globals, PIC, Ext) is true iff
+	% Ext is the extension which should be used on object files according
+	% to the value of PIC.  The value of PIC should be obtained
+	% from a call to `get_object_code_type'.  In particular, on
+	% architectures for which no special handling for PIC is
+	% necessary, only a value of `non_pic' should be used.
+	% The `(in, out, in)' mode guarantees that the returned
+	% value of PIC meets this requirement.
 :- 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 semidet.
 
-	% Same as above except the globals, G, are obtained from the io__state.
+	% Same as above except the globals are obtained from the io__state.
 :- pred maybe_pic_object_file_extension(pic::in, string::out,
 		io__state::di, io__state::uo) is det.
 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------