[m-dev.] for review: --stack-trace-higher-order

Zoltan Somogyi zs at cs.mu.OZ.AU
Mon Nov 2 19:16:57 AEDT 1998


>> compiler/llds_out.m:
>>        Reorganize the way the way the initialization functions are generated,
>>        by putting c_modules falling into different categories into different
>>        bunches. c_module falling into the first category always have their
>>        initialization code included, while those in the second category
>>        have it included only if the old flag MR_MAY_NEED_INITIALIZATION
>>        is set.
> 
> I think this won't have the intended effect, because the if
> MR_MAY_NEED_INITIALIZATION is not set, then the initialization
> functions won't be called, even if they are included.

Which initialization functions won't be called from where?

With --stack-trace-higher-order, the new compiler generates the following code
at the end of library/list.c:

	static void mercury__list_always_bunch_0(void)
	{
		list_module55();
		<deletia>
		list_module92();
	}

	#ifdef MR_MAY_NEED_INITIALIZATION

	static void mercury__list_maybe_bunch_0(void)
	{
		list_module0();
		<deletia>
		list_module39();
	}

	static void mercury__list_maybe_bunch_1(void)
	{
		list_module40();
		<deletia>
		list_module95();
	}

	#endif

	<deletia>
	void mercury__list__init(void)
	{
		static bool done = FALSE;
		if (!done) {
			done = TRUE;
			mercury__list_always_bunch_0();

	#ifdef MR_MAY_NEED_INITIALIZATION
			mercury__list_maybe_bunch_0();
			mercury__list_maybe_bunch_1();
	#endif

			MR_INIT_BASE_TYPE_INFO(
			mercury_data_list__base_type_info_list_1,
				list__list_1_0);
		}
	}

As you can see, any call to mercury__list__init *will* cause the initialization
functions of the modules containing the implementations of higher order preds
to be called.

If you are worried about mercury__list__init itself not being called,
you are right, by default it won't be. However, overriding that default
is what the options to c2init are for.

Zoltan.



More information about the developers mailing list