Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #3009
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: Fortran to C/C++ translation: a running example. |
| Date | 2022-05-17 14:59 +0000 |
| Organization | news.netcologne.de |
| Message-ID | <22-05-036@comp.compilers> (permalink) |
| References | <22-05-032@comp.compilers> |
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.
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar
Fortran to C/C++ translation: a running example. Rock Brentwood <rockbrentwood@gmail.com> - 2022-05-16 12:27 -0700
Re: Fortran to C/C++ translation: a running example. Thomas Koenig <tkoenig@netcologne.de> - 2022-05-17 14:59 +0000
Re: Fortran to C/C++ translation: a running example. Lydia Marie Williamson <lydiamariewilliamson@gmail.com> - 2022-05-20 16:34 -0700
Re: Fortran to C/C++ translation: a running example. gah4 <gah4@u.washington.edu> - 2022-05-21 09:31 -0700
Re: Fortran to C/C++ translation: a running example. Thomas Koenig <tkoenig@netcologne.de> - 2022-05-21 17:24 +0000
csiph-web