[m-dev.] nightly tests failed

[Fergus Henderson]

The following test cases are still failing.

On 23-Jan-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> 	- extras/clpr/cfloat.m got compilation errors.
> 	  This is due to the change to runtime/mercury_type_info.h
> 	  that zs committed recently ("remove several obsolete macros").
> 	  Zoltan, could you please fix this one?
> 
> 	- tests/term/arit_exp.trans_opt is failing at "-O3 --opt-space",
> 	  because the .trans_opt file includes a `pragma termination_info'
> 	  for one of the procedures in the implementation section
> 	  of the module that is not listed in the .trans_opt_exp file.
> 	  This test case failure is spurious, i.e. it is caused by
> 	  a bug in the test, not a bug in the compiler.
> 	  This test case failure was caused by petdr's changes to
> 	  tests/term/Mmakefile: now that EXTRA_MCFLAGS is being honoured,
> 	  these tests are being run at different optimization levels,
> 	  and this leads to different output in the .trans_opt file.
> 	  The problem is that EXTRA_MCFLAGS occurs after MCFLAGS,
> 	  and so the options that disable inlining etc. get overridden
> 	  by the "-O3" option.  Probably the best fix would be to use
> 	  	ALL_MCFLAGS += $(MCTRANSOPTFLAGS)
> 	  rather than
> 	        MCFLAGS = $(MCTRANSOPTFLAGS),
> 	  so that the MCTRANSOPTFLAGS will override EXTRA_MCFLAGS rather
> 	  than vice versa.
> 	  Pete, could you please deal with this one?
> 	  (i.e. add that fix with an appropriate comment, test it, etc.)
> 
> 	- tests/tabling/loopcheck fails in non-GC grades (e.g. asm_fast)
> 	  with the error message "Mercury runtime: Sorry, not implemented: 
> 	  tabling in non-GC grades".  This appears to be due to zs's
> 	  recent changes to tabling.  Zoltan, could you please fix this one?
> 	  One possible fix would be to just update the expected output
> 	  files to allow that as one of the possible expected outputs.
> 	  But I don't understand exactly what the problem with tabling
> 	  in non-GC grades is.  For accurate GC, calls to MR_add_root()
> 	  would be needed, but shouldn't it work OK as is for the no-GC case?
> 	  Would there be anything wrong with changing the `#ifdef CONSERVATIVE_GC'
> 	  test there to `#ifndef ACCURATE_GC'?
>
> 	- tests/debugger/existential_rtti failed

Here's some more information about that last test case.
The symptom for that last one is as follows:

	Uncaught exception:
	Software Error: variable TypeClassInfo_for_c2 (9) not found
	Stack dump not available in this grade.

The problem is related to the way the code generator handles
type_info liveness, and to the types that we give type_info
and type_class_info variables.

When generating the liveness information, we find all of the
ordinary live variables, then we find their types, and finally
we add to the set of live variables the type_info and/or
type_class_info variables corresponding to any type variables
in the types of the ordinary live variables.
Now, because of the types that we give to type_info and
type_class_info variables, the type_info variables and type_class_info
will themselves have types which contain type variables.
But we do _not_ apply this process transitively;
we don't add the type_infos for those type variables
to the live vars set.  During code generation, we try
to save the types_infos for those type variables on
the stack, and this causes a "Software Error" exception.

I can see three possible solutions:

	(1) Change the types that we give to type_info and type_class_info
	    variables so that they don't contain any type variables.

	    I think the reasons for including type variables in
	    the types of builtin:type_infos are mainly historical.
	    However, there are probably lots of places in the system
	    that depend on this now; changing this would be tricky.
	    Also, I seem to recall that there was some reason for
	    putting type variables in the types of type_class_infos,
	    although right now I can't remember what it was.
	    DJ, do you remember?

	(2) During code generation, don't include the type variables
	    from the types of type_info and type_class_info variables
	    in the set of variables to save.

	(3) During liveness computation, apply the process transitively,
	    so that the type variables in question are marked as live
	    at the points where the code generator will reference them.

Of these, (2) looks simplest.  I think something like the
patch below may be sufficient.  However, I haven't tested it.

Index: hlds_pred.m
===================================================================
RCS file: /home/mercury1/repository/mercury/compiler/hlds_pred.m,v
retrieving revision 1.68
diff -u -d -u -r1.68 hlds_pred.m
--- hlds_pred.m	1999/12/03 12:55:00	1.68
+++ hlds_pred.m	2000/02/03 13:30:38
@@ -1986,7 +1986,12 @@
 	( 
 		map__search(VarTypeMap, Var, Type)
 	->
-		type_util__vars(Type, TypeVars),
+		( is_introduced_typeinfo_type(Type) ->
+			% for these types, we don't add the type parameters
+			TypeVars = []
+		;
+			type_util__vars(Type, TypeVars)
+		),
 		(
 			% Optimize common case
 			TypeVars = []

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------