Gale Paeper wrote:
That's interesting. With --no-inline and -O3, the trash procedure in both recursion.pas and nonloc2goto.pas gets tail call optimized with no stack frame at all - just like the C analogue compiled with -O3 (without --no-inline).
Perhaps without `--no-inline' the compiler first inlines the call from the main program (or outer routine), and then it doesn't do tail recursion because it doesn't recurse into the current routine (which is now the one containing the call, e.g. the main program). Just a wild guess, I haven't debugged this further. If that's so, the behaviour is certainly not optimal in this case. Perhaps with these assumptions, you'll be able to reproduce it in C code, which would be easier for reporting it to the backend people.
As I noted, with no stack overflow and with the gpc version 20030830 compiler I see range of errors (illegal instruction, bus error, malloc deallocation problems) during program termination for nonloc2goto.pas and nonloc4goto.pas. (I don't see any of those with your recursion.pas so it is most likely a problem related to goto code generation in at least the gpc version 20030830 compiler.)
It actually wasn't the `goto' code, but the local file variables were not properly cleaned up, then trashed on the stack, so the RTS which later tried to clean them up got confused. Since the internal structures contain function pointers, it's no surprise that a trashed structure can cause all kinds of strange errors.
Frank