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

[Jay]

Thank you for the obvious reminder I needed -- look at all begin_procedure calls.


I briefly mulled over that my changes belong in Stmt or elsewhere, but, the thing is..maybe my understanding isn't right, Stmt occurs in many places, you can say "begin" anywhere. My changes are very related to procedures -- counting TRY per procedure, calling alloca once per procedure, near the start -- before any branches or TRYs.


The breakage is that I was considering finally procs to be part of the enclosing function. Very wrong.


I put the alloca & setting a local pointer per TRY circa Procedure.GenBody, which isn't for the "synthetic" procedures..


I'll poke around more.


Thanks,
 - Jay

On Aug 2, 2015, at 1:18 PM, "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:

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