![[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.