![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-6 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-6 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.2 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.44 from the input 1.1 root 2: file gcc.texi. 3: 4: This file documents the use and the internals of the GNU compiler. 5: 6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc. 7: 8: Permission is granted to make and distribute verbatim copies of 9: this manual provided the copyright notice and this permission notice 10: are preserved on all copies. 11: 12: Permission is granted to copy and distribute modified versions of 13: this manual under the conditions for verbatim copying, provided also 14: that the section entitled "GNU General Public License" is included 15: exactly as in the original, and provided that the entire resulting 16: derived work is distributed under the terms of a permission notice 17: identical to this one. 18: 19: Permission is granted to copy and distribute translations of this 20: manual into another language, under the above conditions for modified 21: versions, except that the section entitled "GNU General Public 22: License" and this permission notice may be included in translations 23: approved by the Free Software Foundation instead of in the original 24: English. 25: 26: 1.1.1.2 ! root 27: File: gcc.info, Node: Bug Reporting, Next: Non-bugs, Prev: Bug Criteria, Up: Bugs ! 28: ! 29: How to Report Bugs ! 30: ================== ! 31: ! 32: Send bug reports for GNU C to one of these addresses: ! 33: ! 34: [email protected] ! 35: {ucbvax|mit-eddie|uunet}!prep.ai.mit.edu!bug-gcc ! 36: ! 37: *Do not send bug reports to `help-gcc', or to the newsgroup ! 38: `gnu.gcc.help'.* Most users of GNU CC do not want to receive bug ! 39: reports. Those that do, have asked to be on `bug-gcc'. ! 40: ! 41: The mailing list `bug-gcc' has a newsgroup which serves as a ! 42: repeater. The mailing list and the newsgroup carry exactly the same ! 43: messages. Often people think of posting bug reports to the newsgroup ! 44: instead of mailing them. This appears to work, but it has one problem ! 45: which can be crucial: a newsgroup posting does not contain a mail path ! 46: back to the sender. Thus, if I need to ask for more information, I ! 47: may be unable to reach you. For this reason, it is better to send bug ! 48: reports to the mailing list. ! 49: ! 50: As a last resort, send bug reports on paper to: ! 51: ! 52: GNU Compiler Bugs ! 53: Free Software Foundation ! 54: 675 Mass Ave ! 55: Cambridge, MA 02139 ! 56: ! 57: The fundamental principle of reporting bugs usefully is this: ! 58: *report all the facts*. If you are not sure whether to state a fact ! 59: or leave it out, state it! ! 60: ! 61: Often people omit facts because they think they know what causes the ! 62: problem and they conclude that some details don't matter. Thus, you ! 63: might assume that the name of the variable you use in an example does ! 64: not matter. Well, probably it doesn't, but one cannot be sure. ! 65: Perhaps the bug is a stray memory reference which happens to fetch ! 66: from the location where that name is stored in memory; perhaps, if the ! 67: name were different, the contents of that location would fool the ! 68: compiler into doing the right thing despite the bug. Play it safe and ! 69: give a specific, complete example. That is the easiest thing for you ! 70: to do, and the most helpful. ! 71: ! 72: Keep in mind that the purpose of a bug report is to enable me to fix ! 73: the bug if it is not known. It isn't very important what happens if ! 74: the bug is already known. Therefore, always write your bug reports on ! 75: the assumption that the bug is not known. ! 76: ! 77: Sometimes people give a few sketchy facts and ask, "Does this ring a ! 78: bell?" Those bug reports are useless, and I urge everyone to *refuse ! 79: to respond to them* except to chide the sender to report bugs properly. ! 80: ! 81: To enable me to fix the bug, you should include all these things: ! 82: ! 83: * The version of GNU CC. You can get this by running it with the ! 84: `-v' option. ! 85: ! 86: Without this, I won't know whether there is any point in looking ! 87: for the bug in the current version of GNU CC. ! 88: ! 89: * A complete input file that will reproduce the bug. If the bug is ! 90: in the C preprocessor, send me a source file and any header files ! 91: that it requires. If the bug is in the compiler proper (`cc1'), ! 92: run your source file through the C preprocessor by doing `gcc -E ! 93: SOURCEFILE > OUTFILE', then include the contents of OUTFILE in ! 94: the bug report. (Any `-I', `-D' or `-U' options that you used in ! 95: actual compilation should also be used when doing this.) ! 96: ! 97: A single statement is not enough of an example. In order to ! 98: compile it, it must be embedded in a function definition; and the ! 99: bug might depend on the details of how this is done. ! 100: ! 101: Without a real example I can compile, all I can do about your bug ! 102: report is wish you luck. It would be futile to try to guess how ! 103: to provoke the bug. For example, bugs in register allocation and ! 104: reloading frequently depend on every little detail of the function ! 105: they happen in. ! 106: ! 107: * The command arguments you gave GNU CC to compile that example and ! 108: observe the bug. For example, did you use `-O'? To guarantee ! 109: you won't omit something important, list them all. ! 110: ! 111: If I were to try to guess the arguments, I would probably guess ! 112: wrong and then I would not encounter the bug. ! 113: ! 114: * The type of machine you are using, and the operating system name ! 115: and version number. ! 116: ! 117: * The operands you gave to the `configure' command when you ! 118: installed the compiler. ! 119: ! 120: * A description of what behavior you observe that you believe is ! 121: incorrect. For example, "It gets a fatal signal," or, "There is ! 122: an incorrect assembler instruction in the output." ! 123: ! 124: Of course, if the bug is that the compiler gets a fatal signal, ! 125: then I will certainly notice it. But if the bug is incorrect ! 126: output, I might not notice unless it is glaringly wrong. I won't ! 127: study all the assembler code from a 50-line C program just on the ! 128: off chance that it might be wrong. ! 129: ! 130: Even if the problem you experience is a fatal signal, you should ! 131: still say so explicitly. Suppose something strange is going on, ! 132: such as, your copy of the compiler is out of synch, or you have ! 133: encountered a bug in the C library on your system. (This has ! 134: happened!) Your copy might crash and mine would not. If you ! 135: told me to expect a crash, then when mine fails to crash, I would ! 136: know that the bug was not happening for me. If you had not told ! 137: me to expect a crash, then I would not be able to draw any ! 138: conclusion from my observations. ! 139: ! 140: Often the observed symptom is incorrect output when your program ! 141: is run. Sad to say, this is not enough information for me unless ! 142: the program is short and simple. If you send me a large program, ! 143: I don't have time to figure out how it would work if compiled ! 144: correctly, much less which line of it was compiled wrong. So you ! 145: will have to do that. Tell me which source line it is, and what ! 146: incorrect result happens when that line is executed. A person ! 147: who understands the program can find this as easily as a bug in ! 148: the program itself. ! 149: ! 150: * If you send me examples of output from GNU CC, please use `-g' ! 151: when you make them. The debugging information includes source ! 152: line numbers which are essential for correlating the output with ! 153: the input. ! 154: ! 155: * If you wish to suggest changes to the GNU CC source, send me ! 156: context diffs. If you even discuss something in the GNU CC ! 157: source, refer to it by context, not by line number. ! 158: ! 159: The line numbers in my development sources don't match those in ! 160: your sources. Your line numbers would convey no useful ! 161: information to me. ! 162: ! 163: * Additional information from a debugger might enable me to find a ! 164: problem on a machine which I do not have available myself. ! 165: However, you need to think when you collect this information if ! 166: you want it to have any chance of being useful. ! 167: ! 168: For example, many people send just a backtrace, but that is never ! 169: useful by itself. A simple backtrace with arguments conveys ! 170: little about GNU CC because the compiler is largely data-driven; ! 171: the same functions are called over and over for different RTL ! 172: insns, doing different things depending on the details of the ! 173: insn. ! 174: ! 175: Most of the arguments listed in the backtrace are useless because ! 176: they are pointers to RTL list structure. The numeric values of ! 177: the pointers, which the debugger prints in the backtrace, have no ! 178: significance whatever; all that matters is the contents of the ! 179: objects they point to (and most of the contents are other such ! 180: pointers). ! 181: ! 182: In addition, most compiler passes consist of one or more loops ! 183: that scan the RTL insn sequence. The most vital piece of ! 184: information about such a loop--which insn it has reached--is ! 185: usually in a local variable, not in an argument. ! 186: ! 187: What you need to provide in addition to a backtrace are the ! 188: values of the local variables for several stack frames up. When ! 189: a local variable or an argument is an RTX, first print its value ! 190: and then use the GDB command `pr' to print the RTL expression ! 191: that it points to. (If GDB doesn't run on your machine, use your ! 192: debugger to call the function `debug_rtx' with the RTX as an ! 193: argument.) In general, whenever a variable is a pointer, its ! 194: value is no use without the data it points to. ! 195: ! 196: In addition, include a debugging dump from just before the pass ! 197: in which the crash happens. Most bugs involve a series of insns, ! 198: not just one. ! 199: ! 200: Here are some things that are not necessary: ! 201: ! 202: * A description of the envelope of the bug. ! 203: ! 204: Often people who encounter a bug spend a lot of time investigating ! 205: which changes to the input file will make the bug go away and ! 206: which changes will not affect it. ! 207: ! 208: This is often time consuming and not very useful, because the way ! 209: I will find the bug is by running a single example under the ! 210: debugger with breakpoints, not by pure deduction from a series of ! 211: examples. I recommend that you save your time for something else. ! 212: ! 213: Of course, if you can find a simpler example to report *instead* ! 214: of the original one, that is a convenience for me. Errors in the ! 215: output will be easier to spot, running under the debugger will ! 216: take less time, etc. Most GNU CC bugs involve just one function, ! 217: so the most straightforward way to simplify an example is to ! 218: delete all the function definitions except the one where the bug ! 219: occurs. Those earlier in the file may be replaced by external ! 220: declarations if the crucial function depends on them. ! 221: (Exception: inline functions may affect compilation of functions ! 222: defined later in the file.) ! 223: ! 224: However, simplification is not vital; if you don't want to do ! 225: this, report the bug anyway and send me the entire test case you ! 226: used. ! 227: ! 228: * A patch for the bug. ! 229: ! 230: A patch for the bug does help me if it is a good one. But don't ! 231: omit the necessary information, such as the test case, on the ! 232: assumption that a patch is all I need. I might see problems with ! 233: your patch and decide to fix the problem another way, or I might ! 234: not understand it at all. ! 235: ! 236: Sometimes with a program as complicated as GNU CC it is very hard ! 237: to construct an example that will make the program follow a ! 238: certain path through the code. If you don't send me the example, ! 239: I won't be able to construct one, so I won't be able to verify ! 240: that the bug is fixed. ! 241: ! 242: And if I can't understand what bug you are trying to fix, or why ! 243: your patch should be an improvement, I won't install it. A test ! 244: case will help me to understand. ! 245: ! 246: * A guess about what the bug is or what it depends on. ! 247: ! 248: Such guesses are usually wrong. Even I can't guess right about ! 249: such things without first using the debugger to find the facts. ! 250: ! 251: 1.1 root 252: File: gcc.info, Node: Non-bugs, Prev: Bug Reporting, Up: Bugs 253: 254: Certain Changes We Don't Want to Make 255: ===================================== 256: 257: This section lists changes that people frequently request, but which 258: we do not make because we think GNU CC is better without them. 259: 260: * Checking the number and type of arguments to a function which has 261: an old-fashioned definition and no prototype. 262: 263: Such a feature would work only occasionally--only for calls that 264: appear in the same file as the called function, following the 265: definition. The only way to check all calls reliably is to add a 1.1.1.2 ! root 266: prototype for the function. But adding a prototype eliminates ! 267: the motivation for this feature. So the feature is not 1.1 root 268: worthwhile. 269: 270: * Warning about using an expression whose type is signed as a shift 271: count. 272: 273: Shift count operands are probably signed more often than unsigned. 274: Warning about this would cause far more annoyance than good. 275: 276: * Warning about assigning a signed value to an unsigned variable. 277: 278: Such assignments must be very common; warning about them would 279: cause more annoyance than good. 280: 1.1.1.2 ! root 281: * Warning when a non-void function value is ignored. ! 282: ! 283: Coming as I do from a Lisp background, I balk at the idea that ! 284: there is something dangerous about discarding a value. There are ! 285: functions that return values which some callers may find useful; ! 286: it makes no sense to clutter the program with a cast to `void' ! 287: whenever the value isn't useful. ! 288: 1.1 root 289: * Making bitfields unsigned by default on particular machines where 290: "the ABI standard" says to do so. 291: 292: The ANSI C standard leaves it up to the implementation whether a 293: bitfield declared plain `int' is signed or not. This in effect 294: creates two alternative dialects of C. 295: 296: The GNU C compiler supports both dialects; you can specify the 297: dialect you want with the option `-fsigned-bitfields' or 298: `-funsigned-bitfields'. However, this leaves open the question 299: of which dialect to use by default. 300: 301: Currently, the preferred dialect makes plain bitfields signed, 302: because this is simplest. Since `int' is the same as `signed 303: int' in every other context, it is cleanest for them to be the 304: same in bitfields as well. 305: 306: Some computer manufacturers have published Application Binary 307: Interface standards which specify that plain bitfields should be 308: unsigned. It is a mistake, however, to say anything about this 309: issue in an ABI. This is because the handling of plain bitfields 310: distinguishes two dialects of C. Both dialects are meaningful on 311: every type of machine. Whether a particular object file was 312: compiled using signed bitfields or unsigned is of no concern to 1.1.1.2 ! root 313: other object files, even if they access the same bitfields in the ! 314: same data structures. 1.1 root 315: 316: A given program is written in one or the other of these two 317: dialects. The program stands a chance to work on most any 318: machine if it is compiled with the proper dialect. It is 319: unlikely to work at all if compiled with the wrong dialect. 320: 321: Many users appreciate the GNU C compiler because it provides an 322: environment that is uniform across machines. These users would be 323: inconvenienced if the compiler treated plain bitfields 324: differently on certain machines. 325: 326: Occasionally users write programs intended only for a particular 327: machine type. On these occasions, the users would benefit if the 328: GNU C compiler were to support by default the same dialect as the 329: other compilers on that machine. But such applications are rare. 330: And users writing a program to run on more than one type of 331: machine cannot possibly benefit from this kind of compatibility. 332: 333: This is why GNU CC does and will treat plain bitfields in the same 334: fashion on all types of machines (by default). 335: 1.1.1.2 ! root 336: There are some arguments for making bitfields unsigned by default ! 337: on all machines. If, for example, this becomes a universal de ! 338: facto standard, it would make sense for GNU CC to go along with ! 339: it. This is something to be considered in the future. ! 340: 1.1 root 341: (Of course, users strongly concerned about portability should 1.1.1.2 ! root 342: indicate explicitly in each bitfield whether it is signed or not. ! 343: In this way, they write programs which have the same meaning in ! 344: both C dialects.) 1.1 root 345: 346: * Undefining `__STDC__' when `-ansi' is not used. 347: 348: Currently, GNU CC defines `__STDC__' as long as you don't use 349: `-traditional'. This provides good results in practice. 350: 351: Programmers normally use conditionals on `__STDC__' to ask whether 352: it is safe to use certain features of ANSI C, such as function 353: prototypes or ANSI token concatenation. Since plain `gcc' 354: supports all the features of ANSI C, the correct answer to these 355: questions is "yes". 356: 357: Some users try to use `__STDC__' to check for the availability of 358: certain library facilities. This is actually incorrect usage in 359: an ANSI C program, because the ANSI C standard says that a 360: conforming freestanding implementation should define `__STDC__' 361: even though it does not have the library facilities. `gcc -ansi 362: -pedantic' is a conforming freestanding implementation, and it is 363: therefore required to define `__STDC__', even though it does not 364: come with an ANSI C library. 365: 366: Sometimes people say that defining `__STDC__' in a compiler that 367: does not completely conform to the ANSI C standard somehow 368: violates the standard. This is illogical. The standard is a 1.1.1.2 ! root 369: standard for compilers that claim to support ANSI C, such as `gcc ! 370: -ansi'--not for other compilers such as plain `gcc'. Whatever ! 371: the ANSI C standard says is relevant to the design of plain `gcc' 1.1 root 372: without `-ansi' only for pragmatic reasons, not as a requirement. 373: 374: * Undefining `__STDC__' in C++. 375: 376: Programs written to compile with C++-to-C translators get the 377: value of `__STDC__' that goes with the C compiler that is 378: subsequently used. These programs must test `__STDC__' to 379: determine what kind of C preprocessor that compiler uses: whether 380: they should concatenate tokens in the ANSI C fashion or in the 381: traditional fashion. 382: 383: These programs work properly with GNU C++ if `__STDC__' is 384: defined. They would not work otherwise. 385: 386: In addition, many header files are written to provide prototypes 387: in ANSI C but not in traditional C. Many of these header files 388: can work without change in C++ provided `__STDC__' is defined. 389: If `__STDC__' is not defined, they will all fail, and will all 390: need to be changed to test explicitly for C++ as well. 391: 392: 393: File: gcc.info, Node: VMS, Next: Portability, Prev: Bugs, Up: Top 394: 395: Using GNU CC on VMS 396: ******************* 397: 398: * Menu: 399: 400: * Include Files and VMS:: Where the preprocessor looks for the include files. 401: * Global Declarations:: How to do globaldef, globalref and globalvalue with 402: GNU CC. 403: * VMS Misc:: Misc information. 404: 405: 406: File: gcc.info, Node: Include Files and VMS, Next: Global Declarations, Prev: VMS, Up: VMS 407: 408: Include Files and VMS 409: ===================== 410: 411: Due to the differences between the filesystems of Unix and VMS, GNU 412: CC attempts to translate file names in `#include' into names that VMS 413: will understand. The basic strategy is to prepend a prefix to the 414: specification of the include file, convert the whole filename to a VMS 415: filename, and then try to open the file. GNU CC tries various prefixes 416: one by one until one of them succeeds: 417: 418: 1. The first prefix is the `GNU_CC_INCLUDE:' logical name: this is 419: where GNU C header files are traditionally stored. If you wish 420: to store header files in non-standard locations, then you can 421: assign the logical `GNU_CC_INCLUDE' to be a search list, where 422: each element of the list is suitable for use with a rooted 423: logical. 424: 425: 2. The next prefix tried is `SYS$SYSROOT:[SYSLIB.]'. This is where 426: VAX-C header files are traditionally stored. 427: 428: 3. If the include file specification by itself is a valid VMS 429: filename, the preprocessor then uses this name with no prefix in 430: an attempt to open the include file. 431: 432: 4. If the file specification is not a valid VMS filename (i.e. does 433: not contain a device or a directory specifier, and contains a `/' 434: character), the preprocessor tries to convert it from Unix syntax 435: to VMS syntax. 436: 437: Conversion works like this: the first directory name becomes a 438: device, and the rest of the directories are converted into 439: VMS-format directory names. For example, `X11/foobar.h' is 440: translated to `X11:[000000]foobar.h' or `X11:foobar.h', whichever 441: one can be opened. This strategy allows you to assign a logical 442: name to point to the actual location of the header files. 443: 444: 5. If none of these strategies succeeds, the `#include' fails. 445: 446: Include directives of the form: 447: 448: #include foobar 449: 450: are a common source of incompatibility between VAX-C and GNU CC. VAX-C 451: treats this much like a standard `#include <foobar.h>' directive. 452: That is incompatible with the ANSI C behavior implemented by GNU CC: to 453: expand the name `foobar' as a macro. Macro expansion should 454: eventually yield one of the two standard formats for `#include': 455: 456: #include "FILE" 457: #include <FILE> 458: 459: If you have this problem, the best solution is to modify the source 460: to convert the `#include' directives to one of the two standard forms. 461: That will work with either compiler. If you want a quick and dirty 462: fix, define the file names as macros with the proper expansion, like 463: this: 464: 465: #define stdio <stdio.h> 466: 467: This will work, as long as the name doesn't conflict with anything else 468: in the program. 469: 470: Another source of incompatibility is that VAX-C assumes that: 471: 472: #include "foobar" 473: 474: is actually asking for the file `foobar.h'. GNU CC does not make this 475: assumption, and instead takes what you ask for literally; it tries to 476: read the file `foobar'. The best way to avoid this problem is to 477: always specify the desired file extension in your include directives. 478: 479: GNU CC for VMS is distributed with a set of include files that is 480: sufficient to compile most general purpose programs. Even though the 481: GNU CC distribution does not contain header files to define constants 482: and structures for some VMS system-specific functions, there is no 483: reason why you cannot use GNU CC with any of these functions. You 484: first may have to generate or create header files, either by using the 485: public domain utility `UNSDL' (which can be found on a DECUS tape), or 486: by extracting the relevant modules from one of the system macro 487: libraries, and using an editor to construct a C header file. 488: 489: 490: File: gcc.info, Node: Global Declarations, Next: VMS Misc, Prev: Include Files and VMS, Up: VMS 491: 492: Global Declarations and VMS 493: =========================== 494: 495: GNU CC does not provide the `globalref', `globaldef' and 496: `globalvalue' keywords of VAX-C. You can get the same effect with an 497: obscure feature of GAS, the GNU assembler. (This requires GAS version 498: 1.39 or later.) The following macros allow you to use this feature in 499: a fairly natural way: 500: 501: #ifdef __GNUC__ 1.1.1.2 ! root 502: #define GLOBALREF(TYPE,NAME) \ ! 503: TYPE NAME \ ! 504: asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME) ! 505: #define GLOBALDEF(TYPE,NAME,VALUE) \ ! 506: TYPE NAME \ ! 507: asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME) \ ! 508: = VALUE ! 509: #define GLOBALVALUEREF(TYPE,NAME) \ ! 510: const TYPE NAME[1] \ ! 511: asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME) ! 512: #define GLOBALVALUEDEF(TYPE,NAME,VALUE) \ ! 513: const TYPE NAME[1] \ ! 514: asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME) \ ! 515: = {VALUE} 1.1 root 516: #else 1.1.1.2 ! root 517: #define GLOBALREF(TYPE,NAME) \ ! 518: globalref TYPE NAME ! 519: #define GLOBALDEF(TYPE,NAME,VALUE) \ ! 520: globaldef TYPE NAME = VALUE ! 521: #define GLOBALVALUEDEF(TYPE,NAME,VALUE) \ ! 522: globalvalue TYPE NAME = VALUE ! 523: #define GLOBALVALUEREF(TYPE,NAME) \ ! 524: globalvalue TYPE NAME 1.1 root 525: #endif 526: 527: (The `_$$PsectAttributes_GLOBALSYMBOL' prefix at the start of the name 528: is removed by the assembler, after it has modified the attributes of 529: the symbol). These macros are provided in the VMS binaries 530: distribution in a header file `GNU_HACKS.H'. An example of the usage 531: is: 532: 1.1.1.2 ! root 533: GLOBALREF (int, ijk); ! 534: GLOBALDEF (int, jkl, 0); 1.1 root 535: 536: The macros `GLOBALREF' and `GLOBALDEF' cannot be used 537: straightforwardly for arrays, since there is no way to insert the array 538: dimension into the declaration at the right place. However, you can 539: declare an array with these macros if you first define a typedef for 540: the array type, like this: 541: 542: typedef int intvector[10]; 1.1.1.2 ! root 543: GLOBALREF (intvector, foo); 1.1 root 544: 545: Array and structure initializers will also break the macros; you can 546: define the initializer to be a macro of its own, or you can expand the 547: `GLOBALDEF' macro by hand. You may find a case where you wish to use 548: the `GLOBALDEF' macro with a large array, but you are not interested 549: in explicitly initializing each element of the array. In such cases 550: you can use an initializer like: `{0,}', which will initialize the 551: entire array to `0'. 552: 553: A shortcoming of this implementation is that a variable declared 554: with `GLOBALVALUEREF' or `GLOBALVALUEDEF' is always an array. For 555: example, the declaration: 556: 1.1.1.2 ! root 557: GLOBALVALUEREF(int, ijk); 1.1 root 558: 559: declares the variable `ijk' as an array of type `int [1]'. This is 560: done because a globalvalue is actually a constant; its "value" is what 561: the linker would normally consider an address. That is not how an 562: integer value works in C, but it is how an array works. So treating 563: the symbol as an array name gives consistent results--with the 564: exception that the value seems to have the wrong type. *Don't try to 565: access an element of the array.* It doesn't have any elements. The 566: array "address" may not be the address of actual storage. 567: 568: The fact that the symbol is an array may lead to warnings where the 569: variable is used. Insert type casts to avoid the warnings. Here is an 570: example; it takes advantage of the ANSI C feature allowing macros that 571: expand to use the same name as the macro itself. 572: 1.1.1.2 ! root 573: GLOBALVALUEREF (int, ss$_normal); ! 574: GLOBALVALUEDEF (int, xyzzy,123); 1.1 root 575: #ifdef __GNUC__ 576: #define ss$_normal ((int) ss$_normal) 577: #define xyzzy ((int) xyzzy) 578: #endif 579: 580: Don't use `globaldef' or `globalref' with a variable whose type is 581: an enumeration type; this is not implemented. Instead, make the 582: variable an integer, and use a `globalvaluedef' for each of the 583: enumeration values. An example of this would be: 584: 585: #ifdef __GNUC__ 1.1.1.2 ! root 586: GLOBALDEF (int, color, 0); ! 587: GLOBALVALUEDEF (int, RED, 0); ! 588: GLOBALVALUEDEF (int, BLUE, 1); ! 589: GLOBALVALUEDEF (int, GREEN, 3); 1.1 root 590: #else 591: enum globaldef color {RED, BLUE, GREEN = 3}; 592: #endif 593: 594: 595: File: gcc.info, Node: VMS Misc, Prev: Global Declarations, Up: VMS 596: 597: Other VMS Issues 598: ================ 599: 600: GNU CC automatically arranges for `main' to return 1 by default if 601: you fail to specify an explicit return value. This will be interpreted 602: by VMS as a status code indicating a normal successful completion. 603: Version 1 of GNU CC did not provide this default. 604: 605: GNU CC on VMS works only with the GNU assembler, GAS. You need 606: version 1.37 or later of GAS in order to produce value debugging 607: information for the VMS debugger. Use the ordinary VMS linker with 608: the object files produced by GAS. 609: 610: Under previous versions of GNU CC, the generated code would 611: occasionally give strange results when linked to the sharable 612: `VAXCRTL' library. Now this should work. 613: 614: A caveat for use of `const' global variables: the `const' modifier 615: must be specified in every external declaration of the variable in all 616: of the source files that use that variable. Otherwise the linker will 617: issue warnings about conflicting attributes for the variable. Your 618: program will still work despite the warnings, but the variable will be 619: placed in writable storage. 620: 621: The VMS linker does not distinguish between upper and lower case 622: letters in function and variable names. However, usual practice in C 623: is to distinguish case. Normally GNU CC (by means of the assembler 624: GAS) implements usual C behavior by augmenting each name that is not 625: all lower-case. A name is augmented by truncating it to at most 23 626: characters and then adding more characters at the end which encode the 627: case pattern the rest. 628: 629: Name augmentation yields bad results for programs that use 630: precompiled libraries (such as Xlib) which were generated by another 631: compiler. You can use the compiler option `/NOCASE_HACK' to inhibit 632: augmentation; it makes external C functions and variables 633: case-independent as is usual on VMS. Alternatively, you could write 634: all references to the functions and variables in such libraries using 635: lower case; this will work on VMS, but is not portable to other 636: systems. 637: 638: Function and variable names are handled somewhat differently with 639: GNU C++. The GNU C++ compiler performs "name mangling" on function 640: names, which means that it adds information to the function name to 641: describe the data types of the arguments that the function takes. One 642: result of this is that the name of a function can become very long. 643: Since the VMS linker only recognizes the first 31 characters in a name, 644: special action is taken to ensure that each function and variable has a 645: unique name that can be represented in 31 characters. 646: 647: If the name (plus a name augmentation, if required) is less than 32 648: characters in length, then no special action is performed. If the name 649: is longer than 31 characters, the assembler (GAS) will generate a hash 650: string based upon the function name, truncate the function name to 23 651: characters, and append the hash string to the truncated name. If the 652: `/VERBOSE' compiler option is used, the assembler will print both the 653: full and truncated names of each symbol that is truncated. 654: 655: The `/NOCASE_HACK' compiler option should not be used when you are 656: compiling programs that use libg++. libg++ has several instances of 657: objects (i.e. `Filebuf' and `filebuf') which become indistinguishable 658: in a case-insensitive environment. This leads to cases where you need 659: to inhibit augmentation selectively (if you were using libg++ and Xlib 660: in the same program, for example). There is no special feature for 661: doing this, but you can get the result by defining a macro for each 662: mixed case symbol for which you wish to inhibit augmentation. The 663: macro should expand into the lower case equivalent of itself. For 664: example: 665: 666: #define StuDlyCapS studlycaps 667: 668: These macro definitions can be placed in a header file to minimize 669: the number of changes to your source code. 670: 671: 672: File: gcc.info, Node: Portability, Next: Interface, Prev: VMS, Up: Top 673: 674: GNU CC and Portability 675: ********************** 676: 677: The main goal of GNU CC was to make a good, fast compiler for 678: machines in the class that the GNU system aims to run on: 32-bit 679: machines that address 8-bit bytes and have several general registers. 680: Elegance, theoretical power and simplicity are only secondary. 681: 682: GNU CC gets most of the information about the target machine from a 683: machine description which gives an algebraic formula for each of the 684: machine's instructions. This is a very clean way to describe the 685: target. But when the compiler needs information that is difficult to 686: express in this fashion, I have not hesitated to define an ad-hoc 687: parameter to the machine description. The purpose of portability is 688: to reduce the total work needed on the compiler; it was not of 689: interest for its own sake. 690: 691: GNU CC does not contain machine dependent code, but it does contain 692: code that depends on machine parameters such as endianness (whether 693: the most significant byte has the highest or lowest address of the 694: bytes in a word) and the availability of autoincrement addressing. In 695: the RTL-generation pass, it is often necessary to have multiple 696: strategies for generating code for a particular kind of syntax tree, 697: strategies that are usable for different combinations of parameters. 698: Often I have not tried to address all possible cases, but only the 699: common ones or only the ones that I have encountered. As a result, a 700: new target may require additional strategies. You will know if this 701: happens because the compiler will call `abort'. Fortunately, the new 702: strategies can be added in a machine-independent fashion, and will 703: affect only the target machines that need them. 704: 705: 706: File: gcc.info, Node: Interface, Next: Passes, Prev: Portability, Up: Top 707: 708: Interfacing to GNU CC Output 709: **************************** 710: 711: GNU CC is normally configured to use the same function calling 712: convention normally in use on the target system. This is done with the 1.1.1.2 ! root 713: machine-description macros described (*note Target Macros::.). 1.1 root 714: 715: However, returning of structure and union values is done 716: differently on some target machines. As a result, functions compiled 717: with PCC returning such types cannot be called from code compiled with 718: GNU CC, and vice versa. This does not cause trouble often because few 719: Unix library routines return structures or unions. 720: 721: GNU CC code returns structures and unions that are 1, 2, 4 or 8 722: bytes long in the same registers used for `int' or `double' return 723: values. (GNU CC typically allocates variables of such types in 724: registers also.) Structures and unions of other sizes are returned by 725: storing them into an address passed by the caller (usually in a 726: register). The machine-description macros `STRUCT_VALUE' and 727: `STRUCT_INCOMING_VALUE' tell GNU CC where to pass this address. 728: 729: By contrast, PCC on most target machines returns structures and 730: unions of any size by copying the data into an area of static storage, 731: and then returning the address of that storage as if it were a pointer 732: value. The caller must copy the data from that memory area to the 733: place where the value is wanted. This is slower than the method used 734: by GNU CC, and fails to be reentrant. 735: 736: On some target machines, such as RISC machines and the 80386, the 737: standard system convention is to pass to the subroutine the address of 738: where to return the value. On these machines, GNU CC has been 739: configured to be compatible with the standard compiler, when this 740: method is used. It may not be compatible for structures of 1, 2, 4 or 741: 8 bytes. 742: 743: GNU CC uses the system's standard convention for passing arguments. 744: On some machines, the first few arguments are passed in registers; in 745: others, all are passed on the stack. It would be possible to use 746: registers for argument passing on any machine, and this would probably 747: result in a significant speedup. But the result would be complete 748: incompatibility with code that follows the standard convention. So 749: this change is practical only if you are switching to GNU CC as the 750: sole C compiler for the system. We may implement register argument 751: passing on certain machines once we have a complete GNU system so that 752: we can compile the libraries with GNU CC. 753: 754: On some machines (particularly the Sparc), certain types of 755: arguments are passed "by invisible reference". This means that the 756: value is stored in memory, and the address of the memory location is 757: passed to the subroutine. 758: 759: If you use `longjmp', beware of automatic variables. ANSI C says 760: that automatic variables that are not declared `volatile' have 761: undefined values after a `longjmp'. And this is all GNU CC promises 762: to do, because it is very difficult to restore register variables 763: correctly, and one of GNU CC's features is that it can put variables 764: in registers without your asking it to. 765: 766: If you want a variable to be unaltered by `longjmp', and you don't 767: want to write `volatile' because old C compilers don't accept it, just 768: take the address of the variable. If a variable's address is ever 769: taken, even if just to compute it and ignore it, then the variable 770: cannot go in a register: 771: 772: { 773: int careful; 774: &careful; 775: ... 776: } 777: 778: Code compiled with GNU CC may call certain library routines. Most 779: of them handle arithmetic for which there are no instructions. This 780: includes multiply and divide on some machines, and floating point 781: operations on any machine for which floating point support is disabled 782: with `-msoft-float'. Some standard parts of the C library, such as 783: `bcopy' or `memcpy', are also called automatically. The usual 784: function call interface is used for calling the library routines. 785: 786: These library routines should be defined in the library `libgcc.a', 787: which GNU CC automatically searches whenever it links a program. On 788: machines that have multiply and divide instructions, if hardware 789: floating point is in use, normally `libgcc.a' is not needed, but it is 790: searched just in case. 791: 792: Each arithmetic function is defined in `libgcc1.c' to use the 793: corresponding C arithmetic operator. As long as the file is compiled 794: with another C compiler, which supports all the C arithmetic operators, 795: this file will work portably. However, `libgcc1.c' does not work if 796: compiled with GNU CC, because each arithmetic function would compile 797: into a call to itself! 798: 799:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.