![[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.5 ! root 31: File: gcc.info, Node: Temporaries, Prev: Static Definitions, Up: C++ Misunderstandings 1.1.1.3 root 32: 1.1.1.5 ! root 33: Temporaries May Vanish Before You Expect ! 34: ---------------------------------------- ! 35: ! 36: It is dangerous to use pointers or references to *portions* of a ! 37: temporary object. The compiler may very well delete the object before ! 38: you expect it to, leaving a pointer to garbage. The most common place ! 39: where this problem crops up is in classes like the libg++ `String' ! 40: class, that define a conversion function to type `char *' or `const ! 41: char *'. However, any class that returns a pointer to some internal ! 42: structure is potentially subject to this problem. ! 43: ! 44: For example, a program may use a function `strfunc' that returns ! 45: `String' objects, and another function `charfunc' that operates on ! 46: pointers to `char': ! 47: ! 48: String strfunc (); ! 49: void charfunc (const char *); ! 50: ! 51: In this situation, it may seem natural to write ! 52: `charfunc (strfunc ());' based on the knowledge that class `String' has ! 53: an explicit conversion to `char' pointers. However, what really ! 54: happens is akin to `charfunc (strfunc ().convert ());', where the ! 55: `convert' method is a function to do the same data conversion normally ! 56: performed by a cast. Since the last use of the temporary `String' ! 57: object is the call to the conversion function, the compiler may delete ! 58: that object before actually calling `charfunc'. The compiler has no ! 59: way of knowing that deleting the `String' object will invalidate the ! 60: pointer. The pointer then points to garbage, so that by the time ! 61: `charfunc' is called, it gets an invalid argument. ! 62: ! 63: Code like this may run successfully under some other compilers, ! 64: especially those that delete temporaries relatively late. However, the ! 65: GNU C++ behavior is also standard-conformant, so if your program depends ! 66: on late destruction of temporaries it is not portable. ! 67: ! 68: If you think this is surprising, you should be aware that the ANSI ! 69: C++ committee continues to debate the lifetime-of-temporaries problem. ! 70: ! 71: For now, at least, the safe way to write such code is to give the ! 72: temporary a name, which forces it to remain until the end of the scope ! 73: of the name. For example: 1.1.1.3 root 74: 1.1.1.5 ! root 75: String& tmp = strfunc (); ! 76: charfunc (tmp); 1.1.1.3 root 77: 78: 1.1.1.5 ! root 79: File: gcc.info, Node: Protoize Caveats, Next: Non-bugs, Prev: C++ Misunderstandings, Up: Trouble 1.1.1.3 root 80: 1.1.1.5 ! root 81: Caveats of using `protoize' ! 82: =========================== ! 83: ! 84: The conversion programs `protoize' and `unprotoize' can sometimes ! 85: change a source file in a way that won't work unless you rearrange it. ! 86: ! 87: * `protoize' can insert references to a type name or type tag before ! 88: the definition, or in a file where they are not defined. ! 89: ! 90: If this happens, compiler error messages should show you where the ! 91: new references are, so fixing the file by hand is straightforward. ! 92: ! 93: * There are some C constructs which `protoize' cannot figure out. ! 94: For example, it can't determine argument types for declaring a ! 95: pointer-to-function variable; this you must do by hand. `protoize' ! 96: inserts a comment containing `???' each time it finds such a ! 97: variable; so you can find all such variables by searching for this ! 98: string. ANSI C does not require declaring the argument types of ! 99: pointer-to-function types. ! 100: ! 101: * Using `unprotoize' can easily introduce bugs. If the program ! 102: relied on prototypes to bring about conversion of arguments, these ! 103: conversions will not take place in the program without prototypes. ! 104: One case in which you can be sure `unprotoize' is safe is when you ! 105: are removing prototypes that were made with `protoize'; if the ! 106: program worked before without any prototypes, it will work again ! 107: without them. ! 108: ! 109: You can find all the places where this problem might occur by ! 110: compiling the program with the `-Wconversion' option. It prints a ! 111: warning whenever an argument is converted. ! 112: ! 113: * Both conversion programs can be confused if there are macro calls ! 114: in and around the text to be converted. In other words, the ! 115: standard syntax for a declaration or definition must not result ! 116: from expanding a macro. This problem is inherent in the design of ! 117: C and cannot be fixed. If only a few functions have confusing ! 118: macro calls, you can easily convert them manually. ! 119: ! 120: * `protoize' cannot get the argument types for a function whose ! 121: definition was not actually compiled due to preprocessor ! 122: conditionals. When this happens, `protoize' changes nothing in ! 123: regard to such a function. `protoize' tries to detect such ! 124: instances and warn about them. ! 125: ! 126: You can generally work around this problem by using `protoize' step ! 127: by step, each time specifying a different set of `-D' options for ! 128: compilation, until all of the functions have been converted. ! 129: There is no automatic way to verify that you have got them all, ! 130: however. ! 131: ! 132: * Confusion may result if there is an occasion to convert a function ! 133: declaration or definition in a region of source code where there ! 134: is more than one formal parameter list present. Thus, attempts to ! 135: convert code containing multiple (conditionally compiled) versions ! 136: of a single function header (in the same vicinity) may not produce ! 137: the desired (or expected) results. ! 138: ! 139: If you plan on converting source files which contain such code, it ! 140: is recommended that you first make sure that each conditionally ! 141: compiled region of source code which contains an alternative ! 142: function header also contains at least one additional follower ! 143: token (past the final right parenthesis of the function header). ! 144: This should circumvent the problem. ! 145: ! 146: * `unprotoize' can become confused when trying to convert a function ! 147: definition or declaration which contains a declaration for a ! 148: pointer-to-function formal argument which has the same name as the ! 149: function being defined or declared. We recommand you avoid such ! 150: choices of formal parameter names. ! 151: ! 152: * You might also want to correct some of the indentation by hand and ! 153: break long lines. (The conversion programs don't write lines ! 154: longer than eighty characters in any case.) ! 155: ! 156: ! 157: File: gcc.info, Node: Non-bugs, Next: Warnings and Errors, Prev: Protoize Caveats, Up: Trouble ! 158: ! 159: Certain Changes We Don't Want to Make ! 160: ===================================== ! 161: ! 162: This section lists changes that people frequently request, but which ! 163: we do not make because we think GNU CC is better without them. 1.1.1.3 root 164: 1.1.1.5 ! root 165: * Checking the number and type of arguments to a function which has ! 166: an old-fashioned definition and no prototype. ! 167: ! 168: Such a feature would work only occasionally--only for calls that ! 169: appear in the same file as the called function, following the ! 170: definition. The only way to check all calls reliably is to add a ! 171: prototype for the function. But adding a prototype eliminates the ! 172: motivation for this feature. So the feature is not worthwhile. ! 173: ! 174: * Warning about using an expression whose type is signed as a shift ! 175: count. ! 176: ! 177: Shift count operands are probably signed more often than unsigned. ! 178: Warning about this would cause far more annoyance than good. ! 179: ! 180: * Warning about assigning a signed value to an unsigned variable. ! 181: ! 182: Such assignments must be very common; warning about them would ! 183: cause more annoyance than good. ! 184: ! 185: * Warning about unreachable code. ! 186: ! 187: It's very common to have unreachable code in machine-generated ! 188: programs. For example, this happens normally in some files of GNU ! 189: C itself. ! 190: ! 191: * Warning when a non-void function value is ignored. ! 192: ! 193: Coming as I do from a Lisp background, I balk at the idea that ! 194: there is something dangerous about discarding a value. There are ! 195: functions that return values which some callers may find useful; ! 196: it makes no sense to clutter the program with a cast to `void' ! 197: whenever the value isn't useful. ! 198: ! 199: * Assuming (for optimization) that the address of an external symbol ! 200: is never zero. ! 201: ! 202: This assumption is false on certain systems when `#pragma weak' is ! 203: used. ! 204: ! 205: * Making `-fshort-enums' the default. ! 206: ! 207: This would cause storage layout to be incompatible with most other ! 208: C compilers. And it doesn't seem very important, given that you ! 209: can get the same result in other ways. The case where it matters ! 210: most is when the enumeration-valued object is inside a structure, ! 211: and in that case you can specify a field width explicitly. ! 212: ! 213: * Making bitfields unsigned by default on particular machines where ! 214: "the ABI standard" says to do so. ! 215: ! 216: The ANSI C standard leaves it up to the implementation whether a ! 217: bitfield declared plain `int' is signed or not. This in effect ! 218: creates two alternative dialects of C. ! 219: ! 220: The GNU C compiler supports both dialects; you can specify the ! 221: signed dialect with `-fsigned-bitfields' and the unsigned dialect ! 222: with `-funsigned-bitfields'. However, this leaves open the ! 223: question of which dialect to use by default. ! 224: ! 225: Currently, the preferred dialect makes plain bitfields signed, ! 226: because this is simplest. Since `int' is the same as `signed int' ! 227: in every other context, it is cleanest for them to be the same in ! 228: bitfields as well. ! 229: ! 230: Some computer manufacturers have published Application Binary ! 231: Interface standards which specify that plain bitfields should be ! 232: unsigned. It is a mistake, however, to say anything about this ! 233: issue in an ABI. This is because the handling of plain bitfields ! 234: distinguishes two dialects of C. Both dialects are meaningful on ! 235: every type of machine. Whether a particular object file was ! 236: compiled using signed bitfields or unsigned is of no concern to ! 237: other object files, even if they access the same bitfields in the ! 238: same data structures. ! 239: ! 240: A given program is written in one or the other of these two ! 241: dialects. The program stands a chance to work on most any machine ! 242: if it is compiled with the proper dialect. It is unlikely to work ! 243: at all if compiled with the wrong dialect. ! 244: ! 245: Many users appreciate the GNU C compiler because it provides an ! 246: environment that is uniform across machines. These users would be ! 247: inconvenienced if the compiler treated plain bitfields differently ! 248: on certain machines. ! 249: ! 250: Occasionally users write programs intended only for a particular ! 251: machine type. On these occasions, the users would benefit if the ! 252: GNU C compiler were to support by default the same dialect as the ! 253: other compilers on that machine. But such applications are rare. ! 254: And users writing a program to run on more than one type of ! 255: machine cannot possibly benefit from this kind of compatibility. ! 256: ! 257: This is why GNU CC does and will treat plain bitfields in the same ! 258: fashion on all types of machines (by default). ! 259: ! 260: There are some arguments for making bitfields unsigned by default ! 261: on all machines. If, for example, this becomes a universal de ! 262: facto standard, it would make sense for GNU CC to go along with ! 263: it. This is something to be considered in the future. ! 264: ! 265: (Of course, users strongly concerned about portability should ! 266: indicate explicitly in each bitfield whether it is signed or not. ! 267: In this way, they write programs which have the same meaning in ! 268: both C dialects.) ! 269: ! 270: * Undefining `__STDC__' when `-ansi' is not used. ! 271: ! 272: Currently, GNU CC defines `__STDC__' as long as you don't use ! 273: `-traditional'. This provides good results in practice. ! 274: ! 275: Programmers normally use conditionals on `__STDC__' to ask whether ! 276: it is safe to use certain features of ANSI C, such as function ! 277: prototypes or ANSI token concatenation. Since plain `gcc' supports ! 278: all the features of ANSI C, the correct answer to these questions ! 279: is "yes". ! 280: ! 281: Some users try to use `__STDC__' to check for the availability of ! 282: certain library facilities. This is actually incorrect usage in ! 283: an ANSI C program, because the ANSI C standard says that a ! 284: conforming freestanding implementation should define `__STDC__' ! 285: even though it does not have the library facilities. `gcc -ansi ! 286: -pedantic' is a conforming freestanding implementation, and it is ! 287: therefore required to define `__STDC__', even though it does not ! 288: come with an ANSI C library. ! 289: ! 290: Sometimes people say that defining `__STDC__' in a compiler that ! 291: does not completely conform to the ANSI C standard somehow ! 292: violates the standard. This is illogical. The standard is a ! 293: standard for compilers that claim to support ANSI C, such as `gcc ! 294: -ansi'--not for other compilers such as plain `gcc'. Whatever the ! 295: ANSI C standard says is relevant to the design of plain `gcc' ! 296: without `-ansi' only for pragmatic reasons, not as a requirement. ! 297: ! 298: * Undefining `__STDC__' in C++. ! 299: ! 300: Programs written to compile with C++-to-C translators get the ! 301: value of `__STDC__' that goes with the C compiler that is ! 302: subsequently used. These programs must test `__STDC__' to ! 303: determine what kind of C preprocessor that compiler uses: whether ! 304: they should concatenate tokens in the ANSI C fashion or in the ! 305: traditional fashion. ! 306: ! 307: These programs work properly with GNU C++ if `__STDC__' is defined. ! 308: They would not work otherwise. ! 309: ! 310: In addition, many header files are written to provide prototypes ! 311: in ANSI C but not in traditional C. Many of these header files ! 312: can work without change in C++ provided `__STDC__' is defined. If ! 313: `__STDC__' is not defined, they will all fail, and will all need ! 314: to be changed to test explicitly for C++ as well. ! 315: ! 316: * Deleting "empty" loops. ! 317: ! 318: GNU CC does not delete "empty" loops because the most likely reason ! 319: you would put one in a program is to have a delay. Deleting them ! 320: will not make real programs run any faster, so it would be ! 321: pointless. ! 322: ! 323: It would be different if optimization of a nonempty loop could ! 324: produce an empty one. But this generally can't happen. ! 325: ! 326: * Making side effects happen in the same order as in some other ! 327: compiler. ! 328: ! 329: It is never safe to depend on the order of evaluation of side ! 330: effects. For example, a function call like this may very well ! 331: behave differently from one compiler to another: ! 332: ! 333: void func (int, int); ! 334: ! 335: int i = 2; ! 336: func (i++, i++); ! 337: ! 338: There is no guarantee (in either the C or the C++ standard language ! 339: definitions) that the increments will be evaluated in any ! 340: particular order. Either increment might happen first. `func' ! 341: might get the arguments `3, 4', or it might get `4, 3', or even ! 342: `3, 3'. ! 343: ! 344: * Using the "canonical" form of the target configuration name as the ! 345: directory for installation. ! 346: ! 347: This would be an improvement in some respects, but it would also ! 348: cause problems. For one thing, users might expect to use in the ! 349: `-b' option the same name specified at installation; if ! 350: installation used the canonical form, that would not work. What's ! 351: more, the canonical name might be too long for certain file ! 352: systems. ! 353: ! 354: We suggest you make a link to the installation directory under the ! 355: canonical name, if you want to use that name in the `-b' option. ! 356: ! 357: ! 358: File: gcc.info, Node: Warnings and Errors, Prev: Non-bugs, Up: Trouble ! 359: ! 360: Warning Messages and Error Messages ! 361: =================================== ! 362: ! 363: The GNU compiler can produce two kinds of diagnostics: errors and ! 364: warnings. Each kind has a different purpose: ! 365: ! 366: *Errors* report problems that make it impossible to compile your ! 367: program. GNU CC reports errors with the source file name and line ! 368: number where the problem is apparent. ! 369: ! 370: *Warnings* report other unusual conditions in your code that *may* ! 371: indicate a problem, although compilation can (and does) proceed. ! 372: Warning messages also report the source file name and line number, ! 373: but include the text `warning:' to distinguish them from error ! 374: messages. ! 375: ! 376: Warnings may indicate danger points where you should check to make ! 377: sure that your program really does what you intend; or the use of ! 378: obsolete features; or the use of nonstandard features of GNU C or C++. ! 379: Many warnings are issued only if you ask for them, with one of the `-W' ! 380: options (for instance, `-Wall' requests a variety of useful warnings). ! 381: ! 382: GNU CC always tries to compile your program if possible; it never ! 383: gratuituously rejects a program whose meaning is clear merely because ! 384: (for instance) it fails to conform to a standard. In some cases, ! 385: however, the C and C++ standards specify that certain extensions are ! 386: forbidden, and a diagnostic *must* be issued by a conforming compiler. ! 387: The `-pedantic' option tells GNU CC to issue warnings in such cases; ! 388: `-pedantic-errors' says to make them errors instead. This does not ! 389: mean that *all* non-ANSI constructs get warnings or errors. ! 390: ! 391: *Note Options to Request or Suppress Warnings: Warning Options, for ! 392: more detail on these and related command-line options. 1.1.1.3 root 393: 394: 1.1.1.5 ! root 395: File: gcc.info, Node: Bugs, Next: Service, Prev: Trouble, Up: Top ! 396: ! 397: Reporting Bugs ! 398: ************** 1.1.1.3 root 399: 1.1.1.5 ! root 400: Your bug reports play an essential role in making GNU CC reliable. 1.1.1.3 root 401: 1.1.1.5 ! root 402: When you encounter a problem, the first thing to do is to see if it ! 403: is already known. *Note Trouble::. If it isn't known, then you should ! 404: report the problem. ! 405: ! 406: Reporting a bug may help you by bringing a solution to your problem, ! 407: or it may not. (If it does not, look in the service directory; see ! 408: *Note Service::.) In any case, the principal function of a bug report ! 409: is to help the entire community by making the next version of GNU CC ! 410: work better. Bug reports are your contribution to the maintenance of ! 411: GNU CC. ! 412: ! 413: In order for a bug report to serve its purpose, you must include the ! 414: information that makes for fixing the bug. ! 415: ! 416: * Menu: ! 417: ! 418: * Criteria: Bug Criteria. Have you really found a bug? ! 419: * Where: Bug Lists. Where to send your bug report. ! 420: * Reporting: Bug Reporting. How to report a bug effectively. ! 421: * Patches: Sending Patches. How to send a patch for GNU CC. ! 422: * Known: Trouble. Known problems. ! 423: * Help: Service. Where to ask for help. 1.1 root 424: 425: 1.1.1.5 ! root 426: File: gcc.info, Node: Bug Criteria, Next: Bug Lists, Up: Bugs 1.1.1.2 root 427: 1.1.1.5 ! root 428: Have You Found a Bug? ! 429: ===================== 1.1.1.2 root 430: 1.1.1.5 ! root 431: If you are not sure whether you have found a bug, here are some ! 432: guidelines: 1.1.1.2 root 433: 1.1.1.5 ! root 434: * If the compiler gets a fatal signal, for any input whatever, that ! 435: is a compiler bug. Reliable compilers never crash. 1.1.1.2 root 436: 1.1.1.5 ! root 437: * If the compiler produces invalid assembly code, for any input ! 438: whatever (except an `asm' statement), that is a compiler bug, ! 439: unless the compiler reports errors (not just warnings) which would ! 440: ordinarily prevent the assembler from being run. ! 441: ! 442: * If the compiler produces valid assembly code that does not ! 443: correctly execute the input source code, that is a compiler bug. ! 444: ! 445: However, you must double-check to make sure, because you may have ! 446: run into an incompatibility between GNU C and traditional C (*note ! 447: Incompatibilities::.). These incompatibilities might be considered ! 448: bugs, but they are inescapable consequences of valuable features. ! 449: ! 450: Or you may have a program whose behavior is undefined, which ! 451: happened by chance to give the desired results with another C or ! 452: C++ compiler. ! 453: ! 454: For example, in many nonoptimizing compilers, you can write `x;' ! 455: at the end of a function instead of `return x;', with the same ! 456: results. But the value of the function is undefined if `return' ! 457: is omitted; it is not a bug when GNU CC produces different results. ! 458: ! 459: Problems often result from expressions with two increment ! 460: operators, as in `f (*p++, *p++)'. Your previous compiler might ! 461: have interpreted that expression the way you intended; GNU CC might ! 462: interpret it another way. Neither compiler is wrong. The bug is ! 463: in your code. ! 464: ! 465: After you have localized the error to a single source line, it ! 466: should be easy to check for these things. If your program is ! 467: correct and well defined, you have found a compiler bug. ! 468: ! 469: * If the compiler produces an error message for valid input, that is ! 470: a compiler bug. ! 471: ! 472: * If the compiler does not produce an error message for invalid ! 473: input, that is a compiler bug. However, you should note that your ! 474: idea of "invalid input" might be my idea of "an extension" or ! 475: "support for traditional practice". ! 476: ! 477: * If you are an experienced user of C or C++ compilers, your ! 478: suggestions for improvement of GNU CC or GNU C++ are welcome in ! 479: any case. 1.1.1.2 root 480: 481: 1.1.1.5 ! root 482: File: gcc.info, Node: Bug Lists, Next: Bug Reporting, Prev: Bug Criteria, Up: Bugs 1.1.1.2 root 483: 1.1.1.5 ! root 484: Where to Report Bugs 1.1.1.4 root 485: ==================== 1.1.1.2 root 486: 1.1.1.5 ! root 487: Send bug reports for GNU C to one of these addresses: ! 488: ! 489: [email protected] ! 490: {ucbvax|mit-eddie|uunet}!prep.ai.mit.edu!bug-gcc 1.1.1.2 root 491: 1.1.1.5 ! root 492: Send bug reports for GNU C++ to one of these addresses: ! 493: ! 494: [email protected] ! 495: {ucbvax|mit-eddie|uunet}!prep.ai.mit.edu!bug-g++ ! 496: ! 497: If your bug involves the C++ class library libg++, send mail to ! 498: `[email protected]'. If you're not sure, you can send the ! 499: bug report to both lists. ! 500: ! 501: *Do not send bug reports to the mailing list `help-gcc', or to the ! 502: newsgroup `gnu.gcc.help'.* Most users of GNU CC do not want to receive ! 503: bug reports. Those that do, have asked to be on `bug-gcc' and/or ! 504: `bug-g++'. ! 505: ! 506: The mailing lists `bug-gcc' and `bug-g++' both have newsgroups which ! 507: serve as repeaters: `gnu.gcc.bug' and `gnu.g++.bug'. Each mailing list ! 508: and its newsgroup carry exactly the same messages. ! 509: ! 510: Often people think of posting bug reports to the newsgroup instead of ! 511: mailing them. This appears to work, but it has one problem which can be ! 512: crucial: a newsgroup posting does not contain a mail path back to the ! 513: sender. Thus, if maintainers need more information, they may be unable ! 514: to reach you. For this reason, you should always send bug reports by ! 515: mail to the proper mailing list. ! 516: ! 517: As a last resort, send bug reports on paper to: ! 518: ! 519: GNU Compiler Bugs ! 520: Free Software Foundation ! 521: 675 Mass Ave ! 522: Cambridge, MA 02139 1.1.1.2 root 523: 1.1.1.4 root 524: 1.1.1.5 ! root 525: File: gcc.info, Node: Bug Reporting, Next: Sending Patches, Prev: Bug Lists, Up: Bugs 1.1.1.2 root 526: 1.1.1.5 ! root 527: How to Report Bugs ! 528: ================== 1.1.1.2 root 529: 1.1.1.5 ! root 530: The fundamental principle of reporting bugs usefully is this: ! 531: *report all the facts*. If you are not sure whether to state a fact or ! 532: leave it out, state it! ! 533: ! 534: Often people omit facts because they think they know what causes the ! 535: problem and they conclude that some details don't matter. Thus, you ! 536: might assume that the name of the variable you use in an example does ! 537: not matter. Well, probably it doesn't, but one cannot be sure. ! 538: Perhaps the bug is a stray memory reference which happens to fetch from ! 539: the location where that name is stored in memory; perhaps, if the name ! 540: were different, the contents of that location would fool the compiler ! 541: into doing the right thing despite the bug. Play it safe and give a ! 542: specific, complete example. That is the easiest thing for you to do, ! 543: and the most helpful. ! 544: ! 545: Keep in mind that the purpose of a bug report is to enable someone to ! 546: fix the bug if it is not known. It isn't very important what happens if ! 547: the bug is already known. Therefore, always write your bug reports on ! 548: the assumption that the bug is not known. ! 549: ! 550: Sometimes people give a few sketchy facts and ask, "Does this ring a ! 551: bell?" This cannot help us fix a bug, so it is basically useless. We ! 552: respond by asking for enough details to enable us to investigate. You ! 553: might as well expedite matters by sending them to begin with. ! 554: ! 555: Try to make your bug report self-contained. If we have to ask you ! 556: for more information, it is best if you include all the previous ! 557: information in your response, as well as the information that was ! 558: missing. ! 559: ! 560: To enable someone to investigate the bug, you should include all ! 561: these things: ! 562: ! 563: * The version of GNU CC. You can get this by running it with the ! 564: `-v' option. ! 565: ! 566: Without this, we won't know whether there is any point in looking ! 567: for the bug in the current version of GNU CC. ! 568: ! 569: * A complete input file that will reproduce the bug. If the bug is ! 570: in the C preprocessor, send a source file and any header files ! 571: that it requires. If the bug is in the compiler proper (`cc1'), ! 572: run your source file through the C preprocessor by doing `gcc -E ! 573: SOURCEFILE > OUTFILE', then include the contents of OUTFILE in the ! 574: bug report. (When you do this, use the same `-I', `-D' or `-U' ! 575: options that you used in actual compilation.) ! 576: ! 577: A single statement is not enough of an example. In order to ! 578: compile it, it must be embedded in a complete file of compiler ! 579: input; and the bug might depend on the details of how this is done. ! 580: ! 581: Without a real example one can compile, all anyone can do about ! 582: your bug report is wish you luck. It would be futile to try to ! 583: guess how to provoke the bug. For example, bugs in register ! 584: allocation and reloading frequently depend on every little detail ! 585: of the function they happen in. ! 586: ! 587: Even if the input file that fails comes from a GNU program, you ! 588: should still send the complete test case. Don't ask the GNU CC ! 589: maintainers to do the extra work of obtaining the program in ! 590: question--they are all overworked as it is. Also, the problem may ! 591: depend on what is in the header files on your system; it is ! 592: unreliable for the GNU CC maintainers to try the problem with the ! 593: header files available to them. By sending CPP output, you can ! 594: eliminate this source of uncertainty and save us a certain ! 595: percentage of wild goose chases. ! 596: ! 597: * The command arguments you gave GNU CC or GNU C++ to compile that ! 598: example and observe the bug. For example, did you use `-O'? To ! 599: guarantee you won't omit something important, list all the options. ! 600: ! 601: If we were to try to guess the arguments, we would probably guess ! 602: wrong and then we would not encounter the bug. ! 603: ! 604: * The type of machine you are using, and the operating system name ! 605: and version number. ! 606: ! 607: * The operands you gave to the `configure' command when you installed ! 608: the compiler. ! 609: ! 610: * A complete list of any modifications you have made to the compiler ! 611: source. (We don't promise to investigate the bug unless it ! 612: happens in an unmodified compiler. But if you've made ! 613: modifications and don't tell us, then you are sending us on a wild ! 614: goose chase.) ! 615: ! 616: Be precise about these changes. A description in English is not ! 617: enough--send a context diff for them. ! 618: ! 619: Adding files of your own (such as a machine description for a ! 620: machine we don't support) is a modification of the compiler source. ! 621: ! 622: * Details of any other deviations from the standard procedure for ! 623: installing GNU CC. ! 624: ! 625: * A description of what behavior you observe that you believe is ! 626: incorrect. For example, "The compiler gets a fatal signal," or, ! 627: "The assembler instruction at line 208 in the output is incorrect." ! 628: ! 629: Of course, if the bug is that the compiler gets a fatal signal, ! 630: then one can't miss it. But if the bug is incorrect output, the ! 631: maintainer might not notice unless it is glaringly wrong. None of ! 632: us has time to study all the assembler code from a 50-line C ! 633: program just on the chance that one instruction might be wrong. ! 634: We need *you* to do this part! ! 635: ! 636: Even if the problem you experience is a fatal signal, you should ! 637: still say so explicitly. Suppose something strange is going on, ! 638: such as, your copy of the compiler is out of synch, or you have ! 639: encountered a bug in the C library on your system. (This has ! 640: happened!) Your copy might crash and the copy here would not. If ! 641: you said to expect a crash, then when the compiler here fails to ! 642: crash, we would know that the bug was not happening. If you don't ! 643: say to expect a crash, then we would not know whether the bug was ! 644: happening. We would not be able to draw any conclusion from our ! 645: observations. ! 646: ! 647: If the problem is a diagnostic when compiling GNU CC with some ! 648: other compiler, say whether it is a warning or an error. ! 649: ! 650: Often the observed symptom is incorrect output when your program ! 651: is run. Sad to say, this is not enough information unless the ! 652: program is short and simple. None of us has time to study a large ! 653: program to figure out how it would work if compiled correctly, ! 654: much less which line of it was compiled wrong. So you will have ! 655: to do that. Tell us which source line it is, and what incorrect ! 656: result happens when that line is executed. A person who ! 657: understands the program can find this as easily as finding a bug ! 658: in the program itself. ! 659: ! 660: * If you send examples of assembler code output from GNU CC or GNU ! 661: C++, please use `-g' when you make them. The debugging information ! 662: includes source line numbers which are essential for correlating ! 663: the output with the input. ! 664: ! 665: * If you wish to mention something in the GNU CC source, refer to it ! 666: by context, not by line number. ! 667: ! 668: The line numbers in the development sources don't match those in ! 669: your sources. Your line numbers would convey no useful ! 670: information to the maintainers. ! 671: ! 672: * Additional information from a debugger might enable someone to ! 673: find a problem on a machine which he does not have available. ! 674: However, you need to think when you collect this information if ! 675: you want it to have any chance of being useful. ! 676: ! 677: For example, many people send just a backtrace, but that is never ! 678: useful by itself. A simple backtrace with arguments conveys little ! 679: about GNU CC because the compiler is largely data-driven; the same ! 680: functions are called over and over for different RTL insns, doing ! 681: different things depending on the details of the insn. ! 682: ! 683: Most of the arguments listed in the backtrace are useless because ! 684: they are pointers to RTL list structure. The numeric values of the ! 685: pointers, which the debugger prints in the backtrace, have no ! 686: significance whatever; all that matters is the contents of the ! 687: objects they point to (and most of the contents are other such ! 688: pointers). ! 689: ! 690: In addition, most compiler passes consist of one or more loops that ! 691: scan the RTL insn sequence. The most vital piece of information ! 692: about such a loop--which insn it has reached--is usually in a ! 693: local variable, not in an argument. ! 694: ! 695: What you need to provide in addition to a backtrace are the values ! 696: of the local variables for several stack frames up. When a local ! 697: variable or an argument is an RTX, first print its value and then ! 698: use the GDB command `pr' to print the RTL expression that it points ! 699: to. (If GDB doesn't run on your machine, use your debugger to call ! 700: the function `debug_rtx' with the RTX as an argument.) In ! 701: general, whenever a variable is a pointer, its value is no use ! 702: without the data it points to. ! 703: ! 704: Here are some things that are not necessary: ! 705: ! 706: * A description of the envelope of the bug. ! 707: ! 708: Often people who encounter a bug spend a lot of time investigating ! 709: which changes to the input file will make the bug go away and which ! 710: changes will not affect it. ! 711: ! 712: This is often time consuming and not very useful, because the way ! 713: we will find the bug is by running a single example under the ! 714: debugger with breakpoints, not by pure deduction from a series of ! 715: examples. You might as well save your time for something else. ! 716: ! 717: Of course, if you can find a simpler example to report *instead* of ! 718: the original one, that is a convenience. Errors in the output ! 719: will be easier to spot, running under the debugger will take less ! 720: time, etc. Most GNU CC bugs involve just one function, so the ! 721: most straightforward way to simplify an example is to delete all ! 722: the function definitions except the one where the bug occurs. ! 723: Those earlier in the file may be replaced by external declarations ! 724: if the crucial function depends on them. (Exception: inline ! 725: functions may affect compilation of functions defined later in the ! 726: file.) ! 727: ! 728: However, simplification is not vital; if you don't want to do this, ! 729: report the bug anyway and send the entire test case you used. ! 730: ! 731: * In particular, some people insert conditionals `#ifdef BUG' around ! 732: a statement which, if removed, makes the bug not happen. These ! 733: are just clutter; we won't pay any attention to them anyway. ! 734: Besides, you should send us cpp output, and that can't have ! 735: conditionals. ! 736: ! 737: * A patch for the bug. ! 738: ! 739: A patch for the bug is useful if it is a good one. But don't omit ! 740: the necessary information, such as the test case, on the ! 741: assumption that a patch is all we need. We might see problems ! 742: with your patch and decide to fix the problem another way, or we ! 743: might not understand it at all. ! 744: ! 745: Sometimes with a program as complicated as GNU CC it is very hard ! 746: to construct an example that will make the program follow a ! 747: certain path through the code. If you don't send the example, we ! 748: won't be able to construct one, so we won't be able to verify that ! 749: the bug is fixed. ! 750: ! 751: And if we can't understand what bug you are trying to fix, or why ! 752: your patch should be an improvement, we won't install it. A test ! 753: case will help us to understand. ! 754: ! 755: *Note Sending Patches::, for guidelines on how to make it easy for ! 756: us to understand and install your patches. ! 757: ! 758: * A guess about what the bug is or what it depends on. ! 759: ! 760: Such guesses are usually wrong. Even I can't guess right about ! 761: such things without first using the debugger to find the facts. ! 762: ! 763: * A core dump file. ! 764: ! 765: We have no way of examining a core dump for your type of machine ! 766: unless we have an identical system--and if we do have one, we ! 767: should be able to reproduce the crash ourselves. 1.1.1.2 root 768: 769: 1.1.1.5 ! root 770: File: gcc.info, Node: Sending Patches, Prev: Bug Reporting, Up: Bugs 1.1 root 771: 1.1.1.5 ! root 772: Sending Patches for GNU CC ! 773: ========================== ! 774: ! 775: If you would like to write bug fixes or improvements for the GNU C ! 776: compiler, that is very helpful. When you send your changes, please ! 777: follow these guidelines to avoid causing extra work for us in studying ! 778: the patches. ! 779: ! 780: If you don't follow these guidelines, your information might still be ! 781: useful, but using it will take extra work. Maintaining GNU C is a lot ! 782: of work in the best of circumstances, and we can't keep up unless you do ! 783: your best to help. ! 784: ! 785: * Send an explanation with your changes of what problem they fix or ! 786: what improvement they bring about. For a bug fix, just include a ! 787: copy of the bug report, and explain why the change fixes the bug. ! 788: ! 789: (Referring to a bug report is not as good as including it, because ! 790: then we will have to look it up, and we have probably already ! 791: deleted it if we've already fixed the bug.) ! 792: ! 793: * Always include a proper bug report for the problem you think you ! 794: have fixed. We need to convince ourselves that the change is ! 795: right before installing it. Even if it is right, we might have ! 796: trouble judging it if we don't have a way to reproduce the problem. ! 797: ! 798: * Include all the comments that are appropriate to help people ! 799: reading the source in the future understand why this change was ! 800: needed. ! 801: ! 802: * Don't mix together changes made for different reasons. Send them ! 803: *individually*. ! 804: ! 805: If you make two changes for separate reasons, then we might not ! 806: want to install them both. We might want to install just one. If ! 807: you send them all jumbled together in a single set of diffs, we ! 808: have to do extra work to disentangle them--to figure out which ! 809: parts of the change serve which purpose. If we don't have time ! 810: for this, we might have to ignore your changes entirely. ! 811: ! 812: If you send each change as soon as you have written it, with its ! 813: own explanation, then the two changes never get tangled up, and we ! 814: can consider each one properly without any extra work to ! 815: disentangle them. ! 816: ! 817: Ideally, each change you send should be impossible to subdivide ! 818: into parts that we might want to consider separately, because each ! 819: of its parts gets its motivation from the other parts. ! 820: ! 821: * Send each change as soon as that change is finished. Sometimes ! 822: people think they are helping us by accumulating many changes to ! 823: send them all together. As explained above, this is absolutely ! 824: the worst thing you could do. ! 825: ! 826: Since you should send each change separately, you might as well ! 827: send it right away. That gives us the option of installing it ! 828: immediately if it is important. ! 829: ! 830: * Use `diff -c' to make your diffs. Diffs without context are hard ! 831: for us to install reliably. More than that, they make it hard for ! 832: us to study the diffs to decide whether we want to install them. ! 833: Unidiff format is better than contextless diffs, but not as easy ! 834: to read as `-c' format. ! 835: ! 836: If you have GNU diff, use `diff -cp', which shows the name of the ! 837: function that each change occurs in. ! 838: ! 839: * Write the change log entries for your changes. We get lots of ! 840: changes, and we don't have time to do all the change log writing ! 841: ourselves. ! 842: ! 843: Read the `ChangeLog' file to see what sorts of information to put ! 844: in, and to learn the style that we use. The purpose of the change ! 845: log is to show people where to find what was changed. So you need ! 846: to be specific about what functions you changed; in large ! 847: functions, it's often helpful to indicate where within the ! 848: function the change was. ! 849: ! 850: On the other hand, once you have shown people where to find the ! 851: change, you need not explain its purpose. Thus, if you add a new ! 852: function, all you need to say about it is that it is new. If you ! 853: feel that the purpose needs explaining, it probably does--but the ! 854: explanation will be much more useful if you put it in comments in ! 855: the code. ! 856: ! 857: If you would like your name to appear in the header line for who ! 858: made the change, send us the header line. ! 859: ! 860: * When you write the fix, keep in mind that we can't install a ! 861: change that would break other systems. ! 862: ! 863: People often suggest fixing a problem by changing ! 864: machine-independent files such as `toplev.c' to do something ! 865: special that a particular system needs. Sometimes it is totally ! 866: obvious that such changes would break GNU CC for almost all users. ! 867: We can't possibly make a change like that. At best it might tell ! 868: us how to write another patch that would solve the problem ! 869: acceptably. ! 870: ! 871: Sometimes people send fixes that *might* be an improvement in ! 872: general--but it is hard to be sure of this. It's hard to install ! 873: such changes because we have to study them very carefully. Of ! 874: course, a good explanation of the reasoning by which you concluded ! 875: the change was correct can help convince us. ! 876: ! 877: The safest changes are changes to the configuration files for a ! 878: particular machine. These are safe because they can't create new ! 879: bugs on other machines. ! 880: ! 881: Please help us keep up with the workload by designing the patch in ! 882: a form that is good to install. ! 883: ! 884: ! 885: File: gcc.info, Node: Service, Next: VMS, Prev: Bugs, Up: Top ! 886: ! 887: How To Get Help with GNU CC ! 888: *************************** ! 889: ! 890: If you need help installing, using or changing GNU CC, there are two ! 891: ways to find it: 1.1 root 892: 1.1.1.5 ! root 893: * Send a message to a suitable network mailing list. First try ! 894: `[email protected]', and if that brings no response, try ! 895: `[email protected]'. ! 896: ! 897: * Look in the service directory for someone who might help you for a ! 898: fee. The service directory is found in the file named `SERVICE' ! 899: in the GNU CC distribution. ! 900: ! 901: ! 902: File: gcc.info, Node: VMS, Next: Portability, Prev: Service, Up: Top ! 903: ! 904: Using GNU CC on VMS ! 905: ******************* ! 906: ! 907: * Menu: ! 908: ! 909: * Include Files and VMS:: Where the preprocessor looks for the include files. ! 910: * Global Declarations:: How to do globaldef, globalref and globalvalue with ! 911: GNU CC. ! 912: * VMS Misc:: Misc information. ! 913: ! 914: ! 915: File: gcc.info, Node: Include Files and VMS, Next: Global Declarations, Up: VMS ! 916: ! 917: Include Files and VMS ! 918: ===================== 1.1 root 919: 1.1.1.5 ! root 920: Due to the differences between the filesystems of Unix and VMS, GNU ! 921: CC attempts to translate file names in `#include' into names that VMS ! 922: will understand. The basic strategy is to prepend a prefix to the ! 923: specification of the include file, convert the whole filename to a VMS ! 924: filename, and then try to open the file. GNU CC tries various prefixes ! 925: one by one until one of them succeeds: ! 926: ! 927: 1. The first prefix is the `GNU_CC_INCLUDE:' logical name: this is ! 928: where GNU C header files are traditionally stored. If you wish to ! 929: store header files in non-standard locations, then you can assign ! 930: the logical `GNU_CC_INCLUDE' to be a search list, where each ! 931: element of the list is suitable for use with a rooted logical. ! 932: ! 933: 2. The next prefix tried is `SYS$SYSROOT:[SYSLIB.]'. This is where ! 934: VAX-C header files are traditionally stored. ! 935: ! 936: 3. If the include file specification by itself is a valid VMS ! 937: filename, the preprocessor then uses this name with no prefix in ! 938: an attempt to open the include file. ! 939: ! 940: 4. If the file specification is not a valid VMS filename (i.e. does ! 941: not contain a device or a directory specifier, and contains a `/' ! 942: character), the preprocessor tries to convert it from Unix syntax ! 943: to VMS syntax. ! 944: ! 945: Conversion works like this: the first directory name becomes a ! 946: device, and the rest of the directories are converted into ! 947: VMS-format directory names. For example, the name `X11/foobar.h' ! 948: is translated to `X11:[000000]foobar.h' or `X11:foobar.h', ! 949: whichever one can be opened. This strategy allows you to assign a ! 950: logical name to point to the actual location of the header files. ! 951: ! 952: 5. If none of these strategies succeeds, the `#include' fails. ! 953: ! 954: Include directives of the form: ! 955: ! 956: #include foobar ! 957: ! 958: are a common source of incompatibility between VAX-C and GNU CC. VAX-C ! 959: treats this much like a standard `#include <foobar.h>' directive. That ! 960: is incompatible with the ANSI C behavior implemented by GNU CC: to ! 961: expand the name `foobar' as a macro. Macro expansion should eventually ! 962: yield one of the two standard formats for `#include': ! 963: ! 964: #include "FILE" ! 965: #include <FILE> ! 966: ! 967: If you have this problem, the best solution is to modify the source ! 968: to convert the `#include' directives to one of the two standard forms. ! 969: That will work with either compiler. If you want a quick and dirty fix, ! 970: define the file names as macros with the proper expansion, like this: ! 971: ! 972: #define stdio <stdio.h> ! 973: ! 974: This will work, as long as the name doesn't conflict with anything else ! 975: in the program. ! 976: ! 977: Another source of incompatibility is that VAX-C assumes that: ! 978: ! 979: #include "foobar" ! 980: ! 981: is actually asking for the file `foobar.h'. GNU CC does not make this ! 982: assumption, and instead takes what you ask for literally; it tries to ! 983: read the file `foobar'. The best way to avoid this problem is to ! 984: always specify the desired file extension in your include directives. ! 985: ! 986: GNU CC for VMS is distributed with a set of include files that is ! 987: sufficient to compile most general purpose programs. Even though the ! 988: GNU CC distribution does not contain header files to define constants ! 989: and structures for some VMS system-specific functions, there is no ! 990: reason why you cannot use GNU CC with any of these functions. You first ! 991: may have to generate or create header files, either by using the public ! 992: domain utility `UNSDL' (which can be found on a DECUS tape), or by ! 993: extracting the relevant modules from one of the system macro libraries, ! 994: and using an editor to construct a C header file. ! 995: ! 996: A `#include' file name cannot contain a DECNET node name. The ! 997: preprocessor reports an I/O error if you attempt to use a node name, ! 998: whether explicitly, or implicitly via a logical name. 1.1 root 999: 1000: 1.1.1.5 ! root 1001: File: gcc.info, Node: Global Declarations, Next: VMS Misc, Prev: Include Files and VMS, Up: VMS 1.1 root 1002: 1.1.1.5 ! root 1003: Global Declarations and VMS ! 1004: =========================== 1.1 root 1005: 1.1.1.5 ! root 1006: GNU CC does not provide the `globalref', `globaldef' and ! 1007: `globalvalue' keywords of VAX-C. You can get the same effect with an ! 1008: obscure feature of GAS, the GNU assembler. (This requires GAS version ! 1009: 1.39 or later.) The following macros allow you to use this feature in ! 1010: a fairly natural way: ! 1011: ! 1012: #ifdef __GNUC__ ! 1013: #define GLOBALREF(TYPE,NAME) \ ! 1014: TYPE NAME \ ! 1015: asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME) ! 1016: #define GLOBALDEF(TYPE,NAME,VALUE) \ ! 1017: TYPE NAME \ ! 1018: asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME) \ ! 1019: = VALUE ! 1020: #define GLOBALVALUEREF(TYPE,NAME) \ ! 1021: const TYPE NAME[1] \ ! 1022: asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME) ! 1023: #define GLOBALVALUEDEF(TYPE,NAME,VALUE) \ ! 1024: const TYPE NAME[1] \ ! 1025: asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME) \ ! 1026: = {VALUE} ! 1027: #else ! 1028: #define GLOBALREF(TYPE,NAME) \ ! 1029: globalref TYPE NAME ! 1030: #define GLOBALDEF(TYPE,NAME,VALUE) \ ! 1031: globaldef TYPE NAME = VALUE ! 1032: #define GLOBALVALUEDEF(TYPE,NAME,VALUE) \ ! 1033: globalvalue TYPE NAME = VALUE ! 1034: #define GLOBALVALUEREF(TYPE,NAME) \ ! 1035: globalvalue TYPE NAME ! 1036: #endif ! 1037: ! 1038: (The `_$$PsectAttributes_GLOBALSYMBOL' prefix at the start of the name ! 1039: is removed by the assembler, after it has modified the attributes of ! 1040: the symbol). These macros are provided in the VMS binaries ! 1041: distribution in a header file `GNU_HACKS.H'. An example of the usage ! 1042: is: ! 1043: ! 1044: GLOBALREF (int, ijk); ! 1045: GLOBALDEF (int, jkl, 0); ! 1046: ! 1047: The macros `GLOBALREF' and `GLOBALDEF' cannot be used ! 1048: straightforwardly for arrays, since there is no way to insert the array ! 1049: dimension into the declaration at the right place. However, you can ! 1050: declare an array with these macros if you first define a typedef for the ! 1051: array type, like this: ! 1052: ! 1053: typedef int intvector[10]; ! 1054: GLOBALREF (intvector, foo); ! 1055: ! 1056: Array and structure initializers will also break the macros; you can ! 1057: define the initializer to be a macro of its own, or you can expand the ! 1058: `GLOBALDEF' macro by hand. You may find a case where you wish to use ! 1059: the `GLOBALDEF' macro with a large array, but you are not interested in ! 1060: explicitly initializing each element of the array. In such cases you ! 1061: can use an initializer like: `{0,}', which will initialize the entire ! 1062: array to `0'. ! 1063: ! 1064: A shortcoming of this implementation is that a variable declared with ! 1065: `GLOBALVALUEREF' or `GLOBALVALUEDEF' is always an array. For example, ! 1066: the declaration: ! 1067: ! 1068: GLOBALVALUEREF(int, ijk); ! 1069: ! 1070: declares the variable `ijk' as an array of type `int [1]'. This is ! 1071: done because a globalvalue is actually a constant; its "value" is what ! 1072: the linker would normally consider an address. That is not how an ! 1073: integer value works in C, but it is how an array works. So treating ! 1074: the symbol as an array name gives consistent results--with the ! 1075: exception that the value seems to have the wrong type. *Don't try to ! 1076: access an element of the array.* It doesn't have any elements. The ! 1077: array "address" may not be the address of actual storage. ! 1078: ! 1079: The fact that the symbol is an array may lead to warnings where the ! 1080: variable is used. Insert type casts to avoid the warnings. Here is an ! 1081: example; it takes advantage of the ANSI C feature allowing macros that ! 1082: expand to use the same name as the macro itself. ! 1083: ! 1084: GLOBALVALUEREF (int, ss$_normal); ! 1085: GLOBALVALUEDEF (int, xyzzy,123); ! 1086: #ifdef __GNUC__ ! 1087: #define ss$_normal ((int) ss$_normal) ! 1088: #define xyzzy ((int) xyzzy) ! 1089: #endif ! 1090: ! 1091: Don't use `globaldef' or `globalref' with a variable whose type is ! 1092: an enumeration type; this is not implemented. Instead, make the ! 1093: variable an integer, and use a `globalvaluedef' for each of the ! 1094: enumeration values. An example of this would be: ! 1095: ! 1096: #ifdef __GNUC__ ! 1097: GLOBALDEF (int, color, 0); ! 1098: GLOBALVALUEDEF (int, RED, 0); ! 1099: GLOBALVALUEDEF (int, BLUE, 1); ! 1100: GLOBALVALUEDEF (int, GREEN, 3); ! 1101: #else ! 1102: enum globaldef color {RED, BLUE, GREEN = 3}; ! 1103: #endif 1.1 root 1104:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.