[M3commit] CVS Update: cm3

[Jay K]

I do keep hitting problems related to static links.
 
 
 
Either the volatile setjmp/fork error (could be a warning, but I made it an error).
Or configure -enable-checking not liking our trees.
 
 
For the first problem I had to disable the "forward prop" optimization.
Not great.
 
 
For the second I disabled the check. Even worse.
These changes are not speculative. So I'm definitely not overestimating in some sense.
Granted 1) I might be overestimating in my comments/thoughts 2) there
should be a better way to fix it.
 
 
 
But there is a problem, either in gcc unpatched, or in how parse.c
constructs trees related to nested functions and/or static links, and/or
in how I patched in the static link tree code, somewhere.
It took me a fair amount of digging to get the static link stuff "working"
in gcc 4.5 -- "working" as in code compiles and runs correctly, albeit
with these optimization/checking problems, not "working" as in clearly
all correct, I now suspect/realize.
 
 
Very little code in the tree uncovers these problems.
  Granted, I don't build m3-sys/tests much.
  But I pretty frequently run do-cm3-all. That's what I mean by "the tree".
 
 
In particular, the setjmp/fork problem only occurs in the recently
added elego directory. (Thanks Olaf! :) )
 
 
m3tk is also a good exerciser of this stuff, I think the file StdFormat.m3.
 
 
I'll try to think more about your point though, later.
 
 
And I'll try to understand more here as well.
Like, why does gcc complain about indirect calls with static links?
  What does that mean? I mostly know, but not enough to understand
  quickly why it complains or why we do or not need it or why we
  end up constructing it.
 
 
I should put together small samples that trigger the check problem.
I think that's easy.
 
 
And maybe the fork/setjmp problem, probably less easy but I do have
a starting point.
 
 
Additional changes in tree-nested.c are ok as part of a fix, since
we unavoidably change that file anyway.
 (though, again, it might be nice to avoid it; I know we are getting
  more optimization this way, but is it worth it? I guess, again,
  I should compare to C, or Ada, and try to understand why our
  difference isn't significant, as you are saying and I think Tony said).
 
 
Later,
 - Jay


----------------------------------------
> Date: Mon, 22 Nov 2010 13:44:00 -0600
> From: rodney_bates at lcwb.coop
> To: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
>
> Jay, I think you overestimate the connection between static links
> and closures/trampolines, which is really quite weak. They are
> almost orthogonal mechanisms.
>
> Closures come into play only when you pass a nested procedure
> as an actual parameter, and then call it via the corresponding
> formal. The closure only stores a pointer to an activation record
> during the interval between these two events. A trampoline does
> the same, using a different mechanism.
>
> Where the AR pointer came from before it was stored in the closure
> and how it is used after it is pulled out of the closure during
> the call through the actual parameter are no different than when
> nested procedures are called only as procedure constants and thus
> no closures exist at all.
>
> If the static link mechanism works without passing/calling nested
> procedures as parameters (and thus without any closures being
> involved), then it should work fine with the above too.
>
> Jay Krell wrote:
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/11/21 23:39:11
> >
> > Modified files:
> > cm3/m3-sys/m3cc/gcc-4.5/gcc/: tree-cfg.c
> >
> > Log message:
> > disable another static chain check
> >
> > arg, clearly I did an adequate job of getting
> > the static link stuff to "work" with gcc-4.5
> > but not so good at getting it to work with optimizations
> > and checking; I still suspect there is a disconnect
> > between our "closures" and gcc's expectations.
> >
> >