[m-dev.] for review: none.gc grade compiling with MSVC

[Fergus Henderson]

On 27-Jun-2000, Peter Ross <petdr at cs.mu.OZ.AU> wrote:
> 
> Changes required for the compiler to bootstrap in the none.gc grade
> using MSVC.
> 
> compiler/rtti.m:
>     The RTTI has forward declarations of static variables with unknown
>     array sizes.  Add a field to all RTTI fields which are represented
>     as C arrays, except base_typeclass_info, which is the size of the
>     array needed to hold the RTTI data.

I suggest rephrasing that as

     For all RTTI fields which are represented as arrays, except
     base_typeclass_info, add a new field holding the length of the
     array needed to hold the RTTI data.  This is needed when generating
     ANSI/ISO C, because some of the RTTI data has static linkage,
     and ANSI/ISO C does not allow forward declarations of static
     data with incomplete types (e.g. array types without an explicit
     array size).

> compiler/rtti_out.m:
>     For RTTI structures of size 0 don't output anything as the forward
>     declaration, has already allocated space.

The comma is misplaced.
And in general that log message is not very clear.
Do you mean "don't output a forward declaration",
or do you mean "don't output anything, because ..."?
If the latter, isn't the comment wrong?
Surely you need to output _something_ for RTTI structures of size 0;
at very least, you need to output a forward declaration for them.

Is this change necessary, or is it just an optimization?

>     No longer output forward declarations for base_typeclass_info, as it
>     is not easy to determine the array size.  AFAIK no other type needs
>     the forward declaration of base_typeclass_info so this should be
>     safe.

Are you talking about the forward declarations of the base_typeclass_info
constants, or about the forward declaration of the base_typeclass_info
type itself?  I think the former, but from the log message it sounds like
the latter.

Anyway, I don't think that is correct.  With the LLDS back-end, we can generate
references to base_type_info constants in static initializers for type_infos
that llds_common hoists out to the top level.  So I think this change
might break the LLDS back-end. (Did I miss something?) 
Currently we don't do the same for the MLDS back-end, but in future it
ought to do so, so this could also cause future problems for the MLDS
back-end.  

If I'm right, that is a serious problem, one that should be fixed before you
commit this change.

> trace/mercury_trace_vars.c:
>     Delete the definitions of mercury_data___type_ctor_info_func_0 and

s/definitions/local declarations/

>     mercury_data___type_ctor_info_pred_0 because the true definitions
>     are visible.

s/true definitions/true declarations from the header file/

> +++ compiler/rtti_out.m	2000/06/27 16:40:53
> @@ -86,11 +86,19 @@
>  
>  output_rtti_data_defn(exist_locns(RttiTypeId, Ordinal, Locns),
>  		DeclSet0, DeclSet) -->
> -	output_generic_rtti_data_defn_start(RttiTypeId, exist_locns(Ordinal),
> +	(
> +			% For size 0 data structures we output nothing.
> +		{ Locns = [] }
> +	->
> +		{ DeclSet = DeclSet0 }
> +	;

The comment here should explain why.

> @@ -495,10 +525,16 @@
>  		% so we don't need to declare them.
>  		% Also rtti_data_to_name/3 does not handle this case.
>  		{ DeclSet = DeclSet0 }
> -	; { RttiData = base_typeclass_info(ClassId, InstanceStr, _) } ->
> +	; { RttiData = base_typeclass_info(_ClassId, _InstanceStr, _) } ->
> +			% We don't output a declartion for the
> +			% base_typeclass_info because we don't know how
> +			% big to make the array.
> +			% AFAIK no other types actually need the forward
> +			% declaration, so it is safe not to declare it.

s/declartion/declaration/

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