<div dir="ltr"><div dir="ltr"> </div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 14 Nov 2024 at 09:34, Zoltan Somogyi <<a href="mailto:zoltan.somogyi@runbox.com">zoltan.somogyi@runbox.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> On 2024-11-13 23:41 +11:00 AEDT, "Zoltan Somogyi" <<a href="mailto:zoltan.somogyi@runbox.com" target="_blank">zoltan.somogyi@runbox.com</a>> wrote: > > Regardless, it does >> not >> seem to be a useful behaviour *now*. > > Then I will next look into undoing it. I have now done so, with the result being the attached diff. It was much more interesting (in the Chinese curse sense) than I expected. For review by anyone. I would particularly like to know whether there is a better way to force the creation of .opt files before the compilation of their would-be consumers than the one adopted by this diff. Until now, I assumed that this was solved long ago, but apparently, this is not the case with mmake. </blockquote><div> </div><div> > Don't treat .m files as substitutes for .opt files.</div>> > compiler/write_deps_file.m: > When trying to check for the existence of .opt files, whether alone > or together with .trans_opt files, do not consider a .m file as > an acceptable substitute. Delete the option that can ask for this > behavior. ... > diff --git a/tests/term/existential_error1.m b/tests/term/existential_error1.m > index f336133eb..4e54b4f1b 100644 > --- a/tests/term/existential_error1.m > +++ b/tests/term/existential_error1.m > @@ -4,10 +4,39 @@ > % > % Regression test for term_norm.m > % Symptom: "Software Error: Unmatched lists in functor_norm_filter_args." > -% This was caused by the list of counted arguments in the weight table differing > -% from the list of arguments the termination analyser provided when it called > -% functor norm. The code that constructed the weight table was ignoring > -% type_infos when constructing the list of counted arguments. > +% This was caused by the list of counted arguments in the weight table > +% differing from the list of arguments the termination analyser provided > +% when it called functor norm. The code that constructed the weight table > +% was ignoring type_infos when constructing the list of counted arguments. > +% > +%---------------------------------------------------------------------------% > +% > +% This test case happens to also expose another issue about intermodule > +% optimization. > +% > +% Whether the deconstruct_univ predicate below terminates or not is determined > +% entirely by whether private_builtin.typed_unify terminates or not. However, > +% private_builtin.opt and private_builtin.trans_opt in the library directory > +% disagree about this: the .opt file gives typed_unify's termination status > +% as can_loop, while .trans_opt gives it as cannot_loop. That initially struck me as strange, but it is correct. Proving termination of typed_unify/2 requires knowing that type_of/1 terminates and we can only know that from type_desc.opt. (I think the comment in compiler/termination.m above set_compiler_gen_terminates/6 is wrong: it implies that the termination status of *all* predicates in builtin and private_builtin is set by that code, but doesn't seem to be what it actually does.) The diff looks fine. Julien. </div></div>