1 | This is Info file gcc.info, produced by Makeinfo version 1.67 from the |
---|
2 | input file gcc.texi. |
---|
3 | |
---|
4 | This file documents the use and the internals of the GNU compiler. |
---|
5 | |
---|
6 | Published by the Free Software Foundation 59 Temple Place - Suite 330 |
---|
7 | Boston, MA 02111-1307 USA |
---|
8 | |
---|
9 | Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998 |
---|
10 | Free Software Foundation, Inc. |
---|
11 | |
---|
12 | Permission is granted to make and distribute verbatim copies of this |
---|
13 | manual provided the copyright notice and this permission notice are |
---|
14 | preserved on all copies. |
---|
15 | |
---|
16 | Permission is granted to copy and distribute modified versions of |
---|
17 | this manual under the conditions for verbatim copying, provided also |
---|
18 | that the sections entitled "GNU General Public License," "Funding for |
---|
19 | Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are |
---|
20 | included exactly as in the original, and provided that the entire |
---|
21 | resulting derived work is distributed under the terms of a permission |
---|
22 | notice identical to this one. |
---|
23 | |
---|
24 | Permission is granted to copy and distribute translations of this |
---|
25 | manual into another language, under the above conditions for modified |
---|
26 | versions, except that the sections entitled "GNU General Public |
---|
27 | License," "Funding for Free Software," and "Protect Your Freedom--Fight |
---|
28 | `Look And Feel'", and this permission notice, may be included in |
---|
29 | translations approved by the Free Software Foundation instead of in the |
---|
30 | original English. |
---|
31 | |
---|
32 | |
---|
33 | File: gcc.info, Node: C++ Signatures, Prev: Template Instantiation, Up: C++ Extensions |
---|
34 | |
---|
35 | Type Abstraction using Signatures |
---|
36 | ================================= |
---|
37 | |
---|
38 | In GNU C++, you can use the keyword `signature' to define a |
---|
39 | completely abstract class interface as a datatype. You can connect this |
---|
40 | abstraction with actual classes using signature pointers. If you want |
---|
41 | to use signatures, run the GNU compiler with the `-fhandle-signatures' |
---|
42 | command-line option. (With this option, the compiler reserves a second |
---|
43 | keyword `sigof' as well, for a future extension.) |
---|
44 | |
---|
45 | Roughly, signatures are type abstractions or interfaces of classes. |
---|
46 | Some other languages have similar facilities. C++ signatures are |
---|
47 | related to ML's signatures, Haskell's type classes, definition modules |
---|
48 | in Modula-2, interface modules in Modula-3, abstract types in Emerald, |
---|
49 | type modules in Trellis/Owl, categories in Scratchpad II, and types in |
---|
50 | POOL-I. For a more detailed discussion of signatures, see `Signatures: |
---|
51 | A Language Extension for Improving Type Abstraction and Subtype |
---|
52 | Polymorphism in C++' by Gerald Baumgartner and Vincent F. Russo (Tech |
---|
53 | report CSD-TR-95-051, Dept. of Computer Sciences, Purdue University, |
---|
54 | August 1995, a slightly improved version appeared in |
---|
55 | *Software--Practice & Experience*, 25(8), pp. 863-889, August 1995). |
---|
56 | You can get the tech report by anonymous FTP from `ftp.cs.purdue.edu' |
---|
57 | in `pub/gb/Signature-design.ps.gz'. |
---|
58 | |
---|
59 | Syntactically, a signature declaration is a collection of member |
---|
60 | function declarations and nested type declarations. For example, this |
---|
61 | signature declaration defines a new abstract type `S' with member |
---|
62 | functions `int foo ()' and `int bar (int)': |
---|
63 | |
---|
64 | signature S |
---|
65 | { |
---|
66 | int foo (); |
---|
67 | int bar (int); |
---|
68 | }; |
---|
69 | |
---|
70 | Since signature types do not include implementation definitions, you |
---|
71 | cannot write an instance of a signature directly. Instead, you can |
---|
72 | define a pointer to any class that contains the required interfaces as a |
---|
73 | "signature pointer". Such a class "implements" the signature type. |
---|
74 | |
---|
75 | To use a class as an implementation of `S', you must ensure that the |
---|
76 | class has public member functions `int foo ()' and `int bar (int)'. |
---|
77 | The class can have other member functions as well, public or not; as |
---|
78 | long as it offers what's declared in the signature, it is suitable as |
---|
79 | an implementation of that signature type. |
---|
80 | |
---|
81 | For example, suppose that `C' is a class that meets the requirements |
---|
82 | of signature `S' (`C' "conforms to" `S'). Then |
---|
83 | |
---|
84 | C obj; |
---|
85 | S * p = &obj; |
---|
86 | |
---|
87 | defines a signature pointer `p' and initializes it to point to an |
---|
88 | object of type `C'. The member function call `int i = p->foo ();' |
---|
89 | executes `obj.foo ()'. |
---|
90 | |
---|
91 | Abstract virtual classes provide somewhat similar facilities in |
---|
92 | standard C++. There are two main advantages to using signatures |
---|
93 | instead: |
---|
94 | |
---|
95 | 1. Subtyping becomes independent from inheritance. A class or |
---|
96 | signature type `T' is a subtype of a signature type `S' |
---|
97 | independent of any inheritance hierarchy as long as all the member |
---|
98 | functions declared in `S' are also found in `T'. So you can |
---|
99 | define a subtype hierarchy that is completely independent from any |
---|
100 | inheritance (implementation) hierarchy, instead of being forced to |
---|
101 | use types that mirror the class inheritance hierarchy. |
---|
102 | |
---|
103 | 2. Signatures allow you to work with existing class hierarchies as |
---|
104 | implementations of a signature type. If those class hierarchies |
---|
105 | are only available in compiled form, you're out of luck with |
---|
106 | abstract virtual classes, since an abstract virtual class cannot |
---|
107 | be retrofitted on top of existing class hierarchies. So you would |
---|
108 | be required to write interface classes as subtypes of the abstract |
---|
109 | virtual class. |
---|
110 | |
---|
111 | There is one more detail about signatures. A signature declaration |
---|
112 | can contain member function *definitions* as well as member function |
---|
113 | declarations. A signature member function with a full definition is |
---|
114 | called a *default implementation*; classes need not contain that |
---|
115 | particular interface in order to conform. For example, a class `C' can |
---|
116 | conform to the signature |
---|
117 | |
---|
118 | signature T |
---|
119 | { |
---|
120 | int f (int); |
---|
121 | int f0 () { return f (0); }; |
---|
122 | }; |
---|
123 | |
---|
124 | whether or not `C' implements the member function `int f0 ()'. If you |
---|
125 | define `C::f0', that definition takes precedence; otherwise, the |
---|
126 | default implementation `S::f0' applies. |
---|
127 | |
---|
128 | |
---|
129 | File: gcc.info, Node: Gcov, Next: Trouble, Prev: C++ Extensions, Up: Top |
---|
130 | |
---|
131 | `gcov': a Test Coverage Program |
---|
132 | ******************************* |
---|
133 | |
---|
134 | `gcov' is a tool you can use in conjunction with GNU CC to test code |
---|
135 | coverage in your programs. |
---|
136 | |
---|
137 | This chapter describes version 1.5 of `gcov'. |
---|
138 | |
---|
139 | * Menu: |
---|
140 | |
---|
141 | * Gcov Intro:: Introduction to gcov. |
---|
142 | * Invoking Gcov:: How to use gcov. |
---|
143 | * Gcov and Optimization:: Using gcov with GCC optimization. |
---|
144 | * Gcov Data Files:: The files used by gcov. |
---|
145 | |
---|
146 | |
---|
147 | File: gcc.info, Node: Gcov Intro, Next: Invoking Gcov, Up: Gcov |
---|
148 | |
---|
149 | Introduction to `gcov' |
---|
150 | ====================== |
---|
151 | |
---|
152 | `gcov' is a test coverage program. Use it in concert with GNU CC to |
---|
153 | analyze your programs to help create more efficient, faster running |
---|
154 | code. You can use `gcov' as a profiling tool to help discover where |
---|
155 | your optimization efforts will best affect your code. You can also use |
---|
156 | `gcov' along with the other profiling tool, `gprof', to assess which |
---|
157 | parts of your code use the greatest amount of computing time. |
---|
158 | |
---|
159 | Profiling tools help you analyze your code's performance. Using a |
---|
160 | profiler such as `gcov' or `gprof', you can find out some basic |
---|
161 | performance statistics, such as: |
---|
162 | |
---|
163 | * how often each line of code executes |
---|
164 | |
---|
165 | * what lines of code are actually executed |
---|
166 | |
---|
167 | * how much computing time each section of code uses |
---|
168 | |
---|
169 | Once you know these things about how your code works when compiled, |
---|
170 | you can look at each module to see which modules should be optimized. |
---|
171 | `gcov' helps you determine where to work on optimization. |
---|
172 | |
---|
173 | Software developers also use coverage testing in concert with |
---|
174 | testsuites, to make sure software is actually good enough for a release. |
---|
175 | Testsuites can verify that a program works as expected; a coverage |
---|
176 | program tests to see how much of the program is exercised by the |
---|
177 | testsuite. Developers can then determine what kinds of test cases need |
---|
178 | to be added to the testsuites to create both better testing and a better |
---|
179 | final product. |
---|
180 | |
---|
181 | You should compile your code without optimization if you plan to use |
---|
182 | `gcov' because the optimization, by combining some lines of code into |
---|
183 | one function, may not give you as much information as you need to look |
---|
184 | for `hot spots' where the code is using a great deal of computer time. |
---|
185 | Likewise, because `gcov' accumulates statistics by line (at the lowest |
---|
186 | resolution), it works best with a programming style that places only |
---|
187 | one statement on each line. If you use complicated macros that expand |
---|
188 | to loops or to other control structures, the statistics are less |
---|
189 | helpful--they only report on the line where the macro call appears. If |
---|
190 | your complex macros behave like functions, you can replace them with |
---|
191 | inline functions to solve this problem. |
---|
192 | |
---|
193 | `gcov' creates a logfile called `SOURCEFILE.gcov' which indicates |
---|
194 | how many times each line of a source file `SOURCEFILE.c' has executed. |
---|
195 | You can use these logfiles along with `gprof' to aid in fine-tuning the |
---|
196 | performance of your programs. `gprof' gives timing information you can |
---|
197 | use along with the information you get from `gcov'. |
---|
198 | |
---|
199 | `gcov' works only on code compiled with GNU CC. It is not |
---|
200 | compatible with any other profiling or test coverage mechanism. |
---|
201 | |
---|
202 | |
---|
203 | File: gcc.info, Node: Invoking Gcov, Next: Gcov and Optimization, Prev: Gcov Intro, Up: Gcov |
---|
204 | |
---|
205 | Invoking gcov |
---|
206 | ============= |
---|
207 | |
---|
208 | gcov [-b] [-v] [-n] [-l] [-f] [-o directory] SOURCEFILE |
---|
209 | |
---|
210 | `-b' |
---|
211 | Write branch frequencies to the output file, and write branch |
---|
212 | summary info to the standard output. This option allows you to |
---|
213 | see how often each branch in your program was taken. |
---|
214 | |
---|
215 | `-v' |
---|
216 | Display the `gcov' version number (on the standard error stream). |
---|
217 | |
---|
218 | `-n' |
---|
219 | Do not create the `gcov' output file. |
---|
220 | |
---|
221 | `-l' |
---|
222 | Create long file names for included source files. For example, if |
---|
223 | the header file `x.h' contains code, and was included in the file |
---|
224 | `a.c', then running `gcov' on the file `a.c' will produce an |
---|
225 | output file called `a.c.x.h.gcov' instead of `x.h.gcov'. This can |
---|
226 | be useful if `x.h' is included in multiple source files. |
---|
227 | |
---|
228 | `-f' |
---|
229 | Output summaries for each function in addition to the file level |
---|
230 | summary. |
---|
231 | |
---|
232 | `-o' |
---|
233 | The directory where the object files live. Gcov will search for |
---|
234 | `.bb', `.bbg', and `.da' files in this directory. |
---|
235 | |
---|
236 | When using `gcov', you must first compile your program with two |
---|
237 | special GNU CC options: `-fprofile-arcs -ftest-coverage'. This tells |
---|
238 | the compiler to generate additional information needed by gcov |
---|
239 | (basically a flow graph of the program) and also includes additional |
---|
240 | code in the object files for generating the extra profiling information |
---|
241 | needed by gcov. These additional files are placed in the directory |
---|
242 | where the source code is located. |
---|
243 | |
---|
244 | Running the program will cause profile output to be generated. For |
---|
245 | each source file compiled with -fprofile-arcs, an accompanying `.da' |
---|
246 | file will be placed in the source directory. |
---|
247 | |
---|
248 | Running `gcov' with your program's source file names as arguments |
---|
249 | will now produce a listing of the code along with frequency of execution |
---|
250 | for each line. For example, if your program is called `tmp.c', this is |
---|
251 | what you see when you use the basic `gcov' facility: |
---|
252 | |
---|
253 | $ gcc -fprofile-arcs -ftest-coverage tmp.c |
---|
254 | $ a.out |
---|
255 | $ gcov tmp.c |
---|
256 | 87.50% of 8 source lines executed in file tmp.c |
---|
257 | Creating tmp.c.gcov. |
---|
258 | |
---|
259 | The file `tmp.c.gcov' contains output from `gcov'. Here is a sample: |
---|
260 | |
---|
261 | main() |
---|
262 | { |
---|
263 | 1 int i, total; |
---|
264 | |
---|
265 | 1 total = 0; |
---|
266 | |
---|
267 | 11 for (i = 0; i < 10; i++) |
---|
268 | 10 total += i; |
---|
269 | |
---|
270 | 1 if (total != 45) |
---|
271 | ###### printf ("Failure\n"); |
---|
272 | else |
---|
273 | 1 printf ("Success\n"); |
---|
274 | 1 } |
---|
275 | |
---|
276 | When you use the `-b' option, your output looks like this: |
---|
277 | |
---|
278 | $ gcov -b tmp.c |
---|
279 | 87.50% of 8 source lines executed in file tmp.c |
---|
280 | 80.00% of 5 branches executed in file tmp.c |
---|
281 | 80.00% of 5 branches taken at least once in file tmp.c |
---|
282 | 50.00% of 2 calls executed in file tmp.c |
---|
283 | Creating tmp.c.gcov. |
---|
284 | |
---|
285 | Here is a sample of a resulting `tmp.c.gcov' file: |
---|
286 | |
---|
287 | main() |
---|
288 | { |
---|
289 | 1 int i, total; |
---|
290 | |
---|
291 | 1 total = 0; |
---|
292 | |
---|
293 | 11 for (i = 0; i < 10; i++) |
---|
294 | branch 0 taken = 91% |
---|
295 | branch 1 taken = 100% |
---|
296 | branch 2 taken = 100% |
---|
297 | 10 total += i; |
---|
298 | |
---|
299 | 1 if (total != 45) |
---|
300 | branch 0 taken = 100% |
---|
301 | ###### printf ("Failure\n"); |
---|
302 | call 0 never executed |
---|
303 | branch 1 never executed |
---|
304 | else |
---|
305 | 1 printf ("Success\n"); |
---|
306 | call 0 returns = 100% |
---|
307 | 1 } |
---|
308 | |
---|
309 | For each basic block, a line is printed after the last line of the |
---|
310 | basic block describing the branch or call that ends the basic block. |
---|
311 | There can be multiple branches and calls listed for a single source |
---|
312 | line if there are multiple basic blocks that end on that line. In this |
---|
313 | case, the branches and calls are each given a number. There is no |
---|
314 | simple way to map these branches and calls back to source constructs. |
---|
315 | In general, though, the lowest numbered branch or call will correspond |
---|
316 | to the leftmost construct on the source line. |
---|
317 | |
---|
318 | For a branch, if it was executed at least once, then a percentage |
---|
319 | indicating the number of times the branch was taken divided by the |
---|
320 | number of times the branch was executed will be printed. Otherwise, the |
---|
321 | message "never executed" is printed. |
---|
322 | |
---|
323 | For a call, if it was executed at least once, then a percentage |
---|
324 | indicating the number of times the call returned divided by the number |
---|
325 | of times the call was executed will be printed. This will usually be |
---|
326 | 100%, but may be less for functions call `exit' or `longjmp', and thus |
---|
327 | may not return everytime they are called. |
---|
328 | |
---|
329 | The execution counts are cumulative. If the example program were |
---|
330 | executed again without removing the `.da' file, the count for the |
---|
331 | number of times each line in the source was executed would be added to |
---|
332 | the results of the previous run(s). This is potentially useful in |
---|
333 | several ways. For example, it could be used to accumulate data over a |
---|
334 | number of program runs as part of a test verification suite, or to |
---|
335 | provide more accurate long-term information over a large number of |
---|
336 | program runs. |
---|
337 | |
---|
338 | The data in the `.da' files is saved immediately before the program |
---|
339 | exits. For each source file compiled with -fprofile-arcs, the profiling |
---|
340 | code first attempts to read in an existing `.da' file; if the file |
---|
341 | doesn't match the executable (differing number of basic block counts) it |
---|
342 | will ignore the contents of the file. It then adds in the new execution |
---|
343 | counts and finally writes the data to the file. |
---|
344 | |
---|
345 | |
---|
346 | File: gcc.info, Node: Gcov and Optimization, Next: Gcov Data Files, Prev: Invoking Gcov, Up: Gcov |
---|
347 | |
---|
348 | Using `gcov' with GCC Optimization |
---|
349 | ================================== |
---|
350 | |
---|
351 | If you plan to use `gcov' to help optimize your code, you must first |
---|
352 | compile your program with two special GNU CC options: `-fprofile-arcs |
---|
353 | -ftest-coverage'. Aside from that, you can use any other GNU CC |
---|
354 | options; but if you want to prove that every single line in your |
---|
355 | program was executed, you should not compile with optimization at the |
---|
356 | same time. On some machines the optimizer can eliminate some simple |
---|
357 | code lines by combining them with other lines. For example, code like |
---|
358 | this: |
---|
359 | |
---|
360 | if (a != b) |
---|
361 | c = 1; |
---|
362 | else |
---|
363 | c = 0; |
---|
364 | |
---|
365 | can be compiled into one instruction on some machines. In this case, |
---|
366 | there is no way for `gcov' to calculate separate execution counts for |
---|
367 | each line because there isn't separate code for each line. Hence the |
---|
368 | `gcov' output looks like this if you compiled the program with |
---|
369 | optimization: |
---|
370 | |
---|
371 | 100 if (a != b) |
---|
372 | 100 c = 1; |
---|
373 | 100 else |
---|
374 | 100 c = 0; |
---|
375 | |
---|
376 | The output shows that this block of code, combined by optimization, |
---|
377 | executed 100 times. In one sense this result is correct, because there |
---|
378 | was only one instruction representing all four of these lines. However, |
---|
379 | the output does not indicate how many times the result was 0 and how |
---|
380 | many times the result was 1. |
---|
381 | |
---|
382 | |
---|
383 | File: gcc.info, Node: Gcov Data Files, Prev: Gcov and Optimization, Up: Gcov |
---|
384 | |
---|
385 | Brief description of `gcov' data files |
---|
386 | ====================================== |
---|
387 | |
---|
388 | `gcov' uses three files for doing profiling. The names of these |
---|
389 | files are derived from the original *source* file by substituting the |
---|
390 | file suffix with either `.bb', `.bbg', or `.da'. All of these files |
---|
391 | are placed in the same directory as the source file, and contain data |
---|
392 | stored in a platform-independent method. |
---|
393 | |
---|
394 | The `.bb' and `.bbg' files are generated when the source file is |
---|
395 | compiled with the GNU CC `-ftest-coverage' option. The `.bb' file |
---|
396 | contains a list of source files (including headers), functions within |
---|
397 | those files, and line numbers corresponding to each basic block in the |
---|
398 | source file. |
---|
399 | |
---|
400 | The `.bb' file format consists of several lists of 4-byte integers |
---|
401 | which correspond to the line numbers of each basic block in the file. |
---|
402 | Each list is terminated by a line number of 0. A line number of -1 is |
---|
403 | used to designate that the source file name (padded to a 4-byte |
---|
404 | boundary and followed by another -1) follows. In addition, a line |
---|
405 | number of -2 is used to designate that the name of a function (also |
---|
406 | padded to a 4-byte boundary and followed by a -2) follows. |
---|
407 | |
---|
408 | The `.bbg' file is used to reconstruct the program flow graph for |
---|
409 | the source file. It contains a list of the program flow arcs (possible |
---|
410 | branches taken from one basic block to another) for each function which, |
---|
411 | in combination with the `.bb' file, enables gcov to reconstruct the |
---|
412 | program flow. |
---|
413 | |
---|
414 | In the `.bbg' file, the format is: |
---|
415 | number of basic blocks for function #0 (4-byte number) |
---|
416 | total number of arcs for function #0 (4-byte number) |
---|
417 | count of arcs in basic block #0 (4-byte number) |
---|
418 | destination basic block of arc #0 (4-byte number) |
---|
419 | flag bits (4-byte number) |
---|
420 | destination basic block of arc #1 (4-byte number) |
---|
421 | flag bits (4-byte number) |
---|
422 | ... |
---|
423 | destination basic block of arc #N (4-byte number) |
---|
424 | flag bits (4-byte number) |
---|
425 | count of arcs in basic block #1 (4-byte number) |
---|
426 | destination basic block of arc #0 (4-byte number) |
---|
427 | flag bits (4-byte number) |
---|
428 | ... |
---|
429 | |
---|
430 | A -1 (stored as a 4-byte number) is used to separate each function's |
---|
431 | list of basic blocks, and to verify that the file has been read |
---|
432 | correctly. |
---|
433 | |
---|
434 | The `.da' file is generated when a program containing object files |
---|
435 | built with the GNU CC `-fprofile-arcs' option is executed. A separate |
---|
436 | `.da' file is created for each source file compiled with this option, |
---|
437 | and the name of the `.da' file is stored as an absolute pathname in the |
---|
438 | resulting object file. This path name is derived from the source file |
---|
439 | name by substituting a `.da' suffix. |
---|
440 | |
---|
441 | The format of the `.da' file is fairly simple. The first 8-byte |
---|
442 | number is the number of counts in the file, followed by the counts |
---|
443 | (stored as 8-byte numbers). Each count corresponds to the number of |
---|
444 | times each arc in the program is executed. The counts are cumulative; |
---|
445 | each time the program is executed, it attemps to combine the existing |
---|
446 | `.da' files with the new counts for this invocation of the program. It |
---|
447 | ignores the contents of any `.da' files whose number of arcs doesn't |
---|
448 | correspond to the current program, and merely overwrites them instead. |
---|
449 | |
---|
450 | All three of these files use the functions in `gcov-io.h' to store |
---|
451 | integers; the functions in this header provide a machine-independent |
---|
452 | mechanism for storing and retrieving data from a stream. |
---|
453 | |
---|
454 | |
---|
455 | File: gcc.info, Node: Trouble, Next: Bugs, Prev: Gcov, Up: Top |
---|
456 | |
---|
457 | Known Causes of Trouble with GNU CC |
---|
458 | *********************************** |
---|
459 | |
---|
460 | This section describes known problems that affect users of GNU CC. |
---|
461 | Most of these are not GNU CC bugs per se--if they were, we would fix |
---|
462 | them. But the result for a user may be like the result of a bug. |
---|
463 | |
---|
464 | Some of these problems are due to bugs in other software, some are |
---|
465 | missing features that are too much work to add, and some are places |
---|
466 | where people's opinions differ as to what is best. |
---|
467 | |
---|
468 | * Menu: |
---|
469 | |
---|
470 | * Actual Bugs:: Bugs we will fix later. |
---|
471 | * Installation Problems:: Problems that manifest when you install GNU CC. |
---|
472 | * Cross-Compiler Problems:: Common problems of cross compiling with GNU CC. |
---|
473 | * Interoperation:: Problems using GNU CC with other compilers, |
---|
474 | and with certain linkers, assemblers and debuggers. |
---|
475 | * External Bugs:: Problems compiling certain programs. |
---|
476 | * Incompatibilities:: GNU CC is incompatible with traditional C. |
---|
477 | * Fixed Headers:: GNU C uses corrected versions of system header files. |
---|
478 | This is necessary, but doesn't always work smoothly. |
---|
479 | * Standard Libraries:: GNU C uses the system C library, which might not be |
---|
480 | compliant with the ISO/ANSI C standard. |
---|
481 | * Disappointments:: Regrettable things we can't change, but not quite bugs. |
---|
482 | * C++ Misunderstandings:: Common misunderstandings with GNU C++. |
---|
483 | * Protoize Caveats:: Things to watch out for when using `protoize'. |
---|
484 | * Non-bugs:: Things we think are right, but some others disagree. |
---|
485 | * Warnings and Errors:: Which problems in your code get warnings, |
---|
486 | and which get errors. |
---|
487 | |
---|
488 | |
---|
489 | File: gcc.info, Node: Actual Bugs, Next: Installation Problems, Up: Trouble |
---|
490 | |
---|
491 | Actual Bugs We Haven't Fixed Yet |
---|
492 | ================================ |
---|
493 | |
---|
494 | * The `fixincludes' script interacts badly with automounters; if the |
---|
495 | directory of system header files is automounted, it tends to be |
---|
496 | unmounted while `fixincludes' is running. This would seem to be a |
---|
497 | bug in the automounter. We don't know any good way to work around |
---|
498 | it. |
---|
499 | |
---|
500 | * The `fixproto' script will sometimes add prototypes for the |
---|
501 | `sigsetjmp' and `siglongjmp' functions that reference the |
---|
502 | `jmp_buf' type before that type is defined. To work around this, |
---|
503 | edit the offending file and place the typedef in front of the |
---|
504 | prototypes. |
---|
505 | |
---|
506 | * There are several obscure case of mis-using struct, union, and |
---|
507 | enum tags that are not detected as errors by the compiler. |
---|
508 | |
---|
509 | * When `-pedantic-errors' is specified, GNU C will incorrectly give |
---|
510 | an error message when a function name is specified in an expression |
---|
511 | involving the comma operator. |
---|
512 | |
---|
513 | * Loop unrolling doesn't work properly for certain C++ programs. |
---|
514 | This is a bug in the C++ front end. It sometimes emits incorrect |
---|
515 | debug info, and the loop unrolling code is unable to recover from |
---|
516 | this error. |
---|
517 | |
---|
518 | |
---|
519 | File: gcc.info, Node: Installation Problems, Next: Cross-Compiler Problems, Prev: Actual Bugs, Up: Trouble |
---|
520 | |
---|
521 | Installation Problems |
---|
522 | ===================== |
---|
523 | |
---|
524 | This is a list of problems (and some apparent problems which don't |
---|
525 | really mean anything is wrong) that show up during installation of GNU |
---|
526 | CC. |
---|
527 | |
---|
528 | * On certain systems, defining certain environment variables such as |
---|
529 | `CC' can interfere with the functioning of `make'. |
---|
530 | |
---|
531 | * If you encounter seemingly strange errors when trying to build the |
---|
532 | compiler in a directory other than the source directory, it could |
---|
533 | be because you have previously configured the compiler in the |
---|
534 | source directory. Make sure you have done all the necessary |
---|
535 | preparations. *Note Other Dir::. |
---|
536 | |
---|
537 | * If you build GNU CC on a BSD system using a directory stored in a |
---|
538 | System V file system, problems may occur in running `fixincludes' |
---|
539 | if the System V file system doesn't support symbolic links. These |
---|
540 | problems result in a failure to fix the declaration of `size_t' in |
---|
541 | `sys/types.h'. If you find that `size_t' is a signed type and |
---|
542 | that type mismatches occur, this could be the cause. |
---|
543 | |
---|
544 | The solution is not to use such a directory for building GNU CC. |
---|
545 | |
---|
546 | * In previous versions of GNU CC, the `gcc' driver program looked for |
---|
547 | `as' and `ld' in various places; for example, in files beginning |
---|
548 | with `/usr/local/lib/gcc-'. GNU CC version 2 looks for them in |
---|
549 | the directory `/usr/local/lib/gcc-lib/TARGET/VERSION'. |
---|
550 | |
---|
551 | Thus, to use a version of `as' or `ld' that is not the system |
---|
552 | default, for example `gas' or GNU `ld', you must put them in that |
---|
553 | directory (or make links to them from that directory). |
---|
554 | |
---|
555 | * Some commands executed when making the compiler may fail (return a |
---|
556 | non-zero status) and be ignored by `make'. These failures, which |
---|
557 | are often due to files that were not found, are expected, and can |
---|
558 | safely be ignored. |
---|
559 | |
---|
560 | * It is normal to have warnings in compiling certain files about |
---|
561 | unreachable code and about enumeration type clashes. These files' |
---|
562 | names begin with `insn-'. Also, `real.c' may get some warnings |
---|
563 | that you can ignore. |
---|
564 | |
---|
565 | * Sometimes `make' recompiles parts of the compiler when installing |
---|
566 | the compiler. In one case, this was traced down to a bug in |
---|
567 | `make'. Either ignore the problem or switch to GNU Make. |
---|
568 | |
---|
569 | * If you have installed a program known as purify, you may find that |
---|
570 | it causes errors while linking `enquire', which is part of building |
---|
571 | GNU CC. The fix is to get rid of the file `real-ld' which purify |
---|
572 | installs--so that GNU CC won't try to use it. |
---|
573 | |
---|
574 | * On GNU/Linux SLS 1.01, there is a problem with `libc.a': it does |
---|
575 | not contain the obstack functions. However, GNU CC assumes that |
---|
576 | the obstack functions are in `libc.a' when it is the GNU C |
---|
577 | library. To work around this problem, change the |
---|
578 | `__GNU_LIBRARY__' conditional around line 31 to `#if 1'. |
---|
579 | |
---|
580 | * On some 386 systems, building the compiler never finishes because |
---|
581 | `enquire' hangs due to a hardware problem in the motherboard--it |
---|
582 | reports floating point exceptions to the kernel incorrectly. You |
---|
583 | can install GNU CC except for `float.h' by patching out the |
---|
584 | command to run `enquire'. You may also be able to fix the problem |
---|
585 | for real by getting a replacement motherboard. This problem was |
---|
586 | observed in Revision E of the Micronics motherboard, and is fixed |
---|
587 | in Revision F. It has also been observed in the MYLEX MXA-33 |
---|
588 | motherboard. |
---|
589 | |
---|
590 | If you encounter this problem, you may also want to consider |
---|
591 | removing the FPU from the socket during the compilation. |
---|
592 | Alternatively, if you are running SCO Unix, you can reboot and |
---|
593 | force the FPU to be ignored. To do this, type `hd(40)unix auto |
---|
594 | ignorefpu'. |
---|
595 | |
---|
596 | * On some 386 systems, GNU CC crashes trying to compile `enquire.c'. |
---|
597 | This happens on machines that don't have a 387 FPU chip. On 386 |
---|
598 | machines, the system kernel is supposed to emulate the 387 when you |
---|
599 | don't have one. The crash is due to a bug in the emulator. |
---|
600 | |
---|
601 | One of these systems is the Unix from Interactive Systems: 386/ix. |
---|
602 | On this system, an alternate emulator is provided, and it does |
---|
603 | work. To use it, execute this command as super-user: |
---|
604 | |
---|
605 | ln /etc/emulator.rel1 /etc/emulator |
---|
606 | |
---|
607 | and then reboot the system. (The default emulator file remains |
---|
608 | present under the name `emulator.dflt'.) |
---|
609 | |
---|
610 | Try using `/etc/emulator.att', if you have such a problem on the |
---|
611 | SCO system. |
---|
612 | |
---|
613 | Another system which has this problem is Esix. We don't know |
---|
614 | whether it has an alternate emulator that works. |
---|
615 | |
---|
616 | On NetBSD 0.8, a similar problem manifests itself as these error |
---|
617 | messages: |
---|
618 | |
---|
619 | enquire.c: In function `fprop': |
---|
620 | enquire.c:2328: floating overflow |
---|
621 | |
---|
622 | * On SCO systems, when compiling GNU CC with the system's compiler, |
---|
623 | do not use `-O'. Some versions of the system's compiler miscompile |
---|
624 | GNU CC with `-O'. |
---|
625 | |
---|
626 | * Sometimes on a Sun 4 you may observe a crash in the program |
---|
627 | `genflags' or `genoutput' while building GNU CC. This is said to |
---|
628 | be due to a bug in `sh'. You can probably get around it by running |
---|
629 | `genflags' or `genoutput' manually and then retrying the `make'. |
---|
630 | |
---|
631 | * On Solaris 2, executables of GNU CC version 2.0.2 are commonly |
---|
632 | available, but they have a bug that shows up when compiling current |
---|
633 | versions of GNU CC: undefined symbol errors occur during assembly |
---|
634 | if you use `-g'. |
---|
635 | |
---|
636 | The solution is to compile the current version of GNU CC without |
---|
637 | `-g'. That makes a working compiler which you can use to recompile |
---|
638 | with `-g'. |
---|
639 | |
---|
640 | * Solaris 2 comes with a number of optional OS packages. Some of |
---|
641 | these packages are needed to use GNU CC fully. If you did not |
---|
642 | install all optional packages when installing Solaris, you will |
---|
643 | need to verify that the packages that GNU CC needs are installed. |
---|
644 | |
---|
645 | To check whether an optional package is installed, use the |
---|
646 | `pkginfo' command. To add an optional package, use the `pkgadd' |
---|
647 | command. For further details, see the Solaris documentation. |
---|
648 | |
---|
649 | For Solaris 2.0 and 2.1, GNU CC needs six packages: `SUNWarc', |
---|
650 | `SUNWbtool', `SUNWesu', `SUNWhea', `SUNWlibm', and `SUNWtoo'. |
---|
651 | |
---|
652 | For Solaris 2.2, GNU CC needs an additional seventh package: |
---|
653 | `SUNWsprot'. |
---|
654 | |
---|
655 | * On Solaris 2, trying to use the linker and other tools in |
---|
656 | `/usr/ucb' to install GNU CC has been observed to cause trouble. |
---|
657 | For example, the linker may hang indefinitely. The fix is to |
---|
658 | remove `/usr/ucb' from your `PATH'. |
---|
659 | |
---|
660 | * If you use the 1.31 version of the MIPS assembler (such as was |
---|
661 | shipped with Ultrix 3.1), you will need to use the |
---|
662 | -fno-delayed-branch switch when optimizing floating point code. |
---|
663 | Otherwise, the assembler will complain when the GCC compiler fills |
---|
664 | a branch delay slot with a floating point instruction, such as |
---|
665 | `add.d'. |
---|
666 | |
---|
667 | * If on a MIPS system you get an error message saying "does not have |
---|
668 | gp sections for all it's [sic] sectons [sic]", don't worry about |
---|
669 | it. This happens whenever you use GAS with the MIPS linker, but |
---|
670 | there is not really anything wrong, and it is okay to use the |
---|
671 | output file. You can stop such warnings by installing the GNU |
---|
672 | linker. |
---|
673 | |
---|
674 | It would be nice to extend GAS to produce the gp tables, but they |
---|
675 | are optional, and there should not be a warning about their |
---|
676 | absence. |
---|
677 | |
---|
678 | * In Ultrix 4.0 on the MIPS machine, `stdio.h' does not work with GNU |
---|
679 | CC at all unless it has been fixed with `fixincludes'. This causes |
---|
680 | problems in building GNU CC. Once GNU CC is installed, the |
---|
681 | problems go away. |
---|
682 | |
---|
683 | To work around this problem, when making the stage 1 compiler, |
---|
684 | specify this option to Make: |
---|
685 | |
---|
686 | GCC_FOR_TARGET="./xgcc -B./ -I./include" |
---|
687 | |
---|
688 | When making stage 2 and stage 3, specify this option: |
---|
689 | |
---|
690 | CFLAGS="-g -I./include" |
---|
691 | |
---|
692 | * Users have reported some problems with version 2.0 of the MIPS |
---|
693 | compiler tools that were shipped with Ultrix 4.1. Version 2.10 |
---|
694 | which came with Ultrix 4.2 seems to work fine. |
---|
695 | |
---|
696 | Users have also reported some problems with version 2.20 of the |
---|
697 | MIPS compiler tools that were shipped with RISC/os 4.x. The |
---|
698 | earlier version 2.11 seems to work fine. |
---|
699 | |
---|
700 | * Some versions of the MIPS linker will issue an assertion failure |
---|
701 | when linking code that uses `alloca' against shared libraries on |
---|
702 | RISC-OS 5.0, and DEC's OSF/1 systems. This is a bug in the |
---|
703 | linker, that is supposed to be fixed in future revisions. To |
---|
704 | protect against this, GNU CC passes `-non_shared' to the linker |
---|
705 | unless you pass an explicit `-shared' or `-call_shared' switch. |
---|
706 | |
---|
707 | * On System V release 3, you may get this error message while |
---|
708 | linking: |
---|
709 | |
---|
710 | ld fatal: failed to write symbol name SOMETHING |
---|
711 | in strings table for file WHATEVER |
---|
712 | |
---|
713 | This probably indicates that the disk is full or your ULIMIT won't |
---|
714 | allow the file to be as large as it needs to be. |
---|
715 | |
---|
716 | This problem can also result because the kernel parameter `MAXUMEM' |
---|
717 | is too small. If so, you must regenerate the kernel and make the |
---|
718 | value much larger. The default value is reported to be 1024; a |
---|
719 | value of 32768 is said to work. Smaller values may also work. |
---|
720 | |
---|
721 | * On System V, if you get an error like this, |
---|
722 | |
---|
723 | /usr/local/lib/bison.simple: In function `yyparse': |
---|
724 | /usr/local/lib/bison.simple:625: virtual memory exhausted |
---|
725 | |
---|
726 | that too indicates a problem with disk space, ULIMIT, or `MAXUMEM'. |
---|
727 | |
---|
728 | * Current GNU CC versions probably do not work on version 2 of the |
---|
729 | NeXT operating system. |
---|
730 | |
---|
731 | * On NeXTStep 3.0, the Objective C compiler does not work, due, |
---|
732 | apparently, to a kernel bug that it happens to trigger. This |
---|
733 | problem does not happen on 3.1. |
---|
734 | |
---|
735 | * On the Tower models 4N0 and 6N0, by default a process is not |
---|
736 | allowed to have more than one megabyte of memory. GNU CC cannot |
---|
737 | compile itself (or many other programs) with `-O' in that much |
---|
738 | memory. |
---|
739 | |
---|
740 | To solve this problem, reconfigure the kernel adding the following |
---|
741 | line to the configuration file: |
---|
742 | |
---|
743 | MAXUMEM = 4096 |
---|
744 | |
---|
745 | * On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a |
---|
746 | bug in the assembler that must be fixed before GNU CC can be |
---|
747 | built. This bug manifests itself during the first stage of |
---|
748 | compilation, while building `libgcc2.a': |
---|
749 | |
---|
750 | _floatdisf |
---|
751 | cc1: warning: `-g' option not supported on this version of GCC |
---|
752 | cc1: warning: `-g1' option not supported on this version of GCC |
---|
753 | ./xgcc: Internal compiler error: program as got fatal signal 11 |
---|
754 | |
---|
755 | A patched version of the assembler is available by anonymous ftp |
---|
756 | from `altdorf.ai.mit.edu' as the file |
---|
757 | `archive/cph/hpux-8.0-assembler'. If you have HP software support, |
---|
758 | the patch can also be obtained directly from HP, as described in |
---|
759 | the following note: |
---|
760 | |
---|
761 | This is the patched assembler, to patch SR#1653-010439, where |
---|
762 | the assembler aborts on floating point constants. |
---|
763 | |
---|
764 | The bug is not really in the assembler, but in the shared |
---|
765 | library version of the function "cvtnum(3c)". The bug on |
---|
766 | "cvtnum(3c)" is SR#4701-078451. Anyway, the attached |
---|
767 | assembler uses the archive library version of "cvtnum(3c)" |
---|
768 | and thus does not exhibit the bug. |
---|
769 | |
---|
770 | This patch is also known as PHCO_4484. |
---|
771 | |
---|
772 | * On HP-UX version 8.05, but not on 8.07 or more recent versions, |
---|
773 | the `fixproto' shell script triggers a bug in the system shell. |
---|
774 | If you encounter this problem, upgrade your operating system or |
---|
775 | use BASH (the GNU shell) to run `fixproto'. |
---|
776 | |
---|
777 | * Some versions of the Pyramid C compiler are reported to be unable |
---|
778 | to compile GNU CC. You must use an older version of GNU CC for |
---|
779 | bootstrapping. One indication of this problem is if you get a |
---|
780 | crash when GNU CC compiles the function `muldi3' in file |
---|
781 | `libgcc2.c'. |
---|
782 | |
---|
783 | You may be able to succeed by getting GNU CC version 1, installing |
---|
784 | it, and using it to compile GNU CC version 2. The bug in the |
---|
785 | Pyramid C compiler does not seem to affect GNU CC version 1. |
---|
786 | |
---|
787 | * There may be similar problems on System V Release 3.1 on 386 |
---|
788 | systems. |
---|
789 | |
---|
790 | * On the Intel Paragon (an i860 machine), if you are using operating |
---|
791 | system version 1.0, you will get warnings or errors about |
---|
792 | redefinition of `va_arg' when you build GNU CC. |
---|
793 | |
---|
794 | If this happens, then you need to link most programs with the |
---|
795 | library `iclib.a'. You must also modify `stdio.h' as follows: |
---|
796 | before the lines |
---|
797 | |
---|
798 | #if defined(__i860__) && !defined(_VA_LIST) |
---|
799 | #include <va_list.h> |
---|
800 | |
---|
801 | insert the line |
---|
802 | |
---|
803 | #if __PGC__ |
---|
804 | |
---|
805 | and after the lines |
---|
806 | |
---|
807 | extern int vprintf(const char *, va_list ); |
---|
808 | extern int vsprintf(char *, const char *, va_list ); |
---|
809 | #endif |
---|
810 | |
---|
811 | insert the line |
---|
812 | |
---|
813 | #endif /* __PGC__ */ |
---|
814 | |
---|
815 | These problems don't exist in operating system version 1.1. |
---|
816 | |
---|
817 | * On the Altos 3068, programs compiled with GNU CC won't work unless |
---|
818 | you fix a kernel bug. This happens using system versions V.2.2 |
---|
819 | 1.0gT1 and V.2.2 1.0e and perhaps later versions as well. See the |
---|
820 | file `README.ALTOS'. |
---|
821 | |
---|
822 | * You will get several sorts of compilation and linking errors on the |
---|
823 | we32k if you don't follow the special instructions. *Note |
---|
824 | Configurations::. |
---|
825 | |
---|
826 | * A bug in the HP-UX 8.05 (and earlier) shell will cause the fixproto |
---|
827 | program to report an error of the form: |
---|
828 | |
---|
829 | ./fixproto: sh internal 1K buffer overflow |
---|
830 | |
---|
831 | To fix this, change the first line of the fixproto script to look |
---|
832 | like: |
---|
833 | |
---|
834 | #!/bin/ksh |
---|
835 | |
---|
836 | |
---|
837 | File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Installation Problems, Up: Trouble |
---|
838 | |
---|
839 | Cross-Compiler Problems |
---|
840 | ======================= |
---|
841 | |
---|
842 | You may run into problems with cross compilation on certain machines, |
---|
843 | for several reasons. |
---|
844 | |
---|
845 | * Cross compilation can run into trouble for certain machines because |
---|
846 | some target machines' assemblers require floating point numbers to |
---|
847 | be written as *integer* constants in certain contexts. |
---|
848 | |
---|
849 | The compiler writes these integer constants by examining the |
---|
850 | floating point value as an integer and printing that integer, |
---|
851 | because this is simple to write and independent of the details of |
---|
852 | the floating point representation. But this does not work if the |
---|
853 | compiler is running on a different machine with an incompatible |
---|
854 | floating point format, or even a different byte-ordering. |
---|
855 | |
---|
856 | In addition, correct constant folding of floating point values |
---|
857 | requires representing them in the target machine's format. (The C |
---|
858 | standard does not quite require this, but in practice it is the |
---|
859 | only way to win.) |
---|
860 | |
---|
861 | It is now possible to overcome these problems by defining macros |
---|
862 | such as `REAL_VALUE_TYPE'. But doing so is a substantial amount of |
---|
863 | work for each target machine. *Note Cross-compilation::. |
---|
864 | |
---|
865 | * At present, the program `mips-tfile' which adds debug support to |
---|
866 | object files on MIPS systems does not work in a cross compile |
---|
867 | environment. |
---|
868 | |
---|
869 | |
---|
870 | File: gcc.info, Node: Interoperation, Next: External Bugs, Prev: Cross-Compiler Problems, Up: Trouble |
---|
871 | |
---|
872 | Interoperation |
---|
873 | ============== |
---|
874 | |
---|
875 | This section lists various difficulties encountered in using GNU C or |
---|
876 | GNU C++ together with other compilers or with the assemblers, linkers, |
---|
877 | libraries and debuggers on certain systems. |
---|
878 | |
---|
879 | * Objective C does not work on the RS/6000. |
---|
880 | |
---|
881 | * GNU C++ does not do name mangling in the same way as other C++ |
---|
882 | compilers. This means that object files compiled with one compiler |
---|
883 | cannot be used with another. |
---|
884 | |
---|
885 | This effect is intentional, to protect you from more subtle |
---|
886 | problems. Compilers differ as to many internal details of C++ |
---|
887 | implementation, including: how class instances are laid out, how |
---|
888 | multiple inheritance is implemented, and how virtual function |
---|
889 | calls are handled. If the name encoding were made the same, your |
---|
890 | programs would link against libraries provided from other |
---|
891 | compilers--but the programs would then crash when run. |
---|
892 | Incompatible libraries are then detected at link time, rather than |
---|
893 | at run time. |
---|
894 | |
---|
895 | * Older GDB versions sometimes fail to read the output of GNU CC |
---|
896 | version 2. If you have trouble, get GDB version 4.4 or later. |
---|
897 | |
---|
898 | * DBX rejects some files produced by GNU CC, though it accepts |
---|
899 | similar constructs in output from PCC. Until someone can supply a |
---|
900 | coherent description of what is valid DBX input and what is not, |
---|
901 | there is nothing I can do about these problems. You are on your |
---|
902 | own. |
---|
903 | |
---|
904 | * The GNU assembler (GAS) does not support PIC. To generate PIC |
---|
905 | code, you must use some other assembler, such as `/bin/as'. |
---|
906 | |
---|
907 | * On some BSD systems, including some versions of Ultrix, use of |
---|
908 | profiling causes static variable destructors (currently used only |
---|
909 | in C++) not to be run. |
---|
910 | |
---|
911 | * Use of `-I/usr/include' may cause trouble. |
---|
912 | |
---|
913 | Many systems come with header files that won't work with GNU CC |
---|
914 | unless corrected by `fixincludes'. The corrected header files go |
---|
915 | in a new directory; GNU CC searches this directory before |
---|
916 | `/usr/include'. If you use `-I/usr/include', this tells GNU CC to |
---|
917 | search `/usr/include' earlier on, before the corrected headers. |
---|
918 | The result is that you get the uncorrected header files. |
---|
919 | |
---|
920 | Instead, you should use these options (when compiling C programs): |
---|
921 | |
---|
922 | -I/usr/local/lib/gcc-lib/TARGET/VERSION/include -I/usr/include |
---|
923 | |
---|
924 | For C++ programs, GNU CC also uses a special directory that |
---|
925 | defines C++ interfaces to standard C subroutines. This directory |
---|
926 | is meant to be searched *before* other standard include |
---|
927 | directories, so that it takes precedence. If you are compiling |
---|
928 | C++ programs and specifying include directories explicitly, use |
---|
929 | this option first, then the two options above: |
---|
930 | |
---|
931 | -I/usr/local/lib/g++-include |
---|
932 | |
---|
933 | * On some SGI systems, when you use `-lgl_s' as an option, it gets |
---|
934 | translated magically to `-lgl_s -lX11_s -lc_s'. Naturally, this |
---|
935 | does not happen when you use GNU CC. You must specify all three |
---|
936 | options explicitly. |
---|
937 | |
---|
938 | * On a Sparc, GNU CC aligns all values of type `double' on an 8-byte |
---|
939 | boundary, and it expects every `double' to be so aligned. The Sun |
---|
940 | compiler usually gives `double' values 8-byte alignment, with one |
---|
941 | exception: function arguments of type `double' may not be aligned. |
---|
942 | |
---|
943 | As a result, if a function compiled with Sun CC takes the address |
---|
944 | of an argument of type `double' and passes this pointer of type |
---|
945 | `double *' to a function compiled with GNU CC, dereferencing the |
---|
946 | pointer may cause a fatal signal. |
---|
947 | |
---|
948 | One way to solve this problem is to compile your entire program |
---|
949 | with GNU CC. Another solution is to modify the function that is |
---|
950 | compiled with Sun CC to copy the argument into a local variable; |
---|
951 | local variables are always properly aligned. A third solution is |
---|
952 | to modify the function that uses the pointer to dereference it via |
---|
953 | the following function `access_double' instead of directly with |
---|
954 | `*': |
---|
955 | |
---|
956 | inline double |
---|
957 | access_double (double *unaligned_ptr) |
---|
958 | { |
---|
959 | union d2i { double d; int i[2]; }; |
---|
960 | |
---|
961 | union d2i *p = (union d2i *) unaligned_ptr; |
---|
962 | union d2i u; |
---|
963 | |
---|
964 | u.i[0] = p->i[0]; |
---|
965 | u.i[1] = p->i[1]; |
---|
966 | |
---|
967 | return u.d; |
---|
968 | } |
---|
969 | |
---|
970 | Storing into the pointer can be done likewise with the same union. |
---|
971 | |
---|
972 | * On Solaris, the `malloc' function in the `libmalloc.a' library may |
---|
973 | allocate memory that is only 4 byte aligned. Since GNU CC on the |
---|
974 | Sparc assumes that doubles are 8 byte aligned, this may result in a |
---|
975 | fatal signal if doubles are stored in memory allocated by the |
---|
976 | `libmalloc.a' library. |
---|
977 | |
---|
978 | The solution is to not use the `libmalloc.a' library. Use instead |
---|
979 | `malloc' and related functions from `libc.a'; they do not have |
---|
980 | this problem. |
---|
981 | |
---|
982 | * Sun forgot to include a static version of `libdl.a' with some |
---|
983 | versions of SunOS (mainly 4.1). This results in undefined symbols |
---|
984 | when linking static binaries (that is, if you use `-static'). If |
---|
985 | you see undefined symbols `_dlclose', `_dlsym' or `_dlopen' when |
---|
986 | linking, compile and link against the file `mit/util/misc/dlsym.c' |
---|
987 | from the MIT version of X windows. |
---|
988 | |
---|
989 | * The 128-bit long double format that the Sparc port supports |
---|
990 | currently works by using the architecturally defined quad-word |
---|
991 | floating point instructions. Since there is no hardware that |
---|
992 | supports these instructions they must be emulated by the operating |
---|
993 | system. Long doubles do not work in Sun OS versions 4.0.3 and |
---|
994 | earlier, because the kernel emulator uses an obsolete and |
---|
995 | incompatible format. Long doubles do not work in Sun OS version |
---|
996 | 4.1.1 due to a problem in a Sun library. Long doubles do work on |
---|
997 | Sun OS versions 4.1.2 and higher, but GNU CC does not enable them |
---|
998 | by default. Long doubles appear to work in Sun OS 5.x (Solaris |
---|
999 | 2.x). |
---|
1000 | |
---|
1001 | * On HP-UX version 9.01 on the HP PA, the HP compiler `cc' does not |
---|
1002 | compile GNU CC correctly. We do not yet know why. However, GNU CC |
---|
1003 | compiled on earlier HP-UX versions works properly on HP-UX 9.01 |
---|
1004 | and can compile itself properly on 9.01. |
---|
1005 | |
---|
1006 | * On the HP PA machine, ADB sometimes fails to work on functions |
---|
1007 | compiled with GNU CC. Specifically, it fails to work on functions |
---|
1008 | that use `alloca' or variable-size arrays. This is because GNU CC |
---|
1009 | doesn't generate HP-UX unwind descriptors for such functions. It |
---|
1010 | may even be impossible to generate them. |
---|
1011 | |
---|
1012 | * Debugging (`-g') is not supported on the HP PA machine, unless you |
---|
1013 | use the preliminary GNU tools (*note Installation::.). |
---|
1014 | |
---|
1015 | * Taking the address of a label may generate errors from the HP-UX |
---|
1016 | PA assembler. GAS for the PA does not have this problem. |
---|
1017 | |
---|
1018 | * Using floating point parameters for indirect calls to static |
---|
1019 | functions will not work when using the HP assembler. There simply |
---|
1020 | is no way for GCC to specify what registers hold arguments for |
---|
1021 | static functions when using the HP assembler. GAS for the PA does |
---|
1022 | not have this problem. |
---|
1023 | |
---|
1024 | * In extremely rare cases involving some very large functions you may |
---|
1025 | receive errors from the HP linker complaining about an out of |
---|
1026 | bounds unconditional branch offset. This used to occur more often |
---|
1027 | in previous versions of GNU CC, but is now exceptionally rare. If |
---|
1028 | you should run into it, you can work around by making your |
---|
1029 | function smaller. |
---|
1030 | |
---|
1031 | * GNU CC compiled code sometimes emits warnings from the HP-UX |
---|
1032 | assembler of the form: |
---|
1033 | |
---|
1034 | (warning) Use of GR3 when |
---|
1035 | frame >= 8192 may cause conflict. |
---|
1036 | |
---|
1037 | These warnings are harmless and can be safely ignored. |
---|
1038 | |
---|
1039 | * The current version of the assembler (`/bin/as') for the RS/6000 |
---|
1040 | has certain problems that prevent the `-g' option in GCC from |
---|
1041 | working. Note that `Makefile.in' uses `-g' by default when |
---|
1042 | compiling `libgcc2.c'. |
---|
1043 | |
---|
1044 | IBM has produced a fixed version of the assembler. The upgraded |
---|
1045 | assembler unfortunately was not included in any of the AIX 3.2 |
---|
1046 | update PTF releases (3.2.2, 3.2.3, or 3.2.3e). Users of AIX 3.1 |
---|
1047 | should request PTF U403044 from IBM and users of AIX 3.2 should |
---|
1048 | request PTF U416277. See the file `README.RS6000' for more |
---|
1049 | details on these updates. |
---|
1050 | |
---|
1051 | You can test for the presense of a fixed assembler by using the |
---|
1052 | command |
---|
1053 | |
---|
1054 | as -u < /dev/null |
---|
1055 | |
---|
1056 | If the command exits normally, the assembler fix already is |
---|
1057 | installed. If the assembler complains that "-u" is an unknown |
---|
1058 | flag, you need to order the fix. |
---|
1059 | |
---|
1060 | * On the IBM RS/6000, compiling code of the form |
---|
1061 | |
---|
1062 | extern int foo; |
---|
1063 | |
---|
1064 | ... foo ... |
---|
1065 | |
---|
1066 | static int foo; |
---|
1067 | |
---|
1068 | will cause the linker to report an undefined symbol `foo'. |
---|
1069 | Although this behavior differs from most other systems, it is not a |
---|
1070 | bug because redefining an `extern' variable as `static' is |
---|
1071 | undefined in ANSI C. |
---|
1072 | |
---|
1073 | * AIX on the RS/6000 provides support (NLS) for environments outside |
---|
1074 | of the United States. Compilers and assemblers use NLS to support |
---|
1075 | locale-specific representations of various objects including |
---|
1076 | floating-point numbers ("." vs "," for separating decimal |
---|
1077 | fractions). There have been problems reported where the library |
---|
1078 | linked with GCC does not produce the same floating-point formats |
---|
1079 | that the assembler accepts. If you have this problem, set the |
---|
1080 | LANG environment variable to "C" or "En_US". |
---|
1081 | |
---|
1082 | * Even if you specify `-fdollars-in-identifiers', you cannot |
---|
1083 | successfully use `$' in identifiers on the RS/6000 due to a |
---|
1084 | restriction in the IBM assembler. GAS supports these identifiers. |
---|
1085 | |
---|
1086 | * On the RS/6000, XLC version 1.3.0.0 will miscompile `jump.c'. XLC |
---|
1087 | version 1.3.0.1 or later fixes this problem. You can obtain |
---|
1088 | XLC-1.3.0.2 by requesting PTF 421749 from IBM. |
---|
1089 | |
---|
1090 | * There is an assembler bug in versions of DG/UX prior to 5.4.2.01 |
---|
1091 | that occurs when the `fldcr' instruction is used. GNU CC uses |
---|
1092 | `fldcr' on the 88100 to serialize volatile memory references. Use |
---|
1093 | the option `-mno-serialize-volatile' if your version of the |
---|
1094 | assembler has this bug. |
---|
1095 | |
---|
1096 | * On VMS, GAS versions 1.38.1 and earlier may cause spurious warning |
---|
1097 | messages from the linker. These warning messages complain of |
---|
1098 | mismatched psect attributes. You can ignore them. *Note VMS |
---|
1099 | Install::. |
---|
1100 | |
---|
1101 | * On NewsOS version 3, if you include both of the files `stddef.h' |
---|
1102 | and `sys/types.h', you get an error because there are two typedefs |
---|
1103 | of `size_t'. You should change `sys/types.h' by adding these |
---|
1104 | lines around the definition of `size_t': |
---|
1105 | |
---|
1106 | #ifndef _SIZE_T |
---|
1107 | #define _SIZE_T |
---|
1108 | ACTUAL TYPEDEF HERE |
---|
1109 | #endif |
---|
1110 | |
---|
1111 | * On the Alliant, the system's own convention for returning |
---|
1112 | structures and unions is unusual, and is not compatible with GNU |
---|
1113 | CC no matter what options are used. |
---|
1114 | |
---|
1115 | * On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different |
---|
1116 | convention for structure and union returning. Use the option |
---|
1117 | `-mhc-struct-return' to tell GNU CC to use a convention compatible |
---|
1118 | with it. |
---|
1119 | |
---|
1120 | * On Ultrix, the Fortran compiler expects registers 2 through 5 to |
---|
1121 | be saved by function calls. However, the C compiler uses |
---|
1122 | conventions compatible with BSD Unix: registers 2 through 5 may be |
---|
1123 | clobbered by function calls. |
---|
1124 | |
---|
1125 | GNU CC uses the same convention as the Ultrix C compiler. You can |
---|
1126 | use these options to produce code compatible with the Fortran |
---|
1127 | compiler: |
---|
1128 | |
---|
1129 | -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 |
---|
1130 | |
---|
1131 | * On the WE32k, you may find that programs compiled with GNU CC do |
---|
1132 | not work with the standard shared C library. You may need to link |
---|
1133 | with the ordinary C compiler. If you do so, you must specify the |
---|
1134 | following options: |
---|
1135 | |
---|
1136 | -L/usr/local/lib/gcc-lib/we32k-att-sysv/2.8.1 -lgcc -lc_s |
---|
1137 | |
---|
1138 | The first specifies where to find the library `libgcc.a' specified |
---|
1139 | with the `-lgcc' option. |
---|
1140 | |
---|
1141 | GNU CC does linking by invoking `ld', just as `cc' does, and there |
---|
1142 | is no reason why it *should* matter which compilation program you |
---|
1143 | use to invoke `ld'. If someone tracks this problem down, it can |
---|
1144 | probably be fixed easily. |
---|
1145 | |
---|
1146 | * On the Alpha, you may get assembler errors about invalid syntax as |
---|
1147 | a result of floating point constants. This is due to a bug in the |
---|
1148 | C library functions `ecvt', `fcvt' and `gcvt'. Given valid |
---|
1149 | floating point numbers, they sometimes print `NaN'. |
---|
1150 | |
---|
1151 | * On Irix 4.0.5F (and perhaps in some other versions), an assembler |
---|
1152 | bug sometimes reorders instructions incorrectly when optimization |
---|
1153 | is turned on. If you think this may be happening to you, try |
---|
1154 | using the GNU assembler; GAS version 2.1 supports ECOFF on Irix. |
---|
1155 | |
---|
1156 | Or use the `-noasmopt' option when you compile GNU CC with itself, |
---|
1157 | and then again when you compile your program. (This is a temporary |
---|
1158 | kludge to turn off assembler optimization on Irix.) If this |
---|
1159 | proves to be what you need, edit the assembler spec in the file |
---|
1160 | `specs' so that it unconditionally passes `-O0' to the assembler, |
---|
1161 | and never passes `-O2' or `-O3'. |
---|
1162 | |
---|