![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-7 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-7 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.4 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.49 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: 6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc. 7: 1.1.1.3 root 8: Permission is granted to make and distribute verbatim copies of this 9: manual provided the copyright notice and this permission notice are 10: preserved on all copies. 1.1 root 11: 12: Permission is granted to copy and distribute modified versions of 13: this manual under the conditions for verbatim copying, provided also 1.1.1.4 ! root 14: that the sections entitled "GNU General Public License" and "Protect ! 15: Your Freedom--Fight `Look And Feel'" are included exactly as in the ! 16: original, and provided that the entire resulting derived work is ! 17: distributed under the terms of a permission notice identical to this ! 18: one. 1.1 root 19: 20: Permission is granted to copy and distribute translations of this 21: manual into another language, under the above conditions for modified 1.1.1.3 root 22: versions, except that the sections entitled "GNU General Public 1.1.1.4 ! root 23: License" and "Protect Your Freedom--Fight `Look And Feel'", and this ! 24: permission notice, may be included in translations approved by the Free ! 25: Software Foundation instead of in the original English. 1.1.1.3 root 26: 27: 1.1.1.4 ! root 28: File: gcc.info, Node: Interoperation, Next: Incompatibilities, Prev: Cross-Compiler Problems, Up: Trouble 1.1.1.3 root 29: 1.1.1.4 ! root 30: Interoperation ! 31: ============== 1.1.1.3 root 32: 1.1.1.4 ! root 33: This section lists various difficulties encountered in using GNU C or ! 34: GNU C++ together with other compilers or with the assemblers, linkers, ! 35: libraries and debuggers on certain systems. ! 36: ! 37: * GNU C normally compiles functions to return small structures and ! 38: unions in registers. Most other compilers arrange to return them ! 39: just like larger structures and unions. This can lead to trouble ! 40: when you link together code compiled by different compilers. To ! 41: avoid the problem, you can use the option `-fpcc-struct-return' ! 42: when compiling with GNU CC. ! 43: ! 44: * GNU C++ does not do name mangling in the same way as other C++ ! 45: compilers. This means that object files compiled with one compiler ! 46: cannot be used with another. ! 47: ! 48: GNU C++ also uses different techniques for arranging virtual ! 49: function tables and the layout of class instances. In general, ! 50: therefore, linking code compiled with different C++ compilers does ! 51: not work. ! 52: ! 53: * Older GDB versions sometimes fail to read the output of GNU CC ! 54: version 2. If you have trouble, get GDB version 4.4 or later. ! 55: ! 56: * DBX rejects some files produced by GNU CC, though it accepts ! 57: similar constructs in output from PCC. Until someone can supply a ! 58: coherent description of what is valid DBX input and what is not, ! 59: there is nothing I can do about these problems. You are on your ! 60: own. ! 61: ! 62: * The GNU assembler (GAS) does not support PIC. To generate PIC ! 63: code, you must use some other assembler, such as `/bin/as'. ! 64: ! 65: * On some BSD systems including some versions of Ultrix, use of ! 66: profiling causes static variable destructors (currently used only ! 67: in C++) not to be run. ! 68: ! 69: * Use of `-I/usr/include' may cause trouble. ! 70: ! 71: Many systems come with header files that won't work with GNU CC ! 72: unless corrected by `fixincludes'. The corrected header files go ! 73: in a new directory; GNU CC searches this directory before ! 74: `/usr/include'. If you use `-I/usr/include', this tells GNU CC to ! 75: search `/usr/include' earlier on, before the corrected headers. ! 76: The result is that you get the uncorrected header files. ! 77: ! 78: Instead, you should use these options: ! 79: ! 80: -I/usr/local/lib/gcc-lib/TARGET/VERSION/include -I/usr/include ! 81: ! 82: * On a Sparc, GNU CC aligns all values of type `double' on an 8-byte ! 83: boundary, and it expects every `double' to be so aligned. The Sun ! 84: compiler usually gives `double' values 8-byte alignment, with one ! 85: exception: function arguments of type `double' may not be aligned. ! 86: ! 87: As a result, if a function compiled with Sun CC takes the address ! 88: of an argument of type `double' and passes this pointer of type ! 89: `double *' to a function compiled with GNU CC, dereferencing the ! 90: pointer may cause a fatal signal. ! 91: ! 92: One way to solve this problem is to compile your entire program ! 93: with GNU CC. Another solution is to modify the function that is ! 94: compiled with Sun CC to copy the argument into a local variable; ! 95: local variables are always properly aligned. A third solution is ! 96: to modify the function that uses the pointer to dereference it via ! 97: the following function `access_double' instead of directly with ! 98: `*': ! 99: ! 100: inline double ! 101: access_double (double *unaligned_ptr) ! 102: { ! 103: union d2i { double d; int i[2]; }; ! 104: ! 105: union d2i *p = (union d2i *) unaligned_ptr; ! 106: union d2i u; ! 107: ! 108: u.i[0] = p->i[0]; ! 109: u.i[1] = p->i[1]; ! 110: ! 111: return u.d; ! 112: } ! 113: ! 114: Storing into the pointer can be done likewise with the same union. ! 115: ! 116: * On a Sun, linking using GNU CC fails to find a shared library and ! 117: reports that the library doesn't exist at all. ! 118: ! 119: This happens if you are using the GNU linker, because it does only ! 120: static linking and looks only for unshared libraries. If you have ! 121: a shared library with no unshared counterpart, the GNU linker ! 122: won't find anything. ! 123: ! 124: We hope to make a linker which supports Sun shared libraries, but ! 125: please don't ask when it will be finished--we don't know. ! 126: ! 127: * Sun forgot to include a static version of `libdl.a' with some ! 128: versions of SunOS (mainly 4.1). This results in undefined symbols ! 129: when linking static binaries (that is, if you use `-static'). If ! 130: you see undefined symbols `_dlclose', `_dlsym' or `_dlopen' when ! 131: linking, compile and link against the file `mit/util/misc/dlsym.c' ! 132: from the MIT version of X windows. ! 133: ! 134: * On the HP PA machine, ADB sometimes fails to work on functions ! 135: compiled with GNU CC. Specifically, it fails to work on functions ! 136: that use `alloca' or variable-size arrays. This is because GNU CC ! 137: doesn't generate HP-UX unwind descriptors for such functions. It ! 138: may even be impossible to generate them. ! 139: ! 140: * Debugging (`-g') is not supported on the HP PA machine, unless you ! 141: use the preliminary GNU tools (*note Installation::.). ! 142: ! 143: * The HP-UX linker has a bug which can cause programs which make use ! 144: of `const' variables to fail in unusual ways. If your program ! 145: makes use of global `const' variables, we suggest you compile with ! 146: the following additional options: ! 147: ! 148: -Dconst="" -D__const="" -D__const__="" -fwritable-strings ! 149: ! 150: This will force the `const' variables into the DATA subspace which ! 151: will avoid the linker bug. ! 152: ! 153: Another option one might use to work around this problem is ! 154: `-mkernel'. `-mkernel' changes how the address of variables is ! 155: computed to a sequence less likely to tickle the HP-UX linker bug. ! 156: ! 157: We hope to work around this problem in GNU CC 2.4, if HP does not ! 158: fix it. ! 159: ! 160: * Taking the address of a label may generate errors from the HP-UX ! 161: PA assembler. GAS for the PA does not have this problem. ! 162: ! 163: * GNU CC produced code will not yet link against HP-UX 8.0 shared ! 164: libraries. We expect to fix this problem in GNU CC 2.4. ! 165: ! 166: * The current version of the assembler (`/bin/as') for the RS/6000 ! 167: has certain problems that prevent the `-g' option in GCC from ! 168: working. ! 169: ! 170: IBM has produced a fixed version of the assembler. The replacement ! 171: assembler is not a standard component of either AIX 3.1.5 or AIX ! 172: 3.2, but is expected to become standard in a future distribution. ! 173: This assembler is available from IBM as APAR IX22829. Yet more ! 174: bugs have been fixed in a newer assembler, which will shortly be ! 175: available as APAR IX26107. See the file `README.RS6000' for more ! 176: details on these assemblers. ! 177: ! 178: * On the IBM RS/6000, compiling code of the form ! 179: ! 180: extern int foo; ! 181: ! 182: ... foo ... ! 183: ! 184: static int foo; ! 185: ! 186: will cause the linker to report an undefined symbol `foo'. ! 187: Although this behavior differs from most other systems, it is not a ! 188: bug because redefining an `extern' variable as `static' is ! 189: undefined in ANSI C. ! 190: ! 191: * On VMS, GAS versions 1.38.1 and earlier may cause spurious warning ! 192: messages from the linker. These warning messages complain of ! 193: mismatched psect attributes. You can ignore them. *Note VMS ! 194: Install::. ! 195: ! 196: * On NewsOS version 3, if you include both `stddef.h' and ! 197: `sys/types.h', you get an error because there are two typedefs of ! 198: `size_t'. You should change `sys/types.h' by adding these lines ! 199: around the definition of `size_t': ! 200: ! 201: #ifndef _SIZE_T ! 202: #define _SIZE_T ! 203: ACTUAL TYPEDEF HERE ! 204: #endif ! 205: ! 206: * On the Alliant, the system's own convention for returning ! 207: structures and unions is unusual, and is not compatible with GNU ! 208: CC no matter what options are used. ! 209: ! 210: * On the IBM RT PC, the MetaWare HighC compiler (hc) uses yet another ! 211: convention for structure and union returning. Use ! 212: `-mhc-struct-return' to tell GNU CC to use a convention compatible ! 213: with it. ! 214: ! 215: * On Ultrix, the Fortran compiler expects registers 2 through 5 to ! 216: be saved by function calls. However, the C compiler uses ! 217: conventions compatible with BSD Unix: registers 2 through 5 may be ! 218: clobbered by function calls. ! 219: ! 220: GNU CC uses the same convention as the Ultrix C compiler. You can ! 221: use these options to produce code compatible with the Fortran ! 222: compiler: ! 223: ! 224: -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 ! 225: ! 226: * On the WE32k, you may find that programs compiled with GNU CC do ! 227: not work with the standard shared C ilbrary. You may need to link ! 228: with the ordinary C compiler. If you do so, you must specify the ! 229: following options: ! 230: ! 231: -L/usr/local/lib/gcc-lib/we32k-att-sysv/2.3 -lgcc -lc_s ! 232: ! 233: The first specifies where to find the library `libgcc.a' specified ! 234: with the `-lgcc' option. ! 235: ! 236: GNU CC does linking by invoking `ld', just as `cc' does, and there ! 237: is no reason why it *should* matter which compilation program you ! 238: use to invoke `ld'. If someone tracks this problem down, it can ! 239: probably be fixed easily. 1.1.1.3 root 240: 1.1.1.4 ! root 241: ! 242: File: gcc.info, Node: Incompatibilities, Next: Disappointments, Prev: Interoperation, Up: Trouble ! 243: ! 244: Incompatibilities of GNU CC ! 245: =========================== 1.1.1.3 root 246: 1.1.1.4 ! root 247: There are several noteworthy incompatibilities between GNU C and most ! 248: existing (non-ANSI) versions of C. The `-traditional' option ! 249: eliminates many of these incompatibilities, *but not all*, by telling ! 250: GNU C to behave like the other C compilers. ! 251: ! 252: * GNU CC normally makes string constants read-only. If several ! 253: identical-looking string constants are used, GNU CC stores only one ! 254: copy of the string. ! 255: ! 256: One consequence is that you cannot call `mktemp' with a string ! 257: constant argument. The function `mktemp' always alters the string ! 258: its argument points to. ! 259: ! 260: Another consequence is that `sscanf' does not work on some systems ! 261: when passed a string constant as its format control string or ! 262: input. This is because `sscanf' incorrectly tries to write into ! 263: the string constant. Likewise `fscanf' and `scanf'. ! 264: ! 265: The best solution to these problems is to change the program to use ! 266: `char'-array variables with initialization strings for these ! 267: purposes instead of string constants. But if this is not possible, ! 268: you can use the `-fwritable-strings' flag, which directs GNU CC to ! 269: handle string constants the same way most C compilers do. ! 270: `-traditional' also has this effect, among others. ! 271: ! 272: * `-2147483648' is positive. ! 273: ! 274: This is because 2147483648 cannot fit in the type `int', so ! 275: (following the ANSI C rules) its data type is `unsigned long int'. ! 276: Negating this value yields 2147483648 again. ! 277: ! 278: * GNU CC does not substitute macro arguments when they appear inside ! 279: of string constants. For example, the following macro in GNU CC ! 280: ! 281: #define foo(a) "a" ! 282: ! 283: will produce output `"a"' regardless of what the argument A is. ! 284: ! 285: The `-traditional' option directs GNU CC to handle such cases ! 286: (among others) in the old-fashioned (non-ANSI) fashion. ! 287: ! 288: * When you use `setjmp' and `longjmp', the only automatic variables ! 289: guaranteed to remain valid are those declared `volatile'. This is ! 290: a consequence of automatic register allocation. Consider this ! 291: function: ! 292: ! 293: jmp_buf j; ! 294: ! 295: foo () ! 296: { ! 297: int a, b; ! 298: ! 299: a = fun1 (); ! 300: if (setjmp (j)) ! 301: return a; ! 302: ! 303: a = fun2 (); ! 304: /* `longjmp (j)' may occur in `fun3'. */ ! 305: return a + fun3 (); ! 306: } ! 307: ! 308: Here `a' may or may not be restored to its first value when the ! 309: `longjmp' occurs. If `a' is allocated in a register, then its ! 310: first value is restored; otherwise, it keeps the last value stored ! 311: in it. ! 312: ! 313: If you use the `-W' option with the `-O' option, you will get a ! 314: warning when GNU CC thinks such a problem might be possible. ! 315: ! 316: The `-traditional' option directs GNU C to put variables in the ! 317: stack by default, rather than in registers, in functions that call ! 318: `setjmp'. This results in the behavior found in traditional C ! 319: compilers. ! 320: ! 321: * Programs that use preprocessor directives in the middle of macro ! 322: arguments do not work with GNU CC. For example, a program like ! 323: this will not work: ! 324: ! 325: foobar ( ! 326: #define luser ! 327: hack) ! 328: ! 329: ANSI C does not permit such a construct. It would make sense to ! 330: support it when `-traditional' is used, but it is too much work to ! 331: implement. ! 332: ! 333: * Declarations of external variables and functions within a block ! 334: apply only to the block containing the declaration. In other ! 335: words, they have the same scope as any other declaration in the ! 336: same place. ! 337: ! 338: In some other C compilers, a `extern' declaration affects all the ! 339: rest of the file even if it happens within a block. ! 340: ! 341: The `-traditional' option directs GNU C to treat all `extern' ! 342: declarations as global, like traditional compilers. ! 343: ! 344: * In traditional C, you can combine `long', etc., with a typedef ! 345: name, as shown here: ! 346: ! 347: typedef int foo; ! 348: typedef long foo bar; ! 349: ! 350: In ANSI C, this is not allowed: `long' and other type modifiers ! 351: require an explicit `int'. Because this criterion is expressed by ! 352: Bison grammar rules rather than C code, the `-traditional' flag ! 353: cannot alter it. ! 354: ! 355: * PCC allows typedef names to be used as function parameters. The ! 356: difficulty described immediately above applies here too. ! 357: ! 358: * PCC allows whitespace in the middle of compound assignment ! 359: operators such as `+='. GNU CC, following the ANSI standard, does ! 360: not allow this. The difficulty described immediately above ! 361: applies here too. ! 362: ! 363: * GNU CC complains about unterminated character constants inside of ! 364: preprocessor conditionals that fail. Some programs have English ! 365: comments enclosed in conditionals that are guaranteed to fail; if ! 366: these comments contain apostrophes, GNU CC will probably report an ! 367: error. For example, this code would produce an error: ! 368: ! 369: #if 0 ! 370: You can't expect this to work. ! 371: #endif ! 372: ! 373: The best solution to such a problem is to put the text into an ! 374: actual C comment delimited by `/*...*/'. However, `-traditional' ! 375: suppresses these error messages. ! 376: ! 377: * Many user programs contain the declaration `long time ();'. In the ! 378: past, the system header files on many systems did not actually ! 379: declare `time', so it did not matter what type your program ! 380: declared it to return. But in systems with ANSI C headers, `time' ! 381: is declared to return `time_t', and if that is not the same as ! 382: `long', then `long time ();' is erroneous. ! 383: ! 384: The solution is to change your program to use `time_t' as the ! 385: return type of `time'. ! 386: ! 387: * When compiling functions that return `float', PCC converts it to a ! 388: double. GNU CC actually returns a `float'. If you are concerned ! 389: with PCC compatibility, you should declare your functions to return ! 390: `double'; you might as well say what you mean. ! 391: ! 392: * When compiling functions that return structures or unions, GNU CC ! 393: output code normally uses a method different from that used on most ! 394: versions of Unix. As a result, code compiled with GNU CC cannot ! 395: call a structure-returning function compiled with PCC, and vice ! 396: versa. ! 397: ! 398: The method used by GNU CC is as follows: a structure or union ! 399: which is 1, 2, 4 or 8 bytes long is returned like a scalar. A ! 400: structure or union with any other size is stored into an address ! 401: supplied by the caller (usually in a special, fixed register, but ! 402: on some machines it is passed on the stack). The ! 403: machine-description macros `STRUCT_VALUE' and ! 404: `STRUCT_INCOMING_VALUE' tell GNU CC where to pass this address. ! 405: ! 406: By contrast, PCC on most target machines returns structures and ! 407: unions of any size by copying the data into an area of static ! 408: storage, and then returning the address of that storage as if it ! 409: were a pointer value. The caller must copy the data from that ! 410: memory area to the place where the value is wanted. GNU CC does ! 411: not use this method because it is slower and nonreentrant. ! 412: ! 413: On some newer machines, PCC uses a reentrant convention for all ! 414: structure and union returning. GNU CC on most of these machines ! 415: uses a compatible convention when returning structures and unions ! 416: in memory, but still returns small structures and unions in ! 417: registers. ! 418: ! 419: You can tell GNU CC to use a compatible convention for all ! 420: structure and union returning with the option ! 421: `-fpcc-struct-return'. 1.1.1.3 root 422: 423: 1.1.1.4 ! root 424: File: gcc.info, Node: Disappointments, Next: Protoize Caveats, Prev: Incompatibilities, Up: Trouble ! 425: ! 426: Disappointments and Misunderstandings ! 427: ===================================== 1.1.1.3 root 428: 1.1.1.4 ! root 429: These problems are perhaps regrettable, but we don't know any ! 430: practical way around them. 1.1.1.3 root 431: 1.1.1.4 ! root 432: * Certain local variables aren't recognized by debuggers when you ! 433: compile with optimization. ! 434: ! 435: This occurs because sometimes GNU CC optimizes the variable out of ! 436: existence. There is no way to tell the debugger how to compute the ! 437: value such a variable "would have had", and it is not clear that ! 438: would be desirable anyway. So GNU CC simply does not mention the ! 439: eliminated variable when it writes debugging information. ! 440: ! 441: You have to expect a certain amount of disagreement between the ! 442: executable and your source code, when you use optimization. ! 443: ! 444: * Users often think it is a bug when GNU CC reports an error for code ! 445: like this: ! 446: ! 447: int foo (struct mumble *); ! 448: ! 449: struct mumble { ... }; ! 450: ! 451: int foo (struct mumble *x) ! 452: { ... } ! 453: ! 454: This code really is erroneous, because the scope of `struct ! 455: mumble' in the prototype is limited to the argument list ! 456: containing it. It does not refer to the `struct mumble' defined ! 457: with file scope immediately below--they are two unrelated types ! 458: with similar names in different scopes. ! 459: ! 460: But in the definition of `foo', the file-scope type is used ! 461: because that is available to be inherited. Thus, the definition ! 462: and the prototype do not match, and you get an error. ! 463: ! 464: This behavior may seem silly, but it's what the ANSI standard ! 465: specifies. It is easy enough for you to make your code work by ! 466: moving the definition of `struct mumble' above the prototype. ! 467: It's not worth being incompatible with ANSI C just to avoid an ! 468: error for the example shown above. ! 469: ! 470: * Accesses to bitfields even in volatile objects works by accessing ! 471: larger objects, such as a byte or a word. You cannot rely on what ! 472: size of object is accessed in order to read or write the bitfield; ! 473: it may even vary for a given bitfield according to the precise ! 474: usage. ! 475: ! 476: If you care about controlling the amount of memory that is ! 477: accessed, use volatile but do not use bitfields. ! 478: ! 479: * On 68000 systems, you can get paradoxical results if you test the ! 480: precise values of floating point numbers. For example, you can ! 481: find that a floating point value which is not a NaN is not equal ! 482: to itself. This results from the fact that the the floating point ! 483: registers hold a few more bits of precision than fit in a `double' ! 484: in memory. Compiled code moves values between memory and floating ! 485: point registers at its convenience, and moving them into memory ! 486: truncates them. ! 487: ! 488: You can partially avoid this problem by using the option ! 489: `-ffloat-store' (*note Optimize Options::.). ! 490: ! 491: * On the MIPS, variable argument functions using `varargs.h' cannot ! 492: have a floating point value for the first argument. The reason ! 493: for this is that in the absence of a prototype in scope, if the ! 494: first argument is a floating point, it is passed in a floating ! 495: point register, rather than an integer resgister. ! 496: ! 497: If the code is rewritten to use the ANSI standard `stdarg.h' ! 498: method of variable arguments, and the prototype is in scope at the ! 499: time of the call, everything will work fine. 1.1.1.3 root 500: 501: 1.1.1.4 ! root 502: File: gcc.info, Node: Protoize Caveats, Next: Non-bugs, Prev: Disappointments, Up: Trouble 1.1.1.3 root 503: 1.1.1.4 ! root 504: Caveats of using `protoize' ! 505: =========================== 1.1.1.3 root 506: 1.1.1.4 ! root 507: The conversion programs `protoize' and `unprotoize' can sometimes ! 508: change a source file in a way that won't work unless you rearrange it. ! 509: ! 510: * `protoize' can insert references to a type name or type tag before ! 511: the definition, or in a file where they are not defined. ! 512: ! 513: If this happens, compiler error messages should show you where the ! 514: new references are, so fixing the file by hand is straightforward. ! 515: ! 516: * There are some C constructs which `protoize' cannot figure out. ! 517: For example, it can't determine argument types for declaring a ! 518: pointer-to-function variable; this you must do by hand. `protoize' ! 519: inserts a comment containing `???' each time it finds such a ! 520: variable; so you can find all such variables by searching for this ! 521: string. ANSI C does not require declaring the argument types of ! 522: pointer-to-function types. ! 523: ! 524: * Using `unprotoize' can easily introduce bugs. If the program ! 525: relied on prototypes to bring about conversion of arguments, these ! 526: conversions will not take place in the program without prototypes. ! 527: One case in which you can be sure `unprotoize' is safe is when you ! 528: are removing prototypes that were made with `protoize'; if the ! 529: program worked before without any prototypes, it will work again ! 530: without them. ! 531: ! 532: You can find all the places where this problem might occur by ! 533: compiling the program with the `-Wconversion' option. It prints a ! 534: warning whenever an argument is converted. ! 535: ! 536: * Both conversion programs can be confused if there are macro calls ! 537: in and around the text to be converted. In other words, the ! 538: standard syntax for a declaration or definition must not result ! 539: from expanding a macro. This problem is inherent in the design of ! 540: C and cannot be fixed. If only a few functions have confusing ! 541: macro calls, you can easily convert them manually. ! 542: ! 543: * `protoize' cannot get the argument types for a function whose ! 544: definition was not actually compiled due to preprocessor ! 545: conditionals. When this happens, `protoize' changes nothing in ! 546: regard to such a function. `protoize' tries to detect such ! 547: instances and warn about them. ! 548: ! 549: You can generally work around this problem by using `protoize' step ! 550: by step, each time specifying a different set of `-D' options for ! 551: compilation, until all of the functions have been converted. ! 552: There is no automatic way to verify that you have got them all, ! 553: however. ! 554: ! 555: * Confusion may result if there is an occasion to convert a function ! 556: declaration or definition in a region of source code where there ! 557: is more than one formal parameter list present. Thus, attempts to ! 558: convert code containing multiple (conditionally compiled) versions ! 559: of a single function header (in the same vicinity) may not produce ! 560: the desired (or expected) results. ! 561: ! 562: If you plan on converting source files which contain such code, it ! 563: is recommended that you first make sure that each conditionally ! 564: compiled region of source code which contains an alternative ! 565: function header also contains at least one additional follower ! 566: token (past the final right parenthesis of the function header). ! 567: This should circumvent the problem. ! 568: ! 569: * `unprotoize' can become confused when trying to convert a function ! 570: definition or declaration which contains a declaration for a ! 571: pointer-to-function formal argument which has the same name as the ! 572: function being defined or declared. We recommand you avoid such ! 573: choices of formal parameter names. ! 574: ! 575: * You might also want to correct some of the indentation by hand and ! 576: break long lines. (The conversion programs don't write lines ! 577: longer than eighty characters in any case.) 1.1 root 578: 579: 1.1.1.4 ! root 580: File: gcc.info, Node: Non-bugs, Prev: Protoize Caveats, Up: Trouble ! 581: ! 582: Certain Changes We Don't Want to Make ! 583: ===================================== 1.1.1.2 root 584: 1.1.1.4 ! root 585: This section lists changes that people frequently request, but which ! 586: we do not make because we think GNU CC is better without them. 1.1.1.2 root 587: 1.1.1.4 ! root 588: * Checking the number and type of arguments to a function which has ! 589: an old-fashioned definition and no prototype. ! 590: ! 591: Such a feature would work only occasionally--only for calls that ! 592: appear in the same file as the called function, following the ! 593: definition. The only way to check all calls reliably is to add a ! 594: prototype for the function. But adding a prototype eliminates the ! 595: motivation for this feature. So the feature is not worthwhile. ! 596: ! 597: * Warning about using an expression whose type is signed as a shift ! 598: count. ! 599: ! 600: Shift count operands are probably signed more often than unsigned. ! 601: Warning about this would cause far more annoyance than good. ! 602: ! 603: * Warning about assigning a signed value to an unsigned variable. ! 604: ! 605: Such assignments must be very common; warning about them would ! 606: cause more annoyance than good. ! 607: ! 608: * Warning about unreachable code. ! 609: ! 610: It's very common to have unreachable code in machine-generated ! 611: programs. For example, this happens normally in some files of GNU ! 612: C itself. ! 613: ! 614: * Warning when a non-void function value is ignored. ! 615: ! 616: Coming as I do from a Lisp background, I balk at the idea that ! 617: there is something dangerous about discarding a value. There are ! 618: functions that return values which some callers may find useful; ! 619: it makes no sense to clutter the program with a cast to `void' ! 620: whenever the value isn't useful. ! 621: ! 622: * Assuming (for optimization) that the address of an external symbol ! 623: is never zero. ! 624: ! 625: This assumption is false on certain systems when `#pragma weak' is ! 626: used. ! 627: ! 628: * Making `-fshort-enums' the default. ! 629: ! 630: This would cause storage layout to be incompatible with most other ! 631: C compilers. And it doesn't seem very important, given that you ! 632: can get the same result in other ways. The case where it matters ! 633: most is when the enumeration-valued object is inside a structure, ! 634: and in that case you can specify a field width explicitly. ! 635: ! 636: * Making bitfields unsigned by default on particular machines where ! 637: "the ABI standard" says to do so. ! 638: ! 639: The ANSI C standard leaves it up to the implementation whether a ! 640: bitfield declared plain `int' is signed or not. This in effect ! 641: creates two alternative dialects of C. ! 642: ! 643: The GNU C compiler supports both dialects; you can specify the ! 644: dialect you want with the option `-fsigned-bitfields' or ! 645: `-funsigned-bitfields'. However, this leaves open the question of ! 646: which dialect to use by default. ! 647: ! 648: Currently, the preferred dialect makes plain bitfields signed, ! 649: because this is simplest. Since `int' is the same as `signed int' ! 650: in every other context, it is cleanest for them to be the same in ! 651: bitfields as well. ! 652: ! 653: Some computer manufacturers have published Application Binary ! 654: Interface standards which specify that plain bitfields should be ! 655: unsigned. It is a mistake, however, to say anything about this ! 656: issue in an ABI. This is because the handling of plain bitfields ! 657: distinguishes two dialects of C. Both dialects are meaningful on ! 658: every type of machine. Whether a particular object file was ! 659: compiled using signed bitfields or unsigned is of no concern to ! 660: other object files, even if they access the same bitfields in the ! 661: same data structures. ! 662: ! 663: A given program is written in one or the other of these two ! 664: dialects. The program stands a chance to work on most any machine ! 665: if it is compiled with the proper dialect. It is unlikely to work ! 666: at all if compiled with the wrong dialect. ! 667: ! 668: Many users appreciate the GNU C compiler because it provides an ! 669: environment that is uniform across machines. These users would be ! 670: inconvenienced if the compiler treated plain bitfields differently ! 671: on certain machines. ! 672: ! 673: Occasionally users write programs intended only for a particular ! 674: machine type. On these occasions, the users would benefit if the ! 675: GNU C compiler were to support by default the same dialect as the ! 676: other compilers on that machine. But such applications are rare. ! 677: And users writing a program to run on more than one type of ! 678: machine cannot possibly benefit from this kind of compatibility. ! 679: ! 680: This is why GNU CC does and will treat plain bitfields in the same ! 681: fashion on all types of machines (by default). ! 682: ! 683: There are some arguments for making bitfields unsigned by default ! 684: on all machines. If, for example, this becomes a universal de ! 685: facto standard, it would make sense for GNU CC to go along with ! 686: it. This is something to be considered in the future. ! 687: ! 688: (Of course, users strongly concerned about portability should ! 689: indicate explicitly in each bitfield whether it is signed or not. ! 690: In this way, they write programs which have the same meaning in ! 691: both C dialects.) ! 692: ! 693: * Undefining `__STDC__' when `-ansi' is not used. ! 694: ! 695: Currently, GNU CC defines `__STDC__' as long as you don't use ! 696: `-traditional'. This provides good results in practice. ! 697: ! 698: Programmers normally use conditionals on `__STDC__' to ask whether ! 699: it is safe to use certain features of ANSI C, such as function ! 700: prototypes or ANSI token concatenation. Since plain `gcc' supports ! 701: all the features of ANSI C, the correct answer to these questions ! 702: is "yes". ! 703: ! 704: Some users try to use `__STDC__' to check for the availability of ! 705: certain library facilities. This is actually incorrect usage in ! 706: an ANSI C program, because the ANSI C standard says that a ! 707: conforming freestanding implementation should define `__STDC__' ! 708: even though it does not have the library facilities. `gcc -ansi ! 709: -pedantic' is a conforming freestanding implementation, and it is ! 710: therefore required to define `__STDC__', even though it does not ! 711: come with an ANSI C library. ! 712: ! 713: Sometimes people say that defining `__STDC__' in a compiler that ! 714: does not completely conform to the ANSI C standard somehow ! 715: violates the standard. This is illogical. The standard is a ! 716: standard for compilers that claim to support ANSI C, such as `gcc ! 717: -ansi'--not for other compilers such as plain `gcc'. Whatever the ! 718: ANSI C standard says is relevant to the design of plain `gcc' ! 719: without `-ansi' only for pragmatic reasons, not as a requirement. ! 720: ! 721: * Undefining `__STDC__' in C++. ! 722: ! 723: Programs written to compile with C++-to-C translators get the ! 724: value of `__STDC__' that goes with the C compiler that is ! 725: subsequently used. These programs must test `__STDC__' to ! 726: determine what kind of C preprocessor that compiler uses: whether ! 727: they should concatenate tokens in the ANSI C fashion or in the ! 728: traditional fashion. ! 729: ! 730: These programs work properly with GNU C++ if `__STDC__' is defined. ! 731: They would not work otherwise. ! 732: ! 733: In addition, many header files are written to provide prototypes ! 734: in ANSI C but not in traditional C. Many of these header files ! 735: can work without change in C++ provided `__STDC__' is defined. If ! 736: `__STDC__' is not defined, they will all fail, and will all need ! 737: to be changed to test explicitly for C++ as well. ! 738: ! 739: * Deleting "empty" loops. ! 740: ! 741: GNU CC does not delete "empty" loops because the most likely reason ! 742: you would put one in a program is to have a delay. Deleting them ! 743: will not make real programs run any faster, so it would be ! 744: pointless. ! 745: ! 746: It would be different if optimization of a nonempty loop could ! 747: produce an empty one. But this generally can't happen. 1.1.1.2 root 748: 749: 1.1.1.4 ! root 750: File: gcc.info, Node: Bugs, Next: Service, Prev: Trouble, Up: Top ! 751: ! 752: Reporting Bugs ! 753: ************** 1.1.1.2 root 754: 1.1.1.4 ! root 755: Your bug reports play an essential role in making GNU CC reliable. 1.1.1.2 root 756: 1.1.1.4 ! root 757: When you encounter a problem, the first thing to do is to see if it ! 758: is already known. *Note Trouble::. If it isn't known, then you should ! 759: report the problem. ! 760: ! 761: Reporting a bug may help you by bringing a solution to your problem, ! 762: or it may not. (If it does not, look in the service directory; see ! 763: *Note Service::.) In any case, the principal function of a bug report ! 764: is to help the entire community by making the next version of GNU CC ! 765: work better. Bug reports are your contribution to the maintenance of ! 766: GNU CC. ! 767: ! 768: In order for a bug report to serve its purpose, you must include the ! 769: information that makes for fixing the bug. 1.1.1.2 root 770: 771: * Menu: 772: 1.1.1.4 ! root 773: * Criteria: Bug Criteria. Have you really found a bug? ! 774: * Where: Bug Lists. Where to send your bug report. ! 775: * Reporting: Bug Reporting. How to report a bug effectively. ! 776: * Patches: Sending Patches. How to send a patch for GNU CC. ! 777: * Known: Trouble. Known problems. ! 778: * Help: Service. Where to ask for help. 1.1.1.2 root 779: 780: 1.1.1.4 ! root 781: File: gcc.info, Node: Bug Criteria, Next: Bug Lists, Up: Bugs 1.1.1.2 root 782: 1.1.1.4 ! root 783: Have You Found a Bug? ! 784: ===================== 1.1.1.2 root 785: 1.1.1.4 ! root 786: If you are not sure whether you have found a bug, here are some ! 787: guidelines: 1.1.1.2 root 788: 1.1.1.4 ! root 789: * If the compiler gets a fatal signal, for any input whatever, that ! 790: is a compiler bug. Reliable compilers never crash. ! 791: ! 792: * If the compiler produces invalid assembly code, for any input ! 793: whatever (except an `asm' statement), that is a compiler bug, ! 794: unless the compiler reports errors (not just warnings) which would ! 795: ordinarily prevent the assembler from being run. ! 796: ! 797: * If the compiler produces valid assembly code that does not ! 798: correctly execute the input source code, that is a compiler bug. ! 799: ! 800: However, you must double-check to make sure, because you may have ! 801: run into an incompatibility between GNU C and traditional C (*note ! 802: Incompatibilities::.). These incompatibilities might be considered ! 803: bugs, but they are inescapable consequences of valuable features. ! 804: ! 805: Or you may have a program whose behavior is undefined, which ! 806: happened by chance to give the desired results with another C or ! 807: C++ compiler. ! 808: ! 809: For example, in many nonoptimizing compilers, you can write `x;' ! 810: at the end of a function instead of `return x;', with the same ! 811: results. But the value of the function is undefined if `return' ! 812: is omitted; it is not a bug when GNU CC produces different results. ! 813: ! 814: Problems often result from expressions with two increment ! 815: operators, as in `f (*p++, *p++)'. Your previous compiler might ! 816: have interpreted that expression the way you intended; GNU CC might ! 817: interpret it another way. Neither compiler is wrong. The bug is ! 818: in your code. ! 819: ! 820: After you have localized the error to a single source line, it ! 821: should be easy to check for these things. If your program is ! 822: correct and well defined, you have found a compiler bug. ! 823: ! 824: * If the compiler produces an error message for valid input, that is ! 825: a compiler bug. ! 826: ! 827: * If the compiler does not produce an error message for invalid ! 828: input, that is a compiler bug. However, you should note that your ! 829: idea of "invalid input" might be my idea of "an extension" or ! 830: "support for traditional practice". ! 831: ! 832: * If you are an experienced user of C or C++ compilers, your ! 833: suggestions for improvement of GNU CC or GNU C++ are welcome in ! 834: any case. 1.1.1.2 root 835: 836: 1.1.1.4 ! root 837: File: gcc.info, Node: Bug Lists, Next: Bug Reporting, Prev: Bug Criteria, Up: Bugs 1.1 root 838: 1.1.1.4 ! root 839: Where to Report Bugs ! 840: ==================== 1.1 root 841: 1.1.1.4 ! root 842: Send bug reports for GNU C to one of these addresses: ! 843: ! 844: [email protected] ! 845: {ucbvax|mit-eddie|uunet}!prep.ai.mit.edu!bug-gcc ! 846: ! 847: Send bug reports for GNU C++ to one of these addresses: ! 848: ! 849: [email protected] ! 850: {ucbvax|mit-eddie|uunet}!prep.ai.mit.edu!bug-g++ ! 851: ! 852: *Do not send bug reports to `help-gcc', or to the newsgroup ! 853: `gnu.gcc.help'.* Most users of GNU CC do not want to receive bug ! 854: reports. Those that do, have asked to be on `bug-gcc' and/or `bug-g++'. ! 855: ! 856: The mailing lists `bug-gcc' and `bug-g++' both have newsgroups which ! 857: serve as repeaters: `gnu.gcc.bug' and `gnu.g++.bug'. Each mailing list ! 858: and its newsgroup carry exactly the same messages. ! 859: ! 860: Often people think of posting bug reports to the newsgroup instead of ! 861: mailing them. This appears to work, but it has one problem which can be ! 862: crucial: a newsgroup posting does not contain a mail path back to the ! 863: sender. Thus, if maintainers need more information, they may be unable ! 864: to reach you. For this reason, you should always send bug reports by ! 865: mail to the proper mailing list. ! 866: ! 867: As a last resort, send bug reports on paper to: ! 868: ! 869: GNU Compiler Bugs ! 870: Free Software Foundation ! 871: 675 Mass Ave ! 872: Cambridge, MA 02139 1.1 root 873: 874: 1.1.1.4 ! root 875: File: gcc.info, Node: Bug Reporting, Next: Sending Patches, Prev: Bug Lists, Up: Bugs 1.1 root 876: 1.1.1.4 ! root 877: How to Report Bugs ! 878: ================== 1.1 root 879: 1.1.1.4 ! root 880: The fundamental principle of reporting bugs usefully is this: ! 881: *report all the facts*. If you are not sure whether to state a fact or ! 882: leave it out, state it! ! 883: ! 884: Often people omit facts because they think they know what causes the ! 885: problem and they conclude that some details don't matter. Thus, you ! 886: might assume that the name of the variable you use in an example does ! 887: not matter. Well, probably it doesn't, but one cannot be sure. Perhaps ! 888: the bug is a stray memory reference which happens to fetch from the ! 889: location where that name is stored in memory; perhaps, if the name were ! 890: different, the contents of that location would fool the compiler into ! 891: doing the right thing despite the bug. Play it safe and give a ! 892: specific, complete example. That is the easiest thing for you to do, ! 893: and the most helpful. ! 894: ! 895: Keep in mind that the purpose of a bug report is to enable someone to ! 896: fix the bug if it is not known. It isn't very important what happens if ! 897: the bug is already known. Therefore, always write your bug reports on ! 898: the assumption that the bug is not known. ! 899: ! 900: Sometimes people give a few sketchy facts and ask, "Does this ring a ! 901: bell?" This cannot help us fix a bug, so it is basically useless. We ! 902: respond by asking for enough details to enable us to investigate. You ! 903: might as well expedite matters by sending them to begin with. ! 904: ! 905: Try to make your bug report self-contained. If we have to ask you ! 906: for more information, it is best if you include all the previous ! 907: information in your response, as well as the information that was ! 908: missing. ! 909: ! 910: To enable someone to investigate the bug, you should include all ! 911: these things: ! 912: ! 913: * The version of GNU CC. You can get this by running it with the ! 914: `-v' option. ! 915: ! 916: Without this, we won't know whether there is any point in looking ! 917: for the bug in the current version of GNU CC. ! 918: ! 919: * A complete input file that will reproduce the bug. If the bug is ! 920: in the C preprocessor, send a source file and any header files ! 921: that it requires. If the bug is in the compiler proper (`cc1'), ! 922: run your source file through the C preprocessor by doing `gcc -E ! 923: SOURCEFILE > OUTFILE', then include the contents of OUTFILE in the ! 924: bug report. (When you do this, use the same `-I', `-D' or `-U' ! 925: options that you used in actual compilation.) ! 926: ! 927: A single statement is not enough of an example. In order to ! 928: compile it, it must be embedded in a complete file of compiler ! 929: input; and the bug might depend on the details of how this is done. ! 930: ! 931: Without a real example one can compile, all anyone can do about ! 932: your bug report is wish you luck. It would be futile to try to ! 933: guess how to provoke the bug. For example, bugs in register ! 934: allocation and reloading frequently depend on every little detail ! 935: of the function they happen in. ! 936: ! 937: Even if the input file that fails comes from a GNU program, you ! 938: should still send the complete test case. Don't ask the GNU CC ! 939: maintainers to do the extra work of obtaining the program in ! 940: question--they are all overworked as it is. Also, the problem may ! 941: depend on what is in the header files on your system; it is ! 942: unreliable for the GNU CC maintainers to try the problem with the ! 943: header files available to them. By sending CPP output, you can ! 944: eliminate this source of uncertainty. ! 945: ! 946: * The command arguments you gave GNU CC or GNU C++ to compile that ! 947: example and observe the bug. For example, did you use `-O'? To ! 948: guarantee you won't omit something important, list all the options. ! 949: ! 950: If we were to try to guess the arguments, we would probably guess ! 951: wrong and then we would not encounter the bug. ! 952: ! 953: * The type of machine you are using, and the operating system name ! 954: and version number. ! 955: ! 956: * The operands you gave to the `configure' command when you installed ! 957: the compiler. ! 958: ! 959: * A complete list of any modifications you have made to the compiler ! 960: source. (We don't promise to investigate the bug unless it ! 961: happens in an unmodified compiler. But if you've made ! 962: modifications and don't tell us, then you are sending us on a wild ! 963: goose chase.) ! 964: ! 965: Be precise about these changes. A description in English is not ! 966: enough--send a context diff for them. ! 967: ! 968: Adding files of your own (such as a machine description for a ! 969: machine we don't support) is a modification of the compiler source. ! 970: ! 971: * Details of any other deviations from the standard procedure for ! 972: installing GNU CC. ! 973: ! 974: * A description of what behavior you observe that you believe is ! 975: incorrect. For example, "The compiler gets a fatal signal," or, ! 976: "The assembler instruction at line 208 in the output is incorrect." ! 977: ! 978: Of course, if the bug is that the compiler gets a fatal signal, ! 979: then one can't miss it. But if the bug is incorrect output, the ! 980: maintainer might not notice unless it is glaringly wrong. None of ! 981: us has time to study all the assembler code from a 50-line C ! 982: program just on the chance that one instruction might be wrong. ! 983: We need *you* to do this part! ! 984: ! 985: Even if the problem you experience is a fatal signal, you should ! 986: still say so explicitly. Suppose something strange is going on, ! 987: such as, your copy of the compiler is out of synch, or you have ! 988: encountered a bug in the C library on your system. (This has ! 989: happened!) Your copy might crash and the copy here would not. If ! 990: you said to expect a crash, then when the compiler here fails to ! 991: crash, we would know that the bug was not happening. If you don't ! 992: say to expect a crash, then we would not know whether the bug was ! 993: happening. We would not be able to draw any conclusion from our ! 994: observations. ! 995: ! 996: If the problem is a diagnostic when compiling GNU CC with some ! 997: other compiler, say whether it is a warning or an error. ! 998: ! 999: Often the observed symptom is incorrect output when your program ! 1000: is run. Sad to say, this is not enough information unless the ! 1001: program is short and simple. None of us has time to study a large ! 1002: program to figure out how it would work if compiled correctly, ! 1003: much less which line of it was compiled wrong. So you will have ! 1004: to do that. Tell us which source line it is, and what incorrect ! 1005: result happens when that line is executed. A person who ! 1006: understands the program can find this as easily as finding a bug ! 1007: in the program itself. ! 1008: ! 1009: * If you send examples of assembler code output from GNU CC or GNU ! 1010: C++, please use `-g' when you make them. The debugging information ! 1011: includes source line numbers which are essential for correlating ! 1012: the output with the input. ! 1013: ! 1014: * If you wish to mention something in the GNU CC source, refer to it ! 1015: by context, not by line number. ! 1016: ! 1017: The line numbers in the development sources don't match those in ! 1018: your sources. Your line numbers would convey no useful ! 1019: information to the maintainers. ! 1020: ! 1021: * Additional information from a debugger might enable someone to ! 1022: find a problem on a machine which he does not have available. ! 1023: However, you need to think when you collect this information if ! 1024: you want it to have any chance of being useful. ! 1025: ! 1026: For example, many people send just a backtrace, but that is never ! 1027: useful by itself. A simple backtrace with arguments conveys little ! 1028: about GNU CC because the compiler is largely data-driven; the same ! 1029: functions are called over and over for different RTL insns, doing ! 1030: different things depending on the details of the insn. ! 1031: ! 1032: Most of the arguments listed in the backtrace are useless because ! 1033: they are pointers to RTL list structure. The numeric values of the ! 1034: pointers, which the debugger prints in the backtrace, have no ! 1035: significance whatever; all that matters is the contents of the ! 1036: objects they point to (and most of the contents are other such ! 1037: pointers). ! 1038: ! 1039: In addition, most compiler passes consist of one or more loops that ! 1040: scan the RTL insn sequence. The most vital piece of information ! 1041: about such a loop--which insn it has reached--is usually in a ! 1042: local variable, not in an argument. ! 1043: ! 1044: What you need to provide in addition to a backtrace are the values ! 1045: of the local variables for several stack frames up. When a local ! 1046: variable or an argument is an RTX, first print its value and then ! 1047: use the GDB command `pr' to print the RTL expression that it points ! 1048: to. (If GDB doesn't run on your machine, use your debugger to call ! 1049: the function `debug_rtx' with the RTX as an argument.) In ! 1050: general, whenever a variable is a pointer, its value is no use ! 1051: without the data it points to. ! 1052: ! 1053: Here are some things that are not necessary: ! 1054: ! 1055: * A description of the envelope of the bug. ! 1056: ! 1057: Often people who encounter a bug spend a lot of time investigating ! 1058: which changes to the input file will make the bug go away and which ! 1059: changes will not affect it. ! 1060: ! 1061: This is often time consuming and not very useful, because the way ! 1062: we will find the bug is by running a single example under the ! 1063: debugger with breakpoints, not by pure deduction from a series of ! 1064: examples. You might as well save your time for something else. ! 1065: ! 1066: Of course, if you can find a simpler example to report *instead* of ! 1067: the original one, that is a convenience. Errors in the output ! 1068: will be easier to spot, running under the debugger will take less ! 1069: time, etc. Most GNU CC bugs involve just one function, so the most ! 1070: straightforward way to simplify an example is to delete all the ! 1071: function definitions except the one where the bug occurs. Those ! 1072: earlier in the file may be replaced by external declarations if ! 1073: the crucial function depends on them. (Exception: inline ! 1074: functions may affect compilation of functions defined later in the ! 1075: file.) ! 1076: ! 1077: However, simplification is not vital; if you don't want to do this, ! 1078: report the bug anyway and send the entire test case you used. ! 1079: ! 1080: * In particular, some people insert conditionals `#ifdef BUG' around ! 1081: a statement which, if removed, makes the bug not happen. These ! 1082: are just clutter; we won't pay any attention to them anyway. ! 1083: Besides, you should send us cpp output, and that can't have ! 1084: conditionals. ! 1085: ! 1086: * A patch for the bug. ! 1087: ! 1088: A patch for the bug is useful if it is a good one. But don't omit ! 1089: the necessary information, such as the test case, on the ! 1090: assumption that a patch is all we need. We might see problems ! 1091: with your patch and decide to fix the problem another way, or we ! 1092: might not understand it at all. ! 1093: ! 1094: Sometimes with a program as complicated as GNU CC it is very hard ! 1095: to construct an example that will make the program follow a ! 1096: certain path through the code. If you don't send the example, we ! 1097: won't be able to construct one, so we won't be able to verify that ! 1098: the bug is fixed. ! 1099: ! 1100: And if we can't understand what bug you are trying to fix, or why ! 1101: your patch should be an improvement, we won't install it. A test ! 1102: case will help us to understand. ! 1103: ! 1104: *Note Sending Patches::, for guidelines on how to make it easy for ! 1105: us to understand and install your patches. ! 1106: ! 1107: * A guess about what the bug is or what it depends on. ! 1108: ! 1109: Such guesses are usually wrong. Even I can't guess right about ! 1110: such things without first using the debugger to find the facts. ! 1111: ! 1112: * A core dump file. ! 1113: ! 1114: We have no way of examining a core dump for your type of machine ! 1115: unless we have an identical system--and if we do have one, we ! 1116: should be able to reproduce the crash ourselves. 1.1 root 1117: 1118:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.