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