This is Info file g77.info, produced by Makeinfo version 1.68 from the input file g77.texi. This file explains how to use the GNU Fortran system. Published by the Free Software Foundation 59 Temple Place - Suite 330 Boston, MA 02111-1307 USA Copyright (C) 1995-1997 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the sections entitled "GNU General Public License," "Funding for Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are included exactly as in the original, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that the sections entitled "GNU General Public License," "Funding for Free Software," and "Protect Your Freedom--Fight `Look And Feel'", and this permission notice, may be included in translations approved by the Free Software Foundation instead of in the original English. Contributed by James Craig Burley (). Inspired by a first pass at translating `g77-0.5.16/f/DOC' that was contributed to Craig by David Ronis (). INFO-DIR-SECTION Fortran Programming START-INFO-DIR-ENTRY * g77: (g77). The GNU Fortran compilation system. END-INFO-DIR-ENTRY  File: g77.info, Node: Bug Criteria, Next: Bug Lists, Up: Bugs Have You Found a Bug? ===================== If you are not sure whether you have found a bug, here are some guidelines: * If the compiler gets a fatal signal, for any input whatever, that is a compiler bug. Reliable compilers never crash--they just remain obsolete. * If the compiler produces invalid assembly code, for any input whatever, that is a compiler bug, unless the compiler reports errors (not just warnings) which would ordinarily prevent the assembler from being run. * If the compiler produces valid assembly code that does not correctly execute the input source code, that is a compiler bug. However, you must double-check to make sure, because you might have run into an incompatibility between GNU Fortran and traditional Fortran. These incompatibilities might be considered bugs, but they are inescapable consequences of valuable features. Or you might have a program whose behavior is undefined, which happened by chance to give the desired results with another Fortran compiler. It is best to check the relevant Fortran standard thoroughly if it is possible that the program indeed does something undefined. After you have localized the error to a single source line, it should be easy to check for these things. If your program is correct and well defined, you have found a compiler bug. It might help if, in your submission, you identified the specific language in the relevant Fortran standard that specifies the desired behavior, if it isn't likely to be obvious and agreed-upon by all Fortran users. * If the compiler produces an error message for valid input, that is a compiler bug. * If the compiler does not produce an error message for invalid input, that is a compiler bug. However, you should note that your idea of "invalid input" might be someone else's idea of "an extension" or "support for traditional practice". * If you are an experienced user of Fortran compilers, your suggestions for improvement of GNU Fortran are welcome in any case. Many, perhaps most, bug reports against `g77' turn out to be bugs in the user's code. While we find such bug reports educational, they sometimes take a considerable amount of time to track down or at least respond to--time we could be spending making `g77', not some user's code, better. Some steps you can take to verify that the bug is not certainly in the code you're compiling with `g77': * Compile your code using the `g77' options `-W -Wall -O'. These options enable many useful warning; the `-O' option enables flow analysis that enables the uninitialized-variable warning. If you investigate the warnings and find evidence of possible bugs in your code, fix them first and retry `g77'. * Compile your code using the `g77' options `-finit-local-zero', `-fno-automatic', `-ffloat-store', and various combinations thereof. If your code works with any of these combinations, that is not proof that the bug isn't in `g77'--a `g77' bug exposed by your code might simply be avoided, or have a different, more subtle effect, when different options are used--but it can be a strong indicator that your code is making unawarranted assumptions about the Fortran dialect and/or underlying machine it is being compiled and run on. *Note Overly Convenient Command-Line Options: Overly Convenient Options, for information on the `-fno-automatic' and `-finit-local-zero' options and how to convert their use into selective changes in your own code. * Validate your code with `ftnchek' or a similar code-checking tool. `ftncheck' can be found at `ftp://ftp.netlib.org/fortran' or `ftp://ftp.dsm.fordham.edu'. Here are some sample `Makefile' rules using `ftnchek' "project" files to do cross-file checking and `sfmakedepend' (from `ftp://ahab.rutgers.edu/pub/perl/sfmakedepend') to maintain dependencies automatically. These assume the use of GNU `make'. # Dummy suffix for ftnchek targets: .SUFFIXES: .chek .PHONY: chekall # How to compile .f files (for implicit rule): FC = g77 # Assume `include' directory: FFLAGS = -Iinclude -g -O -Wall # Flags for ftnchek: CHEK1 = -array=0 -include=includes -noarray CHEK2 = -nonovice -usage=1 -notruncation CHEKFLAGS = $(CHEK1) $(CHEK2) # Run ftnchek with all the .prj files except the one corresponding # to the target's root: %.chek : %.f ; \ ftnchek $(filter-out $*.prj,$(PRJS)) $(CHEKFLAGS) \ -noextern -library $< # Derive a project file from a source file: %.prj : %.f ; \ ftnchek $(CHEKFLAGS) -noextern -project -library $< # The list of objects is assumed to be in variable OBJS. # Sources corresponding to the objects: SRCS = $(OBJS:%.o=%.f) # ftnchek project files: PRJS = $(OBJS:%.o=%.prj) # Build the program prog: $(OBJS) ; \ $(FC) -o $ $(OBJS) chekall: $(PRJS) ; \ ftnchek $(CHEKFLAGS) $(PRJS) prjs: $(PRJS) # For Emacs M-x find-tag: TAGS: $(SRCS) ; \ etags $(SRCS) # Rebuild dependencies: depend: ; \ sfmakedepend -I $(PLTLIBDIR) -I includes -a prj $(SRCS1) * Try your code out using other Fortran compilers, such as `f2c'. If it does not work on at least one other compiler (assuming the compiler supports the features the code needs), that is a strong indicator of a bug in the code. However, even if your code works on many compilers *except* `g77', that does *not* mean the bug is in `g77'. It might mean the bug is in your code, and that `g77' simply exposes it more readily than other compilers.  File: g77.info, Node: Bug Lists, Next: Bug Reporting, Prev: Bug Criteria, Up: Bugs Where to Report Bugs ==================== Send bug reports for GNU Fortran to . Often people think of posting bug reports to a newsgroup instead of mailing them. This sometimes appears to work, but it has one problem which can be crucial: a newsgroup posting does not contain a mail path back to the sender. Thus, if maintainers need more information, they might be unable to reach you. For this reason, you should always send bug reports by mail to the proper mailing list. As a last resort, send bug reports on paper to: GNU Compiler Bugs Free Software Foundation 59 Temple Place - Suite 330 Boston, MA 02111-1307, USA  File: g77.info, Node: Bug Reporting, Next: Sending Patches, Prev: Bug Lists, Up: Bugs How to Report Bugs ================== The fundamental principle of reporting bugs usefully is this: *report all the facts*. If you are not sure whether to state a fact or leave it out, state it! Often people omit facts because they think they know what causes the problem and they conclude that some details don't matter. Thus, you might assume that the name of the variable you use in an example does not matter. Well, probably it doesn't, but one cannot be sure. Perhaps the bug is a stray memory reference which happens to fetch from the location where that name is stored in memory; perhaps, if the name were different, the contents of that location would fool the compiler into doing the right thing despite the bug. Play it safe and give a specific, complete example. That is the easiest thing for you to do, and the most helpful. Keep in mind that the purpose of a bug report is to enable someone to fix the bug if it is not known. It isn't very important what happens if the bug is already known. Therefore, always write your bug reports on the assumption that the bug is not known. Sometimes people give a few sketchy facts and ask, "Does this ring a bell?" This cannot help us fix a bug, so it is rarely helpful. We respond by asking for enough details to enable us to investigate. You might as well expedite matters by sending them to begin with. (Besides, there are enough bells ringing around here as it is.) Try to make your bug report self-contained. If we have to ask you for more information, it is best if you include all the previous information in your response, as well as the information that was missing. Please report each bug in a separate message. This makes it easier for us to track which bugs have been fixed and to forward your bugs reports to the appropriate maintainer. Do not compress and encode any part of your bug report using programs such as `uuencode'. If you do so it will slow down the processing of your bug. If you must submit multiple large files, use `shar', which allows us to read your message without having to run any decompression programs. (As a special exception for GNU Fortran bug-reporting, at least for now, if you are sending more than a few lines of code, if your program's source file format contains "interesting" things like trailing spaces or strange characters, or if you need to include binary data files, it is acceptable to put all the files together in a `tar' archive, and, whether you need to do that, it is acceptable to then compress the single file (`tar' archive or source file) using `gzip' and encode it via `uuencode'. Do not use any MIME stuff--the current maintainer can't decode this. Using `compress' instead of `gzip' is acceptable, assuming you have licensed the use of the patented algorithm in `compress' from Unisys.) To enable someone to investigate the bug, you should include all these things: * The version of GNU Fortran. You can get this by running `g77' with the `-v' option. (Ignore any error messages that might be displayed when the linker is run.) Without this, we won't know whether there is any point in looking for the bug in the current version of GNU Fortran. * A complete input file that will reproduce the bug. If the bug is in the compiler proper (`f771') and you are using the C preprocessor, run your source file through the C preprocessor by doing `g77 -E SOURCEFILE > OUTFILE', then include the contents of OUTFILE in the bug report. (When you do this, use the same `-I', `-D' or `-U' options that you used in actual compilation.) A single statement is not enough of an example. In order to compile it, it must be embedded in a complete file of compiler input; and the bug might depend on the details of how this is done. Without a real example one can compile, all anyone can do about your bug report is wish you luck. It would be futile to try to guess how to provoke the bug. For example, bugs in register allocation and reloading frequently depend on every little detail of the function they happen in. * Note that you should include with your bug report any files included by the source file (via the `#include' or `INCLUDE' directive) that you send, and any files they include, and so on. It is not necessary to replace the `#include' and `INCLUDE' directives with the actual files in the version of the source file that you send, but it might make submitting the bug report easier in the end. However, be sure to *reproduce* the bug using the *exact* version of the source material you submit, to avoid wild-goose chases. * The command arguments you gave GNU Fortran to compile that example and observe the bug. For example, did you use `-O'? To guarantee you won't omit something important, list all the options. If we were to try to guess the arguments, we would probably guess wrong and then we would not encounter the bug. * The type of machine you are using, and the operating system name and version number. (Much of this information is printed by `g77 -v'--if you include that, send along any additional info you have that you don't see clearly represented in that output.) * The operands you gave to the `configure' command when you installed the compiler. * A complete list of any modifications you have made to the compiler source. (We don't promise to investigate the bug unless it happens in an unmodified compiler. But if you've made modifications and don't tell us, then you are sending us on a wild-goose chase.) Be precise about these changes. A description in English is not enough--send a context diff for them. Adding files of your own (such as a machine description for a machine we don't support) is a modification of the compiler source. * Details of any other deviations from the standard procedure for installing GNU Fortran. * A description of what behavior you observe that you believe is incorrect. For example, "The compiler gets a fatal signal," or, "The assembler instruction at line 208 in the output is incorrect." Of course, if the bug is that the compiler gets a fatal signal, then one can't miss it. But if the bug is incorrect output, the maintainer might not notice unless it is glaringly wrong. None of us has time to study all the assembler code from a 50-line Fortran program just on the chance that one instruction might be wrong. We need *you* to do this part! Even if the problem you experience is a fatal signal, you should still say so explicitly. Suppose something strange is going on, such as, your copy of the compiler is out of synch, or you have encountered a bug in the C library on your system. (This has happened!) Your copy might crash and the copy here would not. If you said to expect a crash, then when the compiler here fails to crash, we would know that the bug was not happening. If you don't say to expect a crash, then we would not know whether the bug was happening. We would not be able to draw any conclusion from our observations. If the problem is a diagnostic when building GNU Fortran with some other compiler, say whether it is a warning or an error. Often the observed symptom is incorrect output when your program is run. Sad to say, this is not enough information unless the program is short and simple. None of us has time to study a large program to figure out how it would work if compiled correctly, much less which line of it was compiled wrong. So you will have to do that. Tell us which source line it is, and what incorrect result happens when that line is executed. A person who understands the program can find this as easily as finding a bug in the program itself. * If you send examples of assembler code output from GNU Fortran, please use `-g' when you make them. The debugging information includes source line numbers which are essential for correlating the output with the input. * If you wish to mention something in the GNU Fortran source, refer to it by context, not by line number. The line numbers in the development sources don't match those in your sources. Your line numbers would convey no convenient information to the maintainers. * Additional information from a debugger might enable someone to find a problem on a machine which he does not have available. However, you need to think when you collect this information if you want it to have any chance of being useful. For example, many people send just a backtrace, but that is never useful by itself. A simple backtrace with arguments conveys little about GNU Fortran because the compiler is largely data-driven; the same functions are called over and over for different RTL insns, doing different things depending on the details of the insn. Most of the arguments listed in the backtrace are useless because they are pointers to RTL list structure. The numeric values of the pointers, which the debugger prints in the backtrace, have no significance whatever; all that matters is the contents of the objects they point to (and most of the contents are other such pointers). In addition, most compiler passes consist of one or more loops that scan the RTL insn sequence. The most vital piece of information about such a loop--which insn it has reached--is usually in a local variable, not in an argument. What you need to provide in addition to a backtrace are the values of the local variables for several stack frames up. When a local variable or an argument is an RTX, first print its value and then use the GDB command `pr' to print the RTL expression that it points to. (If GDB doesn't run on your machine, use your debugger to call the function `debug_rtx' with the RTX as an argument.) In general, whenever a variable is a pointer, its value is no use without the data it points to. Here are some things that are not necessary: * A description of the envelope of the bug. Often people who encounter a bug spend a lot of time investigating which changes to the input file will make the bug go away and which changes will not affect it. This is often time consuming and not very useful, because the way we will find the bug is by running a single example under the debugger with breakpoints, not by pure deduction from a series of examples. You might as well save your time for something else. Of course, if you can find a simpler example to report *instead* of the original one, that is a convenience. Errors in the output will be easier to spot, running under the debugger will take less time, etc. Most GNU Fortran bugs involve just one function, so the most straightforward way to simplify an example is to delete all the function definitions except the one where the bug occurs. Those earlier in the file may be replaced by external declarations if the crucial function depends on them. (Exception: inline functions might affect compilation of functions defined later in the file.) However, simplification is not vital; if you don't want to do this, report the bug anyway and send the entire test case you used. * In particular, some people insert conditionals `#ifdef BUG' around a statement which, if removed, makes the bug not happen. These are just clutter; we won't pay any attention to them anyway. Besides, you should send us preprocessor output, and that can't have conditionals. * A patch for the bug. A patch for the bug is useful if it is a good one. But don't omit the necessary information, such as the test case, on the assumption that a patch is all we need. We might see problems with your patch and decide to fix the problem another way, or we might not understand it at all. Sometimes with a program as complicated as GNU Fortran it is very hard to construct an example that will make the program follow a certain path through the code. If you don't send the example, we won't be able to construct one, so we won't be able to verify that the bug is fixed. And if we can't understand what bug you are trying to fix, or why your patch should be an improvement, we won't install it. A test case will help us to understand. *Note Sending Patches::, for guidelines on how to make it easy for us to understand and install your patches. * A guess about what the bug is or what it depends on. Such guesses are usually wrong. Even the maintainer can't guess right about such things without first using the debugger to find the facts. * A core dump file. We have no way of examining a core dump for your type of machine unless we have an identical system--and if we do have one, we should be able to reproduce the crash ourselves.  File: g77.info, Node: Sending Patches, Prev: Bug Reporting, Up: Bugs Sending Patches for GNU Fortran =============================== If you would like to write bug fixes or improvements for the GNU Fortran compiler, that is very helpful. Send suggested fixes to the bug report mailing list, . Please follow these guidelines so we can study your patches efficiently. If you don't follow these guidelines, your information might still be useful, but using it will take extra work. Maintaining GNU Fortran is a lot of work in the best of circumstances, and we can't keep up unless you do your best to help. * Send an explanation with your changes of what problem they fix or what improvement they bring about. For a bug fix, just include a copy of the bug report, and explain why the change fixes the bug. (Referring to a bug report is not as good as including it, because then we will have to look it up, and we have probably already deleted it if we've already fixed the bug.) * Always include a proper bug report for the problem you think you have fixed. We need to convince ourselves that the change is right before installing it. Even if it is right, we might have trouble judging it if we don't have a way to reproduce the problem. * Include all the comments that are appropriate to help people reading the source in the future understand why this change was needed. * Don't mix together changes made for different reasons. Send them *individually*. If you make two changes for separate reasons, then we might not want to install them both. We might want to install just one. If you send them all jumbled together in a single set of diffs, we have to do extra work to disentangle them--to figure out which parts of the change serve which purpose. If we don't have time for this, we might have to ignore your changes entirely. If you send each change as soon as you have written it, with its own explanation, then the two changes never get tangled up, and we can consider each one properly without any extra work to disentangle them. Ideally, each change you send should be impossible to subdivide into parts that we might want to consider separately, because each of its parts gets its motivation from the other parts. * Send each change as soon as that change is finished. Sometimes people think they are helping us by accumulating many changes to send them all together. As explained above, this is absolutely the worst thing you could do. Since you should send each change separately, you might as well send it right away. That gives us the option of installing it immediately if it is important. * Use `diff -c' to make your diffs. Diffs without context are hard for us to install reliably. More than that, they make it hard for us to study the diffs to decide whether we want to install them. Unidiff format is better than contextless diffs, but not as easy to read as `-c' format. If you have GNU `diff', use `diff -cp', which shows the name of the function that each change occurs in. (The maintainer of GNU Fortran currently uses `diff -rcp2N'.) * Write the change log entries for your changes. We get lots of changes, and we don't have time to do all the change log writing ourselves. Read the `ChangeLog' file to see what sorts of information to put in, and to learn the style that we use. The purpose of the change log is to show people where to find what was changed. So you need to be specific about what functions you changed; in large functions, it's often helpful to indicate where within the function the change was. On the other hand, once you have shown people where to find the change, you need not explain its purpose. Thus, if you add a new function, all you need to say about it is that it is new. If you feel that the purpose needs explaining, it probably does--but the explanation will be much more useful if you put it in comments in the code. If you would like your name to appear in the header line for who made the change, send us the header line. * When you write the fix, keep in mind that we can't install a change that would break other systems. People often suggest fixing a problem by changing machine-independent files such as `toplev.c' to do something special that a particular system needs. Sometimes it is totally obvious that such changes would break GNU Fortran for almost all users. We can't possibly make a change like that. At best it might tell us how to write another patch that would solve the problem acceptably. Sometimes people send fixes that *might* be an improvement in general--but it is hard to be sure of this. It's hard to install such changes because we have to study them very carefully. Of course, a good explanation of the reasoning by which you concluded the change was correct can help convince us. The safest changes are changes to the configuration files for a particular machine. These are safe because they can't create new bugs on other machines. Please help us keep up with the workload by designing the patch in a form that is good to install.  File: g77.info, Node: Service, Next: Adding Options, Prev: Bugs, Up: Top How To Get Help with GNU Fortran ******************************** If you need help installing, using or changing GNU Fortran, there are two ways to find it: * Look in the service directory for someone who might help you for a fee. The service directory is found in the file named `SERVICE' in the GNU CC distribution. * Send a message to .  File: g77.info, Node: Adding Options, Next: Projects, Prev: Service, Up: Top Adding Options ************** To add a new command-line option to `g77', first decide what kind of option you wish to add. Search the `g77' and `gcc' documentation for one or more options that is most closely like the one you want to add (in terms of what kind of effect it has, and so on) to help clarify its nature. * *Fortran options* are options that apply only when compiling Fortran programs. They are accepted by `g77' and `gcc', but they apply only when compiling Fortran programs. * *Compiler options* are options that apply when compiling most any kind of program. *Fortran options* are listed in the file `gcc/f/lang-options.h', which is used during the build of `gcc' to build a list of all options that are accepted by at least one language's compiler. This list goes into the `lang_options' array in `gcc/toplev.c', which uses this array to determine whether a particular option should be offered to the linked-in front end for processing by calling `lang_option_decode', which, for `g77', is in `gcc/f/com.c' and just calls `ffe_decode_option'. If the linked-in front end "rejects" a particular option passed to it, `toplev.c' just ignores the option, because *some* language's compiler is willing to accept it. This allows commands like `gcc -fno-asm foo.c bar.f' to work, even though Fortran compilation does not currently support the `-fno-asm' option; even though the `f771' version of `lang_decode_option' rejects `-fno-asm', `toplev.c' doesn't produce a diagnostic because some other language (C) does accept it. This also means that commands like `g77 -fno-asm foo.f' yield no diagnostics, despite the fact that no phase of the command was able to recognize and process `-fno-asm'--perhaps a warning about this would be helpful if it were possible. Code that processes Fortran options is found in `gcc/f/top.c', function `ffe_decode_option'. This code needs to check positive and negative forms of each option. The defaults for Fortran options are set in their global definitions, also found in `gcc/f/top.c'. Many of these defaults are actually macros defined in `gcc/f/target.h', since they might be machine-specific. However, since, in practice, GNU compilers should behave the same way on all configurations (especially when it comes to language constructs), the practice of setting defaults in `target.h' is likely to be deprecated and, ultimately, stopped in future versions of `g77'. Accessor macros for Fortran options, used by code in the `g77' FFE, are defined in `gcc/f/top.h'. *Compiler options* are listed in `gcc/toplev.c' in the array `f_options'. An option not listed in `lang_options' is looked up in `f_options' and handled from there. The defaults for compiler options are set in the global definitions for the corresponding variables, some of which are in `gcc/toplev.c'. You can set different defaults for *Fortran-oriented* or *Fortran-reticent* compiler options by changing the way `f771' handles the `-fset-g77-defaults' option, which is always provided as the first option when called by `g77' or `gcc'. This code is in `ffe_decode_options' in `gcc/f/top.c'. Have it change just the variables that you want to default to a different setting for Fortran compiles compared to compiles of other languages. The `-fset-g77-defaults' option is passed to `f771' automatically because of the specification information kept in `gcc/f/lang-specs.h'. This file tells the `gcc' command how to recognize, in this case, Fortran source files (those to be preprocessed, and those that are not), and further, how to invoke the appropriate programs (including `f771') to process those source files. It is in `gcc/f/lang-specs.h' that `-fset-g77-defaults', `-fversion', and other options are passed, as appropriate, even when the user has not explicitly specified them. Other "internal" options such as `-quiet' also are passed via this mechanism.  File: g77.info, Node: Projects, Next: Diagnostics, Prev: Adding Options, Up: Top Projects ******** If you want to contribute to `g77' by doing research, design, specification, documentation, coding, or testing, the following information should give you some ideas. * Menu: * Efficiency:: Make `g77' itself compile code faster. * Better Optimization:: Teach `g77' to generate faster code. * Simplify Porting:: Make `g77' easier to configure, build, and install. * More Extensions:: Features many users won't know to ask for. * Machine Model:: `g77' should better leverage `gcc'. * Internals Documentation:: Make maintenance easier. * Internals Improvements:: Make internals more robust. * Better Diagnostics:: Make using `g77' on new code easier.  File: g77.info, Node: Efficiency, Next: Better Optimization, Up: Projects Improve Efficiency ================== Don't bother doing any performance analysis until most of the following items are taken care of, because there's no question they represent serious space/time problems, although some of them show up only given certain kinds of (popular) input. * Improve `malloc' package and its uses to specify more info about memory pools and, where feasible, use obstacks to implement them. * Skip over uninitialized portions of aggregate areas (arrays, `COMMON' areas, `EQUIVALENCE' areas) so zeros need not be output. This would reduce memory usage for large initialized aggregate areas, even ones with only one initialized element. As of version 0.5.18, a portion of this item has already been accomplished. * Prescan the statement (in `sta.c') so that the nature of the statement is determined as much as possible by looking entirely at its form, and not looking at any context (previous statements, including types of symbols). This would allow ripping out of the statement-confirmation, symbol retraction/confirmation, and diagnostic inhibition mechanisms. Plus, it would result in much-improved diagnostics. For example, `CALL some-intrinsic(...)', where the intrinsic is not a subroutine intrinsic, would result actual error instead of the unimplemented-statement catch-all. * Throughout `g77', don't pass line/column pairs where a simple `ffewhere' type, which points to the error as much as is desired by the configuration, will do, and don't pass `ffelexToken' types where a simple `ffewhere' type will do. Then, allow new default configuration of `ffewhere' such that the source line text is not preserved, and leave it to things like Emacs' next-error function to point to them (now that `next-error' supports column, or, perhaps, character-offset, numbers). The change in calling sequences should improve performance somewhat, as should not having to save source lines. (Whether this whole item will improve performance is questionable, but it should improve maintainability.) * Handle `DATA (A(I),I=1,1000000)/1000000*2/' more efficiently, especially as regards the assembly output. Some of this might require improving the back end, but lots of improvement in space/time required in `g77' itself can be fairly easily obtained without touching the back end. Maybe type-conversion, where necessary, can be speeded up as well in cases like the one shown (converting the `2' into `2.'). * If analysis shows it to be worthwhile, optimize `lex.c'. * Consider redesigning `lex.c' to not need any feedback during tokenization, by keeping track of enough parse state on its own.  File: g77.info, Node: Better Optimization, Next: Simplify Porting, Prev: Efficiency, Up: Projects Better Optimization =================== Much of this work should be put off until after `g77' has all the features necessary for its widespread acceptance as a useful F77 compiler. However, perhaps this work can be done in parallel during the feature-adding work. * Do the equivalent of the trick of putting `extern inline' in front of every function definition in `libf2c' and #include'ing the resulting file in `f2c'+`gcc'--that is, inline all run-time-library functions that are at all worth inlining. (Some of this has already been done, such as for integral exponentiation.) * When doing `CHAR_VAR = CHAR_FUNC(...)', and it's clear that types line up and `CHAR_VAR' is addressable or not a `VAR_DECL', make `CHAR_VAR', not a temporary, be the receiver for `CHAR_FUNC'. (This is now done for `COMPLEX' variables.) * Design and implement Fortran-specific optimizations that don't really belong in the back end, or where the front end needs to give the back end more info than it currently does. * Design and implement a new run-time library interface, with the code going into `libgcc' so no special linking is required to link Fortran programs using standard language features. This library would speed up lots of things, from I/O (using precompiled formats, doing just one, or, at most, very few, calls for arrays or array sections, and so on) to general computing (array/section implementations of various intrinsics, implementation of commonly performed loops that aren't likely to be optimally compiled otherwise, etc.). Among the important things the library would do are: * Be a one-stop-shop-type library, hence shareable and usable by all, in that what are now library-build-time options in `libf2c' would be moved at least to the `g77' compile phase, if not to finer grains (such as choosing how list-directed I/O formatting is done by default at `OPEN' time, for preconnected units via options or even statements in the main program unit, maybe even on a per-I/O basis with appropriate pragma-like devices). * Probably requiring the new library design, change interface to normally have `COMPLEX' functions return their values in the way `gcc' would if they were declared `__complex__ float', rather than using the mechanism currently used by `CHARACTER' functions (whereby the functions are compiled as returning void and their first arg is a pointer to where to store the result). (Don't append underscores to external names for `COMPLEX' functions in some cases once `g77' uses `gcc' rather than `f2c' calling conventions.) * Do something useful with `doiter' references where possible. For example, `CALL FOO(I)' cannot modify `I' if within a `DO' loop that uses `I' as the iteration variable, and the back end might find that info useful in determining whether it needs to read `I' back into a register after the call. (It normally has to do that, unless it knows `FOO' never modifies its passed-by-reference argument, which is rarely the case for Fortran-77 code.)  File: g77.info, Node: Simplify Porting, Next: More Extensions, Prev: Better Optimization, Up: Projects Simplify Porting ================ Making `g77' easier to configure, port, build, and install, either as a single-system compiler or as a cross-compiler, would be very useful. * A new library (replacing `libf2c') should improve portability as well as produce more optimal code. Further, `g77' and the new library should conspire to simplify naming of externals, such as by removing unnecessarily added underscores, and to reduce/eliminate the possibility of naming conflicts, while making debugger more straightforward. Also, it should make multi-language applications more feasible, such as by providing Fortran intrinsics that get Fortran unit numbers given C `FILE *' descriptors. * Possibly related to a new library, `g77' should produce the equivalent of a `gcc' `main(argc, argv)' function when it compiles a main program unit, instead of compiling something that must be called by a library implementation of `main()'. This would do many useful things such as provide more flexibility in terms of setting up exception handling, not requiring programmers to start their debugging sessions with `breakpoint MAIN__' followed by `run', and so on. * The GBE needs to understand the difference between alignment requirements and desires. For example, on Intel x86 machines, `g77' currently imposes overly strict alignment requirements, due to the back end, but it would be useful for Fortran and C programmers to be able to override these *recommendations* as long as they don't violate the actual processor *requirements*.  File: g77.info, Node: More Extensions, Next: Machine Model, Prev: Simplify Porting, Up: Projects More Extensions =============== These extensions are not the sort of things users ask for "by name", but they might improve the usability of `g77', and Fortran in general, in the long run. Some of these items really pertain to improving `g77' internals so that some popular extensions can be more easily supported. * Look through all the documentation on the GNU Fortran language, dialects, compiler, missing features, bugs, and so on. Many mentions of incomplete or missing features are sprinkled throughout. It is not worth repeating them here. * Support arbitrary operands for concatenation, even in contexts where run-time allocation is required. * Consider adding a `NUMERIC' type to designate typeless numeric constants, named and unnamed. The idea is to provide a forward-looking, effective replacement for things like the old-style `PARAMETER' statement when people really need typelessness in a maintainable, portable, clearly documented way. Maybe `TYPELESS' would include `CHARACTER', `POINTER', and whatever else might come along. (This is not really a call for polymorphism per se, just an ability to express limited, syntactic polymorphism.) * Support `OPEN(...,KEY=(...),...)'. * Support arbitrary file unit numbers, instead of limiting them to 0 through `MXUNIT-1'. (This is a `libf2c' issue.) * `OPEN(NOSPANBLOCKS,...)' is treated as `OPEN(UNIT=NOSPANBLOCKS,...)', so a later `UNIT=' in the first example is invalid. Make sure this is what users of this feature would expect. * Currently `g77' disallows `READ(1'10)' since it is an obnoxious syntax, but supporting it might be pretty easy if needed. More details are needed, such as whether general expressions separated by an apostrophe are supported, or maybe the record number can be a general expression, and so on. * Support `STRUCTURE', `UNION', `MAP', and `RECORD' fully. Currently there is no support at all for `%FILL' in `STRUCTURE' and related syntax, whereas the rest of the stuff has at least some parsing support. This requires either major changes to `libf2c' or its replacement. * F90 and `g77' probably disagree about label scoping relative to `INTERFACE' and `END INTERFACE', and their contained procedure interface bodies (blocks?). * `ENTRY' doesn't support F90 `RESULT()' yet, since that was added after S8.112. * Empty-statement handling (10 ;;CONTINUE;;) probably isn't consistent with the final form of the standard (it was vague at S8.112). * It seems to be an "open" question whether a file, immediately after being `OPEN'ed,is positioned at the beginning, the end, or wherever--it might be nice to offer an option of opening to "undefined" status, requiring an explicit absolute-positioning operation to be performed before any other (besides `CLOSE') to assist in making applications port to systems (some IBM?) that `OPEN' to the end of a file or some such thing.  File: g77.info, Node: Machine Model, Next: Internals Documentation, Prev: More Extensions, Up: Projects Machine Model ============= This items pertain to generalizing `g77''s view of the machine model to more fully accept whatever the GBE provides it via its configuration. * Switch to using `REAL_VALUE_TYPE' to represent floating-point constants exclusively so the target float format need not be required. This means changing the way `g77' handles initialization of aggregate areas having more than one type, such as `REAL' and `INTEGER', because currently it initializes them as if they were arrays of `char' and uses the bit patterns of the constants of the various types in them to determine what to stuff in elements of the arrays. * Rely more and more on back-end info and capabilities, especially in the area of constants (where having the `g77' front-end's IL just store the appropriate tree nodes containing constants might be best). * Suite of C and Fortran programs that a user/administrator can run on a machine to help determine the configuration for `g77' before building and help determine if the compiler works (especially with whatever libraries are installed) after building.  File: g77.info, Node: Internals Documentation, Next: Internals Improvements, Prev: Machine Model, Up: Projects Internals Documentation ======================= Better info on how `g77' works and how to port it is needed. Much of this should be done only after the redesign planned for 0.6 is complete.  File: g77.info, Node: Internals Improvements, Next: Better Diagnostics, Prev: Internals Documentation, Up: Projects Internals Improvements ====================== Some more items that would make `g77' more reliable and easier to maintain: * Generally make expression handling focus more on critical syntax stuff, leaving semantics to callers. For example, anything a caller can check, semantically, let it do so, rather than having `expr.c' do it. (Exceptions might include things like diagnosing `FOO(I--K:)=BAR' where `FOO' is a `PARAMETER'--if it seems important to preserve the left-to-right-in-source order of production of diagnostics.) * Come up with better naming conventions for `-D' to establish requirements to achieve desired implementation dialect via `proj.h'. * Clean up used tokens and `ffewhere's in `ffeglobal_terminate_1'. * Replace `sta.c' `outpooldisp' mechanism with `malloc_pool_use'. * Check for `opANY' in more places in `com.c', `std.c', and `ste.c', and get rid of the `opCONVERT(opANY)' kludge (after determining if there is indeed no real need for it). * Utility to read and check `bad.def' messages and their references in the code, to make sure calls are consistent with message templates. * Search and fix `&ffe...' and similar so that `ffe...ptr...' macros are available instead (a good argument for wishing this could have written all this stuff in C++, perhaps). On the other hand, it's questionable whether this sort of improvement is really necessary, given the availability of tools such as Emacs and Perl, which make finding any address-taking of structure members easy enough? * Some modules truly export the member names of their structures (and the structures themselves), maybe fix this, and fix other modules that just appear to as well (by appending `_', though it'd be ugly and probably not worth the time). * Implement C macros `RETURNS(value)' and `SETS(something,value)' in `proj.h' and use them throughout `g77' source code (especially in the definitions of access macros in `.h' files) so they can be tailored to catch code writing into a `RETURNS()' or reading from a `SETS()'. * Decorate throughout with `const' and other such stuff. * All F90 notational derivations in the source code are still based on the S8.112 version of the draft standard. Probably should update to the official standard, or put documentation of the rules as used in the code...uh...in the code. * Some `ffebld_new' calls (those outside of `ffeexpr.c' or inside but invoked via paths not involving `ffeexpr_lhs' or `ffeexpr_rhs') might be creating things in improper pools, leading to such things staying around too long or (doubtful, but possible and dangerous) not long enough. * Some `ffebld_list_new' (or whatever) calls might not be matched by `ffebld_list_bottom' (or whatever) calls, which might someday matter. (It definitely is not a problem just yet.) * Probably not doing clean things when we fail to `EQUIVALENCE' something due to alignment/mismatch or other problems--they end up without `ffestorag' objects, so maybe the backend (and other parts of the front end) can notice that and handle like an `opANY' (do what it wants, just don't complain or crash). Most of this seems to have been addressed by now, but a code review wouldn't hurt.  File: g77.info, Node: Better Diagnostics, Prev: Internals Improvements, Up: Projects Better Diagnostics ================== These are things users might not ask about, or that need to be looked into, before worrying about. Also here are items that involve reducing unnecessary diagnostic clutter. * When `FUNCTION' and `ENTRY' point types disagree (`CHARACTER' lengths, type classes, and so on), `ANY'-ize the offending `ENTRY' point and any *new* dummies it specifies. * Speed up and improve error handling for data when repeat-count is specified. For example, don't output 20 unnecessary messages after the first necessary one for: INTEGER X(20) CONTINUE DATA (X(I), J= 1, 20) /20*5/ END (The `CONTINUE' statement ensures the `DATA' statement is processed in the context of executable, not specification, statements.)  File: g77.info, Node: Diagnostics, Next: Index, Prev: Projects, Up: Top Diagnostics *********** Some diagnostics produced by `g77' require sufficient explanation that the explanations are given below, and the diagnostics themselves identify the appropriate explanation. Identification uses the GNU Info format--specifically, the `info' command that displays the explanation is given within square brackets in the diagnostic. For example: foo.f:5: Invalid statement [info -f g77 M FOOEY] More details about the above diagnostic is found in the `g77' Info documentation, menu item `M', submenu item `FOOEY', which is displayed by typing the UNIX command `info -f g77 M FOOEY'. Other Info readers, such as EMACS, may be just as easily used to display the pertinent node. In the above example, `g77' is the Info document name, `M' is the top-level menu item to select, and, in that node (named `Diagnostics', the name of this chapter, which is the very text you're reading now), `FOOEY' is the menu item to select. * Menu: * CMPAMBIG:: Ambiguous use of intrinsic. * EXPIMP:: Intrinsic used explicitly and implicitly. * INTGLOB:: Intrinsic also used as name of global. * LEX:: Various lexer messages * GLOBALS:: Disagreements about globals.