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]

Re: Experimental hacking of gfortran


On 08/12/2009 02:56 PM, N.M. Maclaren wrote:
> I have some interest in doing some experimental hacking of gfortran
> (for C interoperability, especially for MPI)

Just for curiosity: If I understand it correctly, you essentially want
to experiment with the issues which should be solved by TR 29113
("Further Interoperability of Fortran with C") [1] - though not
necessarily in the way it is done in the current draft.
And the main issues are (a) to access/work with the array descriptor
from C and - especially for MPI [2] - (b) to allow to pass a kind of
"void *buffer" for MPI communication, which solves the problem of
defining hundreds of interfaces.

If you did not sign any copyright assignment regarding GCC, I think it
would be useful if you would do this. The procedure (can) take rather
long and the assignment would be helpful if your changes should end up
in gfortran at some point, even if it is not immediately planned. See
http://gcc.gnu.org/contribute.html

Another item: We plan to revise the array descriptor used by gfortran;
the current one has some issues with subreferences  in array assignments
and it has a hard limit of 7 dimensional arrays which needs to be fixed
for Fortran 2008. (For coarrays, DT length parameters, polymorphic data
types one also will need some fields.) Changing the array descriptor
will break the ABI and will presumably happen in the next version (4.6,
currently 4.5 is being developed). See
http://gcc.gnu.org/wiki/ArrayDescriptorUpdate

> and should appreciate any pointers to documents, places in the source
> and so on that would reduce the effort in finding my way around it.

Some quick overview about gfortran: There are two ways of representing
the code: (a) a gfortran front-end specific structure (gfc_expr,
gfc_symbol etc.) and one which is used by the middle end (TREE). The
translation of into TREE happens in trans*.c. The source parsing happens
essentially in decl.c and match*.c; changes on symbols (adding
attributes with conflict checking, copying attributes etc.) in symbol.c.
The resolving of things which cannot be done at parse time happen in
resolve.c.
trans-decl.c is responsible for the function declaration and the
function body, trans-expr.c for the function call, and trans-types.c is
also involved for the declaration.

The documentation of the internal representation in gfortran is relative
sparse, there is something at
http://gcc.gnu.org/onlinedocs/gfc-internals/, some very limited bits
about internals in http://gcc.gnu.org/onlinedocs/gfortran/. For TREE and
other middle end documentation, see http://gcc.gnu.org/onlinedocs/gccint/

> Specifically, I would like to do the following:
>
>    Introduce a new option to BIND - say, BIND(DESCRIPTOR)
>    Change the calling sequence to pass everything by descriptor
>    Create descriptors for the argument, recursively[*]
>    Diagnose things that I can't or won't handle
>
If it is only a flag and reuses the rest of gfortran, I would add it to
symbol_attribute in gfortran.h, modify the parser  gfc_match_bind_c  in
decl.c, update some checks in symbol.c and resolve.c, and work then on
the calls in trans*.c  (search for attr.is_bind_c). For the call, this
is the trans-expr.c function gfc_conv_procedure_call.

I think that should be enough for the beginning. If you have more
questions regarding the programming or building of GCC, simply ask. Via
IRC you can also ask at irc.oftc.net in the channels #gfortran and for
middle-end questions (TREE) at #gcc.

Tobias

[1] ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1761.txt
[2] http://meetings.mpi-forum.org/mpi3.0_fortran.php


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