[PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static

[Fritz Reese]

Greetings,

This patch extends the GNU Fortran front-end to add support for
DEC-style AUTOMATIC and STATIC symbol attributes with a new flag
-fdec-static, allowing explicit control of variable storage. AUTOMATIC
local variables are placed on the stack, whereas STATIC variables are
placed in static storage.

Currently, GNU Fortran provides some control over variable storage
through the use of its options -f[no-]automatic, -f[no-]recursive, and
-fmax-stack-var-size=, as well as the Fortran standard SAVE attribute.
However there is no way to mark a particular variable to be allocated
in automatic storage without potentially affecting other variables in
a given program. There are programs written in legacy (non-standard)
Fortran which do use the AUTOMATIC attribute for this reason. STATIC
is just an alias for SAVE, but provides further compatibility for such
legacy programs.

AUTOMATIC is implemented as a new symbol_attribute 'automatic', which
is checked in a couple places in resolve.c (apply_default_init_local,
resolve_fl_variable_derived, resolve_symbol), symbol.c
(gfc_is_var_automatic), and trans-decl.c (gfc_finish_var_decl). Note
that AUTOMATIC does NOT override -fno-automatic; with the flag, a
warning is produced for variables marked AUTOMATIC. STATIC is
implemented by setting the 'save' attribute and no distinction is made
from SAVE. Parser support for these attributes is enabled only with
the new compile flag -fdec-static.

Bootstraps and regtests on x86_64-redhat-linux. Questions, comments,
and critique welcome. Ok for trunk?

P.S. Historical note: a user of some legacy code pointed out to me
that some other compilers allow the AUTOMATIC attribute to be
specified for variables in an EQUIVALENCE, and that some legacy code
contains usages of such. As one of my primary goals is (unfortunately)
to provide support for legacy code I debated whether to allow this. In
the end I restricted this combination for several reasons. Firstly,
F95§5.5.1 states "... an equivalence object shall not be... an
automatic object...". This is a less convincing reason, since the
AUTOMATIC/STATIC attributes are already non-standard, and implement
non-standard behavior, but GNU Fortran in implementing the standard
will follow this behavior. Thus implementing an "automatic
equivalence" variable would potentially be non-trivial and have
strange consequences in the first place. Furthermore, I have found
empirically that other compilers which accept the combination
syntactically still specify in documentation that the combination is
illegal, and the implementation is unpredictable. So AUTOMATIC +
EQUIVALENCE seems like something to be fixed in user code.

---
Fritz Reese

08-17-2016  Fritz Reese  <fritzoreese@gmail.com>

    gcc/fortran/
        * lang.opt, invoke.texi, gfortran.texi: New flag -fdec-static.
            * options.c (set_dec_flags): Set -fdec-static with -fdec.
        * gfortran.h (symbol_attribute): New attribute AUTOMATIC.
        * gfortran.h (gfc_add_automatic): New prototype.
        * match.h (gfc_match_automatic, gfc_match_static): New functions.
        * decl.c (gfc_match_automatic, gfc_match_static): Ditto.
        * symbol.c (gfc_add_automatic): Ditto.
        * decl.c (match_attr_spec): Match AUTOMATIC and STATIC decls.
        * parse.c (decode_specification_statement, decode_statement): Ditto.
        * resolve.c (apply_default_init_local, resolve_fl_variable_derived,
        resolve_symbol): Support for automatic attribute.
        * symbol.c (check_conflict, gfc_copy_attr, gfc_is_var_automatic):
        Ditto.
        * trans-decl.c (gfc_finish_var_decl): Ditto.

    gcc/testsuite/gfortran.dg/
        * dec_static_1.f90, dec_static_2.f90: New testcases.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dec_static.patch
Type: text/x-patch
Size: 22931 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20160817/f8a484a0/attachment.bin>