This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Fwd: DEC Extension Patches: Structure, Union, and Map


Greetings,

Please see the previous thread on this discussion for my original proposal:
https://gcc.gnu.org/ml/fortran/2014-09/msg00255.html

It has been a year and a half since I originally opened this
discussion. For a quick refresher: I had drafted patches to introduce
some old compiler extensions to GNU Fortran, enabled by a special
compile flag. I had these extensions fully functional in gcc-4.8.3,
with a new testsuite and no regressions, but it was requested that I
rebase my patches on the gcc trunk (gcc-5 at the time) before
submitting them to GNU.

The first six months went by awaiting legal confirmation of my
copyright assignment, since my patches were nontrivial. After a
succesful copyright agreement with the FSF the second six months went
by attempting the rebase. With the fairly significant architectural
changes from gcc-4.8 to gcc-5, this was more time-consuming than
originally expected. Finally, the last six months I fell ill and was
unable to perform any work whatsoever. Now I have fully recovered and
have finished up rebasing my first patch on the gcc development trunk
which introduces the STRUCTURE, UNION, and MAP constructs.

This submission contains (4) patches. The first three are minor
self-contained refactoring steps which simplify the implementation of
the much larger fourth patch, which contains the actual implementation
of STRUCTURE and friends. It seems I actually have to submit these
patches separately, because currently they are being blocked by the
spam filter when sent with this post.

I attempted to ensure all my changes were well-documented. Details
from the user perspective as well as some implementation details can
be found in the updated gfortran info and man pages. These pages
describe the supported syntax of STRUCTURE, UNION, MAP, and RECORD
statements, and how STRUCTURE differs from TYPE. The use of these
statements is enabled ONLY through a new command-line option
'-fdec-structure'. NB: My 4.8.3 compiler has a slew of DEC extensions
which are all enabled with compiler options beginning with '-fdec-'. I
plan to submit future patches for some of these as well.

More details of the implementation can be found in comments throughout
the source code, but I will summarize here for convenience.

STRUCTURE is implemented as a very simple version of TYPE, with a new
flavor FL_STRUCT. The key differences are outlined in the gfortran
info page. Instances of STRUCTUREs still have basic type BT_DERIVED,
and are treated mostly the same as instances of TYPEs. Just like TYPE,
a STRUCTURE definition is stored in the symbol table beginning with an
upper-case letter to disambiguate it from other symbols, which are
converted to lower-case during parsing. Unlike TYPE however, STRUCTURE
does not imply a FL_PROCEDURE symbol with the same name in lower-case
for a constructor. The translation to generic is handled by the same
function as for TYPE (gfc_get_derived_type), though STRUCTURE is
always treated as if the SEQUENCE attribute were specified.

The big reason for introducing this extension is because STRUCTURE
definitions can also contain UNION definitions. These are much like C
unions, which is something difficult to achieve in standard Fortran.
Syntactically, UNION contains MAP definitions: each MAP defines a
sub-structure within the union that all occupy the same storage.
UNIONs are always components of STRUCTUREs, and always have a list of
MAP components. A UNION component has basic type BT_UNION and its
derived symbol (ts.u.derived) has flavor FL_UNION. A FL_UNION symbol
is similar to a FL_STRUCTURE symbol but can make special assumptions
about its list of MAP components (via usym->components). MAP
components are exactly the same as STRUCTURE instances. They have
basic type BT_DERIVED and their derived symbol (ts.u.derived) has
flavor FL_STRUCT. When a FL_UNION is translated its typenode is built
(in gfc_get_union_type) by setting its type to UNION_TYPE. Its fields
will always be of MAP type, which have flavor FL_STRUCT and are again
translated just like derived types with the SEQUENCE attribute (via
gfc_get_derived_type).

Since MAP and UNION (and STRUCTURE in certain cases - see info
page/test cases) define structures anonymously, these structures are
saved in the symbol table with autogenerated names. UNIONs are named
UU$N, MAPs are named MM$N, and anonymous STRUCTUREs are named SS$N,
where N is an integer which increments upon the creation of each
anonymous name (separately for each type). The leading two uppercase
characters and '#39; ensure the names are invalid Fortran identifiers.

The submission also includes a suite of test cases alongside the other
gfortran.dg tests which help isolate regressions that I have
experienced while maintaining these patches on gcc-4.8.3 for the last
[almost] two years.

Please let me know your comments and concerns. I understand the patch
is quite large, but I hope it is acceptable. I do intend to provide
support for any problems which might be related to this extension.


- Fritz Reese


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]