this problem by simply offering the appropriate feature to users of the
respective systems. This approach treats users of various Fortran
systems and dialects as remote "islands", or camps, of programmers, and
assume that these camps rarely come into contact with each other (or,
especially, with each other's code).
Project GNU takes a radically different approach to software and
language design, in that it assumes that users of GNU software do not
necessarily care what kind of underlying system they are using,
regardless of whether they are using software (at the user-interface
level) or writing it (for example, writing Fortran or C code).
As such, GNU users rarely need consider just what kind of underlying
hardware (or, in many cases, operating system) they are using at any
particular time. They can use and write software designed for a
general-purpose, widely portable, heteregenous environment--the GNU
environment.
In line with this philosophy, GNU Fortran must evolve into a product
that is widely ported and portable not only in the sense that it can be
successfully built, installed, and run by users, but in the larger
sense that its users can use it in the same way, and expect largely the
same behaviors from it, regardless of the kind of system they are using
at any particular time.
This approach constrains the solutions `g77' can use to resolve
conflicts between various camps of Fortran users. If these two camps
disagree about what a particular construct should mean, `g77' cannot
simply be changed to treat that particular construct as having one
meaning without comment (such as a warning), lest the users expecting
it to have the other meaning are unpleasantly surprised that their code
misbehaves when executed.
The use of the ASCII backslash character in character constants is
an excellent (and still somewhat unresolved) example of this kind of
controversy. *Note Backslash in Constants::. Other examples are
likely to arise in the future, as `g77' developers strive to improve
its ability to accept an ever-wider variety of existing Fortran code
without requiring significant modifications to said code.
Development of GNU Fortran is further constrained by the desire to
avoid requiring programmers to change their code. This is important
because it allows programmers, administrators, and others to more
faithfully evaluate and validate `g77' (as an overall product and as
new versions are distributed) without having to support multiple
versions of their programs so that they continue to work the same way
on their existing systems (non-GNU perhaps, but possibly also earlier
versions of `g77').
File: g77.info, Node: Standard Support, Next: Conformance, Prev: Direction of Language Development, Up: Language
ANSI FORTRAN 77 Standard Support
================================
GNU Fortran supports ANSI FORTRAN 77 with the following caveats. In
summary, the only ANSI FORTRAN 77 features `g77' doesn't support are
those that are probably rarely used in actual code, some of which are
explicitly disallowed by the Fortran 90 standard.
* Menu:
* No Passing External Assumed-length:: CHAR*(*) CFUNC restriction.
* No Passing Dummy Assumed-length:: CHAR*(*) CFUNC restriction.
* No Pathological Implied-DO:: No `((..., I=...), I=...)'.
* No Useless Implied-DO:: No `(A, I=1, 1)'.
File: g77.info, Node: No Passing External Assumed-length, Next: No Passing Dummy Assumed-length, Up: Standard Support
No Passing External Assumed-length
----------------------------------
`g77' disallows passing of an external procedure as an actual
argument if the procedure's type is declared `CHARACTER*(*)'. For
example:
CHARACTER*(*) CFUNC
EXTERNAL CFUNC
CALL FOO(CFUNC)
END
It isn't clear whether the standard considers this conforming.
File: g77.info, Node: No Passing Dummy Assumed-length, Next: No Pathological Implied-DO, Prev: No Passing External Assumed-length, Up: Standard Support
No Passing Dummy Assumed-length
-------------------------------
`g77' disallows passing of a dummy procedure as an actual argument
if the procedure's type is declared `CHARACTER*(*)'.
SUBROUTINE BAR(CFUNC)
CHARACTER*(*) CFUNC
EXTERNAL CFUNC
CALL FOO(CFUNC)
END
It isn't clear whether the standard considers this conforming.
File: g77.info, Node: No Pathological Implied-DO, Next: No Useless Implied-DO, Prev: No Passing Dummy Assumed-length, Up: Standard Support
No Pathological Implied-DO
--------------------------
The `DO' variable for an implied-`DO' construct in a `DATA'
statement may not be used as the `DO' variable for an outer
implied-`DO' construct. For example, this fragment is disallowed by
`g77':
DATA ((A(I, I), I= 1, 10), I= 1, 10) /.../
This also is disallowed by Fortran 90, as it offers no additional
capabilities and would have a variety of possible meanings.
Note that it is *very* unlikely that any production Fortran code
tries to use this unsupported construct.
File: g77.info, Node: No Useless Implied-DO, Prev: No Pathological Implied-DO, Up: Standard Support
No Useless Implied-DO
---------------------
An array element initializer in an implied-`DO' construct in a
`DATA' statement must contain at least one reference to the `DO'
variables of each outer implied-`DO' construct. For example, this
fragment is disallowed by `g77':
DATA (A, I= 1, 1) /1./
This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
requirements offer no additional capabilities. However, `g77' doesn't
necessarily diagnose all cases where this requirement is not met.
Note that it is *very* unlikely that any production Fortran code
tries to use this unsupported construct.
File: g77.info, Node: Conformance, Next: Notation Used, Prev: Standard Support, Up: Language
Conformance
===========
(The following information augments or overrides the information in
Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language. Chapter 1 of that document otherwise serves as the basis for
the relevant aspects of GNU Fortran.)
The definition of the GNU Fortran language is akin to that of the
ANSI FORTRAN 77 language in that it does not generally require
conforming implementations to diagnose cases where programs do not
conform to the language.
However, `g77' as a compiler is being developed in a way that is
intended to enable it to diagnose such cases in an easy-to-understand
manner.
A program that conforms to the GNU Fortran language should, when
compiled, linked, and executed using a properly installed `g77' system,
perform as described by the GNU Fortran language definition. Reasons
for different behavior include, among others:
* Use of resources (memory--heap, stack, and so on; disk space; CPU
time; etc.) exceeds those of the system.
* Range and/or precision of calculations required by the program
exceeds that of the system.
* Excessive reliance on behaviors that are system-dependent
(non-portable Fortran code).
* Bugs in the program.
* Bug in `g77'.
* Bugs in the system.
Despite these "loopholes", the availability of a clear specification
of the language of programs submitted to `g77', as this document is
intended to provide, is considered an important aspect of providing a
The `gcc' backend and, consequently, `g77', currently provides no
control over whether or not floating-point exceptions are trapped or
ignored. (Ignoring them typically results in NaN values being
propagated in systems that conform to IEEE 754.) The behaviour is
inherited from the system-dependent startup code.
Most systems provide some C-callable mechanism to change this; this
can be invoked at startup using `gcc''s `constructor' attribute. For
example, just compiling and linking the following C code with your
program will turn on exception trapping for the "common" exceptions on
an x86-based GNU system:
#include <fpu_control.h>
void __attribute__ ((constructor))
trapfpe () {
(void) __setfpucw (_FPU_DEFAULT &
~(_FPU_MASK_IM | _FPU_MASK_ZM | _FPU_MASK_OM));
}
File: g77.info, Node: Nonportable Conversions, Next: Large Automatic Arrays, Prev: Floating-point Exception Handling, Up: Missing Features
Nonportable Conversions
-----------------------
`g77' doesn't accept some particularly nonportable, silent data-type
conversions such as `LOGICAL' to `REAL' (as in `A=.FALSE.', where `A'
is type `REAL'), that other compilers might quietly accept.
Some of these conversions are accepted by `g77' when the `-fugly'
option is specified. Perhaps it should accept more or all of them.
File: g77.info, Node: Large Automatic Arrays, Next: Support for Threads, Prev: Nonportable Conversions, Up: Missing Features
Large Automatic Arrays
----------------------
Currently, automatic arrays always are allocated on the stack. For
situations where the stack cannot be made large enough, `g77' should
offer a compiler option that specifies allocation of automatic arrays
in heap storage.
File: g77.info, Node: Support for Threads, Next: Increasing Precision/Range, Prev: Large Automatic Arrays, Up: Missing Features
Support for Threads
-------------------
Neither the code produced by `g77' nor the `libf2c' library are
thread-safe, nor does `g77' have support for parallel processing (other
than the instruction-level parallelism available on some processors).
A package such as PVM might help here.
File: g77.info, Node: Gracefully Handle Sensible Bad Code, Next: Non-standard Conversions, Prev: Increasing Precision/Range, Up: Missing Features
Gracefully Handle Sensible Bad Code
-----------------------------------
`g77' generally should continue processing for warnings and
recoverable (user) errors whenever possible--that is, it shouldn't
gratuitously make bad or useless code.
For example:
INTRINSIC ZABS
CALL FOO(ZABS)
END
When compiling the above with `-ff2c-intrinsics-disable', `g77' should
indeed complain about passing `ZABS', but it still should compile,
instead of rejecting the entire `CALL' statement. (Some of this is
related to improving the compiler internals to improve how statements
are analyzed.)
File: g77.info, Node: Non-standard Conversions, Next: Non-standard Intrinsics, Prev: Gracefully Handle Sensible Bad Code, Up: Missing Features
Non-standard Conversions
------------------------
`-Wconversion' and related should flag places where non-standard
conversions are found. Perhaps much of this would be part of `-Wugly*'.
File: g77.info, Node: Non-standard Intrinsics, Next: Modifying DO Variable, Prev: Non-standard Conversions, Up: Missing Features
Non-standard Intrinsics
-----------------------
`g77' needs a new option, like `-Wintrinsics', to warn about use of
non-standard intrinsics without explicit `INTRINSIC' statements for
them. This would help find code that might fail silently when ported
to another compiler.
File: g77.info, Node: Modifying DO Variable, Next: Better Pedantic Compilation, Prev: Non-standard Intrinsics, Up: Missing Features
Modifying `DO' Variable
-----------------------
`g77' should warn about modifying `DO' variables via `EQUIVALENCE'.
(The internal information gathered to produce this warning might also
be useful in setting the internal "doiter" flag for a variable or even
array reference within a loop, since that might produce faster code
someday.)
For example, this code is invalid, so `g77' should warn about the
invalid assignment to `NOTHER':
EQUIVALENCE (I, NOTHER)
DO I = 1, 100
IF (I.EQ. 10) NOTHER = 20
END DO
File: g77.info, Node: Better Pedantic Compilation, Next: Warn About Implicit Conversions, Prev: Modifying DO Variable, Up: Missing Features
Better Pedantic Compilation
---------------------------
`g77' needs to support `-fpedantic' more thoroughly, and use it only
to generate warnings instead of rejecting constructs outright. Have it
warn: if a variable that dimensions an array is not a dummy or placed
explicitly in `COMMON' (F77 does not allow it to be placed in `COMMON'
via `EQUIVALENCE'); if specification statements follow
statement-function-definition statements; about all sorts of syntactic
extensions.
File: g77.info, Node: Warn About Implicit Conversions, Next: Invalid Use of Hollerith Constant, Prev: Better Pedantic Compilation, Up: Missing Features
Warn About Implicit Conversions
-------------------------------
`g77' needs a `-Wpromotions' option to warn if source code appears
to expect automatic, silent, and somewhat dangerous compiler-assisted
conversion of `REAL(KIND=1)' constants to `REAL(KIND=2)' based on
context.
For example, it would warn about cases like this:
DOUBLE PRECISION FOO
PARAMETER (TZPHI = 9.435784839284958)
FOO = TZPHI * 3D0
File: g77.info, Node: Invalid Use of Hollerith Constant, Next: Dummy Array Without Dimensioning Dummy, Prev: Warn About Implicit Conversions, Up: Missing Features
Invalid Use of Hollerith Constant
---------------------------------
`g77' should disallow statements like `RETURN 2HAB', which are
invalid in both source forms (unlike `RETURN (2HAB)', which probably
still makes no sense but at least can be reliably parsed). Fixed-form
processing rejects it, but not free-form, except in a way that is a bit
difficult to understand.
File: g77.info, Node: Dummy Array Without Dimensioning Dummy, Next: Invalid FORMAT Specifiers, Prev: Invalid Use of Hollerith Constant, Up: Missing Features
Dummy Array Without Dimensioning Dummy
--------------------------------------
`g77' should complain when a list of dummy arguments containing an
adjustable dummy array does not also contain every variable listed in
the dimension list of the adjustable array.
Currently, `g77' does complain about a variable that dimensions an
array but doesn't appear in any dummy list or `COMMON' area, but this
needs to be extended to catch cases where it doesn't appear in every
dummy list that also lists any arrays it dimensions.
For example, `g77' should warn about the entry point `ALT' below,
since it includes `ARRAY' but not `ISIZE' in its list of arguments:
SUBROUTINE PRIMARY(ARRAY, ISIZE)
REAL ARRAY(ISIZE)
ENTRY ALT(ARRAY)
File: g77.info, Node: Invalid FORMAT Specifiers, Next: Ambiguous Dialects, Prev: Dummy Array Without Dimensioning Dummy, Up: Missing Features
Invalid FORMAT Specifiers
-------------------------
`g77' should check `FORMAT' specifiers for validity as it does
(.txt)