Re: Fortran to C/C++ translation: a running example.

Rock Brentwood <rockbrentwood@gmail.com> schrieb:
[...]


> A key issue that arise, which led to later revision in the Fortran standard,
> is the lack of information required to distinguish between parameters that are
> input-only, output-only, input/output.


Nit: In Fortran, "parameters" are what you would call "constants"
in another language. Arguments to functions or subroutines are
called "dummy arguments", which are then associated with "actual
arguments" on the caller's side.


> That has to be inferred, which requires
> either transparency of library functions (here: the functions in the f2c
> library or whatever is written in its place) or I/O specifications in the
> library functions. So, a "strength reduction" step is required to lift
> input/output parameters (the default) to input-only or output-only.


"Strength reduction" is a term normally used for something else,
for example when replacing multiplication (as in a loop for array
processing) by addition.


It's a question of the semantics of the code. For something like
(C side)


      aux_var = 5;
      foo (&aux_var);


you can almost certainly rewrite foo to take a value argument.


> A similar issue arises with locals, which are "static", by default, in Fortran
> (or the Fortran equivalent of "static"). A "strength reduction" step is
> required to lift non-static locals to bona fide "auto" locals.


The FORTRAN language never guaranteed that variables would keep their
data unless SAVE was specified, but many compilers did it anyway, so the
code may indeed assume so.


Some experimentation on the Fortran side can help there. Compiling
the code with -frecursive and/or with one of the -finit-integer
and -finit-real options (I'm talking gfortran options here, but
other compilers have similar) will help you find trouble spots.
If you happen to have access to nagfor, they have a -C=all option
which will find very many bugs in code that people think correct,
even more with -C=undefined.


> Another key issue the aliasing that goes on with "equivalence" constructs.


> There is no good uniform translation for this into C ...


The question is - what is equivalence used for? Something sane?


Generally, C's union are a good match for Fortran's equivalence,
with the same problem with undefined behavior if the unions are
used for type punning.


>it actually better
> fits C++, where you have reference types available. There's really no good
> reason why those have been left out of C, when other things which appeared
> first in C++, like "const", "bool" or function prototypes, found their way
> into C.
>
> However, a substantial chunk of use-cases for equivalence constructs can be
> carved out as "enum" types, so there was a strength reduction step for this,
> too.
>
> Perhaps the moderator will have more to say about the intricacies of Fortran
> translation. In the meanwhile, another project has already been staged for
> conversion to C++ - LAPACK
>
> https://github.com/LydiaMarieWilliamson/lapack
>
> but is in a holding pattern for now. This one will more heavily involve the
> synthesis of "template" types. To date, ongoing attempts, elsewhere, have been
> mostly limited to creating C or C++ shells for the Fortran core, rather than a
> conversion of the core, itself.


Fortran has guarantees on the semantics which are quite well tuned for
optimization. Converting it into C or C++ may well lose execution
speed.

Return to the comp.compilers page.
Search the comp.compilers archives again.