https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92196
Bug ID: 92196
Summary: Regression: -fno-automatic affects local variables in
subroutines/function declared with recursive keyword
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mark.eggleston at codethink dot com
Target Milestone: ---
I've noticed a change in behaviour regarding the use of -fno-automatic and
recursive subroutines and functions. This was the result of a contrived
recursive test routine formerly made recursive via -frecursive being converted
to use the recursive keyword instead of relying on -frecursive.
Local variables in a recursive subroutine or function (declared as such in
code) with default attributes are treated as though they have the automatic
attribute and are allocated on the stack. For the 7 and 8 branch compilers
using -fno-automatic has no affect on these local variables, for the 9 branch
and trunk compilers these local variables are treated as having the save
attribute and are not allocated on the stack.
The following test subroutine, declared recursive, even though it is not,
demonstrates the issue:
recursive subroutine foo
integer :: a
a = 5
if (a.ne.5) stop 1
end subroutine
Compiled using -fdump-tree-original with and without -fno-automatic the output
is identical for 7 and 8 branch compilers.
foo ()
{
integer(kind=4) a;
a = 5;
if (a != 5)
{
_gfortran_stop_numeric (1, 0);
}
L.1:;
}
For the 9 branch and trunk compilers the output is the same without
-fno-automatic but with the output is:
foo ()
{
static integer(kind=4) a;
a = 5;
if (a != 5)
{
_gfortran_stop_numeric (1, 0);
}
L.1:;
}
Showing that a is treated as having the save attribute.
I've tracked this down to
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=268098.
