On Sat, Aug 10, 2019 at 11:57 PM Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > > On Sat, Aug 10, 2019 at 11:34:15PM +0300, Janne Blomqvist wrote: > > When moving a local variable from the stack to static storage, the > > procedure is no longer safe to be called recursively or concurrently > > from multiple threads. Thus generate a warning when this is done. > > Also double the default limit for switching from stack to static. > > > > Regtested on x86_64-pc-linux-gnu, Ok for trunk? > > > > OK.
Thanks for the quick review, committed as r274264. To be clear, this patch does not fix the PR, just makes it slightly less likely to happen, and makes some noise when it does happen. To reignite the discussion from https://gcc.gnu.org/ml/fortran/2017-12/msg00082.html , any opinions how this should properly be fixed? I can see two main options: - Use the heap instead of static storage for local variables going over the size limit set by -fmax-stack-var-size= . This is IMHO a bit ugly, going behind the back of the user like this; If the user wants to use the heap, she can use allocatable arrays. Also, it needs to be done somewhere else than in trans-decl.c (gfc_finish_var_decl) as at that point there is no access to the block, and hence one cannot add new code to malloc() and free() the variable. I'm not sure where the proper place for this would be. - Make -frecursive the default for GFC_STD_F2018 (and thus also for -std=gnu), while keeping the existing behavior for older standards. This would follow the wishes of the user, but would risk crashing applications with stack exhaustion. Any opinions which would be preferable, or any other solution to this problem? -- Janne Blomqvist
