[M3devel] enable-checking vs. static link

[Jay K]

Alas..

== package /Users/jay/dev2/cm3/m3-tools/m3tk ==

new source -> compiling StdFormat.m3
../src/astdisplay/StdFormat.m3: In function 'StdFormat__Enumeration_type':
../src/astdisplay/StdFormat.m3:193:0: internal compiler error: Bus error
Please submit a full bug report,

 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: enable-checking vs. static link
Date: Sat, 20 Nov 2010 14:11:26 +0000








So, I had sprinkled in volatile for some reason, on static link loads.
That seems to make the first check fail:


  if (gimple_call_chain (stmt)
      && !is_gimple_val (gimple_call_chain (stmt)))
    {
#if 0 /* Modula-3 hack */
      error ("invalid static chain in gimple call");
      debug_generic_stmt (gimple_call_chain (stmt));
      return true;
#else
      return false;
#endif
    }


because is_gimple_val has something to do with if the value can be in a register,
and volatile values cannot be.


So I removed the volatile in parse.c


However, then this next check fails:


  /* If there is a static chain argument, this should not be an indirect
     call, and the decl should have DECL_STATIC_CHAIN set.  */
  if (gimple_call_chain (stmt))
    {
      if (TREE_CODE (fn) != ADDR_EXPR
      || TREE_CODE (TREE_OPERAND (fn, 0)) != FUNCTION_DECL)
    {
#if 0 /* Modula-3 hack */
      error ("static chain in indirect gimple call");
      return true;
#else
      return false;
#endif
    }



and I think this might just be a fundamental disagreement between gcc and Modula-3. ??
As well, even the first check still fails sometimes, just not as much. I have to look into that further.


The second check fails around here RTExFrame.m3:


PROCEDURE CallProc (p: FinallyProc;  VAR a: RT0.RaiseActivation) RAISES ANY =
  (* we need to fool the compiler into generating a call
     to a nested procedure... *)
  BEGIN
    p (a);
  END CallProc;


Hm. A way we can probably fix this and reduce code size, but deoptimize, is make all
function pointer calls go to a C helper?

That might also reduce the patch to gcc?
  (the "necessary patch" -- I know I changed it a bunch, but it's all fairly optional)

I don't know.
I still don't know how this static link stuff really works.
I do know that a closure is a -1 marker, a function pointer, a static link.
I guess the function pointer could to be a function with any signature.
So writing a portable C helper would be..difficult.


Well, more later.


I'm curious to see the affects of removing the volatile, somewhat independent
of the enable-checking. Maybe that is related to the inlining/nested/setjmp/fork problem.
That'll be nice to clear up.


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