The other bug is unfortunately rather more serious and doesn't have a workaround. Essentially it means that --make might not recompile as much of the program as it should, and you might end up with an inconsistent executable (which is likely to crash). Simon P.J. noticed the bug while revamping the front end recently, and we've verified that it can indeed lead to crashing programs. There isn't a simple fix, nor a workaround, although avoiding -O in conjunction with --make might help matters.
That sounds like what I've been seeing (no -O in use though, so that can't be it), thanks. Any indications as to what kinds of change are likely to fall into this gap? So far, I'm rather glad that crashes are the normal consequence - makes it easy to see whether the bug is mine or ghc's.
6.2 will have the bug (because the fix is in Simon P.J.'s rewrite of the front-end, which is scheduled for 6.4). That is unless we can think of a way to fix it that doesn't involve writing hundreds of lines of new code.
While you don't have a fix, could you please make ghc --make err on the safe side, i.e., if in doubt, re-compile? That would still be better than recompiling the whole project because something in the last few dozen modules went wrong (and a whole lot better than quickly constructing non-working code:). As a horrid hack-around, given that ghc --make from scratch gets things right, you could restart the dependency-ordered compilation sequence from the first change. Btw, could you give a pointer to the relevant module in cvs (unless it's unreadable)? Sounds like an interesting bug;-)
This bug has basically been there ever since we had --make, and it has only been seen in the wild perhaps a handful of times, so it's arguably not a showstopper. However, it is rather disturbing.
probably my projects were not wild enough until recently - do I get a trophy for spotting a rare bug in the wild, or do I have to send a photo?-) cheers, claus