On Mon, Feb 22, 2010 at 5:09 PM, Alessio Stalla alessiostalla@gmail.com wrote:
On Mon, Feb 22, 2010 at 11:25 AM, Mark Evenson evenson@panix.com wrote:
- Alessio's recent work on lambda inlining. In my opinion we have to address the bug Alan Ruttenberg has found or backout these changes before release.
I've been silent on the issue, but that doesn't mean I'm not working on it :) I still haven't been able to find out what's wrong, but there's a potential clue. My changes break one ANSI test, apparently because I do a copy-tree I shouldn't do. (without the copy-tree the compiler crashed, so I need to pinpoint exactly what and when to copy). That may be unrelated with Alan's bug, but nevertheless I'll try to fix it. I have the feeling, not backed out by actual evidence, that Alan's bug is related only to the runtime compiler, which somewhat suggests that that copy-tree might have something to do with it as well. So, stay tuned. And in case I don't solve it in time for the release, no problem - it's easy to disable the optimization without reverting anything.
I think I've fixed it. It was indeed a copy-tree, but not the one I thought (incidentally that one was only in my local copy, probably left over from a previous experiment). In one case the expanded function body shared structure with the form that generated the lambda call, and with compiler macros, like in Alan's case, that's really bad, as the code of the compiler macro gets destructively modified by the compilation process (at least, in my understanding), so I added a copy-tree for the function body. I'm not completely sure that copy-tree isn't copying too much, but it was already used in other places for the same thing before my changes. It seems now that read-obo works like it should, and the ANSI tests still pass, so I committed the change. Still, since it was quite a challenge for me to fix it, and it left me almost in a catatonic state :D, I may have missed something: please check that your code still works after the commit.
Alessio