![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-10 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-10 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: External Bugs, Next: Incompatibilities, Prev: Interoperation, Up: Trouble 1.1.1.6 root 34: 1.1.1.7 ! root 35: Problems Compiling Certain Programs ! 36: =================================== ! 37: ! 38: Certain programs have problems compiling. ! 39: ! 40: * Parse errors may occur compiling X11 on a Decstation running ! 41: Ultrix 4.2 because of problems in DEC's versions of the X11 header ! 42: files `X11/Xlib.h' and `X11/Xutil.h'. People recommend adding ! 43: `-I/usr/include/mit' to use the MIT versions of the header files, ! 44: using the `-traditional' switch to turn off ANSI C, or fixing the ! 45: header files by adding this: ! 46: ! 47: #ifdef __STDC__ ! 48: #define NeedFunctionPrototypes 0 ! 49: #endif ! 50: ! 51: * If you have trouble compiling Perl on a SunOS 4 system, it may be ! 52: because Perl specifies `-I/usr/ucbinclude'. This accesses the ! 53: unfixed header files. Perl specifies the options ! 54: ! 55: -traditional -Dvolatile=__volatile__ ! 56: -I/usr/include/sun -I/usr/ucbinclude ! 57: -fpcc-struct-return ! 58: ! 59: most of which are unnecessary with GCC 2.4.5 and newer versions. ! 60: You can make a properly working Perl by setting `ccflags' to ! 61: `-fwritable-strings' (implied by the `-traditional' in the ! 62: original options) and `cppflags' to empty in `config.sh', then ! 63: typing `./doSH; make depend; make'. ! 64: ! 65: * On various 386 Unix systems derived from System V, including SCO, ! 66: ISC, and ESIX, you may get error messages about running out of ! 67: virtual memory while compiling certain programs. ! 68: ! 69: You can prevent this problem by linking GNU CC with the GNU malloc ! 70: (which thus replaces the malloc that comes with the system). GNU ! 71: malloc is available as a separate package, and also in the file ! 72: `src/gmalloc.c' in the GNU Emacs 19 distribution. ! 73: ! 74: If you have installed GNU malloc as a separate library package, ! 75: use this option when you relink GNU CC: ! 76: ! 77: MALLOC=/usr/local/lib/libgmalloc.a ! 78: ! 79: Alternatively, if you have compiled `gmalloc.c' from Emacs 19, copy ! 80: the object file to `gmalloc.o' and use this option when you relink ! 81: GNU CC: ! 82: ! 83: MALLOC=gmalloc.o ! 84: ! 85: ! 86: File: gcc.info, Node: Incompatibilities, Next: Fixed Headers, Prev: External Bugs, Up: Trouble ! 87: ! 88: Incompatibilities of GNU CC ! 89: =========================== ! 90: ! 91: There are several noteworthy incompatibilities between GNU C and most ! 92: existing (non-ANSI) versions of C. The `-traditional' option ! 93: eliminates many of these incompatibilities, *but not all*, by telling ! 94: GNU C to behave like the other C compilers. ! 95: ! 96: * GNU CC normally makes string constants read-only. If several ! 97: identical-looking string constants are used, GNU CC stores only one ! 98: copy of the string. ! 99: ! 100: One consequence is that you cannot call `mktemp' with a string ! 101: constant argument. The function `mktemp' always alters the string ! 102: its argument points to. ! 103: ! 104: Another consequence is that `sscanf' does not work on some systems ! 105: when passed a string constant as its format control string or ! 106: input. This is because `sscanf' incorrectly tries to write into ! 107: the string constant. Likewise `fscanf' and `scanf'. ! 108: ! 109: The best solution to these problems is to change the program to use ! 110: `char'-array variables with initialization strings for these ! 111: purposes instead of string constants. But if this is not possible, ! 112: you can use the `-fwritable-strings' flag, which directs GNU CC to ! 113: handle string constants the same way most C compilers do. ! 114: `-traditional' also has this effect, among others. ! 115: ! 116: * `-2147483648' is positive. ! 117: ! 118: This is because 2147483648 cannot fit in the type `int', so ! 119: (following the ANSI C rules) its data type is `unsigned long int'. ! 120: Negating this value yields 2147483648 again. ! 121: ! 122: * GNU CC does not substitute macro arguments when they appear inside ! 123: of string constants. For example, the following macro in GNU CC ! 124: ! 125: #define foo(a) "a" ! 126: ! 127: will produce output `"a"' regardless of what the argument A is. ! 128: ! 129: The `-traditional' option directs GNU CC to handle such cases ! 130: (among others) in the old-fashioned (non-ANSI) fashion. ! 131: ! 132: * When you use `setjmp' and `longjmp', the only automatic variables ! 133: guaranteed to remain valid are those declared `volatile'. This is ! 134: a consequence of automatic register allocation. Consider this ! 135: function: ! 136: ! 137: jmp_buf j; ! 138: ! 139: foo () ! 140: { ! 141: int a, b; ! 142: ! 143: a = fun1 (); ! 144: if (setjmp (j)) ! 145: return a; ! 146: ! 147: a = fun2 (); ! 148: /* `longjmp (j)' may occur in `fun3'. */ ! 149: return a + fun3 (); ! 150: } ! 151: ! 152: Here `a' may or may not be restored to its first value when the ! 153: `longjmp' occurs. If `a' is allocated in a register, then its ! 154: first value is restored; otherwise, it keeps the last value stored ! 155: in it. ! 156: ! 157: If you use the `-W' option with the `-O' option, you will get a ! 158: warning when GNU CC thinks such a problem might be possible. ! 159: ! 160: The `-traditional' option directs GNU C to put variables in the ! 161: stack by default, rather than in registers, in functions that call ! 162: `setjmp'. This results in the behavior found in traditional C ! 163: compilers. ! 164: ! 165: * Programs that use preprocessor directives in the middle of macro ! 166: arguments do not work with GNU CC. For example, a program like ! 167: this will not work: ! 168: ! 169: foobar ( ! 170: #define luser ! 171: hack) ! 172: ! 173: ANSI C does not permit such a construct. It would make sense to ! 174: support it when `-traditional' is used, but it is too much work to ! 175: implement. ! 176: ! 177: * Declarations of external variables and functions within a block ! 178: apply only to the block containing the declaration. In other ! 179: words, they have the same scope as any other declaration in the ! 180: same place. ! 181: ! 182: In some other C compilers, a `extern' declaration affects all the ! 183: rest of the file even if it happens within a block. ! 184: ! 185: The `-traditional' option directs GNU C to treat all `extern' ! 186: declarations as global, like traditional compilers. ! 187: ! 188: * In traditional C, you can combine `long', etc., with a typedef ! 189: name, as shown here: ! 190: ! 191: typedef int foo; ! 192: typedef long foo bar; ! 193: ! 194: In ANSI C, this is not allowed: `long' and other type modifiers ! 195: require an explicit `int'. Because this criterion is expressed by ! 196: Bison grammar rules rather than C code, the `-traditional' flag ! 197: cannot alter it. ! 198: ! 199: * PCC allows typedef names to be used as function parameters. The ! 200: difficulty described immediately above applies here too. ! 201: ! 202: * PCC allows whitespace in the middle of compound assignment ! 203: operators such as `+='. GNU CC, following the ANSI standard, does ! 204: not allow this. The difficulty described immediately above ! 205: applies here too. ! 206: ! 207: * GNU CC complains about unterminated character constants inside of ! 208: preprocessor conditionals that fail. Some programs have English ! 209: comments enclosed in conditionals that are guaranteed to fail; if ! 210: these comments contain apostrophes, GNU CC will probably report an ! 211: error. For example, this code would produce an error: ! 212: ! 213: #if 0 ! 214: You can't expect this to work. ! 215: #endif ! 216: ! 217: The best solution to such a problem is to put the text into an ! 218: actual C comment delimited by `/*...*/'. However, `-traditional' ! 219: suppresses these error messages. ! 220: ! 221: * Many user programs contain the declaration `long time ();'. In the ! 222: past, the system header files on many systems did not actually ! 223: declare `time', so it did not matter what type your program ! 224: declared it to return. But in systems with ANSI C headers, `time' ! 225: is declared to return `time_t', and if that is not the same as ! 226: `long', then `long time ();' is erroneous. ! 227: ! 228: The solution is to change your program to use `time_t' as the ! 229: return type of `time'. ! 230: ! 231: * When compiling functions that return `float', PCC converts it to a ! 232: double. GNU CC actually returns a `float'. If you are concerned ! 233: with PCC compatibility, you should declare your functions to return ! 234: `double'; you might as well say what you mean. ! 235: ! 236: * When compiling functions that return structures or unions, GNU CC ! 237: output code normally uses a method different from that used on most ! 238: versions of Unix. As a result, code compiled with GNU CC cannot ! 239: call a structure-returning function compiled with PCC, and vice ! 240: versa. ! 241: ! 242: The method used by GNU CC is as follows: a structure or union ! 243: which is 1, 2, 4 or 8 bytes long is returned like a scalar. A ! 244: structure or union with any other size is stored into an address ! 245: supplied by the caller (usually in a special, fixed register, but ! 246: on some machines it is passed on the stack). The ! 247: machine-description macros `STRUCT_VALUE' and ! 248: `STRUCT_INCOMING_VALUE' tell GNU CC where to pass this address. ! 249: ! 250: By contrast, PCC on most target machines returns structures and ! 251: unions of any size by copying the data into an area of static ! 252: storage, and then returning the address of that storage as if it ! 253: were a pointer value. The caller must copy the data from that ! 254: memory area to the place where the value is wanted. GNU CC does ! 255: not use this method because it is slower and nonreentrant. ! 256: ! 257: On some newer machines, PCC uses a reentrant convention for all ! 258: structure and union returning. GNU CC on most of these machines ! 259: uses a compatible convention when returning structures and unions ! 260: in memory, but still returns small structures and unions in ! 261: registers. ! 262: ! 263: You can tell GNU CC to use a compatible convention for all ! 264: structure and union returning with the option ! 265: `-fpcc-struct-return'. ! 266: ! 267: * GNU C complains about program fragments such as `0x74ae-0x4000' ! 268: which appear to be two hexadecimal constants separated by the minus ! 269: operator. Actually, this string is a single "preprocessing token". ! 270: Each such token must correspond to one token in C. Since this ! 271: does not, GNU C prints an error message. Although it may appear ! 272: obvious that what is meant is an operator and two values, the ANSI ! 273: C standard specifically requires that this be treated as erroneous. ! 274: ! 275: A "preprocessing token" is a "preprocessing number" if it begins ! 276: with a digit and is followed by letters, underscores, digits, ! 277: periods and `e+', `e-', `E+', or `E-' character sequences. ! 278: ! 279: To make the above program fragment valid, place whitespace in ! 280: front of the minus sign. This whitespace will end the ! 281: preprocessing number. ! 282: ! 283: ! 284: File: gcc.info, Node: Fixed Headers, Next: Disappointments, Prev: Incompatibilities, Up: Trouble ! 285: ! 286: Fixed Header Files 1.1.1.6 root 287: ================== 288: 1.1.1.7 ! root 289: GNU CC needs to install corrected versions of some system header ! 290: files. This is because most target systems have some header files that ! 291: won't work with GNU CC unless they are changed. Some have bugs, some ! 292: are incompatible with ANSI C, and some depend on special features of ! 293: other compilers. ! 294: ! 295: Installing GNU CC automatically creates and installs the fixed header ! 296: files, by running a program called `fixincludes' (or for certain ! 297: targets an alternative such as `fixinc.svr4'). Normally, you don't ! 298: need to pay attention to this. But there are cases where it doesn't do ! 299: the right thing automatically. ! 300: ! 301: * If you update the system's header files, such as by installing a ! 302: new system version, the fixed header files of GNU CC are not ! 303: automatically updated. The easiest way to update them is to ! 304: reinstall GNU CC. (If you want to be clever, look in the makefile ! 305: and you can find a shortcut.) ! 306: ! 307: * On some systems, in particular SunOS 4, header file directories ! 308: contain machine-specific symbolic links in certain places. This ! 309: makes it possible to share most of the header files among hosts ! 310: running the same version of SunOS 4 on different machine models. ! 311: ! 312: The programs that fix the header files do not understand this ! 313: special way of using symbolic links; therefore, the directory of ! 314: fixed header files is good only for the machine model used to ! 315: build it. ! 316: ! 317: In SunOS 4, only programs that look inside the kernel will notice ! 318: the difference between machine models. Therefore, for most ! 319: purposes, you need not be concerned about this. ! 320: ! 321: It is possible to make separate sets of fixed header files for the ! 322: different machine models, and arrange a structure of symbolic ! 323: links so as to use the proper set, but you'll have to do this by ! 324: hand. ! 325: ! 326: * On Lynxos, GNU CC by default does not fix the header files. This ! 327: is because bugs in the shell cause the `fixincludes' script to ! 328: fail. ! 329: ! 330: This means you will encounter problems due to bugs in the system ! 331: header files. It may be no comfort that they aren't GNU CC's ! 332: fault, but it does mean that there's nothing for us to do about ! 333: them. 1.1.1.6 root 334: 335: 1.1.1.7 ! root 336: File: gcc.info, Node: Disappointments, Next: C++ Misunderstandings, Prev: Fixed Headers, Up: Trouble 1.1.1.6 root 337: 1.1.1.7 ! root 338: Disappointments and Misunderstandings ! 339: ===================================== 1.1.1.6 root 340: 1.1.1.7 ! root 341: These problems are perhaps regrettable, but we don't know any ! 342: practical way around them. 1.1.1.6 root 343: 1.1.1.7 ! root 344: * Certain local variables aren't recognized by debuggers when you ! 345: compile with optimization. ! 346: ! 347: This occurs because sometimes GNU CC optimizes the variable out of ! 348: existence. There is no way to tell the debugger how to compute the ! 349: value such a variable "would have had", and it is not clear that ! 350: would be desirable anyway. So GNU CC simply does not mention the ! 351: eliminated variable when it writes debugging information. ! 352: ! 353: You have to expect a certain amount of disagreement between the ! 354: executable and your source code, when you use optimization. ! 355: ! 356: * Users often think it is a bug when GNU CC reports an error for code ! 357: like this: ! 358: ! 359: int foo (struct mumble *); ! 360: ! 361: struct mumble { ... }; ! 362: ! 363: int foo (struct mumble *x) ! 364: { ... } ! 365: ! 366: This code really is erroneous, because the scope of `struct ! 367: mumble' in the prototype is limited to the argument list ! 368: containing it. It does not refer to the `struct mumble' defined ! 369: with file scope immediately below--they are two unrelated types ! 370: with similar names in different scopes. ! 371: ! 372: But in the definition of `foo', the file-scope type is used ! 373: because that is available to be inherited. Thus, the definition ! 374: and the prototype do not match, and you get an error. ! 375: ! 376: This behavior may seem silly, but it's what the ANSI standard ! 377: specifies. It is easy enough for you to make your code work by ! 378: moving the definition of `struct mumble' above the prototype. ! 379: It's not worth being incompatible with ANSI C just to avoid an ! 380: error for the example shown above. ! 381: ! 382: * Accesses to bitfields even in volatile objects works by accessing ! 383: larger objects, such as a byte or a word. You cannot rely on what ! 384: size of object is accessed in order to read or write the bitfield; ! 385: it may even vary for a given bitfield according to the precise ! 386: usage. ! 387: ! 388: If you care about controlling the amount of memory that is ! 389: accessed, use volatile but do not use bitfields. ! 390: ! 391: * GNU CC comes with shell scripts to fix certain known problems in ! 392: system header files. They install corrected copies of various ! 393: header files in a special directory where only GNU CC will ! 394: normally look for them. The scripts adapt to various systems by ! 395: searching all the system header files for the problem cases that ! 396: we know about. ! 397: ! 398: If new system header files are installed, nothing automatically ! 399: arranges to update the corrected header files. You will have to ! 400: reinstall GNU CC to fix the new header files. More specifically, ! 401: go to the build directory and delete the files `stmp-fixinc' and ! 402: `stmp-headers', and the subdirectory `include'; then do `make ! 403: install' again. ! 404: ! 405: * On 68000 systems, you can get paradoxical results if you test the ! 406: precise values of floating point numbers. For example, you can ! 407: find that a floating point value which is not a NaN is not equal ! 408: to itself. This results from the fact that the the floating point ! 409: registers hold a few more bits of precision than fit in a `double' ! 410: in memory. Compiled code moves values between memory and floating ! 411: point registers at its convenience, and moving them into memory ! 412: truncates them. ! 413: ! 414: You can partially avoid this problem by using the `-ffloat-store' ! 415: option (*note Optimize Options::.). ! 416: ! 417: * On the MIPS, variable argument functions using `varargs.h' cannot ! 418: have a floating point value for the first argument. The reason ! 419: for this is that in the absence of a prototype in scope, if the ! 420: first argument is a floating point, it is passed in a floating ! 421: point register, rather than an integer register. ! 422: ! 423: If the code is rewritten to use the ANSI standard `stdarg.h' ! 424: method of variable arguments, and the prototype is in scope at the ! 425: time of the call, everything will work fine. 1.1.1.6 root 426: 427: 1.1.1.7 ! root 428: File: gcc.info, Node: C++ Misunderstandings, Next: Protoize Caveats, Prev: Disappointments, Up: Trouble 1.1.1.6 root 429: 1.1.1.7 ! root 430: Common Misunderstandings with GNU C++ ! 431: ===================================== 1.1.1.6 root 432: 1.1.1.7 ! root 433: C++ is a complex language and an evolving one, and its standard ! 434: definition (the ANSI C++ draft standard) is also evolving. As a result, ! 435: your C++ compiler may occasionally surprise you, even when its behavior ! 436: is correct. This section discusses some areas that frequently give ! 437: rise to questions of this sort. ! 438: ! 439: * Menu: ! 440: ! 441: * Static Definitions:: Static member declarations are not definitions ! 442: * Temporaries:: Temporaries may vanish before you expect 1.1.1.6 root 443: 444: 1.1.1.7 ! root 445: File: gcc.info, Node: Static Definitions, Next: Temporaries, Up: C++ Misunderstandings 1.1.1.6 root 446: 1.1.1.7 ! root 447: Declare *and* Define Static Members ! 448: ----------------------------------- 1.1.1.6 root 449: 1.1.1.7 ! root 450: When a class has static data members, it is not enough to *declare* ! 451: the static member; you must also *define* it. For example: 1.1.1.5 root 452: 1.1.1.7 ! root 453: class Foo 1.1.1.5 root 454: { 455: ... 1.1.1.7 ! root 456: void method(); ! 457: static int bar; ! 458: }; ! 459: ! 460: This declaration only establishes that the class `Foo' has an `int' ! 461: named `Foo::bar', and a member function named `Foo::method'. But you ! 462: still need to define *both* `method' and `bar' elsewhere. According to ! 463: the draft ANSI standard, you must supply an initializer in one (and ! 464: only one) source file, such as: ! 465: ! 466: int Foo::bar = 0; ! 467: ! 468: Other C++ compilers may not correctly implement the standard ! 469: behavior. As a result, when you switch to `g++' from one of these ! 470: compilers, you may discover that a program that appeared to work ! 471: correctly in fact does not conform to the standard: `g++' reports as ! 472: undefined symbols any static data members that lack definitions. ! 473: ! 474: ! 475: File: gcc.info, Node: Temporaries, Prev: Static Definitions, Up: C++ Misunderstandings ! 476: ! 477: Temporaries May Vanish Before You Expect ! 478: ---------------------------------------- ! 479: ! 480: It is dangerous to use pointers or references to *portions* of a ! 481: temporary object. The compiler may very well delete the object before ! 482: you expect it to, leaving a pointer to garbage. The most common place ! 483: where this problem crops up is in classes like the libg++ `String' ! 484: class, that define a conversion function to type `char *' or `const ! 485: char *'. However, any class that returns a pointer to some internal ! 486: structure is potentially subject to this problem. ! 487: ! 488: For example, a program may use a function `strfunc' that returns ! 489: `String' objects, and another function `charfunc' that operates on ! 490: pointers to `char': ! 491: ! 492: String strfunc (); ! 493: void charfunc (const char *); ! 494: ! 495: In this situation, it may seem natural to write ! 496: `charfunc (strfunc ());' based on the knowledge that class `String' has ! 497: an explicit conversion to `char' pointers. However, what really ! 498: happens is akin to `charfunc (strfunc ().convert ());', where the ! 499: `convert' method is a function to do the same data conversion normally ! 500: performed by a cast. Since the last use of the temporary `String' ! 501: object is the call to the conversion function, the compiler may delete ! 502: that object before actually calling `charfunc'. The compiler has no ! 503: way of knowing that deleting the `String' object will invalidate the ! 504: pointer. The pointer then points to garbage, so that by the time ! 505: `charfunc' is called, it gets an invalid argument. ! 506: ! 507: Code like this may run successfully under some other compilers, ! 508: especially those that delete temporaries relatively late. However, the ! 509: GNU C++ behavior is also standard-conformant, so if your program depends ! 510: on late destruction of temporaries it is not portable. ! 511: ! 512: If you think this is surprising, you should be aware that the ANSI ! 513: C++ committee continues to debate the lifetime-of-temporaries problem. ! 514: ! 515: For now, at least, the safe way to write such code is to give the ! 516: temporary a name, which forces it to remain until the end of the scope ! 517: of the name. For example: ! 518: ! 519: String& tmp = strfunc (); ! 520: charfunc (tmp); ! 521: ! 522: ! 523: File: gcc.info, Node: Protoize Caveats, Next: Non-bugs, Prev: C++ Misunderstandings, Up: Trouble ! 524: ! 525: Caveats of using `protoize' ! 526: =========================== ! 527: ! 528: The conversion programs `protoize' and `unprotoize' can sometimes ! 529: change a source file in a way that won't work unless you rearrange it. ! 530: ! 531: * `protoize' can insert references to a type name or type tag before ! 532: the definition, or in a file where they are not defined. ! 533: ! 534: If this happens, compiler error messages should show you where the ! 535: new references are, so fixing the file by hand is straightforward. ! 536: ! 537: * There are some C constructs which `protoize' cannot figure out. ! 538: For example, it can't determine argument types for declaring a ! 539: pointer-to-function variable; this you must do by hand. `protoize' ! 540: inserts a comment containing `???' each time it finds such a ! 541: variable; so you can find all such variables by searching for this ! 542: string. ANSI C does not require declaring the argument types of ! 543: pointer-to-function types. ! 544: ! 545: * Using `unprotoize' can easily introduce bugs. If the program ! 546: relied on prototypes to bring about conversion of arguments, these ! 547: conversions will not take place in the program without prototypes. ! 548: One case in which you can be sure `unprotoize' is safe is when you ! 549: are removing prototypes that were made with `protoize'; if the ! 550: program worked before without any prototypes, it will work again ! 551: without them. ! 552: ! 553: You can find all the places where this problem might occur by ! 554: compiling the program with the `-Wconversion' option. It prints a ! 555: warning whenever an argument is converted. ! 556: ! 557: * Both conversion programs can be confused if there are macro calls ! 558: in and around the text to be converted. In other words, the ! 559: standard syntax for a declaration or definition must not result ! 560: from expanding a macro. This problem is inherent in the design of ! 561: C and cannot be fixed. If only a few functions have confusing ! 562: macro calls, you can easily convert them manually. ! 563: ! 564: * `protoize' cannot get the argument types for a function whose ! 565: definition was not actually compiled due to preprocessor ! 566: conditionals. When this happens, `protoize' changes nothing in ! 567: regard to such a function. `protoize' tries to detect such ! 568: instances and warn about them. ! 569: ! 570: You can generally work around this problem by using `protoize' step ! 571: by step, each time specifying a different set of `-D' options for ! 572: compilation, until all of the functions have been converted. ! 573: There is no automatic way to verify that you have got them all, ! 574: however. ! 575: ! 576: * Confusion may result if there is an occasion to convert a function ! 577: declaration or definition in a region of source code where there ! 578: is more than one formal parameter list present. Thus, attempts to ! 579: convert code containing multiple (conditionally compiled) versions ! 580: of a single function header (in the same vicinity) may not produce ! 581: the desired (or expected) results. ! 582: ! 583: If you plan on converting source files which contain such code, it ! 584: is recommended that you first make sure that each conditionally ! 585: compiled region of source code which contains an alternative ! 586: function header also contains at least one additional follower ! 587: token (past the final right parenthesis of the function header). ! 588: This should circumvent the problem. ! 589: ! 590: * `unprotoize' can become confused when trying to convert a function ! 591: definition or declaration which contains a declaration for a ! 592: pointer-to-function formal argument which has the same name as the ! 593: function being defined or declared. We recommand you avoid such ! 594: choices of formal parameter names. ! 595: ! 596: * You might also want to correct some of the indentation by hand and ! 597: break long lines. (The conversion programs don't write lines ! 598: longer than eighty characters in any case.) ! 599: ! 600: ! 601: File: gcc.info, Node: Non-bugs, Next: Warnings and Errors, Prev: Protoize Caveats, Up: Trouble ! 602: ! 603: Certain Changes We Don't Want to Make ! 604: ===================================== ! 605: ! 606: This section lists changes that people frequently request, but which ! 607: we do not make because we think GNU CC is better without them. ! 608: ! 609: * Checking the number and type of arguments to a function which has ! 610: an old-fashioned definition and no prototype. ! 611: ! 612: Such a feature would work only occasionally--only for calls that ! 613: appear in the same file as the called function, following the ! 614: definition. The only way to check all calls reliably is to add a ! 615: prototype for the function. But adding a prototype eliminates the ! 616: motivation for this feature. So the feature is not worthwhile. ! 617: ! 618: * Warning about using an expression whose type is signed as a shift ! 619: count. ! 620: ! 621: Shift count operands are probably signed more often than unsigned. ! 622: Warning about this would cause far more annoyance than good. ! 623: ! 624: * Warning about assigning a signed value to an unsigned variable. ! 625: ! 626: Such assignments must be very common; warning about them would ! 627: cause more annoyance than good. ! 628: ! 629: * Warning about unreachable code. ! 630: ! 631: It's very common to have unreachable code in machine-generated ! 632: programs. For example, this happens normally in some files of GNU ! 633: C itself. ! 634: ! 635: * Warning when a non-void function value is ignored. ! 636: ! 637: Coming as I do from a Lisp background, I balk at the idea that ! 638: there is something dangerous about discarding a value. There are ! 639: functions that return values which some callers may find useful; ! 640: it makes no sense to clutter the program with a cast to `void' ! 641: whenever the value isn't useful. ! 642: ! 643: * Assuming (for optimization) that the address of an external symbol ! 644: is never zero. ! 645: ! 646: This assumption is false on certain systems when `#pragma weak' is ! 647: used. ! 648: ! 649: * Making `-fshort-enums' the default. ! 650: ! 651: This would cause storage layout to be incompatible with most other ! 652: C compilers. And it doesn't seem very important, given that you ! 653: can get the same result in other ways. The case where it matters ! 654: most is when the enumeration-valued object is inside a structure, ! 655: and in that case you can specify a field width explicitly. ! 656: ! 657: * Making bitfields unsigned by default on particular machines where ! 658: "the ABI standard" says to do so. ! 659: ! 660: The ANSI C standard leaves it up to the implementation whether a ! 661: bitfield declared plain `int' is signed or not. This in effect ! 662: creates two alternative dialects of C. ! 663: ! 664: The GNU C compiler supports both dialects; you can specify the ! 665: signed dialect with `-fsigned-bitfields' and the unsigned dialect ! 666: with `-funsigned-bitfields'. However, this leaves open the ! 667: question of which dialect to use by default. ! 668: ! 669: Currently, the preferred dialect makes plain bitfields signed, ! 670: because this is simplest. Since `int' is the same as `signed int' ! 671: in every other context, it is cleanest for them to be the same in ! 672: bitfields as well. ! 673: ! 674: Some computer manufacturers have published Application Binary ! 675: Interface standards which specify that plain bitfields should be ! 676: unsigned. It is a mistake, however, to say anything about this ! 677: issue in an ABI. This is because the handling of plain bitfields ! 678: distinguishes two dialects of C. Both dialects are meaningful on ! 679: every type of machine. Whether a particular object file was ! 680: compiled using signed bitfields or unsigned is of no concern to ! 681: other object files, even if they access the same bitfields in the ! 682: same data structures. ! 683: ! 684: A given program is written in one or the other of these two ! 685: dialects. The program stands a chance to work on most any machine ! 686: if it is compiled with the proper dialect. It is unlikely to work ! 687: at all if compiled with the wrong dialect. ! 688: ! 689: Many users appreciate the GNU C compiler because it provides an ! 690: environment that is uniform across machines. These users would be ! 691: inconvenienced if the compiler treated plain bitfields differently ! 692: on certain machines. ! 693: ! 694: Occasionally users write programs intended only for a particular ! 695: machine type. On these occasions, the users would benefit if the ! 696: GNU C compiler were to support by default the same dialect as the ! 697: other compilers on that machine. But such applications are rare. ! 698: And users writing a program to run on more than one type of ! 699: machine cannot possibly benefit from this kind of compatibility. ! 700: ! 701: This is why GNU CC does and will treat plain bitfields in the same ! 702: fashion on all types of machines (by default). ! 703: ! 704: There are some arguments for making bitfields unsigned by default ! 705: on all machines. If, for example, this becomes a universal de ! 706: facto standard, it would make sense for GNU CC to go along with ! 707: it. This is something to be considered in the future. ! 708: ! 709: (Of course, users strongly concerned about portability should ! 710: indicate explicitly in each bitfield whether it is signed or not. ! 711: In this way, they write programs which have the same meaning in ! 712: both C dialects.) ! 713: ! 714: * Undefining `__STDC__' when `-ansi' is not used. ! 715: ! 716: Currently, GNU CC defines `__STDC__' as long as you don't use ! 717: `-traditional'. This provides good results in practice. ! 718: ! 719: Programmers normally use conditionals on `__STDC__' to ask whether ! 720: it is safe to use certain features of ANSI C, such as function ! 721: prototypes or ANSI token concatenation. Since plain `gcc' supports ! 722: all the features of ANSI C, the correct answer to these questions ! 723: is "yes". ! 724: ! 725: Some users try to use `__STDC__' to check for the availability of ! 726: certain library facilities. This is actually incorrect usage in ! 727: an ANSI C program, because the ANSI C standard says that a ! 728: conforming freestanding implementation should define `__STDC__' ! 729: even though it does not have the library facilities. `gcc -ansi ! 730: -pedantic' is a conforming freestanding implementation, and it is ! 731: therefore required to define `__STDC__', even though it does not ! 732: come with an ANSI C library. ! 733: ! 734: Sometimes people say that defining `__STDC__' in a compiler that ! 735: does not completely conform to the ANSI C standard somehow ! 736: violates the standard. This is illogical. The standard is a ! 737: standard for compilers that claim to support ANSI C, such as `gcc ! 738: -ansi'--not for other compilers such as plain `gcc'. Whatever the ! 739: ANSI C standard says is relevant to the design of plain `gcc' ! 740: without `-ansi' only for pragmatic reasons, not as a requirement. ! 741: ! 742: * Undefining `__STDC__' in C++. ! 743: ! 744: Programs written to compile with C++-to-C translators get the ! 745: value of `__STDC__' that goes with the C compiler that is ! 746: subsequently used. These programs must test `__STDC__' to ! 747: determine what kind of C preprocessor that compiler uses: whether ! 748: they should concatenate tokens in the ANSI C fashion or in the ! 749: traditional fashion. ! 750: ! 751: These programs work properly with GNU C++ if `__STDC__' is defined. ! 752: They would not work otherwise. ! 753: ! 754: In addition, many header files are written to provide prototypes ! 755: in ANSI C but not in traditional C. Many of these header files ! 756: can work without change in C++ provided `__STDC__' is defined. If ! 757: `__STDC__' is not defined, they will all fail, and will all need ! 758: to be changed to test explicitly for C++ as well. ! 759: ! 760: * Deleting "empty" loops. ! 761: ! 762: GNU CC does not delete "empty" loops because the most likely reason ! 763: you would put one in a program is to have a delay. Deleting them ! 764: will not make real programs run any faster, so it would be ! 765: pointless. ! 766: ! 767: It would be different if optimization of a nonempty loop could ! 768: produce an empty one. But this generally can't happen. ! 769: ! 770: * Making side effects happen in the same order as in some other ! 771: compiler. ! 772: ! 773: It is never safe to depend on the order of evaluation of side ! 774: effects. For example, a function call like this may very well ! 775: behave differently from one compiler to another: ! 776: ! 777: void func (int, int); ! 778: ! 779: int i = 2; ! 780: func (i++, i++); ! 781: ! 782: There is no guarantee (in either the C or the C++ standard language ! 783: definitions) that the increments will be evaluated in any ! 784: particular order. Either increment might happen first. `func' ! 785: might get the arguments `3, 4', or it might get `4, 3', or even ! 786: `3, 3'. ! 787: ! 788: * Not allowing structures with volatile fields in registers. ! 789: ! 790: Strictly speaking, there is no prohibition in the ANSI C standard ! 791: against allowing structures with volatile fields in registers, but ! 792: it does not seem to make any sense and is probably not what you ! 793: wanted to do. So the compiler will give an error message in this ! 794: case. ! 795: ! 796: ! 797: File: gcc.info, Node: Warnings and Errors, Prev: Non-bugs, Up: Trouble ! 798: ! 799: Warning Messages and Error Messages ! 800: =================================== ! 801: ! 802: The GNU compiler can produce two kinds of diagnostics: errors and ! 803: warnings. Each kind has a different purpose: ! 804: ! 805: *Errors* report problems that make it impossible to compile your ! 806: program. GNU CC reports errors with the source file name and line ! 807: number where the problem is apparent. ! 808: ! 809: *Warnings* report other unusual conditions in your code that *may* ! 810: indicate a problem, although compilation can (and does) proceed. ! 811: Warning messages also report the source file name and line number, ! 812: but include the text `warning:' to distinguish them from error ! 813: messages. ! 814: ! 815: Warnings may indicate danger points where you should check to make ! 816: sure that your program really does what you intend; or the use of ! 817: obsolete features; or the use of nonstandard features of GNU C or C++. ! 818: Many warnings are issued only if you ask for them, with one of the `-W' ! 819: options (for instance, `-Wall' requests a variety of useful warnings). ! 820: ! 821: GNU CC always tries to compile your program if possible; it never ! 822: gratuituously rejects a program whose meaning is clear merely because ! 823: (for instance) it fails to conform to a standard. In some cases, ! 824: however, the C and C++ standards specify that certain extensions are ! 825: forbidden, and a diagnostic *must* be issued by a conforming compiler. ! 826: The `-pedantic' option tells GNU CC to issue warnings in such cases; ! 827: `-pedantic-errors' says to make them errors instead. This does not ! 828: mean that *all* non-ANSI constructs get warnings or errors. ! 829: ! 830: *Note Options to Request or Suppress Warnings: Warning Options, for ! 831: more detail on these and related command-line options. ! 832: ! 833: ! 834: File: gcc.info, Node: Bugs, Next: Service, Prev: Trouble, Up: Top ! 835: ! 836: Reporting Bugs ! 837: ************** ! 838: ! 839: Your bug reports play an essential role in making GNU CC reliable. ! 840: ! 841: When you encounter a problem, the first thing to do is to see if it ! 842: is already known. *Note Trouble::. If it isn't known, then you should ! 843: report the problem. ! 844: ! 845: Reporting a bug may help you by bringing a solution to your problem, ! 846: or it may not. (If it does not, look in the service directory; see ! 847: *Note Service::.) In any case, the principal function of a bug report ! 848: is to help the entire community by making the next version of GNU CC ! 849: work better. Bug reports are your contribution to the maintenance of ! 850: GNU CC. ! 851: ! 852: Since the maintainers are very overloaded, we cannot respond to every ! 853: bug report. However, if the bug has not been fixed, we are likely to ! 854: send you a patch and ask you to tell us whether it works. ! 855: ! 856: In order for a bug report to serve its purpose, you must include the ! 857: information that makes for fixing the bug. ! 858: ! 859: * Menu: ! 860: ! 861: * Criteria: Bug Criteria. Have you really found a bug? ! 862: * Where: Bug Lists. Where to send your bug report. ! 863: * Reporting: Bug Reporting. How to report a bug effectively. ! 864: * Patches: Sending Patches. How to send a patch for GNU CC. ! 865: * Known: Trouble. Known problems. ! 866: * Help: Service. Where to ask for help. ! 867: ! 868: ! 869: File: gcc.info, Node: Bug Criteria, Next: Bug Lists, Up: Bugs ! 870: ! 871: Have You Found a Bug? ! 872: ===================== ! 873: ! 874: If you are not sure whether you have found a bug, here are some ! 875: guidelines: ! 876: ! 877: * If the compiler gets a fatal signal, for any input whatever, that ! 878: is a compiler bug. Reliable compilers never crash. ! 879: ! 880: * If the compiler produces invalid assembly code, for any input ! 881: whatever (except an `asm' statement), that is a compiler bug, ! 882: unless the compiler reports errors (not just warnings) which would ! 883: ordinarily prevent the assembler from being run. ! 884: ! 885: * If the compiler produces valid assembly code that does not ! 886: correctly execute the input source code, that is a compiler bug. ! 887: ! 888: However, you must double-check to make sure, because you may have ! 889: run into an incompatibility between GNU C and traditional C (*note ! 890: Incompatibilities::.). These incompatibilities might be considered ! 891: bugs, but they are inescapable consequences of valuable features. ! 892: ! 893: Or you may have a program whose behavior is undefined, which ! 894: happened by chance to give the desired results with another C or ! 895: C++ compiler. ! 896: ! 897: For example, in many nonoptimizing compilers, you can write `x;' ! 898: at the end of a function instead of `return x;', with the same ! 899: results. But the value of the function is undefined if `return' ! 900: is omitted; it is not a bug when GNU CC produces different results. ! 901: ! 902: Problems often result from expressions with two increment ! 903: operators, as in `f (*p++, *p++)'. Your previous compiler might ! 904: have interpreted that expression the way you intended; GNU CC might ! 905: interpret it another way. Neither compiler is wrong. The bug is ! 906: in your code. ! 907: ! 908: After you have localized the error to a single source line, it ! 909: should be easy to check for these things. If your program is ! 910: correct and well defined, you have found a compiler bug. ! 911: ! 912: * If the compiler produces an error message for valid input, that is ! 913: a compiler bug. ! 914: ! 915: * If the compiler does not produce an error message for invalid ! 916: input, that is a compiler bug. However, you should note that your ! 917: idea of "invalid input" might be my idea of "an extension" or ! 918: "support for traditional practice". ! 919: ! 920: * If you are an experienced user of C or C++ compilers, your ! 921: suggestions for improvement of GNU CC or GNU C++ are welcome in ! 922: any case. ! 923: ! 924: ! 925: File: gcc.info, Node: Bug Lists, Next: Bug Reporting, Prev: Bug Criteria, Up: Bugs ! 926: ! 927: Where to Report Bugs ! 928: ==================== ! 929: ! 930: Send bug reports for GNU C to `[email protected]'. 1.1.1.5 root 931: 1.1.1.7 ! root 932: Send bug reports for GNU C++ to `[email protected]'. If your ! 933: bug involves the C++ class library libg++, send mail to ! 934: `[email protected]'. If you're not sure, you can send the ! 935: bug report to both lists. ! 936: ! 937: *Do not send bug reports to `[email protected]' or to the ! 938: newsgroup `gnu.gcc.help'.* Most users of GNU CC do not want to receive ! 939: bug reports. Those that do, have asked to be on `bug-gcc' and/or ! 940: `bug-g++'. ! 941: ! 942: The mailing lists `bug-gcc' and `bug-g++' both have newsgroups which ! 943: serve as repeaters: `gnu.gcc.bug' and `gnu.g++.bug'. Each mailing list ! 944: and its newsgroup carry exactly the same messages. ! 945: ! 946: Often people think of posting bug reports to the newsgroup instead of ! 947: mailing them. This appears to work, but it has one problem which can be ! 948: crucial: a newsgroup posting does not contain a mail path back to the ! 949: sender. Thus, if maintainers need more information, they may be unable ! 950: to reach you. For this reason, you should always send bug reports by ! 951: mail to the proper mailing list. ! 952: ! 953: As a last resort, send bug reports on paper to: ! 954: ! 955: GNU Compiler Bugs ! 956: Free Software Foundation ! 957: 675 Mass Ave ! 958: Cambridge, MA 02139 1.1.1.2 root 959:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.