aboutsummaryrefslogtreecommitdiff
path: root/gcc/f/g77.texi
diff options
context:
space:
mode:
Diffstat (limited to 'gcc/f/g77.texi')
-rw-r--r--gcc/f/g77.texi210
1 files changed, 169 insertions, 41 deletions
diff --git a/gcc/f/g77.texi b/gcc/f/g77.texi
index 25070dbd5f8..eaab2543e6b 100644
--- a/gcc/f/g77.texi
+++ b/gcc/f/g77.texi
@@ -2,7 +2,7 @@
@c %**start of header
@setfilename g77.info
-@set last-update 1999-05-13
+@set last-update 1999-06-06
@set copyrights-g77 1995-1999
@include root.texi
@@ -1471,7 +1471,7 @@ by type. Explanations are in the following sections.
-falias-check -fargument-alias
-fargument-noalias -fno-argument-noalias-global
-fno-globals -fflatten-arrays
--fsubscript-check -ff2c-subscript-check
+-fbounds-check -ffortran-bounds-check
@end smallexample
@end table
@@ -3386,10 +3386,10 @@ It is intended for use only by @code{g77} developers,
to evaluate code-generation issues.
It might be removed at any time.
-@cindex -fsubscript-check option
-@cindex -ff2c-subscript-check option
-@item -fsubscript-check
-@itemx -ff2c-subscript-check
+@cindex -fbounds-check option
+@cindex -ffortran-bounds-check option
+@item -fbounds-check
+@itemx -ffortran-bounds-check
@cindex bounds checking
@cindex range checking
@cindex array bounds checking
@@ -3414,12 +3414,12 @@ such as references to below the beginning of an assumed-size array.
@code{g77} also generates checks for @code{CHARACTER} substring references,
something @code{f2c} currently does not do.
-Since a future version of @code{g77} might use a different implementation,
-use the new @samp{-ff2c-subscript-check} option
-if your application requires use of @code{s_rnge} or a compile-time diagnostic.
+Use the new @samp{-ffortran-bounds-check} option
+to specify bounds-checking for only the Fortran code you are compiling,
+not necessarily for code written in other languages.
@emph{Note:} To provide more detailed information on the offending subscript,
-@code{g77} provides @code{s_rnge}
+@code{g77} provides the @code{libg2c} run-time library routine @code{s_rnge}
with somewhat differently-formatted information.
Here's a sample diagnostic:
@@ -4243,7 +4243,7 @@ stream-based text file is translated to GNU Fortran lines as follows:
A newline in the file is the character that represents the end of
a line of text to the underlying system.
For example, on ASCII-based systems, a newline is the @key{NL}
-character, which has ASCII value 12 (decimal).
+character, which has ASCII value 10 (decimal).
@item
Each newline in the file serves to end the line of text that precedes
@@ -10774,30 +10774,25 @@ compiler, typically @code{gcc}.)
@node Use Submodel Options
@subsection Use Submodel Options
-@cindex Pentium optimizations
-@cindex optimization, for Pentium
-@cindex 586/686 CPUs
@cindex submodels
Using an appropriate @samp{-m} option to generate specific code for your
CPU may be worthwhile, though it may mean the executable won't run on
other versions of the CPU that don't support the same instruction set.
@xref{Submodel Options,,Hardware Models and Configurations,gcc,Using and
-Porting GNU CC}.
+Porting GNU CC}. For instance on an x86 system the compiler might have
+been built---as shown by @samp{g77 -v}---for the target
+@samp{i386-pc-linux-gnu}, i.e.@: an @samp{i386} CPU@. In that case to
+generate code best optimized for a Pentium you could use the option
+@samp{-march=pentium}.
-For recent CPUs that don't have explicit support in
-the released version of @code{gcc}, it may still be possible to get
-improvements.
-For instance, the flags recommended for 586/686
-(Pentium(Pro)) chips for building the Linux kernel are:
+For recent CPUs that don't have explicit support in the released version
+of @code{gcc}, it @emph{might} still be possible to get improvements
+with certain @samp{-m} options.
-@smallexample
--m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2
--fomit-frame-pointer
-@end smallexample
-
-@noindent @samp{-fomit-frame-pointer} will, however, inhibit debugging
-on x86 systems.
+@samp{-fomit-frame-pointer} can help performance on x86 systems and
+others. It will, however, inhibit debugging on the systems on which it
+is not turned on anyway by @samp{-O}.
@node Trouble
@chapter Known Causes of Trouble with GNU Fortran
@@ -10926,7 +10921,7 @@ How to cope with such problems is well beyond the scope
of this manual.
However, users of Linux-based systems (such as GNU/Linux)
-should review @uref{http://www.bitwizard.nl/sig11}, a source
+should review @uref{http://www.bitwizard.nl/sig11/}, a source
of detailed information on diagnosing hardware problems,
by recognizing their common symptoms.
@@ -11178,7 +11173,7 @@ themselves as @emph{visible} problems some time later.
Overflowing the bounds of an array---usually by writing beyond
the end of it---is one of two kinds of bug that often occurs
in Fortran code.
-(Compile your code with the @samp{-fsubscript-check} option
+(Compile your code with the @samp{-fbounds-check} option
to catch many of these kinds of errors at program run time.)
The other kind of bug is a mismatch between the actual arguments
@@ -11340,13 +11335,13 @@ Goldberg, `What Every Computer Scientist Should Know About
Floating-Point Arithmetic', Computing Surveys, 23, March 1991, pp.@:
5-48.
An online version is available at
-@uref{http://docs.sun.com},
+@uref{http://docs.sun.com/},
and there is a supplemented version, in PostScript form, at
@uref{http://www.validgh.com/goldberg/paper.ps}.
Information related to the IEEE 754
floating-point standard by a leading light can be found at
-@uref{http://http.cs.berkeley.edu/%7Ewkahan/ieee754status};
+@uref{http://http.cs.berkeley.edu/%7Ewkahan/ieee754status/};
see also slides from the short course referenced from
@uref{http://http.cs.berkeley.edu/%7Efateman/}.
@uref{http://www.linuxsupportline.com/%7Ebillm/} has a brief
@@ -11418,6 +11413,7 @@ GNU Fortran dialects:
* Suppressing Space Padding::
* Fortran Preprocessor::
* Bit Operations on Floating-point Data::
+* Really Ugly Character Assignments::
New facilities:
* POSIX Standard::
@@ -11426,8 +11422,10 @@ New facilities:
* Large Automatic Arrays::
* Support for Threads::
* Increasing Precision/Range::
+* Enabling Debug Lines::
Better diagnostics:
+* Better Warnings::
* Gracefully Handle Sensible Bad Code::
* Non-standard Conversions::
* Non-standard Intrinsics::
@@ -11444,6 +11442,8 @@ Better diagnostics:
Run-time facilities:
* Uninitialized Variables at Run Time::
* Portable Unformatted Files::
+* Better List-directed I/O::
+* Default to Console I/O::
Debugging:
* Labels Visible to Debugger::
@@ -12094,6 +12094,24 @@ PRINT *, IAND(A, B)
END
@end smallexample
+@node Really Ugly Character Assignments
+@subsection Really Ugly Character Assignments
+
+An option such as @samp{-fugly-char} should be provided
+to allow
+
+@smallexample
+REAL*8 A1
+DATA A1 / '12345678' /
+@end smallexample
+
+and:
+
+@smallexample
+REAL*8 A1
+A1 = 'ABCDEFGH'
+@end smallexample
+
@node POSIX Standard
@subsection @code{POSIX} Standard
@@ -12174,6 +12192,73 @@ are thread-safe, nor does @code{g77} have support for parallel processing
processors).
A package such as PVM might help here.
+@node Enabling Debug Lines
+@subsection Enabling Debug Lines
+@cindex debug line
+@cindex comment line, debug
+
+An option such as @samp{-fdebug-lines} should be provided
+to turn fixed-form lines beginning with @samp{D}
+to be treated as if they began with a space,
+instead of as if they began with a @samp{C}
+(as comment lines).
+
+@node Better Warnings
+@subsection Better Warnings
+
+Because of how @code{g77} generates code via the back end,
+it doesn't always provide warnings the user wants.
+Consider:
+
+@smallexample
+PROGRAM X
+PRINT *, A
+END
+@end smallexample
+
+Currently, the above is not flagged as a case of
+using an uninitialized variable,
+because @code{g77} generates a run-time library call that looks,
+to the GBE, like it might actually @emph{modify} @samp{A} at run time.
+(And, in fact, depending on the previous run-time library call,
+it would!)
+
+Fixing this requires one of the following:
+
+@itemize @bullet
+@item
+Switch to new library, @code{libg77}, that provides
+a more ``clean'' interface,
+vis-a-vis input, output, and modified arguments,
+so the GBE can tell what's going on.
+
+This would provide a pretty big performance improvement,
+at least theoretically, and, ultimately, in practice,
+for some types of code.
+
+@item
+Have @code{g77} pass a pointer to a temporary
+containing a copy of @samp{A},
+instead of to @samp{A} itself.
+The GBE would then complain about the copy operation
+involving a potentially uninitialized variable.
+
+This might also provide a performance boost for some code,
+because @samp{A} might then end up living in a register,
+which could help with inner loops.
+
+@item
+Have @code{g77} use a GBE construct similar to @code{ADDR_EXPR}
+but with extra information on the fact that the
+item pointed to won't be modified
+(a la @code{const} in C).
+
+Probably the best solution for now, but not quite trivial
+to implement in the general case.
+Worth considering after @code{g77} 0.6 is considered
+pretty solid.
+@end itemize
+
@node Gracefully Handle Sensible Bad Code
@subsection Gracefully Handle Sensible Bad Code
@@ -12413,6 +12498,49 @@ only incur overhead when they are read on a system with a different
format.) A future @code{g77} runtime library should use such
techniques.
+@node Better List-directed I/O
+@subsection Better List-directed I/O
+
+Values output using list-directed I/O
+(@samp{PRINT *, R, D})
+should be written with a field width, precision, and so on
+appropriate for the type (precision) of each value.
+
+(Currently, no distinction is made between single-precision
+and double-precision values
+by @code{libf2c}.)
+
+It is likely this item will require the @code{libg77} project
+to be undertaken.
+
+In the meantime, use of formatted I/O is recommended.
+While it might be of little consolation,
+@code{g77} does support @samp{FORMAT(F<WIDTH>.4)}, for example,
+as long as @samp{WIDTH} is defined as a named constant
+(via @code{PARAMETER}).
+That at least allows some compile-time specification
+of the precision of a data type,
+perhaps controlled by preprocessing directives.
+
+@node Default to Console I/O
+@subsection Default to Console I/O
+
+The default I/O units,
+specified by @samp{READ @var{fmt}},
+@samp{READ (UNIT=*)},
+@samp{WRITE (UNIT=*)}, and
+@samp{PRINT @var{fmt}},
+should not be units 5 (input) and 6 (output),
+but, rather, unit numbers not normally available
+for use in statements such as @code{OPEN} and @code{CLOSE}.
+
+Changing this would allow a program to connect units 5 and 6
+to files via @code{OPEN},
+but still use @samp{READ (UNIT=*)} and @samp{PRINT}
+to do I/O to the ``console''.
+
+This change probably requires the @code{libg77} project.
+
@node Labels Visible to Debugger
@subsection Labels Visible to Debugger
@@ -13808,8 +13936,16 @@ the source code of @code{g77} and rebuilding.
How to do this depends on the version of @code{g77}:
@table @code
-@item EGCS-1.0
-@itemx FSF
+@item G77 0.5.24 (EGCS 1.1)
+@itemx G77 0.5.25 (EGCS 1.2)
+Change the @code{lang_init_options} routine in @file{egcs/gcc/f/com.c}.
+
+(Note that these versions of @code{g77}
+perform internal consistency checking automatically
+when the @samp{-fversion} option is specified.)
+
+@item G77 0.5.23
+@itemx G77 0.5.24 (EGCS 1.0)
Change the way @code{f771} handles the @samp{-fset-g77-defaults}
option, which is always provided as the first option when
called by @code{g77} or @code{gcc}.
@@ -13833,14 +13969,6 @@ It is in @file{@value{path-g77}/lang-specs.h} that @samp{-fset-g77-defaults},
even when the user has not explicitly specified them.
Other ``internal'' options such as @samp{-quiet} also
are passed via this mechanism.
-
-@item EGCS-1.1
-@itemx EGCS-1.2
-Change the @code{lang_init_options} routine in @file{egcs/gcc/f/com.c}.
-
-(Note that these versions of @code{g77}
-perform internal consistency checking automatically
-when the @samp{-fversion} option is specified.)
@end table
@node Projects