[M3devel] [M3commit] [modula3/cm3] 496e9b: Fix compiler-generated FINALLY procedure using par...

[Rodney M. Bates]

On 08/02/2015 04:23 AM, Jay K wrote:
> Eh, these finally procedures cause other problems..I have code to alloca a jmpbuf per try in a procedure..and it is broken by finally generating procedures in a custom way..
>
> so I have to move shared code to something called...ProcedureOrFinallyProcedure?
> that otherwise was just in Procedure.

I'm not sure what the breakage is, but for finally, the custom procedure generation consists
only of:

       CG.Begin_procedure (p.handler.cg_proc);
       xc := Stmt.Compile (p.finally);
       CG.Exit_proc (CG.Type.Void);
       CG.End_procedure (p.handler.cg_proc);

in two places in TryFinStmt.m3.  I would expect what you need to do to happen
somewhere inside Stmt.Compile.  Only there would it be known whether any TRYs
are inside the FINALLY procedure.

I find Begin_procedure called in Procedure.m3, Exceptionz.m3, ObjectType.m3(2),
RefType.m3, TryFinStmt.m3(2). and Module.m3.  All but Procedure.m3 would no
doubt be compiler internally generated procedures.  I would expect only those
emitted by Procedure.m3, Module.m3, and TryFinStmt could have any TRY statements
inside.



>
>   - Jay
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> From: jay.krell at cornell.edu
> To: rodney.m.bates at acm.org; m3commit at elegosoft.com
> Subject: RE: [M3commit] [modula3/cm3] 496e9b: Fix compiler-generated FINALLY procedure using par...
> Date: Sun, 2 Aug 2015 02:20:51 +0000
>
> Rodney, Do you have a test case that was broken before and fixed afterward?
>
> If possible, though not required, check something into m3-sys/m3tests?
>
> I don't mean to imply the code was correct before. I don't know, at all.
>
> Thank you,
>   - Jay
>
>
>
> Date: Sat, 1 Aug 2015 17:36:54 -0700
> From: rodney.m.bates at acm.org
> To: m3commit at elegosoft.com
> Subject: [M3commit] [modula3/cm3] 496e9b: Fix compiler-generated FINALLY procedure using par...
>
>    Branch: refs/heads/master
>    Home:https://github.com/modula3/cm3
>    Commit: 496e9be1dcdcf87bda8e72239fc90132591b4cf4
>        https://github.com/modula3/cm3/commit/496e9be1dcdcf87bda8e72239fc90132591b4cf4
>    Author: Rodney Bates <rodney.m.bates at acm.org>
>    Date:   2015-08-01 (Sat, 01 Aug 2015)
>
>    Changed paths:
>      M m3-sys/m3front/src/misc/CG.m3
>
>    Log Message:
>    -----------
>    Fix compiler-generated FINALLY procedure using parent procedure's temporary.
>
>   Changes to be committed:
>
> 	modified:   m3-sys/m3front/src/misc/CG.m3
>
> CG was not stacking global variables used for keeping track of temporaries
> when entering nested procedures.  In the case of a compiler-generated
> nested procedure for the finally part of a TRY--FINALLY block, this
> meant the finally code could use a temporary allocated by the parent,
> though not in use at the time.  This violated the comment in M3CG_Ops.i3:
>
>      declare_temp (s: ByteSize;  a: Alignment;  t: Type;
>              in_memory: BOOLEAN): Var;
>      (* declares an anonymous local variable.  Temps are declared
>         and freed between their containing procedure's begin_procedure and
>         end_procedure calls.  Temps are never referenced by nested procedures. *)
>
> In cases of nested procedures explicitly declared in source code, this
> didn't matter because they are located ahead of any of the parent
> procedure's executable code, when it has no allocated temps, and they
> free their own temps at their end, restoring the previous state.
>
>
>
>
> _______________________________________________ M3commit mailing list M3commit at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3commit
>
>
> _______________________________________________
> M3commit mailing list
> M3commit at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3commit
>

-- 
Rodney Bates
rodney.m.bates at acm.org