![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-8 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Apple XNU] / GNUtools / cc|
Return to gcc.info-8 CVS log | Up to [Apple XNU] / GNUtools / cc |
1.1 root 1: This is Info file gcc.info, produced by Makeinfo-1.54 from the input
2: 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 675 Massachusetts Avenue
7: Cambridge, MA 02139 USA
8:
9: Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
10:
11: Permission is granted to make and distribute verbatim copies of this
12: manual provided the copyright notice and this permission notice are
13: preserved on all copies.
14:
15: Permission is granted to copy and distribute modified versions of
16: this manual under the conditions for verbatim copying, provided also
17: that the sections entitled "GNU General Public License" and "Protect
18: Your Freedom--Fight `Look And Feel'" are included exactly as in the
19: original, and provided that the entire resulting derived work is
20: distributed under the terms of a permission notice identical to this
21: one.
22:
23: Permission is granted to copy and distribute translations of this
24: manual into another language, under the above conditions for modified
25: versions, except that the sections entitled "GNU General Public
26: License" and "Protect Your Freedom--Fight `Look And Feel'", and this
27: permission notice, may be included in translations approved by the Free
28: Software Foundation instead of in the original English.
29:
30:
31: File: gcc.info, Node: C++ Extensions, Next: Trouble, Prev: C Extensions, Up: Top
32:
33: Extensions to the C++ Language
34: ******************************
35:
36: The GNU compiler provides these extensions to the C++ language (and
37: you can also use most of the C language extensions in your C++
38: programs). If you want to write code that checks whether these
39: features are available, you can test for the GNU compiler the same way
40: as for C programs: check for a predefined macro `__GNUC__'. You can
41: also use `__GNUG__' to test specifically for GNU C++ (*note Standard
42: Predefined Macros: (cpp.info)Standard Predefined.).
43:
44: * Menu:
45:
46: * Naming Results:: Giving a name to C++ function return values.
47: * Min and Max:: C++ Minimum and maximum operators.
48: * Destructors and Goto:: Goto is safe to use in C++ even when destructors
49: are needed.
50: * C++ Interface:: You can use a single C++ header file for both
51: declarations and definitions.
52:
53:
54: File: gcc.info, Node: Naming Results, Next: Min and Max, Up: C++ Extensions
55:
56: Named Return Values in C++
57: ==========================
58:
59: GNU C++ extends the function-definition syntax to allow you to
60: specify a name for the result of a function outside the body of the
61: definition, in C++ programs:
62:
63: TYPE
64: FUNCTIONNAME (ARGS) return RESULTNAME;
65: {
66: ...
67: BODY
68: ...
69: }
70:
71: You can use this feature to avoid an extra constructor call when a
72: function result has a class type. For example, consider a function
73: `m', declared as `X v = m ();', whose result is of class `X':
74:
75: X
76: m ()
77: {
78: X b;
79: b.a = 23;
80: return b;
81: }
82:
83: Although `m' appears to have no arguments, in fact it has one
84: implicit argument: the address of the return value. At invocation, the
85: address of enough space to hold `v' is sent in as the implicit argument.
86: Then `b' is constructed and its `a' field is set to the value 23.
87: Finally, a copy constructor (a constructor of the form `X(X&)') is
88: applied to `b', with the (implicit) return value location as the
89: target, so that `v' is now bound to the return value.
90:
91: But this is wasteful. The local `b' is declared just to hold
92: something that will be copied right out. While a compiler that
93: combined an "elision" algorithm with interprocedural data flow analysis
94: could conceivably eliminate all of this, it is much more practical to
95: allow you to assist the compiler in generating efficient code by
96: manipulating the return value explicitly, thus avoiding the local
97: variable and copy constructor altogether.
98:
99: Using the extended GNU C++ function-definition syntax, you can avoid
100: the temporary allocation and copying by naming `r' as your return value
101: as the outset, and assigning to its `a' field directly:
102:
103: X
104: m () return r;
105: {
106: r.a = 23;
107: }
108:
109: The declaration of `r' is a standard, proper declaration, whose effects
110: are executed *before* any of the body of `m'.
111:
112: Functions of this type impose no additional restrictions; in
113: particular, you can execute `return' statements, or return implicitly by
114: reaching the end of the function body ("falling off the edge"). Cases
115: like
116:
117: X
118: m () return r (23);
119: {
120: return;
121: }
122:
123: (or even `X m () return r (23); { }') are unambiguous, since the return
124: value `r' has been initialized in either case. The following code may
125: be hard to read, but also works predictably:
126:
127: X
128: m () return r;
129: {
130: X b;
131: return b;
132: }
133:
134: The return value slot denoted by `r' is initialized at the outset,
135: but the statement `return b;' overrides this value. The compiler deals
136: with this by destroying `r' (calling the destructor if there is one, or
137: doing nothing if there is not), and then reinitializing `r' with `b'.
138:
139: This extension is provided primarily to help people who use
140: overloaded operators, where there is a great need to control not just
141: the arguments, but the return values of functions. For classes where
142: the copy constructor incurs a heavy performance penalty (especially in
143: the common case where there is a quick default constructor), this is a
144: major savings. The disadvantage of this extension is that you do not
145: control when the default constructor for the return value is called: it
146: is always called at the beginning.
147:
148:
149: File: gcc.info, Node: Min and Max, Next: Destructors and Goto, Prev: Naming Results, Up: C++ Extensions
150:
151: Minimum and Maximum Operators in C++
152: ====================================
153:
154: It is very convenient to have operators which return the "minimum"
155: or the "maximum" of two arguments. In GNU C++ (but not in GNU C),
156:
157: `A <? B'
158: is the "minimum", returning the smaller of the numeric values A
159: and B;
160:
161: `A >? B'
162: is the "maximum", returning the larger of the numeric values A and
163: B.
164:
165: These operations are not primitive in ordinary C++, since you can
166: use a macro to return the minimum of two things in C++, as in the
167: following example.
168:
169: #define MIN(X,Y) ((X) < (Y) ? : (X) : (Y))
170:
171: You might then use `int min = MIN (i, j);' to set MIN to the minimum
172: value of variables I and J.
173:
174: However, side effects in `X' or `Y' may cause unintended behavior.
175: For example, `MIN (i++, j++)' will fail, incrementing the smaller
176: counter twice. A GNU C extension allows you to write safe macros that
177: avoid this kind of problem (*note Naming an Expression's Type: Naming
178: Types.). However, writing `MIN' and `MAX' as macros also forces you to
179: use function-call notation notation for a fundamental arithmetic
180: operation. Using GNU C++ extensions, you can write `int min = i <? j;'
181: instead.
182:
183: Since `<?' and `>?' are built into the compiler, they properly
184: handle expressions with side-effects; `int min = i++ <? j++;' works
185: correctly.
186:
187:
188: File: gcc.info, Node: Destructors and Goto, Next: C++ Interface, Prev: Min and Max, Up: C++ Extensions
189:
190: `goto' and Destructors in GNU C++
191: =================================
192:
193: In C++ programs, you can safely use the `goto' statement. When you
194: use it to exit a block which contains aggregates requiring destructors,
195: the destructors will run before the `goto' transfers control. (In ANSI
196: C++, `goto' is restricted to targets within the current block.)
197:
198: The compiler still forbids using `goto' to *enter* a scope that
199: requires constructors.
200:
201:
202: File: gcc.info, Node: C++ Interface, Prev: Destructors and Goto, Up: C++ Extensions
203:
204: Declarations and Definitions in One Header
205: ==========================================
206:
207: C++ object definitions can be quite complex. In principle, your
208: source code will need two kinds of things for each object that you use
209: across more than one source file. First, you need an "interface"
210: specification, describing its structure with type declarations and
211: function prototypes. Second, you need the "implementation" itself. It
212: can be tedious to maintain a separate interface description in a header
213: file, in parallel to the actual implementation. It is also dangerous,
214: since separate interface and implementation definitions may not remain
215: parallel.
216:
217: With GNU C++, you can use a single header file for both purposes.
218:
219: *Warning:* The mechanism to specify this is in transition. For the
220: nonce, you must use one of two `#pragma' commands; in a future
221: release of GNU C++, an alternative mechanism will make these
222: `#pragma' commands unnecessary.
223:
224: The header file contains the full definitions, but is marked with
225: `#pragma interface' in the source code. This allows the compiler to
226: use the header file only as an interface specification when ordinary
227: source files incorporate it with `#include'. In the single source file
228: where the full implementation belongs, you can use either a naming
229: convention or `#pragma implementation' to indicate this alternate use
230: of the header file.
231:
232: `#pragma interface'
233: Use this directive in *header files* that define object classes,
234: to save space in most of the object files that use those classes.
235: Normally, local copies of certain information (backup copies of
236: inline member functions, debugging information, and the internal
237: tables that implement virtual functions) must be kept in each
238: object file that includes class definitions. You can use this
239: pragma to avoid such duplication. When a header file containing
240: `#pragma interface' is included in a compilation, this auxiliary
241: information will not be generated (unless the main input source
242: file itself uses `#pragma implementation'). Instead, the object
243: files will contain references to be resolved at link time.
244:
245: `#pragma implementation'
246: `#pragma implementation "OBJECTS.h"'
247: Use this pragma in a *main input file*, when you want full output
248: from included header files to be generated (and made globally
249: visible). The included header file, in turn, should use `#pragma
250: interface'. Backup copies of inline member functions, debugging
251: information, and the internal tables used to implement virtual
252: functions are all generated in implementation files.
253:
254: `#pragma implementation' is *implied* whenever the basename(1) of
255: your source file matches the basename of a header file it
256: includes. There is no way to turn this off (other than using a
257: different name for one of the two files). In the same vein, if
258: you use `#pragma implementation' with no argument, it applies to an
259: include file with the same basename as your source file. For
260: example, in `allclass.cc', `#pragma implementation' by itself is
261: equivalent to `#pragma implementation "allclass.h"'; but even if
262: you do not say `#pragma implementation' at all, `allclass.h' is
263: treated as an implementation file whenever you include it from
264: `allclass.cc'.
265:
266: If you use an explicit `#pragma implementation', it must appear in
267: your source file *before* you include the affected header files.
268:
269: Use the string argument if you want a single implementation file to
270: include code from multiple header files. (You must also use
271: `#include' to include the header file; `#pragma implementation'
272: only specifies how to use the file--it doesn't actually include
273: it.)
274:
275: There is no way to split up the contents of a single header file
276: into multiple implementation files.
277:
278: `#pragma implementation' and `#pragma interface' also have an effect
279: on function inlining.
280:
281: If you define a class in a header file marked with `#pragma
282: interface', the effect on a function defined in that class is similar to
283: an explicit `extern' declaration--the compiler emits no code at all to
284: define an independent version of the function. Its definition is used
285: only for inlining with its callers.
286:
287: Conversely, when you include the same header file in a main source
288: file that declares it as `#pragma implementation', the compiler emits
289: code for the function itself; this defines a version of the function
290: that can be found via pointers (or by callers compiled without
291: inlining).
292:
293: ---------- Footnotes ----------
294:
295: (1) A file's "basename" is the name stripped of all leading path
296: information and of trailing suffixes, such as `.h' or `.C' or `.cc'.
297:
298:
299: File: gcc.info, Node: Trouble, Next: Bugs, Prev: C++ Extensions, Up: Top
300:
301: Known Causes of Trouble with GNU CC
302: ***********************************
303:
304: This section describes known problems that affect users of GNU CC.
305: Most of these are not GNU CC bugs per se--if they were, we would fix
306: them. But the result for a user may be like the result of a bug.
307:
308: Some of these problems are due to bugs in other software, some are
309: missing features that are too much work to add, and some are places
310: where people's opinions differ as to what is best.
311:
312: * Menu:
313:
314: * Actual Bugs:: Bugs we will fix later.
315: * Installation Problems:: Problems that manifest when you install GNU CC.
316: * Cross-Compiler Problems:: Common problems of cross compiling with GNU CC.
317: * Interoperation:: Problems using GNU CC with other compilers,
318: and with certain linkers, assemblers and debuggers.
319: * External Bugs:: Problems compiling certain programs.
320: * Incompatibilities:: GNU CC is incompatible with traditional C.
321: * Fixed Headers:: GNU C uses corrected versions of system header files.
322: This is necessary, but doesn't always work smoothly.
323: * Disappointments:: Regrettable things we can't change, but not quite bugs.
324: * C++ Misunderstandings:: Common misunderstandings with GNU C++.
325: * Protoize Caveats:: Things to watch out for when using `protoize'.
326: * Non-bugs:: Things we think are right, but some others disagree.
327: * Warnings and Errors:: Which problems in your code get warnings,
328: and which get errors.
329:
330:
331: File: gcc.info, Node: Actual Bugs, Next: Installation Problems, Up: Trouble
332:
333: Actual Bugs We Haven't Fixed Yet
334: ================================
335:
336: * The `fixincludes' script interacts badly with automounters; if the
337: directory of system header files is automounted, it tends to be
338: unmounted while `fixincludes' is running. This would seem to be a
339: bug in the automounter. We don't know any good way to work around
340: it.
341:
342: * Loop unrolling doesn't work properly for certain C++ programs.
343: This is because of difficulty in updating the debugging
344: information within the loop being unrolled. We plan to revamp the
345: representation of debugging information so that this will work
346: properly, but we have not done this in version 2.5 because we
347: don't want to delay it any further.
348:
349:
350: File: gcc.info, Node: Installation Problems, Next: Cross-Compiler Problems, Prev: Actual Bugs, Up: Trouble
351:
352: Installation Problems
353: =====================
354:
355: This is a list of problems (and some apparent problems which don't
356: really mean anything is wrong) that show up during installation of GNU
357: CC.
358:
359: * On certain systems, defining certain environment variables such as
360: `CC' can interfere with the functioning of `make'.
361:
362: * If you encounter seemingly strange errors when trying to build the
363: compiler in a directory other than the source directory, it could
364: be because you have previously configured the compiler in the
365: source directory. Make sure you have done all the necessary
366: preparations. *Note Other Dir::.
367:
368: * In previous versions of GNU CC, the `gcc' driver program looked for
369: `as' and `ld' in various places; for example, in files beginning
370: with `/usr/local/lib/gcc-'. GNU CC version 2 looks for them in
371: the directory `/usr/local/lib/gcc-lib/TARGET/VERSION'.
372:
373: Thus, to use a version of `as' or `ld' that is not the system
374: default, for example `gas' or GNU `ld', you must put them in that
375: directory (or make links to them from that directory).
376:
377: * Some commands executed when making the compiler may fail (return a
378: non-zero status) and be ignored by `make'. These failures, which
379: are often due to files that were not found, are expected, and can
380: safely be ignored.
381:
382: * It is normal to have warnings in compiling certain files about
383: unreachable code and about enumeration type clashes. These files'
384: names begin with `insn-'. Also, `real.c' may get some warnings
385: that you can ignore.
386:
387: * Sometimes `make' recompiles parts of the compiler when installing
388: the compiler. In one case, this was traced down to a bug in
389: `make'. Either ignore the problem or switch to GNU Make.
390:
391: * If you have installed a program known as purify, you may find that
392: it causes errors while linking `enquire', which is part of building
393: GNU CC. The fix is to get rid of the file `real-ld' which purify
394: installs--so that GNU CC won't try to use it.
395:
396: * On Linux SLS 1.01, there is a problem with `libc.a': it does not
397: contain the obstack functions. However, GNU CC assumes that the
398: obstack functions are in `libc.a' when it is the GNU C library.
399: To work around this problem, change the `__GNU_LIBRARY__'
400: conditional around line 31 to `#if 1'.
401:
402: * On some 386 systems, building the compiler never finishes because
403: `enquire' hangs due to a hardware problem in the motherboard--it
404: reports floating point exceptions to the kernel incorrectly. You
405: can install GNU CC except for `float.h' by patching out the
406: command to run `enquire'. You may also be able to fix the problem
407: for real by getting a replacement motherboard. This problem was
408: observed in Revision E of the Micronics motherboard, and is fixed
409: in Revision F. It has also been observed in the MYLEX MXA-33
410: motherboard.
411:
412: If you encounter this problem, you may also want to consider
413: removing the FPU from the socket during the compilation.
414: Alternatively, if you are running SCO Unix, you can reboot and
415: force the FPU to be ignored. To do this, type `hd(40)unix auto
416: ignorefpu'.
417:
418: * On some 386 systems, GNU CC crashes trying to compile `enquire.c'.
419: This happens on machines that don't have a 387 FPU chip. On 386
420: machines, the system kernel is supposed to emulate the 387 when you
421: don't have one. The crash is due to a bug in the emulator.
422:
423: One of these systems is the Unix from Interactive Systems: 386/ix.
424: On this system, an alternate emulator is provided, and it does
425: work. To use it, execute this command as super-user:
426:
427: ln /etc/emulator.rel1 /etc/emulator
428:
429: and then reboot the system. (The default emulator file remains
430: present under the name `emulator.dflt'.)
431:
432: Try using `/etc/emulator.att', if you have such a problem on the
433: SCO system.
434:
435: Another system which has this problem is Esix. We don't know
436: whether it has an alternate emulator that works.
437:
438: On NetBSD 0.8, a similar problem manifests itself as these error
439: messages:
440:
441: enquire.c: In function `fprop':
442: enquire.c:2328: floating overflow
443:
444: * On SCO systems, when compiling GNU CC with the system's compiler,
445: do not use `-O'. Some versions of the system's compiler miscompile
446: GNU CC with `-O'.
447:
448: * Sometimes on a Sun 4 you may observe a crash in the program
449: `genflags' or `genoutput' while building GNU CC. This is said to
450: be due to a bug in `sh'. You can probably get around it by running
451: `genflags' or `genoutput' manually and then retrying the `make'.
452:
453: * On Solaris 2, executables of GNU CC version 2.0.2 are commonly
454: available, but they have a bug that shows up when compiling current
455: versions of GNU CC: undefined symbol errors occur during assembly
456: if you use `-g'.
457:
458: The solution is to compile the current version of GNU CC without
459: `-g'. That makes a working compiler which you can use to recompile
460: with `-g'.
461:
462: * Solaris 2 comes with a number of optional OS packages. Some of
463: these packages are needed to use GNU CC fully. If you did not
464: install all optional packages when installing Solaris, you will
465: need to verify that the packages that GNU CC needs are installed.
466:
467: To check whether an optional package is installed, use the
468: `pkginfo' command. To add an optional package, use the `pkgadd'
469: command. For further details, see the Solaris documentation.
470:
471: For Solaris 2.0 and 2.1, GNU CC needs six packages: `SUNWarc',
472: `SUNWbtool', `SUNWesu', `SUNWhea', `SUNWlibm', and `SUNWtoo'.
473:
474: For Solaris 2.2, GNU CC needs an additional seventh package:
475: `SUNWsprot'.
476:
477: * On Solaris 2, trying to use the linker and other tools in
478: `/usr/ucb' to install GNU CC has been observed to cause trouble.
479: For example, the linker may hang indefinitely. The fix is to
480: remove `/usr/ucb' from your `PATH'.
481:
482: * If you use the 1.31 version of the MIPS assembler (such as was
483: shipped with Ultrix 3.1), you will need to use the
484: -fno-delayed-branch switch when optimizing floating point code.
485: Otherwise, the assembler will complain when the GCC compiler fills
486: a branch delay slot with a floating point instruction, such as
487: add.d.
488:
489: * If on a MIPS system you get an error message saying "does not have
490: gp sections for all it's [sic] sectons [sic]", don't worry about
491: it. This happens whenever you use GAS with the MIPS linker, but
492: there is not really anything wrong, and it is okay to use the
493: output file. You can stop such warnings by installing the GNU
494: linker.
495:
496: It would be nice to extend GAS to produce the gp tables, but they
497: are optional, and there should not be a warning about their
498: absence.
499:
500: * Users have reported some problems with version 2.0 of the MIPS
501: compiler tools that were shipped with Ultrix 4.1. Version 2.10
502: which came with Ultrix 4.2 seems to work fine.
503:
504: * Some versions of the MIPS linker will issue an assertion failure
505: when linking code that uses `alloca' against shared libraries on
506: RISC-OS 5.0, and DEC's OSF/1 systems. This is a bug in the
507: linker, that is supposed to be fixed in future revisions. To
508: protect against this, GCC passes `-non_shared' to the linker
509: unless you pass an explicit `-shared' or `-call_shared' switch.
510:
511: * On System V release 3, you may get this error message while
512: linking:
513:
514: ld fatal: failed to write symbol name SOMETHING
515: in strings table for file WHATEVER
516:
517: This probably indicates that the disk is full or your ULIMIT won't
518: allow the file to be as large as it needs to be.
519:
520: This problem can also result because the kernel parameter `MAXUMEM'
521: is too small. If so, you must regenerate the kernel and make the
522: value much larger. The default value is reported to be 1024; a
523: value of 32768 is said to work. Smaller values may also work.
524:
525: * On System V, if you get an error like this,
526:
527: /usr/local/lib/bison.simple: In function `yyparse':
528: /usr/local/lib/bison.simple:625: virtual memory exhausted
529:
530: that too indicates a problem with disk space, ULIMIT, or `MAXUMEM'.
531:
532: * Current GNU CC versions probably do not work on version 2 of the
533: NeXT operating system.
534:
535: * On the Tower models 4N0 and 6N0, by default a process is not
536: allowed to have more than one megabyte of memory. GNU CC cannot
537: compile itself (or many other programs) with `-O' in that much
538: memory.
539:
540: To solve this problem, reconfigure the kernel adding the following
541: line to the configuration file:
542:
543: MAXUMEM = 4096
544:
545: * On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a
546: bug in the assembler that must be fixed before GNU CC can be
547: built. This bug manifests itself during the first stage of
548: compilation, while building `libgcc2.a':
549:
550: _floatdisf
551: cc1: warning: `-g' option not supported on this version of GCC
552: cc1: warning: `-g1' option not supported on this version of GCC
553: ./xgcc: Internal compiler error: program as got fatal signal 11
554:
555: A patched version of the assembler is available by anonymous ftp
556: from `altdorf.ai.mit.edu' as the file
557: `archive/cph/hpux-8.0-assembler'. If you have HP software support,
558: the patch can also be obtained directly from HP, as described in
559: the following note:
560:
561: This is the patched assembler, to patch SR#1653-010439, where
562: the assembler aborts on floating point constants.
563:
564: The bug is not really in the assembler, but in the shared
565: library version of the function "cvtnum(3c)". The bug on
566: "cvtnum(3c)" is SR#4701-078451. Anyway, the attached
567: assembler uses the archive library version of "cvtnum(3c)"
568: and thus does not exhibit the bug.
569:
570: This patch is also known as PHCO_0800.
571:
572: * Some versions of the Pyramid C compiler are reported to be unable
573: to compile GNU CC. You must use an older version of GNU CC for
574: bootstrapping. One indication of this problem is if you get a
575: crash when GNU CC compiles the function `muldi3' in file
576: `libgcc2.c'.
577:
578: You may be able to succeed by getting GNU CC version 1, installing
579: it, and using it to compile GNU CC version 2. The bug in the
580: Pyramid C compiler does not seem to affect GNU CC version 1.
581:
582: * There may be similar problems on System V Release 3.1 on 386
583: systems.
584:
585: * On the Altos 3068, programs compiled with GNU CC won't work unless
586: you fix a kernel bug. This happens using system versions V.2.2
587: 1.0gT1 and V.2.2 1.0e and perhaps later versions as well. See the
588: file `README.ALTOS'.
589:
590: * You will get several sorts of compilation and linking errors on the
591: we32k if you don't follow the special instructions. *Note WE32K
592: Install::.
593:
594:
595: File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Installation Problems, Up: Trouble
596:
597: Cross-Compiler Problems
598: =======================
599:
600: You may run into problems with cross compilation on certain machines,
601: for several reasons.
602:
603: * Cross compilation can run into trouble for certain machines because
604: some target machines' assemblers require floating point numbers to
605: be written as *integer* constants in certain contexts.
606:
607: The compiler writes these integer constants by examining the
608: floating point value as an integer and printing that integer,
609: because this is simple to write and independent of the details of
610: the floating point representation. But this does not work if the
611: compiler is running on a different machine with an incompatible
612: floating point format, or even a different byte-ordering.
613:
614: In addition, correct constant folding of floating point values
615: requires representing them in the target machine's format. (The C
616: standard does not quite require this, but in practice it is the
617: only way to win.)
618:
619: It is now possible to overcome these problems by defining macros
620: such as `REAL_VALUE_TYPE'. But doing so is a substantial amount of
621: work for each target machine. *Note Cross-compilation::.
622:
623: * At present, the program `mips-tfile' which adds debug support to
624: object files on MIPS systems does not work in a cross compile
625: environment.
626:
627:
628: File: gcc.info, Node: Interoperation, Next: External Bugs, Prev: Cross-Compiler Problems, Up: Trouble
629:
630: Interoperation
631: ==============
632:
633: This section lists various difficulties encountered in using GNU C or
634: GNU C++ together with other compilers or with the assemblers, linkers,
635: libraries and debuggers on certain systems.
636:
637: * If you are using version 2.3 of libg++, you need to rebuild it with
638: `make CC=gcc' to avoid mismatches in the definition of `size_t'.
639:
640: * Objective C does not work on the RS/6000 or the Alpha.
641:
642: * GNU C++ does not do name mangling in the same way as other C++
643: compilers. This means that object files compiled with one compiler
644: cannot be used with another.
645:
646: This effect is intentional, to protect you from more subtle
647: problems. Compilers differ as to many internal details of C++
648: implementation, including: how class instances are laid out, how
649: multiple inheritance is implemented, and how virtual function
650: calls are handled. If the name encoding were made the same, your
651: programs would link against libraries provided from other
652: compilers--but the programs would then crash when run.
653: Incompatible libraries are then detected at link time, rather than
654: at run time.
655:
656: * Older GDB versions sometimes fail to read the output of GNU CC
657: version 2. If you have trouble, get GDB version 4.4 or later.
658:
659: * DBX rejects some files produced by GNU CC, though it accepts
660: similar constructs in output from PCC. Until someone can supply a
661: coherent description of what is valid DBX input and what is not,
662: there is nothing I can do about these problems. You are on your
663: own.
664:
665: * The GNU assembler (GAS) does not support PIC. To generate PIC
666: code, you must use some other assembler, such as `/bin/as'.
667:
668: * On some BSD systems including some versions of Ultrix, use of
669: profiling causes static variable destructors (currently used only
670: in C++) not to be run.
671:
672: * Use of `-I/usr/include' may cause trouble.
673:
674: Many systems come with header files that won't work with GNU CC
675: unless corrected by `fixincludes'. The corrected header files go
676: in a new directory; GNU CC searches this directory before
677: `/usr/include'. If you use `-I/usr/include', this tells GNU CC to
678: search `/usr/include' earlier on, before the corrected headers.
679: The result is that you get the uncorrected header files.
680:
681: Instead, you should use these options (when compiling C programs):
682:
683: -I/usr/local/lib/gcc-lib/TARGET/VERSION/include -I/usr/include
684:
685: For C++ programs, GNU CC also uses a special directory that
686: defines C++ interfaces to standard C subroutines. This directory
687: is meant to be searched *before* other standard include
688: directories, so that it takes precedence. If you are compiling
689: C++ programs and specifying include directories explicitly, use
690: this option first, then the two options above:
691:
692: -I/usr/local/lib/g++-include
693:
694: * On a Sparc, GNU CC aligns all values of type `double' on an 8-byte
695: boundary, and it expects every `double' to be so aligned. The Sun
696: compiler usually gives `double' values 8-byte alignment, with one
697: exception: function arguments of type `double' may not be aligned.
698:
699: As a result, if a function compiled with Sun CC takes the address
700: of an argument of type `double' and passes this pointer of type
701: `double *' to a function compiled with GNU CC, dereferencing the
702: pointer may cause a fatal signal.
703:
704: One way to solve this problem is to compile your entire program
705: with GNU CC. Another solution is to modify the function that is
706: compiled with Sun CC to copy the argument into a local variable;
707: local variables are always properly aligned. A third solution is
708: to modify the function that uses the pointer to dereference it via
709: the following function `access_double' instead of directly with
710: `*':
711:
712: inline double
713: access_double (double *unaligned_ptr)
714: {
715: union d2i { double d; int i[2]; };
716:
717: union d2i *p = (union d2i *) unaligned_ptr;
718: union d2i u;
719:
720: u.i[0] = p->i[0];
721: u.i[1] = p->i[1];
722:
723: return u.d;
724: }
725:
726: Storing into the pointer can be done likewise with the same union.
727:
728: * On Solaris, the `malloc' function in the `libmalloc.a' library may
729: allocate memory that is only 4 byte aligned. Since GNU CC on the
730: Sparc assumes that doubles are 8 byte aligned, this may result in a
731: fatal signal if doubles are stored in memory allocated by the
732: `libmalloc.a' library.
733:
734: The solution is to not use the `libmalloc.a' library. Use instead
735: `malloc' and related functions from `libc.a'; they do not have
736: this problem.
737:
738: * On a Sun, linking using GNU CC fails to find a shared library and
739: reports that the library doesn't exist at all.
740:
741: This happens if you are using the GNU linker, because it does only
742: static linking and looks only for unshared libraries. If you have
743: a shared library with no unshared counterpart, the GNU linker
744: won't find anything.
745:
746: We hope to make a linker which supports Sun shared libraries, but
747: please don't ask when it will be finished--we don't know.
748:
749: * Sun forgot to include a static version of `libdl.a' with some
750: versions of SunOS (mainly 4.1). This results in undefined symbols
751: when linking static binaries (that is, if you use `-static'). If
752: you see undefined symbols `_dlclose', `_dlsym' or `_dlopen' when
753: linking, compile and link against the file `mit/util/misc/dlsym.c'
754: from the MIT version of X windows.
755:
756: * The 128-bit long double format that the Sparc port supports
757: currently works by using the architecturally defined quad-word
758: floating point instructions. Since there is no hardware that
759: supports these instructions they must be emulated by the operating
760: system. Long doubles do not work in Sun OS versions 4.0.3 and
761: earlier, because the kernel eumulator uses an obsolete and
762: incompatible format. Long doubles do not work in Sun OS versions
763: 4.1.1 to 4.1.3 because of emululator bugs that cause random
764: unpredicatable failures. Long doubles appear to work in Sun OS 5.x
765: (Solaris 2.x).
766:
767: A future implementation of the sparc long double support will use
768: functions calls to library routines instead of the quad-word
769: floating point instructions. This will allow long doubles to work
770: in more situtations, since one can then substitute a working
771: library if the kernel emulator is buggy.
772:
773: * On HP-UX version 9.01 on the HP PA, the HP compiler `cc' does not
774: compile GNU CC correctly. We do not yet know why. However, GNU CC
775: compiled on earlier HP-UX versions works properly on HP-UX 9.01
776: and can compile itself properly on 9.01.
777:
778: * On the HP PA machine, ADB sometimes fails to work on functions
779: compiled with GNU CC. Specifically, it fails to work on functions
780: that use `alloca' or variable-size arrays. This is because GNU CC
781: doesn't generate HP-UX unwind descriptors for such functions. It
782: may even be impossible to generate them.
783:
784: * Debugging (`-g') is not supported on the HP PA machine, unless you
785: use the preliminary GNU tools (*note Installation::.).
786:
787: * Taking the address of a label may generate errors from the HP-UX
788: PA assembler. GAS for the PA does not have this problem.
789:
790: * Using floating point parameters for indirect calls to static
791: functions will not work when using the HP assembler. There simply
792: is no way for GCC to specify what registers hold arguments for
793: static functions when using the HP assembler. GAS for the PA does
794: not have this problem.
795:
796: * For some very large functions you may receive errors from the HP
797: linker complaining about an out of bounds unconditional branch
798: offset. Fixing this problem correctly requires fixing problems in
799: GNU CC and GAS. We hope to fix this in time for GNU CC 2.6.
800: Until then you can work around by making your function smaller,
801: and if you are using GAS, splitting the function into multiple
802: source files may be necessary.
803:
804: * GNU CC compiled code sometimes emits warnings from the HP-UX
805: assembler of the form:
806:
807: (warning) Use of GR3 when
808: frame >= 8192 may cause conflict.
809:
810: These warnings are harmless and can be safely ignored.
811:
812: * The current version of the assembler (`/bin/as') for the RS/6000
813: has certain problems that prevent the `-g' option in GCC from
814: working. Note that `Makefile.in' uses `-g' by default when
815: compiling `libgcc2.c'.
816:
817: IBM has produced a fixed version of the assembler. The upgraded
818: assembler unfortunately was not included in any of the AIX 3.2
819: update PTF releases (3.2.2, 3.2.3, or 3.2.3e). Users of AIX 3.1
820: should request PTF U403044 from IBM and users of AIX 3.2 should
821: request PTF U416277. See the file `README.RS6000' for more
822: details on these updates.
823:
824: You can test for the presense of a fixed assembler by using the
825: command
826:
827: as -u < /dev/null
828:
829: If the command exits normally, the assembler fix already is
830: installed. If the assembler complains that "-u" is an unknown
831: flag, you need to order the fix.
832:
833: * On the IBM RS/6000, compiling code of the form
834:
835: extern int foo;
836:
837: ... foo ...
838:
839: static int foo;
840:
841: will cause the linker to report an undefined symbol `foo'.
842: Although this behavior differs from most other systems, it is not a
843: bug because redefining an `extern' variable as `static' is
844: undefined in ANSI C.
845:
846: * AIX on the RS/6000 provides support (NLS) for environments outside
847: of the United States. Compilers and assemblers use NLS to support
848: locale-specific representations of various objects including
849: floating-point numbers ("." vs "," for separating decimal
850: fractions). There have been problems reported where the library
851: linked with GCC does not produce the same floating-point formats
852: that the assembler accepts. If you have this problem, set the
853: LANG environment variable to "C" or "En_US".
854:
855: * On the RS/6000, XLC version 1.3.0.0 will miscompile `jump.c'. XLC
856: version 1.3.0.1 or later fixes this problem. We do not yet have a
857: PTF number for this fix.
858:
859: * There is an assembler bug in versions of DG/UX prior to 5.4.2.01
860: that occurs when the `fldcr' instruction is used. GNU CC uses
861: `fldcr' on the 88100 to serialize volatile memory references. Use
862: the option `-mno-serialize-volatile' if your version of the
863: assembler has this bug.
864:
865: * On VMS, GAS versions 1.38.1 and earlier may cause spurious warning
866: messages from the linker. These warning messages complain of
867: mismatched psect attributes. You can ignore them. *Note VMS
868: Install::.
869:
870: * On NewsOS version 3, if you include both of the files `stddef.h'
871: and `sys/types.h', you get an error because there are two typedefs
872: of `size_t'. You should change `sys/types.h' by adding these
873: lines around the definition of `size_t':
874:
875: #ifndef _SIZE_T
876: #define _SIZE_T
877: ACTUAL TYPEDEF HERE
878: #endif
879:
880: * On the Alliant, the system's own convention for returning
881: structures and unions is unusual, and is not compatible with GNU
882: CC no matter what options are used.
883:
884: * On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different
885: convention for structure and union returning. Use the option
886: `-mhc-struct-return' to tell GNU CC to use a convention compatible
887: with it.
888:
889: * On Ultrix, the Fortran compiler expects registers 2 through 5 to
890: be saved by function calls. However, the C compiler uses
891: conventions compatible with BSD Unix: registers 2 through 5 may be
892: clobbered by function calls.
893:
894: GNU CC uses the same convention as the Ultrix C compiler. You can
895: use these options to produce code compatible with the Fortran
896: compiler:
897:
898: -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5
899:
900: * On the WE32k, you may find that programs compiled with GNU CC do
901: not work with the standard shared C ilbrary. You may need to link
902: with the ordinary C compiler. If you do so, you must specify the
903: following options:
904:
905: -L/usr/local/lib/gcc-lib/we32k-att-sysv/2.5 -lgcc -lc_s
906:
907: The first specifies where to find the library `libgcc.a' specified
908: with the `-lgcc' option.
909:
910: GNU CC does linking by invoking `ld', just as `cc' does, and there
911: is no reason why it *should* matter which compilation program you
912: use to invoke `ld'. If someone tracks this problem down, it can
913: probably be fixed easily.
914:
915: * On the Alpha, you may get assembler errors about invalid syntax as
916: a result of floating point constants. This is due to a bug in the
917: C library functions `ecvt', `fcvt' and `gcvt'. Given valid
918: floating point numbers, they sometimes print `NaN'.
919:
920: * On Irix 4.0.5F (and perhaps in some other versions), an assembler
921: bug sometimes reorders instructions incorrectly when optimization
922: is turned on. If you think this may be happening to you, try
923: using the GNU assembler; GAS version 2.1 supports ECOFF on Irix.
924:
925: Or use the `-noasmopt' option when you compile GNU CC with itself,
926: and then again when you compile your program. (This is a temporary
927: kludge to turn off assembler optimization on Irix.) If this
928: proves to be what you need, edit the assembler spec in the file
929: `specs' so that it unconditionally passes `-O0' to the assembler,
930: and never passes `-O2' or `-O3'.
931:
932:
933: File: gcc.info, Node: External Bugs, Next: Incompatibilities, Prev: Interoperation, Up: Trouble
934:
935: Problems Compiling Certain Programs
936: ===================================
937:
938: * Parse errors may occur compiling X11 on a Decstation running
939: Ultrix 4.2 because of problems in DEC's versions of the X11 header
940: files `X11/Xlib.h' and `X11/Xutil.h'. People recommend adding
941: `-I/usr/include/mit' to use the MIT versions of the header files,
942: using the `-traditional' switch to turn off ANSI C, or fixing the
943: header files by adding this:
944:
945: #ifdef __STDC__
946: #define NeedFunctionPrototypes 0
947: #endif
948:
949: * If you have trouble compiling Perl on a SunOS 4 system, it may be
950: because Perl specifies `-I/usr/ucbinclude'. This accesses the
951: unfixed header files. Perl specifies the options
952:
953: -traditional -Dvolatile=__volatile__
954: -I/usr/include/sun -I/usr/ucbinclude
955: -fpcc-struct-return
956:
957: all of which are unnecessary with GCC 2.4.5 and newer versions.
958: You can make a properly working Perl by setting `ccflags' and
959: `cppflags' to empty values in `config.sh', then typing `./doSH;
960: make depend; make'.
961:
962: * On various 386 Unix systems derived from System V, including SCO,
963: ISC, and ESIX, you may get error messages about running out of
964: virtual memory while compiling certain programs.
965:
966: You can prevent this problem by linking GNU CC with the GNU malloc
967: (which thus replaces the malloc that comes with the system). GNU
968: malloc is available as a separate package, and also in the file
969: `src/gmalloc.c' in the GNU Emacs 19 distribution.
970:
971: If you have installed GNU malloc as a separate library package,
972: use this option when you relink GNU CC:
973:
974: MALLOC=/usr/local/lib/libgmalloc.a
975:
976: Alternatively, if you have compiled `gmalloc.c' from Emacs 19, copy
977: the object file to `gmalloc.o' and use this option when you relink
978: GNU CC:
979:
980: MALLOC=gmalloc.o
981:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.