------- Comment #3 from vadimn at redhat dot com 2005-11-21 21:34 -------
Yeah, this may be a dup.
Bryce did mention that native-compiling this program with -O2 should
turn on the TCO. There are two problems with this theory. Number
one, it still segfaults for me:
| $ gcj -O2 --main=Workout Workout.java
| $ ./a.out
| Segmentation fault
This may be ok, because I'm using a rather old GCJ build.
Number two, the TCO cannot possibly be applied in this case. (I can't
see how at the moment, but I'm willing to be convinced otherwise.)
Bryce ran the program under a newer version of GCJ and got some
equally bizarre results:
public static void main(String[] args) {
workHard();
System.out.println("It's nap time.");
}
In his case, it printed out "It's nap time." This is incorrect,
because the program should either run out of stack and throw a
StackOverflowError, or it should it should run out of memory if stack
frames are allocated on the heap. Under no circumstances can the
method return normally. (I misspoke in my original post where I said
the program should, in theory, terminate successfully.)
So, yeah, if this is a dup, close it. Note though this program
generates a much more interesting stress pattern than the one that aph
posted in bug 1373.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24980
