| This is Info file gcc.info, produced by Makeinfo version 1.68 from the |
| input file gcc.texi. |
| |
| This file documents the use and the internals of the GNU compiler. |
| |
| Published by the Free Software Foundation 59 Temple Place - Suite 330 |
| Boston, MA 02111-1307 USA |
| |
| Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998 |
| Free Software Foundation, Inc. |
| |
| Permission is granted to make and distribute verbatim copies of this |
| manual provided the copyright notice and this permission notice are |
| preserved on all copies. |
| |
| Permission is granted to copy and distribute modified versions of |
| this manual under the conditions for verbatim copying, provided also |
| that the sections entitled "GNU General Public License," "Funding for |
| Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are |
| included exactly as in the original, and provided that the entire |
| resulting derived work is distributed under the terms of a permission |
| notice identical to this one. |
| |
| Permission is granted to copy and distribute translations of this |
| manual into another language, under the above conditions for modified |
| versions, except that the sections entitled "GNU General Public |
| License," "Funding for Free Software," and "Protect Your Freedom--Fight |
| `Look And Feel'", and this permission notice, may be included in |
| translations approved by the Free Software Foundation instead of in the |
| original English. |
| |
| |
| File: gcc.info, Node: C++ Signatures, Prev: Template Instantiation, Up: C++ Extensions |
| |
| Type Abstraction using Signatures |
| ================================= |
| |
| In GNU C++, you can use the keyword `signature' to define a |
| completely abstract class interface as a datatype. You can connect this |
| abstraction with actual classes using signature pointers. If you want |
| to use signatures, run the GNU compiler with the `-fhandle-signatures' |
| command-line option. (With this option, the compiler reserves a second |
| keyword `sigof' as well, for a future extension.) |
| |
| Roughly, signatures are type abstractions or interfaces of classes. |
| Some other languages have similar facilities. C++ signatures are |
| related to ML's signatures, Haskell's type classes, definition modules |
| in Modula-2, interface modules in Modula-3, abstract types in Emerald, |
| type modules in Trellis/Owl, categories in Scratchpad II, and types in |
| POOL-I. For a more detailed discussion of signatures, see `Signatures: |
| A Language Extension for Improving Type Abstraction and Subtype |
| Polymorphism in C++' by Gerald Baumgartner and Vincent F. Russo (Tech |
| report CSD-TR-95-051, Dept. of Computer Sciences, Purdue University, |
| August 1995, a slightly improved version appeared in |
| *Software--Practice & Experience*, 25(8), pp. 863-889, August 1995). |
| You can get the tech report by anonymous FTP from `ftp.cs.purdue.edu' |
| in `pub/gb/Signature-design.ps.gz'. |
| |
| Syntactically, a signature declaration is a collection of member |
| function declarations and nested type declarations. For example, this |
| signature declaration defines a new abstract type `S' with member |
| functions `int foo ()' and `int bar (int)': |
| |
| signature S |
| { |
| int foo (); |
| int bar (int); |
| }; |
| |
| Since signature types do not include implementation definitions, you |
| cannot write an instance of a signature directly. Instead, you can |
| define a pointer to any class that contains the required interfaces as a |
| "signature pointer". Such a class "implements" the signature type. |
| |
| To use a class as an implementation of `S', you must ensure that the |
| class has public member functions `int foo ()' and `int bar (int)'. |
| The class can have other member functions as well, public or not; as |
| long as it offers what's declared in the signature, it is suitable as |
| an implementation of that signature type. |
| |
| For example, suppose that `C' is a class that meets the requirements |
| of signature `S' (`C' "conforms to" `S'). Then |
| |
| C obj; |
| S * p = &obj; |
| |
| defines a signature pointer `p' and initializes it to point to an |
| object of type `C'. The member function call `int i = p->foo ();' |
| executes `obj.foo ()'. |
| |
| Abstract virtual classes provide somewhat similar facilities in |
| standard C++. There are two main advantages to using signatures |
| instead: |
| |
| 1. Subtyping becomes independent from inheritance. A class or |
| signature type `T' is a subtype of a signature type `S' |
| independent of any inheritance hierarchy as long as all the member |
| functions declared in `S' are also found in `T'. So you can |
| define a subtype hierarchy that is completely independent from any |
| inheritance (implementation) hierarchy, instead of being forced to |
| use types that mirror the class inheritance hierarchy. |
| |
| 2. Signatures allow you to work with existing class hierarchies as |
| implementations of a signature type. If those class hierarchies |
| are only available in compiled form, you're out of luck with |
| abstract virtual classes, since an abstract virtual class cannot |
| be retrofitted on top of existing class hierarchies. So you would |
| be required to write interface classes as subtypes of the abstract |
| virtual class. |
| |
| There is one more detail about signatures. A signature declaration |
| can contain member function *definitions* as well as member function |
| declarations. A signature member function with a full definition is |
| called a *default implementation*; classes need not contain that |
| particular interface in order to conform. For example, a class `C' can |
| conform to the signature |
| |
| signature T |
| { |
| int f (int); |
| int f0 () { return f (0); }; |
| }; |
| |
| whether or not `C' implements the member function `int f0 ()'. If you |
| define `C::f0', that definition takes precedence; otherwise, the |
| default implementation `S::f0' applies. |
| |
| |
| File: gcc.info, Node: Gcov, Next: Trouble, Prev: C++ Extensions, Up: Top |
| |
| `gcov': a Test Coverage Program |
| ******************************* |
| |
| `gcov' is a tool you can use in conjunction with GNU CC to test code |
| coverage in your programs. |
| |
| This chapter describes version 1.5 of `gcov'. |
| |
| * Menu: |
| |
| * Gcov Intro:: Introduction to gcov. |
| * Invoking Gcov:: How to use gcov. |
| * Gcov and Optimization:: Using gcov with GCC optimization. |
| * Gcov Data Files:: The files used by gcov. |
| |
| |
| File: gcc.info, Node: Gcov Intro, Next: Invoking Gcov, Up: Gcov |
| |
| Introduction to `gcov' |
| ====================== |
| |
| `gcov' is a test coverage program. Use it in concert with GNU CC to |
| analyze your programs to help create more efficient, faster running |
| code. You can use `gcov' as a profiling tool to help discover where |
| your optimization efforts will best affect your code. You can also use |
| `gcov' along with the other profiling tool, `gprof', to assess which |
| parts of your code use the greatest amount of computing time. |
| |
| Profiling tools help you analyze your code's performance. Using a |
| profiler such as `gcov' or `gprof', you can find out some basic |
| performance statistics, such as: |
| |
| * how often each line of code executes |
| |
| * what lines of code are actually executed |
| |
| * how much computing time each section of code uses |
| |
| Once you know these things about how your code works when compiled, |
| you can look at each module to see which modules should be optimized. |
| `gcov' helps you determine where to work on optimization. |
| |
| Software developers also use coverage testing in concert with |
| testsuites, to make sure software is actually good enough for a release. |
| Testsuites can verify that a program works as expected; a coverage |
| program tests to see how much of the program is exercised by the |
| testsuite. Developers can then determine what kinds of test cases need |
| to be added to the testsuites to create both better testing and a better |
| final product. |
| |
| You should compile your code without optimization if you plan to use |
| `gcov' because the optimization, by combining some lines of code into |
| one function, may not give you as much information as you need to look |
| for `hot spots' where the code is using a great deal of computer time. |
| Likewise, because `gcov' accumulates statistics by line (at the lowest |
| resolution), it works best with a programming style that places only |
| one statement on each line. If you use complicated macros that expand |
| to loops or to other control structures, the statistics are less |
| helpful--they only report on the line where the macro call appears. If |
| your complex macros behave like functions, you can replace them with |
| inline functions to solve this problem. |
| |
| `gcov' creates a logfile called `SOURCEFILE.gcov' which indicates |
| how many times each line of a source file `SOURCEFILE.c' has executed. |
| You can use these logfiles along with `gprof' to aid in fine-tuning the |
| performance of your programs. `gprof' gives timing information you can |
| use along with the information you get from `gcov'. |
| |
| `gcov' works only on code compiled with GNU CC. It is not |
| compatible with any other profiling or test coverage mechanism. |
| |
| |
| File: gcc.info, Node: Invoking Gcov, Next: Gcov and Optimization, Prev: Gcov Intro, Up: Gcov |
| |
| Invoking gcov |
| ============= |
| |
| gcov [-b] [-v] [-n] [-l] [-f] [-o directory] SOURCEFILE |
| |
| `-b' |
| Write branch frequencies to the output file, and write branch |
| summary info to the standard output. This option allows you to |
| see how often each branch in your program was taken. |
| |
| `-v' |
| Display the `gcov' version number (on the standard error stream). |
| |
| `-n' |
| Do not create the `gcov' output file. |
| |
| `-l' |
| Create long file names for included source files. For example, if |
| the header file `x.h' contains code, and was included in the file |
| `a.c', then running `gcov' on the file `a.c' will produce an |
| output file called `a.c.x.h.gcov' instead of `x.h.gcov'. This can |
| be useful if `x.h' is included in multiple source files. |
| |
| `-f' |
| Output summaries for each function in addition to the file level |
| summary. |
| |
| `-o' |
| The directory where the object files live. Gcov will search for |
| `.bb', `.bbg', and `.da' files in this directory. |
| |
| When using `gcov', you must first compile your program with two |
| special GNU CC options: `-fprofile-arcs -ftest-coverage'. This tells |
| the compiler to generate additional information needed by gcov |
| (basically a flow graph of the program) and also includes additional |
| code in the object files for generating the extra profiling information |
| needed by gcov. These additional files are placed in the directory |
| where the source code is located. |
| |
| Running the program will cause profile output to be generated. For |
| each source file compiled with -fprofile-arcs, an accompanying `.da' |
| file will be placed in the source directory. |
| |
| Running `gcov' with your program's source file names as arguments |
| will now produce a listing of the code along with frequency of execution |
| for each line. For example, if your program is called `tmp.c', this is |
| what you see when you use the basic `gcov' facility: |
| |
| $ gcc -fprofile-arcs -ftest-coverage tmp.c |
| $ a.out |
| $ gcov tmp.c |
| 87.50% of 8 source lines executed in file tmp.c |
| Creating tmp.c.gcov. |
| |
| The file `tmp.c.gcov' contains output from `gcov'. Here is a sample: |
| |
| main() |
| { |
| 1 int i, total; |
| |
| 1 total = 0; |
| |
| 11 for (i = 0; i < 10; i++) |
| 10 total += i; |
| |
| 1 if (total != 45) |
| ###### printf ("Failure\n"); |
| else |
| 1 printf ("Success\n"); |
| 1 } |
| |
| When you use the `-b' option, your output looks like this: |
| |
| $ gcov -b tmp.c |
| 87.50% of 8 source lines executed in file tmp.c |
| 80.00% of 5 branches executed in file tmp.c |
| 80.00% of 5 branches taken at least once in file tmp.c |
| 50.00% of 2 calls executed in file tmp.c |
| Creating tmp.c.gcov. |
| |
| Here is a sample of a resulting `tmp.c.gcov' file: |
| |
| main() |
| { |
| 1 int i, total; |
| |
| 1 total = 0; |
| |
| 11 for (i = 0; i < 10; i++) |
| branch 0 taken = 91% |
| branch 1 taken = 100% |
| branch 2 taken = 100% |
| 10 total += i; |
| |
| 1 if (total != 45) |
| branch 0 taken = 100% |
| ###### printf ("Failure\n"); |
| call 0 never executed |
| branch 1 never executed |
| else |
| 1 printf ("Success\n"); |
| call 0 returns = 100% |
| 1 } |
| |
| For each basic block, a line is printed after the last line of the |
| basic block describing the branch or call that ends the basic block. |
| There can be multiple branches and calls listed for a single source |
| line if there are multiple basic blocks that end on that line. In this |
| case, the branches and calls are each given a number. There is no |
| simple way to map these branches and calls back to source constructs. |
| In general, though, the lowest numbered branch or call will correspond |
| to the leftmost construct on the source line. |
| |
| For a branch, if it was executed at least once, then a percentage |
| indicating the number of times the branch was taken divided by the |
| number of times the branch was executed will be printed. Otherwise, the |
| message "never executed" is printed. |
| |
| For a call, if it was executed at least once, then a percentage |
| indicating the number of times the call returned divided by the number |
| of times the call was executed will be printed. This will usually be |
| 100%, but may be less for functions call `exit' or `longjmp', and thus |
| may not return everytime they are called. |
| |
| The execution counts are cumulative. If the example program were |
| executed again without removing the `.da' file, the count for the |
| number of times each line in the source was executed would be added to |
| the results of the previous run(s). This is potentially useful in |
| several ways. For example, it could be used to accumulate data over a |
| number of program runs as part of a test verification suite, or to |
| provide more accurate long-term information over a large number of |
| program runs. |
| |
| The data in the `.da' files is saved immediately before the program |
| exits. For each source file compiled with -fprofile-arcs, the profiling |
| code first attempts to read in an existing `.da' file; if the file |
| doesn't match the executable (differing number of basic block counts) it |
| will ignore the contents of the file. It then adds in the new execution |
| counts and finally writes the data to the file. |
| |
| |
| File: gcc.info, Node: Gcov and Optimization, Next: Gcov Data Files, Prev: Invoking Gcov, Up: Gcov |
| |
| Using `gcov' with GCC Optimization |
| ================================== |
| |
| If you plan to use `gcov' to help optimize your code, you must first |
| compile your program with two special GNU CC options: `-fprofile-arcs |
| -ftest-coverage'. Aside from that, you can use any other GNU CC |
| options; but if you want to prove that every single line in your |
| program was executed, you should not compile with optimization at the |
| same time. On some machines the optimizer can eliminate some simple |
| code lines by combining them with other lines. For example, code like |
| this: |
| |
| if (a != b) |
| c = 1; |
| else |
| c = 0; |
| |
| can be compiled into one instruction on some machines. In this case, |
| there is no way for `gcov' to calculate separate execution counts for |
| each line because there isn't separate code for each line. Hence the |
| `gcov' output looks like this if you compiled the program with |
| optimization: |
| |
| 100 if (a != b) |
| 100 c = 1; |
| 100 else |
| 100 c = 0; |
| |
| The output shows that this block of code, combined by optimization, |
| executed 100 times. In one sense this result is correct, because there |
| was only one instruction representing all four of these lines. However, |
| the output does not indicate how many times the result was 0 and how |
| many times the result was 1. |
| |
| |
| File: gcc.info, Node: Gcov Data Files, Prev: Gcov and Optimization, Up: Gcov |
| |
| Brief description of `gcov' data files |
| ====================================== |
| |
| `gcov' uses three files for doing profiling. The names of these |
| files are derived from the original *source* file by substituting the |
| file suffix with either `.bb', `.bbg', or `.da'. All of these files |
| are placed in the same directory as the source file, and contain data |
| stored in a platform-independent method. |
| |
| The `.bb' and `.bbg' files are generated when the source file is |
| compiled with the GNU CC `-ftest-coverage' option. The `.bb' file |
| contains a list of source files (including headers), functions within |
| those files, and line numbers corresponding to each basic block in the |
| source file. |
| |
| The `.bb' file format consists of several lists of 4-byte integers |
| which correspond to the line numbers of each basic block in the file. |
| Each list is terminated by a line number of 0. A line number of -1 is |
| used to designate that the source file name (padded to a 4-byte |
| boundary and followed by another -1) follows. In addition, a line |
| number of -2 is used to designate that the name of a function (also |
| padded to a 4-byte boundary and followed by a -2) follows. |
| |
| The `.bbg' file is used to reconstruct the program flow graph for |
| the source file. It contains a list of the program flow arcs (possible |
| branches taken from one basic block to another) for each function which, |
| in combination with the `.bb' file, enables gcov to reconstruct the |
| program flow. |
| |
| In the `.bbg' file, the format is: |
| number of basic blocks for function #0 (4-byte number) |
| total number of arcs for function #0 (4-byte number) |
| count of arcs in basic block #0 (4-byte number) |
| destination basic block of arc #0 (4-byte number) |
| flag bits (4-byte number) |
| destination basic block of arc #1 (4-byte number) |
| flag bits (4-byte number) |
| ... |
| destination basic block of arc #N (4-byte number) |
| flag bits (4-byte number) |
| count of arcs in basic block #1 (4-byte number) |
| destination basic block of arc #0 (4-byte number) |
| flag bits (4-byte number) |
| ... |
| |
| A -1 (stored as a 4-byte number) is used to separate each function's |
| list of basic blocks, and to verify that the file has been read |
| correctly. |
| |
| The `.da' file is generated when a program containing object files |
| built with the GNU CC `-fprofile-arcs' option is executed. A separate |
| `.da' file is created for each source file compiled with this option, |
| and the name of the `.da' file is stored as an absolute pathname in the |
| resulting object file. This path name is derived from the source file |
| name by substituting a `.da' suffix. |
| |
| The format of the `.da' file is fairly simple. The first 8-byte |
| number is the number of counts in the file, followed by the counts |
| (stored as 8-byte numbers). Each count corresponds to the number of |
| times each arc in the program is executed. The counts are cumulative; |
| each time the program is executed, it attemps to combine the existing |
| `.da' files with the new counts for this invocation of the program. It |
| ignores the contents of any `.da' files whose number of arcs doesn't |
| correspond to the current program, and merely overwrites them instead. |
| |
| All three of these files use the functions in `gcov-io.h' to store |
| integers; the functions in this header provide a machine-independent |
| mechanism for storing and retrieving data from a stream. |
| |
| |
| File: gcc.info, Node: Trouble, Next: Bugs, Prev: Gcov, Up: Top |
| |
| Known Causes of Trouble with GNU CC |
| *********************************** |
| |
| This section describes known problems that affect users of GNU CC. |
| Most of these are not GNU CC bugs per se--if they were, we would fix |
| them. But the result for a user may be like the result of a bug. |
| |
| Some of these problems are due to bugs in other software, some are |
| missing features that are too much work to add, and some are places |
| where people's opinions differ as to what is best. |
| |
| * Menu: |
| |
| * Actual Bugs:: Bugs we will fix later. |
| * Installation Problems:: Problems that manifest when you install GNU CC. |
| * Cross-Compiler Problems:: Common problems of cross compiling with GNU CC. |
| * Interoperation:: Problems using GNU CC with other compilers, |
| and with certain linkers, assemblers and debuggers. |
| * External Bugs:: Problems compiling certain programs. |
| * Incompatibilities:: GNU CC is incompatible with traditional C. |
| * Fixed Headers:: GNU C uses corrected versions of system header files. |
| This is necessary, but doesn't always work smoothly. |
| * Standard Libraries:: GNU C uses the system C library, which might not be |
| compliant with the ISO/ANSI C standard. |
| * Disappointments:: Regrettable things we can't change, but not quite bugs. |
| * C++ Misunderstandings:: Common misunderstandings with GNU C++. |
| * Protoize Caveats:: Things to watch out for when using `protoize'. |
| * Non-bugs:: Things we think are right, but some others disagree. |
| * Warnings and Errors:: Which problems in your code get warnings, |
| and which get errors. |
| |
| |
| File: gcc.info, Node: Actual Bugs, Next: Installation Problems, Up: Trouble |
| |
| Actual Bugs We Haven't Fixed Yet |
| ================================ |
| |
| * The `fixincludes' script interacts badly with automounters; if the |
| directory of system header files is automounted, it tends to be |
| unmounted while `fixincludes' is running. This would seem to be a |
| bug in the automounter. We don't know any good way to work around |
| it. |
| |
| * The `fixproto' script will sometimes add prototypes for the |
| `sigsetjmp' and `siglongjmp' functions that reference the |
| `jmp_buf' type before that type is defined. To work around this, |
| edit the offending file and place the typedef in front of the |
| prototypes. |
| |
| * There are several obscure case of mis-using struct, union, and |
| enum tags that are not detected as errors by the compiler. |
| |
| * When `-pedantic-errors' is specified, GNU C will incorrectly give |
| an error message when a function name is specified in an expression |
| involving the comma operator. |
| |
| * Loop unrolling doesn't work properly for certain C++ programs. |
| This is a bug in the C++ front end. It sometimes emits incorrect |
| debug info, and the loop unrolling code is unable to recover from |
| this error. |
| |
| |
| File: gcc.info, Node: Installation Problems, Next: Cross-Compiler Problems, Prev: Actual Bugs, Up: Trouble |
| |
| Installation Problems |
| ===================== |
| |
| This is a list of problems (and some apparent problems which don't |
| really mean anything is wrong) that show up during installation of GNU |
| CC. |
| |
| * On certain systems, defining certain environment variables such as |
| `CC' can interfere with the functioning of `make'. |
| |
| * If you encounter seemingly strange errors when trying to build the |
| compiler in a directory other than the source directory, it could |
| be because you have previously configured the compiler in the |
| source directory. Make sure you have done all the necessary |
| preparations. *Note Other Dir::. |
| |
| * If you build GNU CC on a BSD system using a directory stored in a |
| System V file system, problems may occur in running `fixincludes' |
| if the System V file system doesn't support symbolic links. These |
| problems result in a failure to fix the declaration of `size_t' in |
| `sys/types.h'. If you find that `size_t' is a signed type and |
| that type mismatches occur, this could be the cause. |
| |
| The solution is not to use such a directory for building GNU CC. |
| |
| * In previous versions of GNU CC, the `gcc' driver program looked for |
| `as' and `ld' in various places; for example, in files beginning |
| with `/usr/local/lib/gcc-'. GNU CC version 2 looks for them in |
| the directory `/usr/local/lib/gcc-lib/TARGET/VERSION'. |
| |
| Thus, to use a version of `as' or `ld' that is not the system |
| default, for example `gas' or GNU `ld', you must put them in that |
| directory (or make links to them from that directory). |
| |
| * Some commands executed when making the compiler may fail (return a |
| non-zero status) and be ignored by `make'. These failures, which |
| are often due to files that were not found, are expected, and can |
| safely be ignored. |
| |
| * It is normal to have warnings in compiling certain files about |
| unreachable code and about enumeration type clashes. These files' |
| names begin with `insn-'. Also, `real.c' may get some warnings |
| that you can ignore. |
| |
| * Sometimes `make' recompiles parts of the compiler when installing |
| the compiler. In one case, this was traced down to a bug in |
| `make'. Either ignore the problem or switch to GNU Make. |
| |
| * If you have installed a program known as purify, you may find that |
| it causes errors while linking `enquire', which is part of building |
| GNU CC. The fix is to get rid of the file `real-ld' which purify |
| installs--so that GNU CC won't try to use it. |
| |
| * On GNU/Linux SLS 1.01, there is a problem with `libc.a': it does |
| not contain the obstack functions. However, GNU CC assumes that |
| the obstack functions are in `libc.a' when it is the GNU C |
| library. To work around this problem, change the |
| `__GNU_LIBRARY__' conditional around line 31 to `#if 1'. |
| |
| * On some 386 systems, building the compiler never finishes because |
| `enquire' hangs due to a hardware problem in the motherboard--it |
| reports floating point exceptions to the kernel incorrectly. You |
| can install GNU CC except for `float.h' by patching out the |
| command to run `enquire'. You may also be able to fix the problem |
| for real by getting a replacement motherboard. This problem was |
| observed in Revision E of the Micronics motherboard, and is fixed |
| in Revision F. It has also been observed in the MYLEX MXA-33 |
| motherboard. |
| |
| If you encounter this problem, you may also want to consider |
| removing the FPU from the socket during the compilation. |
| Alternatively, if you are running SCO Unix, you can reboot and |
| force the FPU to be ignored. To do this, type `hd(40)unix auto |
| ignorefpu'. |
| |
| * On some 386 systems, GNU CC crashes trying to compile `enquire.c'. |
| This happens on machines that don't have a 387 FPU chip. On 386 |
| machines, the system kernel is supposed to emulate the 387 when you |
| don't have one. The crash is due to a bug in the emulator. |
| |
| One of these systems is the Unix from Interactive Systems: 386/ix. |
| On this system, an alternate emulator is provided, and it does |
| work. To use it, execute this command as super-user: |
| |
| ln /etc/emulator.rel1 /etc/emulator |
| |
| and then reboot the system. (The default emulator file remains |
| present under the name `emulator.dflt'.) |
| |
| Try using `/etc/emulator.att', if you have such a problem on the |
| SCO system. |
| |
| Another system which has this problem is Esix. We don't know |
| whether it has an alternate emulator that works. |
| |
| On NetBSD 0.8, a similar problem manifests itself as these error |
| messages: |
| |
| enquire.c: In function `fprop': |
| enquire.c:2328: floating overflow |
| |
| * On SCO systems, when compiling GNU CC with the system's compiler, |
| do not use `-O'. Some versions of the system's compiler miscompile |
| GNU CC with `-O'. |
| |
| * Sometimes on a Sun 4 you may observe a crash in the program |
| `genflags' or `genoutput' while building GNU CC. This is said to |
| be due to a bug in `sh'. You can probably get around it by running |
| `genflags' or `genoutput' manually and then retrying the `make'. |
| |
| * On Solaris 2, executables of GNU CC version 2.0.2 are commonly |
| available, but they have a bug that shows up when compiling current |
| versions of GNU CC: undefined symbol errors occur during assembly |
| if you use `-g'. |
| |
| The solution is to compile the current version of GNU CC without |
| `-g'. That makes a working compiler which you can use to recompile |
| with `-g'. |
| |
| * Solaris 2 comes with a number of optional OS packages. Some of |
| these packages are needed to use GNU CC fully. If you did not |
| install all optional packages when installing Solaris, you will |
| need to verify that the packages that GNU CC needs are installed. |
| |
| To check whether an optional package is installed, use the |
| `pkginfo' command. To add an optional package, use the `pkgadd' |
| command. For further details, see the Solaris documentation. |
| |
| For Solaris 2.0 and 2.1, GNU CC needs six packages: `SUNWarc', |
| `SUNWbtool', `SUNWesu', `SUNWhea', `SUNWlibm', and `SUNWtoo'. |
| |
| For Solaris 2.2, GNU CC needs an additional seventh package: |
| `SUNWsprot'. |
| |
| * On Solaris 2, trying to use the linker and other tools in |
| `/usr/ucb' to install GNU CC has been observed to cause trouble. |
| For example, the linker may hang indefinitely. The fix is to |
| remove `/usr/ucb' from your `PATH'. |
| |
| * If you use the 1.31 version of the MIPS assembler (such as was |
| shipped with Ultrix 3.1), you will need to use the |
| -fno-delayed-branch switch when optimizing floating point code. |
| Otherwise, the assembler will complain when the GCC compiler fills |
| a branch delay slot with a floating point instruction, such as |
| `add.d'. |
| |
| * If on a MIPS system you get an error message saying "does not have |
| gp sections for all it's [sic] sectons [sic]", don't worry about |
| it. This happens whenever you use GAS with the MIPS linker, but |
| there is not really anything wrong, and it is okay to use the |
| output file. You can stop such warnings by installing the GNU |
| linker. |
| |
| It would be nice to extend GAS to produce the gp tables, but they |
| are optional, and there should not be a warning about their |
| absence. |
| |
| * In Ultrix 4.0 on the MIPS machine, `stdio.h' does not work with GNU |
| CC at all unless it has been fixed with `fixincludes'. This causes |
| problems in building GNU CC. Once GNU CC is installed, the |
| problems go away. |
| |
| To work around this problem, when making the stage 1 compiler, |
| specify this option to Make: |
| |
| GCC_FOR_TARGET="./xgcc -B./ -I./include" |
| |
| When making stage 2 and stage 3, specify this option: |
| |
| CFLAGS="-g -I./include" |
| |
| * Users have reported some problems with version 2.0 of the MIPS |
| compiler tools that were shipped with Ultrix 4.1. Version 2.10 |
| which came with Ultrix 4.2 seems to work fine. |
| |
| Users have also reported some problems with version 2.20 of the |
| MIPS compiler tools that were shipped with RISC/os 4.x. The |
| earlier version 2.11 seems to work fine. |
| |
| * Some versions of the MIPS linker will issue an assertion failure |
| when linking code that uses `alloca' against shared libraries on |
| RISC-OS 5.0, and DEC's OSF/1 systems. This is a bug in the |
| linker, that is supposed to be fixed in future revisions. To |
| protect against this, GNU CC passes `-non_shared' to the linker |
| unless you pass an explicit `-shared' or `-call_shared' switch. |
| |
| * On System V release 3, you may get this error message while |
| linking: |
| |
| ld fatal: failed to write symbol name SOMETHING |
| in strings table for file WHATEVER |
| |
| This probably indicates that the disk is full or your ULIMIT won't |
| allow the file to be as large as it needs to be. |
| |
| This problem can also result because the kernel parameter `MAXUMEM' |
| is too small. If so, you must regenerate the kernel and make the |
| value much larger. The default value is reported to be 1024; a |
| value of 32768 is said to work. Smaller values may also work. |
| |
| * On System V, if you get an error like this, |
| |
| /usr/local/lib/bison.simple: In function `yyparse': |
| /usr/local/lib/bison.simple:625: virtual memory exhausted |
| |
| that too indicates a problem with disk space, ULIMIT, or `MAXUMEM'. |
| |
| * Current GNU CC versions probably do not work on version 2 of the |
| NeXT operating system. |
| |
| * On NeXTStep 3.0, the Objective C compiler does not work, due, |
| apparently, to a kernel bug that it happens to trigger. This |
| problem does not happen on 3.1. |
| |
| * On the Tower models 4N0 and 6N0, by default a process is not |
| allowed to have more than one megabyte of memory. GNU CC cannot |
| compile itself (or many other programs) with `-O' in that much |
| memory. |
| |
| To solve this problem, reconfigure the kernel adding the following |
| line to the configuration file: |
| |
| MAXUMEM = 4096 |
| |
| * On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a |
| bug in the assembler that must be fixed before GNU CC can be |
| built. This bug manifests itself during the first stage of |
| compilation, while building `libgcc2.a': |
| |
| _floatdisf |
| cc1: warning: `-g' option not supported on this version of GCC |
| cc1: warning: `-g1' option not supported on this version of GCC |
| ./xgcc: Internal compiler error: program as got fatal signal 11 |
| |
| A patched version of the assembler is available by anonymous ftp |
| from `altdorf.ai.mit.edu' as the file |
| `archive/cph/hpux-8.0-assembler'. If you have HP software support, |
| the patch can also be obtained directly from HP, as described in |
| the following note: |
| |
| This is the patched assembler, to patch SR#1653-010439, where |
| the assembler aborts on floating point constants. |
| |
| The bug is not really in the assembler, but in the shared |
| library version of the function "cvtnum(3c)". The bug on |
| "cvtnum(3c)" is SR#4701-078451. Anyway, the attached |
| assembler uses the archive library version of "cvtnum(3c)" |
| and thus does not exhibit the bug. |
| |
| This patch is also known as PHCO_4484. |
| |
| * On HP-UX version 8.05, but not on 8.07 or more recent versions, |
| the `fixproto' shell script triggers a bug in the system shell. |
| If you encounter this problem, upgrade your operating system or |
| use BASH (the GNU shell) to run `fixproto'. |
| |
| * Some versions of the Pyramid C compiler are reported to be unable |
| to compile GNU CC. You must use an older version of GNU CC for |
| bootstrapping. One indication of this problem is if you get a |
| crash when GNU CC compiles the function `muldi3' in file |
| `libgcc2.c'. |
| |
| You may be able to succeed by getting GNU CC version 1, installing |
| it, and using it to compile GNU CC version 2. The bug in the |
| Pyramid C compiler does not seem to affect GNU CC version 1. |
| |
| * There may be similar problems on System V Release 3.1 on 386 |
| systems. |
| |
| * On the Intel Paragon (an i860 machine), if you are using operating |
| system version 1.0, you will get warnings or errors about |
| redefinition of `va_arg' when you build GNU CC. |
| |
| If this happens, then you need to link most programs with the |
| library `iclib.a'. You must also modify `stdio.h' as follows: |
| before the lines |
| |
| #if defined(__i860__) && !defined(_VA_LIST) |
| #include <va_list.h> |
| |
| insert the line |
| |
| #if __PGC__ |
| |
| and after the lines |
| |
| extern int vprintf(const char *, va_list ); |
| extern int vsprintf(char *, const char *, va_list ); |
| #endif |
| |
| insert the line |
| |
| #endif /* __PGC__ */ |
| |
| These problems don't exist in operating system version 1.1. |
| |
| * On the Altos 3068, programs compiled with GNU CC won't work unless |
| you fix a kernel bug. This happens using system versions V.2.2 |
| 1.0gT1 and V.2.2 1.0e and perhaps later versions as well. See the |
| file `README.ALTOS'. |
| |
| * You will get several sorts of compilation and linking errors on the |
| we32k if you don't follow the special instructions. *Note |
| Configurations::. |
| |
| * A bug in the HP-UX 8.05 (and earlier) shell will cause the fixproto |
| program to report an error of the form: |
| |
| ./fixproto: sh internal 1K buffer overflow |
| |
| To fix this, change the first line of the fixproto script to look |
| like: |
| |
| #!/bin/ksh |
| |
| |
| File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Installation Problems, Up: Trouble |
| |
| Cross-Compiler Problems |
| ======================= |
| |
| You may run into problems with cross compilation on certain machines, |
| for several reasons. |
| |
| * Cross compilation can run into trouble for certain machines because |
| some target machines' assemblers require floating point numbers to |
| be written as *integer* constants in certain contexts. |
| |
| The compiler writes these integer constants by examining the |
| floating point value as an integer and printing that integer, |
| because this is simple to write and independent of the details of |
| the floating point representation. But this does not work if the |
| compiler is running on a different machine with an incompatible |
| floating point format, or even a different byte-ordering. |
| |
| In addition, correct constant folding of floating point values |
| requires representing them in the target machine's format. (The C |
| standard does not quite require this, but in practice it is the |
| only way to win.) |
| |
| It is now possible to overcome these problems by defining macros |
| such as `REAL_VALUE_TYPE'. But doing so is a substantial amount of |
| work for each target machine. *Note Cross-compilation::. |
| |
| * At present, the program `mips-tfile' which adds debug support to |
| object files on MIPS systems does not work in a cross compile |
| environment. |
| |
| |
| File: gcc.info, Node: Interoperation, Next: External Bugs, Prev: Cross-Compiler Problems, Up: Trouble |
| |
| Interoperation |
| ============== |
| |
| This section lists various difficulties encountered in using GNU C or |
| GNU C++ together with other compilers or with the assemblers, linkers, |
| libraries and debuggers on certain systems. |
| |
| * Objective C does not work on the RS/6000. |
| |
| * GNU C++ does not do name mangling in the same way as other C++ |
| compilers. This means that object files compiled with one compiler |
| cannot be used with another. |
| |
| This effect is intentional, to protect you from more subtle |
| problems. Compilers differ as to many internal details of C++ |
| implementation, including: how class instances are laid out, how |
| multiple inheritance is implemented, and how virtual function |
| calls are handled. If the name encoding were made the same, your |
| programs would link against libraries provided from other |
| compilers--but the programs would then crash when run. |
| Incompatible libraries are then detected at link time, rather than |
| at run time. |
| |
| * Older GDB versions sometimes fail to read the output of GNU CC |
| version 2. If you have trouble, get GDB version 4.4 or later. |
| |
| * DBX rejects some files produced by GNU CC, though it accepts |
| similar constructs in output from PCC. Until someone can supply a |
| coherent description of what is valid DBX input and what is not, |
| there is nothing I can do about these problems. You are on your |
| own. |
| |
| * The GNU assembler (GAS) does not support PIC. To generate PIC |
| code, you must use some other assembler, such as `/bin/as'. |
| |
| * On some BSD systems, including some versions of Ultrix, use of |
| profiling causes static variable destructors (currently used only |
| in C++) not to be run. |
| |
| * Use of `-I/usr/include' may cause trouble. |
| |
| Many systems come with header files that won't work with GNU CC |
| unless corrected by `fixincludes'. The corrected header files go |
| in a new directory; GNU CC searches this directory before |
| `/usr/include'. If you use `-I/usr/include', this tells GNU CC to |
| search `/usr/include' earlier on, before the corrected headers. |
| The result is that you get the uncorrected header files. |
| |
| Instead, you should use these options (when compiling C programs): |
| |
| -I/usr/local/lib/gcc-lib/TARGET/VERSION/include -I/usr/include |
| |
| For C++ programs, GNU CC also uses a special directory that |
| defines C++ interfaces to standard C subroutines. This directory |
| is meant to be searched *before* other standard include |
| directories, so that it takes precedence. If you are compiling |
| C++ programs and specifying include directories explicitly, use |
| this option first, then the two options above: |
| |
| -I/usr/local/lib/g++-include |
| |
| * On some SGI systems, when you use `-lgl_s' as an option, it gets |
| translated magically to `-lgl_s -lX11_s -lc_s'. Naturally, this |
| does not happen when you use GNU CC. You must specify all three |
| options explicitly. |
| |
| * On a Sparc, GNU CC aligns all values of type `double' on an 8-byte |
| boundary, and it expects every `double' to be so aligned. The Sun |
| compiler usually gives `double' values 8-byte alignment, with one |
| exception: function arguments of type `double' may not be aligned. |
| |
| As a result, if a function compiled with Sun CC takes the address |
| of an argument of type `double' and passes this pointer of type |
| `double *' to a function compiled with GNU CC, dereferencing the |
| pointer may cause a fatal signal. |
| |
| One way to solve this problem is to compile your entire program |
| with GNU CC. Another solution is to modify the function that is |
| compiled with Sun CC to copy the argument into a local variable; |
| local variables are always properly aligned. A third solution is |
| to modify the function that uses the pointer to dereference it via |
| the following function `access_double' instead of directly with |
| `*': |
| |
| inline double |
| access_double (double *unaligned_ptr) |
| { |
| union d2i { double d; int i[2]; }; |
| |
| union d2i *p = (union d2i *) unaligned_ptr; |
| union d2i u; |
| |
| u.i[0] = p->i[0]; |
| u.i[1] = p->i[1]; |
| |
| return u.d; |
| } |
| |
| Storing into the pointer can be done likewise with the same union. |
| |
| * On Solaris, the `malloc' function in the `libmalloc.a' library may |
| allocate memory that is only 4 byte aligned. Since GNU CC on the |
| Sparc assumes that doubles are 8 byte aligned, this may result in a |
| fatal signal if doubles are stored in memory allocated by the |
| `libmalloc.a' library. |
| |
| The solution is to not use the `libmalloc.a' library. Use instead |
| `malloc' and related functions from `libc.a'; they do not have |
| this problem. |
| |
| * Sun forgot to include a static version of `libdl.a' with some |
| versions of SunOS (mainly 4.1). This results in undefined symbols |
| when linking static binaries (that is, if you use `-static'). If |
| you see undefined symbols `_dlclose', `_dlsym' or `_dlopen' when |
| linking, compile and link against the file `mit/util/misc/dlsym.c' |
| from the MIT version of X windows. |
| |
| * The 128-bit long double format that the Sparc port supports |
| currently works by using the architecturally defined quad-word |
| floating point instructions. Since there is no hardware that |
| supports these instructions they must be emulated by the operating |
| system. Long doubles do not work in Sun OS versions 4.0.3 and |
| earlier, because the kernel emulator uses an obsolete and |
| incompatible format. Long doubles do not work in Sun OS version |
| 4.1.1 due to a problem in a Sun library. Long doubles do work on |
| Sun OS versions 4.1.2 and higher, but GNU CC does not enable them |
| by default. Long doubles appear to work in Sun OS 5.x (Solaris |
| 2.x). |
| |
| * On HP-UX version 9.01 on the HP PA, the HP compiler `cc' does not |
| compile GNU CC correctly. We do not yet know why. However, GNU CC |
| compiled on earlier HP-UX versions works properly on HP-UX 9.01 |
| and can compile itself properly on 9.01. |
| |
| * On the HP PA machine, ADB sometimes fails to work on functions |
| compiled with GNU CC. Specifically, it fails to work on functions |
| that use `alloca' or variable-size arrays. This is because GNU CC |
| doesn't generate HP-UX unwind descriptors for such functions. It |
| may even be impossible to generate them. |
| |
| * Debugging (`-g') is not supported on the HP PA machine, unless you |
| use the preliminary GNU tools (*note Installation::.). |
| |
| * Taking the address of a label may generate errors from the HP-UX |
| PA assembler. GAS for the PA does not have this problem. |
| |
| * Using floating point parameters for indirect calls to static |
| functions will not work when using the HP assembler. There simply |
| is no way for GCC to specify what registers hold arguments for |
| static functions when using the HP assembler. GAS for the PA does |
| not have this problem. |
| |
| * In extremely rare cases involving some very large functions you may |
| receive errors from the HP linker complaining about an out of |
| bounds unconditional branch offset. This used to occur more often |
| in previous versions of GNU CC, but is now exceptionally rare. If |
| you should run into it, you can work around by making your |
| function smaller. |
| |
| * GNU CC compiled code sometimes emits warnings from the HP-UX |
| assembler of the form: |
| |
| (warning) Use of GR3 when |
| frame >= 8192 may cause conflict. |
| |
| These warnings are harmless and can be safely ignored. |
| |
| * The current version of the assembler (`/bin/as') for the RS/6000 |
| has certain problems that prevent the `-g' option in GCC from |
| working. Note that `Makefile.in' uses `-g' by default when |
| compiling `libgcc2.c'. |
| |
| IBM has produced a fixed version of the assembler. The upgraded |
| assembler unfortunately was not included in any of the AIX 3.2 |
| update PTF releases (3.2.2, 3.2.3, or 3.2.3e). Users of AIX 3.1 |
| should request PTF U403044 from IBM and users of AIX 3.2 should |
| request PTF U416277. See the file `README.RS6000' for more |
| details on these updates. |
| |
| You can test for the presense of a fixed assembler by using the |
| command |
| |
| as -u < /dev/null |
| |
| If the command exits normally, the assembler fix already is |
| installed. If the assembler complains that "-u" is an unknown |
| flag, you need to order the fix. |
| |
| * On the IBM RS/6000, compiling code of the form |
| |
| extern int foo; |
| |
| ... foo ... |
| |
| static int foo; |
| |
| will cause the linker to report an undefined symbol `foo'. |
| Although this behavior differs from most other systems, it is not a |
| bug because redefining an `extern' variable as `static' is |
| undefined in ANSI C. |
| |
| * AIX on the RS/6000 provides support (NLS) for environments outside |
| of the United States. Compilers and assemblers use NLS to support |
| locale-specific representations of various objects including |
| floating-point numbers ("." vs "," for separating decimal |
| fractions). There have been problems reported where the library |
| linked with GCC does not produce the same floating-point formats |
| that the assembler accepts. If you have this problem, set the |
| LANG environment variable to "C" or "En_US". |
| |
| * Even if you specify `-fdollars-in-identifiers', you cannot |
| successfully use `$' in identifiers on the RS/6000 due to a |
| restriction in the IBM assembler. GAS supports these identifiers. |
| |
| * On the RS/6000, XLC version 1.3.0.0 will miscompile `jump.c'. XLC |
| version 1.3.0.1 or later fixes this problem. You can obtain |
| XLC-1.3.0.2 by requesting PTF 421749 from IBM. |
| |
| * There is an assembler bug in versions of DG/UX prior to 5.4.2.01 |
| that occurs when the `fldcr' instruction is used. GNU CC uses |
| `fldcr' on the 88100 to serialize volatile memory references. Use |
| the option `-mno-serialize-volatile' if your version of the |
| assembler has this bug. |
| |
| * On VMS, GAS versions 1.38.1 and earlier may cause spurious warning |
| messages from the linker. These warning messages complain of |
| mismatched psect attributes. You can ignore them. *Note VMS |
| Install::. |
| |
| * On NewsOS version 3, if you include both of the files `stddef.h' |
| and `sys/types.h', you get an error because there are two typedefs |
| of `size_t'. You should change `sys/types.h' by adding these |
| lines around the definition of `size_t': |
| |
| #ifndef _SIZE_T |
| #define _SIZE_T |
| ACTUAL TYPEDEF HERE |
| #endif |
| |
| * On the Alliant, the system's own convention for returning |
| structures and unions is unusual, and is not compatible with GNU |
| CC no matter what options are used. |
| |
| * On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different |
| convention for structure and union returning. Use the option |
| `-mhc-struct-return' to tell GNU CC to use a convention compatible |
| with it. |
| |
| * On Ultrix, the Fortran compiler expects registers 2 through 5 to |
| be saved by function calls. However, the C compiler uses |
| conventions compatible with BSD Unix: registers 2 through 5 may be |
| clobbered by function calls. |
| |
| GNU CC uses the same convention as the Ultrix C compiler. You can |
| use these options to produce code compatible with the Fortran |
| compiler: |
| |
| -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 |
| |
| * On the WE32k, you may find that programs compiled with GNU CC do |
| not work with the standard shared C library. You may need to link |
| with the ordinary C compiler. If you do so, you must specify the |
| following options: |
| |
| -L/usr/local/lib/gcc-lib/we32k-att-sysv/2.7.1 -lgcc -lc_s |
| |
| The first specifies where to find the library `libgcc.a' specified |
| with the `-lgcc' option. |
| |
| GNU CC does linking by invoking `ld', just as `cc' does, and there |
| is no reason why it *should* matter which compilation program you |
| use to invoke `ld'. If someone tracks this problem down, it can |
| probably be fixed easily. |
| |
| * On the Alpha, you may get assembler errors about invalid syntax as |
| a result of floating point constants. This is due to a bug in the |
| C library functions `ecvt', `fcvt' and `gcvt'. Given valid |
| floating point numbers, they sometimes print `NaN'. |
| |
| * On Irix 4.0.5F (and perhaps in some other versions), an assembler |
| bug sometimes reorders instructions incorrectly when optimization |
| is turned on. If you think this may be happening to you, try |
| using the GNU assembler; GAS version 2.1 supports ECOFF on Irix. |
| |
| Or use the `-noasmopt' option when you compile GNU CC with itself, |
| and then again when you compile your program. (This is a temporary |
| kludge to turn off assembler optimization on Irix.) If this |
| proves to be what you need, edit the assembler spec in the file |
| `specs' so that it unconditionally passes `-O0' to the assembler, |
| and never passes `-O2' or `-O3'. |
| |