<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Alas..<br><br>== package /Users/jay/dev2/cm3/m3-tools/m3tk ==<br><br>new source -> compiling StdFormat.m3<br>../src/astdisplay/StdFormat.m3: In function 'StdFormat__Enumeration_type':<br>../src/astdisplay/StdFormat.m3:193:0: internal compiler error: Bus error<br>Please submit a full bug report,<br><br> - Jay<br><br><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: m3devel@elegosoft.com<br>Subject: enable-checking vs. static link<br>Date: Sat, 20 Nov 2010 14:11:26 +0000<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<style>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
So, I had sprinkled in volatile for some reason, on static link loads.<br>That seems to make the first check fail:<br><br><br> if (gimple_call_chain (stmt)<br> && !is_gimple_val (gimple_call_chain (stmt)))<br> {<br>#if 0 /* Modula-3 hack */<br> error ("invalid static chain in gimple call");<br> debug_generic_stmt (gimple_call_chain (stmt));<br> return true;<br>#else<br> return false;<br>#endif<br> }<br><br><br>because is_gimple_val has something to do with if the value can be in a register,<br>and volatile values cannot be.<br><br><br>So I removed the volatile in parse.c<br><br><br>However, then this next check fails:<br><br><br> /* If there is a static chain argument, this should not be an indirect<br> call, and the decl should have DECL_STATIC_CHAIN set. */<br> if (gimple_call_chain (stmt))<br> {<br> if (TREE_CODE (fn) != ADDR_EXPR<br> || TREE_CODE (TREE_OPERAND (fn, 0)) != FUNCTION_DECL)<br> {<br>#if 0 /* Modula-3 hack */<br> error ("static chain in indirect gimple call");<br> return true;<br>#else<br> return false;<br>#endif<br> }<br><br><br><br>and I think this might just be a fundamental disagreement between gcc and Modula-3. ??<br>As well, even the first check still fails sometimes, just not as much. I have to look into that further.<br><br><br>The second check fails around here RTExFrame.m3:<br><br><br>PROCEDURE CallProc (p: FinallyProc; VAR a: RT0.RaiseActivation) RAISES ANY =<br> (* we need to fool the compiler into generating a call<br> to a nested procedure... *)<br> BEGIN<br> p (a);<br> END CallProc;<br><br><br>Hm. A way we can probably fix this and reduce code size, but deoptimize, is make all<br>function pointer calls go to a C helper?<br><br>That might also reduce the patch to gcc?<br> (the "necessary patch" -- I know I changed it a bunch, but it's all fairly optional)<br><br>I don't know.<br>I still don't know how this static link stuff really works.<br>I do know that a closure is a -1 marker, a function pointer, a static link.<br>I guess the function pointer could to be a function with any signature.<br>So writing a portable C helper would be..difficult.<br><br><br>Well, more later.<br><br><br>I'm curious to see the affects of removing the volatile, somewhat independent<br>of the enable-checking. Maybe that is related to the inlining/nested/setjmp/fork problem.<br>That'll be nice to clear up.<br><br><br> - Jay<br> </body>
</html>