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