[M3devel] nested functions vs. setjmp vs. inlining

Jay K jay.krell at cornell.edu
Fri Nov 19 17:21:02 CET 2010


Good question. I can look into that. But notice that it will *definitely* be different. But maybe not
in a critical way -- they use trampolines.

 - Jay

From: hosking at cs.purdue.edu
Date: Fri, 19 Nov 2010 09:39:00 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] nested functions vs. setjmp vs. inlining



This is a shame.1. gcc supports nested functions.2. gcc supports inlining.3. gcc should work with both nested functions and inlining.
If gcc can handle all of this for C but not M3 then we must be doing something wrong.Can we see how similar code fragments behave when expressed in C?


On Nov 19, 2010, at 4:12 AM, Jay K wrote:parse.c:
/* don't inline anything, to fix:
elego/m3msh/src/M3MiniShell.m3: In function 'M3MiniShell__ProcessParameters':
elego/m3msh/src/M3MiniShell.m3:608:0: error: variable '_nonlocal_var_rec.188' might be clobbered by 'longjmp' or 'vfork'
*/


I'm very welling to make an extra pass through the IR, and only turn off inlining if I see both nested functions and calls to setjmp/longjmp/fork/vfork.
Oh, and a use of a static link.
I wouldn't check for their intersection.
Most modules wouldn't have any nested functions. And then sometimes nested functions are only nested to limit their use.

I tried selectively disabling inlining. No luck.
  I might try again, but don't plan on success there.


OK?


Fixing this "properly" I'm not keen on doing right now either, as I already spent a while trying to figure out how and failed.
(not to mention my keenness for evading this issue entirely, such as by using C or having the frontend transform away nested functions...)


 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101119/f4e3cd83/attachment-0002.html>


More information about the M3devel mailing list