On Fri, Apr 13, 2018 at 12:50 AM, Thomas König <t...@tkoenig.net> wrote:
> Hello world, > > with Fortran 2018, recursive is becoming the default. This will likely > have a serious impact on many user codes, which often declare large > arrays which could then overflow stacks, leading to segfaults without > further explanation. > Yes. For reference, we had some previous discussion about this at https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01417.html and https://gcc.gnu.org/ml/fortran/2017-12/msg00082.html . > > What could we do? A few options, not all mutally exclusive. > > We could extend -fmax-stack-var-size so it allocates memory > from the heap in recursive procedures, too, and set this to > some default value. Of course, it would also have to free them > afterwards, but we manage that for allocatable arrays already. > +1. I think this is the pragmatic approach. It ought to work everywhere, and should be implementable with modest effort (I did try to have a go at it, but I'm not that familiar with that part of the frontend, so I didn't really make any progress). > We could warn when large arrays with sizes known at compile time > are translated. > +1. Although this shouldn't perhaps be part of -Wall, as it's not a correctness issue, only a *potential* performance one. > We could use -fsplit-stack by default. How reliable is that > option? Can it be used, for example, with -fopenmp? > Is it available on all (relevant) platforms? > One drawback would be that this would allow for infinite > recursions to go on for much longer. > Seems not all targets support it, like Ramana said. Also, IIRC go (the language, that is) originally used split stacks, but at some point they switched to larger stacks, due to the overhead of checking the stack usage at every procedure call. And Go isn't even a particularly performance-oriented language (compared to C/C++/Fortran). > > Other ideas / options? > Nicks suggestion to have a separate split stack for large and variable-sized arrays sounds good, although I suspect it would run into the same portability issues as -fsplit-stack and then some. So in the short term, I think what ought to be done in rough order of importance: 1) Make -fmax-stack-var-size use the heap instead of static memory. 2) Make -frecursive the default. 3) Warning for array that is large enough to be allocated on the heap. 4) Run-time error for automatic heap allocation. Longer term, if somebody has the energy to deal with the (potential) portability issues, Nicks secondary split stack approach could be good. -- Janne Blomqvist
