Re: Mark Mitchell's 15-May toplev.c patch breaks some Fortranstatement functions

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

    Toon> Mark, could you dig up *why* this change was necessary ?

>  Actually, I was as surprised as you to see this go in;
>  I'd submitted it months ago!  Jason Merrill checked it
>  in.  I think this comment explains what either he or I
>  believed the problem to be:
>
>  	 /* We cannot defer functions containing nested
>  	    functions
>  	    since the nested function data is in our
>  	    non-saved obstack.  We cannot defer nested	***
>  	    functions for the same reason.  */		***

[ Actually, Dave Love detected that this patch was the problem ]

Yep, after sending my mail to egcs@cygnus.com, I saw the comment in  
the source.  However, this still doesn't:

A. Supply me with a test-case that shows that there's something
   wrong here.

B. Explain why the Fortran Frontend has been able to use nested
   functions for years in a relatively popular construct like
   statement functions *without it ever leading to a problem*.
   NOTE: Statement functions in Fortran are not an extension -
   they are part of the Standard.  It's g77's use of *what con-
   stitutes an extension in C* that makes this an interesting ;-)
   problem.

If you have a test case (even if it's C++) I'm willing to look into  
it (it might be that we still both can get what we want if I can  
determine why the g77 use of this feature doesn't lead to problems).

Thanks in advance,
Toon.

On a completely unrelated note [for the list]:  Yesterday I started  
a run of our Numerical Weather Prediction code compiled by a recent  
CVS snapshot containing the GCSE code.  Guess what:  Not the  
faintest hint of faster execution.  I must confess that I couldn't  
come up with common Fortran idiom that would immediately benefit  
from GCSE, but that it would have no effect at all is pretty  
surprising to me ...