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
|
This file lists known bugs in the GNU Fortran compiler. Copyright (C)
1995, 1996 Free Software Foundation, Inc. You may copy, distribute,
and modify it freely as long as you preserve this copyright notice and
permission notice.
Bugs in GNU Fortran
*******************
This section identifies bugs that `g77' *users* might run into.
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 that might afflict people who configure,
port, build, and install `g77', *Note Problems Installing::.
* Work is needed on the `SIGNAL()' intrinsic to ensure that pointers
and integers are properly handled on all targets, including 64-bit
machines.
* When using `-fugly-comma', `g77' assumes an extra `%VAL(0)'
argument is to be passed to intrinsics taking no arguments, such
as `IARGC()', which in turn reject such a call. Although this has
been worked around for 0.5.18 due to changes in the handling of
intrinsics, `g77' needs to do the ugly-argument-appending trick
only for external-function invocation, as this would probably be
more consistent with compilers that default to using that trick.
* 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. (Probably improved, but not wholly
fixed, in 0.5.21.)
* The `g77' command itself should more faithfully process options
the way the `gcc' command does. For example, `gcc' accepts
abbreviated forms of long options, `g77' generally doesn't.
* 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. *Note Initialization of
Large Aggregate Areas: Large Initialization, for information on
how to change the point at which `g77' decides to issue this
warning.
* `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.
*Note Options for Code Generation Conventions: Code Gen Options,
for information on the `-fdebug-kludge' option.
* 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' 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's good for performance).
It is possible that this is not a real bug, and could be considered
a performance feature, but it might be important to provide the
ability to Fortran code to specify minimum padding for aggregate
areas such as common blocks--and, certainly, there is the
potential, with the current setup, for interface differences in
the way such areas are laid out between `g77' and other compilers.
* Some crashes occur when compiling under Solaris on x86 machines.
Nothing has been heard about any such problems for some time, so
this is considering a closed item as of 0.5.20. Please submit any
bug reports pertinent to `g77''s support for Solaris/x86 systems.
* RS/6000 support is not complete as of the gcc 2.6.3 back end. The
2.7.0 back end appears to fix this problem, or at least mitigate
it significantly, but there is at least one known problem that is
likely to be a code-generation bug in `gcc-2.7.0' plus
`g77-0.5.16'. This problem shows up only when compiling the
Fortran program with `-O'.
Nothing has been heard about any RS/6000 problems for some time,
so this is considering a closed item as of 0.5.20. Please submit
any bug reports pertinent to `g77''s support for RS/6000 systems.
* SGI support is known to be a bit buggy. The known problem shows
up only when compiling the Fortran program with `-O'.
It is possible these problems have all been fixed in 0.5.20 by
emulating complex arithmetic in the front end. Please submit any
bug reports pertinent to `g77''s support for SGI systems.
* `g77' doesn't work perfectly on 64-bit configurations such as the
Alpha. This problem is expected to be largely resolved as of
version 0.5.20, and further addressed by 0.5.21. Version 0.6
should solve most or all related problems (such as 64-bit machines
other than Digital Semiconductor ("DEC") Alphas).
One known bug that causes a compile-time crash occurs when
compiling code such as the following with optimization:
SUBROUTINE CRASH (TEMP)
INTEGER*2 HALF(2)
REAL TEMP
HALF(1) = NINT (TEMP)
END
It is expected that a future version of `g77' will have a fix for
this problem, almost certainly by the time `g77' supports the
forthcoming version 2.8.0 of `gcc'.
* 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.
* There seem to be some problems with passing constants, and perhaps
general expressions (other than simple variables/arrays), to
procedures when compiling on some systems (such as i386) with
`-fPIC', as in when compiling for ELF targets. The symptom is
that the assembler complains about invalid opcodes. More
investigation is needed, but the problem is almost certainly in
the gcc back end, and it apparently occurs only when compiling
sufficiently complicated functions *without* the `-O' option.
|
