[M3devel] importing types not described to backend

[Jay K]

Arg. Another problem I see in some attempted fixes is:

opaque type defined twice: _t9a0e5dbc
  defined in  FileWr.i3
  and also    System.m3
 
I don't need to reveal opaque types repeatedly but I do need to declare them repeatedly -- so that backend
knows they are pointers..

 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Sun, 29 Aug 2010 07:35:24 +0000
> Subject: Re: [M3devel] importing types not described to backend
>
>
> I've been quite banging my head against this.
> I believe basically every type referenced in a module must be
> "described" to the backend, such as with declare_opaque, declare_record, etc.
>
> Type.Compile should call t.compile on more stuff.
> You need not declare everything in every imported module. Only types that are used.
>
> There is at least one hard to solve problem here, for some level of lack of understanding at least.
> Specifically if you call t.compile on all types in Type.Compile, RecordType.Compiler => Scope.InitValues
>  => assertion failures about non-empty stack.
>
> It seems Type.Compile gets called "in the middle of stuff" instead of just from CompileAll.
>
> I'm almost stumped.
> I have to check still where Type.Compile vs. Type.CompileAll are called.
>
>  - Jay
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Subject: RE: [M3devel] importing types not described to backend
> > Date: Sat, 28 Aug 2010 09:54:54 +0000
> >
> >
> > Interesting.
> >
> > TYPE Color1 = RECORD a,b,c: REAL; END;
> > TYPE Color2 = RECORD a,b,c: REAL; END;
> >
> > Have the same id.
> > If the module defining them also imports an interface with a type with the same id,
> > or I think, if its interface defines a type with same id (same thing I think,
> > no relationship at the cg level between a module and its interface),
> > then the declare_records are skipped.
> >
> > The fix is probably something simple in Type.Compile involve the order it checks the tables in
> > when deciding to call t.compile or not.
> >
> > Or can it just always call t.compile?
> > Worst thing is that extra type information created?
> > A lot of it? (all types in all imports, instead of just the used ones??)
> >
> > - Jay
> >
> > ----------------------------------------
> > > From: jay.krell at cornell.edu
> > > To: m3devel at elegosoft.com
> > > Subject: RE: [M3devel] importing types not described to backend
> > > Date: Fri, 27 Aug 2010 18:35:00 +0000
> > >
> > >
> > > Very wierd:
> > >
> > > MODULE Main;
> > > IMPORT Color;
> > > TYPE ColorT = RECORD a,b,c: REAL; END;
> > >
> > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) =
> > > BEGIN
> > > END F1;
> > >
> > > BEGIN
> > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0});
> > > END Main.
> > >
> > >
> > > This fails. If you remove the IMPORT, it worked.
> > > The declare_record of ColorT comes and goes with that change.
> > > So I guess the error really is in F1.
> > >
> > >
> > > - Jay
> > >
> > > ----------------------------------------
> > > > From: jay.krell at cornell.edu
> > > > To: m3devel at elegosoft.com
> > > > Date: Fri, 27 Aug 2010 18:28:47 +0000
> > > > Subject: [M3devel] importing types not described to backend
> > > >
> > > >
> > > > This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3
> > > >
> > > > INTERFACE Color;
> > > > TYPE T = RECORD a,b,c:REAL; END;
> > > > END Color.
> > > >
> > > >
> > > > MODULE Main;
> > > > IMPORT Color;
> > > > TYPE ColorT = RECORD a,b,c: REAL; END;
> > > >
> > > >
> > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) =
> > > > BEGIN
> > > > END F1;
> > > >
> > > >
> > > > <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) =
> > > > BEGIN
> > > > END F2;
> > > >
> > > >
> > > > BEGIN
> > > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0});
> > > > F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0});
> > > > END Main.
> > > >
> > > >
> > > > On SPARC64_SOLARIS there is an assertion failure in the backend:
> > > > /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1 -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Main.mc -o Main.ms
> > > > ../Main.m3: In function 'Main__F1':
> > > > ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038
> > > >
> > > >
> > > > I fixed it so F1 is ok.
> > > > But still F2 isn't.
> > > > The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok.
> > > >
> > > >
> > > > The problem as I understand is we don't tell the backend about imported types.
> > > > There is nothing in the IR about them, judging from -y and a quick look at parse.c.
> > > >
> > > >
> > > > I intend to fix this if I don't here any objections.
> > > > I'm hoping it isn't too much work.
> > > > I believe it will mostly/all be in m3front.
> > > >
> > > >
> > > > My opinion of our gcc backend drops..
> > > >
> > > >
> > > > Perhaps the time is better used on a C front end.
> > > > Though in this case, I think the work is shared, the same stuff would be missing there too.
> > > >
> > > >
> > > > Thanks,
> > > > - Jay
> > > >
> > >
> >
>