[M3devel] record types in backend

[Jay K]

I should point out that the type we do build up contains fields of I think integers.

static void
debug_field (const char *name)
{
  tree f = build_decl (FIELD_DECL, get_identifier (name), t_int);

That also needs work and shouldn't be difficult.

I'm not sure where the builtin typeids come from though.

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: record types in backend
Date: Sat, 21 Aug 2010 22:42:21 +0000








In debugging this..the gcc code wants to enumerate the fields of a struct.
We spend the effort building up most of this information, but we never hook it up to the parameter.
 The fields are null. From debugging it.

Then from reading our code:
declare_param:
  m3_build_type
    case T_struct:
      {
        tree ts = make_node (RECORD_TYPE);
        TYPE_FIELDS (ts) = NULL_TREE;

Seems to me we should have a hash of typeid to tree, and here we should look
up the typeid and set the fields appropriately.

I'll try that.

Besides fixing SPARC64_SOLARIS here, it should dramatically improve debugging with stock gdb.
We'll see.

 - Jay

From: jay.krell at cornell.edu
To: jkrell at elego.de; m3commit at elegosoft.com
Date: Sat, 21 Aug 2010 21:49:04 +0000
Subject: Re: [M3commit] CVS Update: cm3








It turns out 4.3.5 fails the same way.

 - Jay

> Date: Sat, 21 Aug 2010 10:39:34 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	10/08/21 10:39:34
> 
> Modified files:
> 	cm3/m3-sys/m3cc/src/: m3makefile 
> 
> Log message:
> 	back to gcc 4.3 for SPARC64_SOLARIS, see m3-sys/m3tests/src/p2/p247
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100821/03c4f4c7/attachment-0002.html>