[Bug fortran/34053] New: -frecursive: No need to use the stack for local variables of the main program

[Bug fortran/34053] New: -frecursive: No need to use the stack for local variables of the main program

[burnus at gcc dot gnu dot org]

Using -fopenmp or -frecursive, local variables are put on the stack. This makes
sense, but for the main program there is no need for the stack and the static
memory can be used. This seems to be done what sunf95 does (contrary to ifort
and gfortran).

The following example is based on the thread at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9a7daa8d75084b6b/
and using static memory should have no negative side effects.

Example: Run the following program with -fopenmp or -frecursive and
  ulimit -S -s 8192
Due to this low stack size, it will crash.

program sums
   implicit none
   integer, parameter :: sp = kind(1.0)
   integer, parameter :: dp = selected_real_kind(2*precision(1.0_sp))

   integer, parameter                      :: num_steps = 2000000
   real                                    :: t1, t2
   integer                                 :: i, j
   real(kind=dp), dimension(0:num_steps-1) :: y
   call cpu_time(t1)
   y = 0.0_dp
!$omp parallel do
   do j=0,num_steps-1
     do i=0,49
       y(j) = y(j) + 0.7_dp**i
     end do
   end do
!$omp end parallel do
   call cpu_time(t2)
   print *, "y(end) = ", y(num_steps-1)
   print *, "Reached result in ", t2-t1, " seconds processor time."
end program sums


-- 
           Summary: -frecursive: No need to use the stack for local
                    variables of the main program
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34053

[Bug fortran/34053] -frecursive: No need to use the stack for local variables of the main program

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2007-11-10 19:23 -------
As follow up, currently -frecursive is implemented as:

  /* Implied -frecursive; implemented as -fmax-stack-var-size=-1.  */
  if (gfc_option.flag_max_stack_var_size == -2 && gfc_option.flag_openmp)
    gfc_option.flag_max_stack_var_size = -1;

I'm thus not sure how to handle this easily (i.e. what limit to use for the
main PROGRAM?). Maybe one should leave the status quo, or not?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34053

[Bug fortran/34053] -frecursive: No need to use the stack for local variables of the main program

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2007-11-19 04:38 -------
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-11-19 04:38:02
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34053

[Bug fortran/34053] -frecursive: No need to use the stack for local variables of the main program

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2009-05-25 23:02 -------
The following should be enough. gfc_can_put_var_on_stack is also called
elsewhere but those calls shouldn't matter so much.

Index: trans-decl.c
===================================================================
--- trans-decl.c        (Revision 147558)
+++ trans-decl.c        (Arbeitskopie)
@@ -544,10 +544,12 @@
       TREE_TYPE (decl) = new_type;
     }

-  /* Keep variables larger than max-stack-var-size off stack.  */
+  /* Keep variables larger than max-stack-var-size off stack and
+     - even with -frecursive - variables of the main program. */
   if (!sym->ns->proc_name->attr.recursive
       && INTEGER_CST_P (DECL_SIZE_UNIT (decl))
-      && !gfc_can_put_var_on_stack (DECL_SIZE_UNIT (decl))
+      && (!gfc_can_put_var_on_stack (DECL_SIZE_UNIT (decl))
+         || sym->ns->proc_name->attr.main_program)
         /* Put variable length auto array pointers always into stack.  */
       && (TREE_CODE (TREE_TYPE (decl)) != POINTER_TYPE
          || sym->attr.dimension == 0


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34053

[Bug fortran/34053] -frecursive: No need to use the stack for local variables of the main program

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2009-05-26 19:29 -------
s/main_program/is_main_program/

CLOSE as WONTFIX. As Andrew pointed out, there are a couple of issues using
static memory:

1. The middle end does not optimize static variables that well as it does not
know about non-recursive procedures

2. Marking loop variables etc. as static does not work well in the context of
OpenMP's private. This problem can be reduced by using a certain threshold (as
currently done for local variables), but it always exists

3. Given all the trouble, it is unlikely that a real-world program only has a
too large array in the main program (which can be cured by this patch); more
likely is that further large arrays exists in subroutines etc. For those this
patch won't help, but "ulimit -s unlimited" does.

4. This seems to be a relatively rarely reported problem; general stack limit
problems are more common, though.

-> CLOSE


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34053