[m-rev.] for review: [CTGC] bugfix, use typevarset from pred_info

[Nancy]

Julien Fischer wrote:
> On Mon, 19 Jun 2006, Nancy Mazur wrote:
> 
>> Hi,
>>
>> this is a bugfix. The error occurred when analysing TypeSpecOf__ predicates,
>> but may as well occur in other predicates too. The problem was that the
>> typevarset used to determine type substitutions was in sometimes simply set to
>> an empty varset, instead of getting it from the pred_info structure as it
>> should be.
> 
> If this was caused by the XXX comment at the end of this diff (the on
> that says to be checked) the that's fine, otherwise where was the other
> typevarset coming from?

Yes, that is indeed the clue of the fix...

>> Question: I was wondering what the use is of analysing the TypeSpecOf__
>> predicates, as the results are (explicitly) not recorded in the trans_opt
>> files (Cf. the XXX remark in structure_sharing.analysis.m, and in analogy,
>> in structure_reuse.analysis.m)? I might as well simply not analyse them?
> 
> They're not recorded in the .trans_opt files because of limitations in
> the way transitive intermodule optimization works.  It's certainly worth
> analysing them, particularly if they are local to a module, it's just
> that (at the moment) we won't be able to use specialized versions
> created by structure reuse across module boundaries.

Okay...

>> Estimated hours taken: 5
>> Branches: main
>>
>> Bugfix. Make sure to use the typevarset stored in the pred_info when
>> determining the type substitution between formal and actual sharing
>> information.
>>
>> compiler/structure_reuse.direct.detect_garbage.m:
>> compiler/structure_reuse.direct.m:
>> compiler/structure_reuse.indirect.m:
>> compiler/structure_sharing.domain.m:
>> 	Use the typevarset from the pred_info structure when looking up
>> 	and renaming sharing information.
>> 	Thread pred_info until the place where it is used.
> 
> Is there a test case for this bug?

Well, the list module wouldn't compile without the fix...
Should I add that kind of testcase somewhere (and how?)?

Nancy

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

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