Description of problem: GFortran erroneously issues an error for EQUIVALENCES involving AUTOMATIC variables. More generally testing for invalid attributes in an EQUIVALENCE needs to be done after the entire equivalence set is visible. Additionally, for an EQUIVALENCE with AUTOMATIC variables, the compiler must continue to place those objects onto the stack, even if -fno-automatic. Version-Release number of selected component (if applicable): How reproducible: > This is the test code we have: > > program recurse > call cleanstack(42, 42) > call recursive(42,0) > call cleanstack(42, 42) > call recursive(0,5) > call cleanstack(42, 42) > call recursive(0,5) > end > > subroutine recursive(setup, count) > integer*4 setup > integer*4 count > integer*4 setupcopy > integer*4 countcopy > integer*4 something > automatic countcopy,something > equivalence (countcopy, something) > countcopy = count > > if (setup .gt. 0) setupcopy = setup > print *, " > setup = ", setupcopy, " count = ", countcopy > if (count .gt. 0) call recursive(setupcopy - 1, count - 1) > print *, " < setup = ", setupcopy, " count = ", countcopy > end > > subroutine cleanstack(dummy1, dummy2) > integer*4 dummy1 > integer*4 dummy2 > integer*4 dummy3 > integer*4 dummy4 > > dummy3 = dummy1 > dummy4 = dummy2 > > print *, " = clean ", dummy1, " ", dummy2 > end > > The expected output would be > > = clean 42 42 >> setup = 42 count = 0 > < setup = 42 count = 0 > = clean 42 42 >> setup = 42 count = 5 >> setup = 41 count = 4 >> setup = 40 count = 3 >> setup = 39 count = 2 >> setup = 38 count = 1 >> setup = 37 count = 0 > < setup = 37 count = 0 > < setup = 37 count = 1 > < setup = 37 count = 2 > < setup = 37 count = 3 > < setup = 37 count = 4 > < setup = 37 count = 5 > = clean 42 42 >> setup = 37 count = 5 >> setup = 36 count = 4 >> setup = 35 count = 3 >> setup = 34 count = 2 >> setup = 33 count = 1 >> setup = 32 count = 0 > < setup = 32 count = 0 > < setup = 32 count = 1 > < setup = 32 count = 2 > < setup = 32 count = 3 > < setup = 32 count = 4 > < setup = 32 count = 5 Compile with -fno-automatic -frecursive Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Is it the following? $ scl enable devtoolset-7 -- gfortran -frecursive -fno-automatic -fdec-static -o test test.f90 f951: Warning: Flag ‘-fno-automatic’ overwrites ‘-frecursive’ test.f90:17:22: equivalence (countcopy, something) 1 Error: EQUIVALENCE attribute conflicts with AUTOMATIC attribute in ‘countcopy’ at (1) $ rpmquery devtoolset-7-gcc-gfortran devtoolset-7-gcc-gfortran-7.3.1-5.10.el7.x86_64
I see e.g. in fortran-08-007r2.pdf in 5.7.1.1: "An equivalence-object shall not be a designator with a base object that is a dummy argument, a pointer, an allocatable variable, a derived-type object that has an allocatable ultimate component, an object of a nonsequence derived type, an object of a derived type that has a pointer at any level of component selection, an automatic object, a function name, an entry name, a result name, a variable with the BIND attribute, a variable in a common block that has the BIND attribute, or a named constant." Are the automatic variables not automatic objects in Fortran terms?
Mpetlan -- you have to use one or more of the legacy fortran options. I don't recall which one offhand. Jakub -- Certainly allowed in legacy codes. I even found it explicitly allowed in various docs when I was doing research. Ultimately Bloomberg needs it, so we have to do something here. We already tried "don't do that" with them. They were actually receptive to that until they dug deeper into their code and realized how much would have to change.
After further reading, it seems automatic object as Fortran term is roughly variable length types, something where array bounds or other type parameters aren't initialization expressions (approx. constant expressions). Then there is the DEC -fdec-static AUTOMATIC extension, I guess if the DEC derived implementations don't complain about conflicts between that attribute and equivalence, it might be ok.
I think the options should be -std=extra-legacy -fdec-static -frecursive -fno-automatic
VERIFIED for devtoolset-7-gcc-7.3.1-5.13.el{6,7}.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2604