1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
|
*Note:* This file is automatically generated from the files
`bugs0.texi' and `bugs.texi'. `BUGS' is *not* a source file, although
it is normally included within source distributions.
This file lists known bugs in the EGCS-1.2 version of the GNU
Fortran compiler. Copyright (C) 1995-1999 Free Software Foundation,
Inc. You may copy, distribute, and modify it freely as long as you
preserve this copyright notice and permission notice.
Known Bugs In GNU Fortran
*************************
This section identifies bugs that `g77' *users* might run into in
the EGCS-1.2 version of `g77'. This includes bugs that are actually in
the `gcc' back end (GBE) or in `libf2c', because those sets of code are
at least somewhat under the control of (and necessarily intertwined
with) `g77', so it isn't worth separating them out.
For information on bugs in *other* versions of `g77', see
`egcs/gcc/f/NEWS'. There, lists of bugs fixed in various versions of
`g77' can help determine what bugs existed in prior versions.
*Warning:* The information below is still under development, and
might not accurately reflect the `g77' code base of which it is a part.
Efforts are made to keep it somewhat up-to-date, but they are
particularly concentrated on any version of this information that is
distributed as part of a *released* `g77'.
In particular, while this information is intended to apply to the
EGCS-1.2 version of `g77', only an official *release* of that version
is expected to contain documentation that is most consistent with the
`g77' product in that version.
An online, "live" version of this document (derived directly from
the mainline, development version of `g77' within `egcs') is available
via `http://egcs.cygnus.com/onlinedocs/g77_bugs.html'. Follow the
"Known Bugs" link.
For information on bugs that might afflict people who configure,
port, build, and install `g77', see "Problems Installing" in
`egcs/gcc/f/INSTALL'.
The following information was last updated on 1999-03-15:
* Automatic arrays possibly aren't working on HP-UX systems, at
least in HP-UX version 10.20. Writing into them apparently causes
over-writing of statically declared data in the main program.
This probably means the arrays themselves are being
under-allocated, or pointers to them being improperly handled,
e.g. not passed to other procedures as they should be.
* `g77' fails to warn about use of a "live" iterative-DO variable as
an implied-DO variable in a `WRITE' or `PRINT' statement (although
it does warn about this in a `READ' statement).
* Something about `g77''s straightforward handling of label
references and definitions sometimes prevents the GBE from
unrolling loops. Until this is solved, try inserting or removing
`CONTINUE' statements as the terminal statement, using the `END DO'
form instead, and so on.
* Some confusion in diagnostics concerning failing `INCLUDE'
statements from within `INCLUDE''d or `#include''d files.
* `g77' assumes that `INTEGER(KIND=1)' constants range from `-2**31'
to `2**31-1' (the range for two's-complement 32-bit values),
instead of determining their range from the actual range of the
type for the configuration (and, someday, for the constant).
Further, it generally doesn't implement the handling of constants
very well in that it makes assumptions about the configuration
that it no longer makes regarding variables (types).
Included with this item is the fact that `g77' doesn't recognize
that, on IEEE-754/854-compliant systems, `0./0.' should produce a
NaN and no warning instead of the value `0.' and a warning. This
is to be fixed in version 0.6, when `g77' will use the `gcc' back
end's constant-handling mechanisms to replace its own.
* `g77' uses way too much memory and CPU time to process large
aggregate areas having any initialized elements.
For example, `REAL A(1000000)' followed by `DATA A(1)/1/' takes up
way too much time and space, including the size of the generated
assembler file. This is to be mitigated somewhat in version 0.6.
Version 0.5.18 improves cases like this--specifically, cases of
*sparse* initialization that leave large, contiguous areas
uninitialized--significantly. However, even with the
improvements, these cases still require too much memory and CPU
time.
(Version 0.5.18 also improves cases where the initial values are
zero to a much greater degree, so if the above example ends with
`DATA A(1)/0/', the compile-time performance will be about as good
as it will ever get, aside from unrelated improvements to the
compiler.)
Note that `g77' does display a warning message to notify the user
before the compiler appears to hang.
* `g77' doesn't emit variable and array members of common blocks for
use with a debugger (the `-g' command-line option). The code is
present to do this, but doesn't work with at least one debug
format--perhaps it works with others. And it turns out there's a
similar bug for local equivalence areas, so that has been disabled
as well.
As of Version 0.5.19, a temporary kludge solution is provided
whereby some rudimentary information on a member is written as a
string that is the member's value as a character string.
* When debugging, after starting up the debugger but before being
able to see the source code for the main program unit, the user
must currently set a breakpoint at `MAIN__' (or `MAIN___' or
`MAIN_' if `MAIN__' doesn't exist) and run the program until it
hits the breakpoint. At that point, the main program unit is
activated and about to execute its first executable statement, but
that's the state in which the debugger should start up, as is the
case for languages like C.
* Debugging `g77'-compiled code using debuggers other than `gdb' is
likely not to work.
Getting `g77' and `gdb' to work together is a known
problem--getting `g77' to work properly with other debuggers, for
which source code often is unavailable to `g77' developers, seems
like a much larger, unknown problem, and is a lower priority than
making `g77' and `gdb' work together properly.
On the other hand, information about problems other debuggers have
with `g77' output might make it easier to properly fix `g77', and
perhaps even improve `gdb', so it is definitely welcome. Such
information might even lead to all relevant products working
together properly sooner.
* `g77' doesn't work perfectly on 64-bit configurations such as the
Digital Semiconductor ("DEC") Alpha.
This problem is largely resolved as of version 0.5.23. Version
0.6 should solve most or all remaining problems (such as
cross-compiling involving 64-bit machines).
* Maintainers of `gcc' report that the back end definitely has
"broken" support for `COMPLEX' types. Based on their input, it
seems many of the problems affect only the more-general facilities
for gcc's `__complex__' type, such as `__complex__ int' (where the
real and imaginary parts are integers) that GNU Fortran does not
use.
Version 0.5.20 of `g77' works around this problem by not using the
back end's support for `COMPLEX'. The new option
`-fno-emulate-complex' avoids the work-around, reverting to using
the same "broken" mechanism as that used by versions of `g77'
prior to 0.5.20.
* `g77' currently inserts needless padding for things like `COMMON
A,IPAD' where `A' is `CHARACTER*1' and `IPAD' is `INTEGER(KIND=1)'
on machines like x86, because the back end insists that `IPAD' be
aligned to a 4-byte boundary, but the processor has no such
requirement (though it is usually good for performance).
The `gcc' back end needs to provide a wider array of
specifications of alignment requirements and preferences for
targets, and front ends like `g77' should take advantage of this
when it becomes available.
* The x86 target's `-malign-double' option no longer reliably aligns
double-precision variables and arrays when they are placed in the
stack frame.
This can significantly reduce the performance of some applications,
even on a run-to-run basis (that is, performance measurements can
vary fairly widely depending on whether frequently used variables
are properly aligned, and that can change from one program run to
the next, even from one procedure call to the next).
Versions 0.5.22 and earlier of `g77' included a patch to `gcc'
that enabled this, but that patch has been deemed an improper
(probably buggy) one for version 2.8 of `gcc' and for `egcs'.
Note that version 1.1 of `egcs' aligns double-precision variables
and arrays when they are in static storage even if
`-malign-double' is not specified.
There is ongoing investigation into how to make `-malign-double'
work properly, also into how to make it unnecessary to get all
double-precision variables and arrays aligned when such alignment
would not violate the relevant specifications for processor and
inter-procedural interfaces.
For a suite of programs to test double-precision alignment, see
`ftp://alpha.gnu.org/gnu/g77/align/'.
* The `libf2c' routines that perform some run-time arithmetic on
`COMPLEX' operands were modified circa version 0.5.20 of `g77' to
work properly even in the presence of aliased operands.
While the `g77' and `netlib' versions of `libf2c' differ on how
this is accomplished, the main differences are that we believe the
`g77' version works properly even in the presence of *partially*
aliased operands.
However, these modifications have reduced performance on targets
such as x86, due to the extra copies of operands involved.
|
