[m-rev.] for review: avoid test failures in hlc grades with GCC 12

Julien Fischer jfischer at opturion.com
Sat Jul 2 03:22:40 AEST 2022

On Sat, 2 Jul 2022, Zoltan Somogyi wrote:

> 2022-07-02 02:37 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
>> The failing tests were the following (all from tests/valid):
>>     higher_order5
>>     loop_in_disj
>>     mode_syntax
>>     recursive_no_tag_type
>>     same_length_2
>>     stack_alloc
> The same_length_2 test case should not be fixed; it should be
> *deleted*. It is almost identical to mode_syntax.m, and it tests
> mode syntax, in just a very slightly different way than mode_syntax.m.
> So the predicate q from mode_syntax.m should be moved to
> mode_syntax.m after being renamed.
> Since the predicate definitions are irrelevant to what mode_syntax.m
> is intended to test, I think the infinite recursion warning should be
> switched off for it specifically.
> In both higher_order5 and recursive_no_tag_type, it should be
> possible to add extra arguments to the now-infinite-loop predicates
> to avoid the infinite loop, but if this turns out to be too complicated,
> then again, the warning should be switch off for them specifically.

Actually, I see we now have a suitable mechanism for doing this (i.e.
tests/DEFNS_FOR_TESTS), so I will go ahead and do the above.

> For loop_in_disj and stack_alloc, I have no idea what they are testing,
> and "git log" can't tell me either. I would look it up in the CVS repository,
> but I would have to find it first :-(

I don't think the CVS repository will tell you anything more than what
git already does; all the history from CVS should be in there.

> In stack_alloc's case, adding an extra
> argument to p that is decremented on each call, and adding a base case
> that that does nothing when it reaches zero, looks like it would preserve
> whatever functionality it is trying to test. For loop_in_disj, testing
> the treatment of calls with erroneous determinism seems to be at least
> part of the objective, but I have no idea whether replacing the calls to
> loop with a call to e.g. error would screw up the *rest* of the objective.
> So again, I would switch off the warning for loop_in_disj specifically.

Shall do.


More information about the reviews mailing list