![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-8 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-8 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.4 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.49 from the input 1.1 root 2: file gcc.texi. 3: 4: This file documents the use and the internals of the GNU compiler. 5: 6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc. 7: 1.1.1.3 root 8: Permission is granted to make and distribute verbatim copies of this 9: manual provided the copyright notice and this permission notice are 10: preserved on all copies. 1.1 root 11: 12: Permission is granted to copy and distribute modified versions of 13: this manual under the conditions for verbatim copying, provided also 1.1.1.4 ! root 14: that the sections entitled "GNU General Public License" and "Protect ! 15: Your Freedom--Fight `Look And Feel'" are included exactly as in the ! 16: original, and provided that the entire resulting derived work is ! 17: distributed under the terms of a permission notice identical to this ! 18: one. 1.1 root 19: 20: Permission is granted to copy and distribute translations of this 21: manual into another language, under the above conditions for modified 1.1.1.3 root 22: versions, except that the sections entitled "GNU General Public 1.1.1.4 ! root 23: License" and "Protect Your Freedom--Fight `Look And Feel'", and this ! 24: permission notice, may be included in translations approved by the Free ! 25: Software Foundation instead of in the original English. 1.1.1.2 root 26: 27: 1.1.1.4 ! root 28: File: gcc.info, Node: Sending Patches, Prev: Bug Reporting, Up: Bugs 1.1.1.2 root 29: 1.1.1.4 ! root 30: Sending Patches for GNU CC ! 31: ========================== ! 32: ! 33: If you would like to write bug fixes or improvements for the GNU C ! 34: compiler, that is very helpful. When you send your changes, please ! 35: follow these guidelines to avoid causing extra work for us in studying ! 36: the patches. ! 37: ! 38: If you don't follow these guidelines, your information might still be ! 39: useful, but using it will take extra work. Maintaining GNU C is a lot ! 40: of work in the best of circumstances, and we can't keep up unless you do ! 41: your best to help. ! 42: ! 43: * Send an explanation with your changes of what problem they fix or ! 44: what improvement they bring about. For a bug fix, just include a ! 45: copy of the bug report, and explain why the change fixes the bug. ! 46: ! 47: (Referring to a bug report is not as good as including it, because ! 48: then we will have to look it up, and we have probably already ! 49: deleted it if we've already fixed the bug.) ! 50: ! 51: * Always include a proper bug report for the problem you think you ! 52: have fixed. We need to convince ourselves that the change is ! 53: right before installing it. Even if it is right, we might have ! 54: trouble judging it if we don't have a way to reproduce the problem. ! 55: ! 56: * Include all the comments that are appropriate to help people ! 57: reading the source in the future understand why this change was ! 58: needed. ! 59: ! 60: * Don't mix together changes made for different reasons. Send them ! 61: *individually*. ! 62: ! 63: If you make two changes for separate reasons, then we might not ! 64: want to install them both. We might want to install just one. If ! 65: you send them all jumbled together in a single set of diffs, we ! 66: have to do extra work to disentangle them--to figure out which ! 67: parts of the change serve which purpose. If we don't have time ! 68: for this, we might have to ignore your changes entirely. ! 69: ! 70: If you send each change as soon as you have written it, with its ! 71: own explanation, then the two changes never get tangled up, and we ! 72: can consider each one properly without any extra work to ! 73: disentangle them. ! 74: ! 75: Ideally, each change you send should be impossible to subdivide ! 76: into parts that we might want to consider separately, because each ! 77: of its parts gets its motivation from the other parts. ! 78: ! 79: * Send each change as soon as that change is finished. Sometimes ! 80: people think they are helping us by accumulating many changes to ! 81: send them all together. As explained above, this is absolutely ! 82: the worst thing you could do. ! 83: ! 84: Since you should send each change separately, you might as well ! 85: send it right away. That gives us the option of installing it ! 86: immediately if it is important. ! 87: ! 88: * Use `diff -c' to make your diffs. Diffs without context are hard ! 89: for us to install reliably. More than that, they make it hard for ! 90: us to study the diffs to decide whether we want to install them. ! 91: Unidiff format is better than contextless diffs, but not as easy ! 92: to read as `-c' format. ! 93: ! 94: If you have GNU diff, use `diff -cp', which shows the name of the ! 95: function that each change occurs in. ! 96: ! 97: * Write the change log entries for your changes. We get lots of ! 98: changes, and we don't have time to do all the change log writing ! 99: ourselves. ! 100: ! 101: Read the `ChangeLog' file to see what sorts of information to put ! 102: in, and to learn the style that we use. The purpose of the change ! 103: log is to show people where to find what was changed. So you need ! 104: to be specific about what functions you changed; in large ! 105: functions, it's often helpful to indicate where within the ! 106: function the change was. ! 107: ! 108: On the other hand, once you have shown people where to find the ! 109: change, you need not explain its purpose. Thus, if you add a new ! 110: function, all you need to say about it is that it is new. If you ! 111: feel that the purpose needs explaining, it probably does--but the ! 112: explanation will be much more useful if you put it in comments in ! 113: the code. ! 114: ! 115: If you would like your name to appear in the header line for who ! 116: made the change, send us the header line. ! 117: ! 118: * When you write the fix, keep in mind that we can't install a ! 119: change that would break other systems. ! 120: ! 121: People often suggest fixing a problem by changing ! 122: machine-independent files such as `toplev.c' to do something ! 123: special that a particular system needs. Sometimes it is totally ! 124: obvious that such changes would break GNU CC for almost all users. ! 125: We can't possibly make a change like that. At best it might tell ! 126: us how to write another patch that would solve the problem ! 127: acceptably. ! 128: ! 129: Sometimes people send fixes that *might* be an improvement in ! 130: general--but it is hard to be sure of this. It's hard to install ! 131: such changes because we have to study them very carefully. Of ! 132: course, a good explanation of the reasoning by which you concluded ! 133: the change was correct can help convince us. ! 134: ! 135: The safest changes are changes to the configuration files for a ! 136: particular machine. These are safe because they can't create new ! 137: bugs on other machines. ! 138: ! 139: Please help us keep up with the workload by designing the patch in ! 140: a form that is good to install. ! 141: ! 142: ! 143: File: gcc.info, Node: Service, Next: VMS, Prev: Bugs, Up: Top ! 144: ! 145: How To Get Help with GNU CC ! 146: *************************** ! 147: ! 148: If you need help installing, using or changing GNU CC, there are two ! 149: ways to find it: ! 150: ! 151: * Send a message to a suitable network mailing list. First try ! 152: `[email protected]', and if that brings no response, try ! 153: `[email protected]'. ! 154: ! 155: * Look in the service directory for someone who might help you for a ! 156: fee. The service directory is found in the file named `SERVICE' in ! 157: the GNU CC distribution. ! 158: ! 159: ! 160: File: gcc.info, Node: VMS, Next: Portability, Prev: Service, Up: Top ! 161: ! 162: Using GNU CC on VMS ! 163: ******************* ! 164: ! 165: * Menu: ! 166: ! 167: * Include Files and VMS:: Where the preprocessor looks for the include files. ! 168: * Global Declarations:: How to do globaldef, globalref and globalvalue with ! 169: GNU CC. ! 170: * VMS Misc:: Misc information. ! 171: ! 172: ! 173: File: gcc.info, Node: Include Files and VMS, Next: Global Declarations, Up: VMS ! 174: ! 175: Include Files and VMS 1.1.1.2 root 176: ===================== 177: 1.1.1.4 ! root 178: Due to the differences between the filesystems of Unix and VMS, GNU ! 179: CC attempts to translate file names in `#include' into names that VMS ! 180: will understand. The basic strategy is to prepend a prefix to the ! 181: specification of the include file, convert the whole filename to a VMS ! 182: filename, and then try to open the file. GNU CC tries various prefixes ! 183: one by one until one of them succeeds: ! 184: ! 185: 1. The first prefix is the `GNU_CC_INCLUDE:' logical name: this is ! 186: where GNU C header files are traditionally stored. If you wish to ! 187: store header files in non-standard locations, then you can assign ! 188: the logical `GNU_CC_INCLUDE' to be a search list, where each ! 189: element of the list is suitable for use with a rooted logical. ! 190: ! 191: 2. The next prefix tried is `SYS$SYSROOT:[SYSLIB.]'. This is where ! 192: VAX-C header files are traditionally stored. ! 193: ! 194: 3. If the include file specification by itself is a valid VMS ! 195: filename, the preprocessor then uses this name with no prefix in ! 196: an attempt to open the include file. ! 197: ! 198: 4. If the file specification is not a valid VMS filename (i.e. does ! 199: not contain a device or a directory specifier, and contains a `/' ! 200: character), the preprocessor tries to convert it from Unix syntax ! 201: to VMS syntax. ! 202: ! 203: Conversion works like this: the first directory name becomes a ! 204: device, and the rest of the directories are converted into ! 205: VMS-format directory names. For example, `X11/foobar.h' is ! 206: translated to `X11:[000000]foobar.h' or `X11:foobar.h', whichever ! 207: one can be opened. This strategy allows you to assign a logical ! 208: name to point to the actual location of the header files. ! 209: ! 210: 5. If none of these strategies succeeds, the `#include' fails. ! 211: ! 212: Include directives of the form: ! 213: ! 214: #include foobar ! 215: ! 216: are a common source of incompatibility between VAX-C and GNU CC. VAX-C ! 217: treats this much like a standard `#include <foobar.h>' directive. That ! 218: is incompatible with the ANSI C behavior implemented by GNU CC: to ! 219: expand the name `foobar' as a macro. Macro expansion should eventually ! 220: yield one of the two standard formats for `#include': ! 221: ! 222: #include "FILE" ! 223: #include <FILE> ! 224: ! 225: If you have this problem, the best solution is to modify the source ! 226: to convert the `#include' directives to one of the two standard forms. ! 227: That will work with either compiler. If you want a quick and dirty fix, ! 228: define the file names as macros with the proper expansion, like this: ! 229: ! 230: #define stdio <stdio.h> ! 231: ! 232: This will work, as long as the name doesn't conflict with anything else ! 233: in the program. ! 234: ! 235: Another source of incompatibility is that VAX-C assumes that: ! 236: ! 237: #include "foobar" ! 238: ! 239: is actually asking for the file `foobar.h'. GNU CC does not make this ! 240: assumption, and instead takes what you ask for literally; it tries to ! 241: read the file `foobar'. The best way to avoid this problem is to ! 242: always specify the desired file extension in your include directives. ! 243: ! 244: GNU CC for VMS is distributed with a set of include files that is ! 245: sufficient to compile most general purpose programs. Even though the ! 246: GNU CC distribution does not contain header files to define constants ! 247: and structures for some VMS system-specific functions, there is no ! 248: reason why you cannot use GNU CC with any of these functions. You first ! 249: may have to generate or create header files, either by using the public ! 250: domain utility `UNSDL' (which can be found on a DECUS tape), or by ! 251: extracting the relevant modules from one of the system macro libraries, ! 252: and using an editor to construct a C header file. ! 253: ! 254: A `#include' file name cannot contain a DECNET node name. The ! 255: preprocessor reports an I/O error if you attempt to use a node name, ! 256: whether explicitly, or implicitly via a logical name. ! 257: ! 258: ! 259: File: gcc.info, Node: Global Declarations, Next: VMS Misc, Prev: Include Files and VMS, Up: VMS ! 260: ! 261: Global Declarations and VMS ! 262: =========================== ! 263: ! 264: GNU CC does not provide the `globalref', `globaldef' and ! 265: `globalvalue' keywords of VAX-C. You can get the same effect with an ! 266: obscure feature of GAS, the GNU assembler. (This requires GAS version ! 267: 1.39 or later.) The following macros allow you to use this feature in ! 268: a fairly natural way: ! 269: ! 270: #ifdef __GNUC__ ! 271: #define GLOBALREF(TYPE,NAME) \ ! 272: TYPE NAME \ ! 273: asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME) ! 274: #define GLOBALDEF(TYPE,NAME,VALUE) \ ! 275: TYPE NAME \ ! 276: asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME) \ ! 277: = VALUE ! 278: #define GLOBALVALUEREF(TYPE,NAME) \ ! 279: const TYPE NAME[1] \ ! 280: asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME) ! 281: #define GLOBALVALUEDEF(TYPE,NAME,VALUE) \ ! 282: const TYPE NAME[1] \ ! 283: asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME) \ ! 284: = {VALUE} ! 285: #else ! 286: #define GLOBALREF(TYPE,NAME) \ ! 287: globalref TYPE NAME ! 288: #define GLOBALDEF(TYPE,NAME,VALUE) \ ! 289: globaldef TYPE NAME = VALUE ! 290: #define GLOBALVALUEDEF(TYPE,NAME,VALUE) \ ! 291: globalvalue TYPE NAME = VALUE ! 292: #define GLOBALVALUEREF(TYPE,NAME) \ ! 293: globalvalue TYPE NAME ! 294: #endif ! 295: ! 296: (The `_$$PsectAttributes_GLOBALSYMBOL' prefix at the start of the name ! 297: is removed by the assembler, after it has modified the attributes of ! 298: the symbol). These macros are provided in the VMS binaries ! 299: distribution in a header file `GNU_HACKS.H'. An example of the usage ! 300: is: ! 301: ! 302: GLOBALREF (int, ijk); ! 303: GLOBALDEF (int, jkl, 0); ! 304: ! 305: The macros `GLOBALREF' and `GLOBALDEF' cannot be used ! 306: straightforwardly for arrays, since there is no way to insert the array ! 307: dimension into the declaration at the right place. However, you can ! 308: declare an array with these macros if you first define a typedef for the ! 309: array type, like this: ! 310: ! 311: typedef int intvector[10]; ! 312: GLOBALREF (intvector, foo); ! 313: ! 314: Array and structure initializers will also break the macros; you can ! 315: define the initializer to be a macro of its own, or you can expand the ! 316: `GLOBALDEF' macro by hand. You may find a case where you wish to use ! 317: the `GLOBALDEF' macro with a large array, but you are not interested in ! 318: explicitly initializing each element of the array. In such cases you ! 319: can use an initializer like: `{0,}', which will initialize the entire ! 320: array to `0'. ! 321: ! 322: A shortcoming of this implementation is that a variable declared with ! 323: `GLOBALVALUEREF' or `GLOBALVALUEDEF' is always an array. For example, ! 324: the declaration: ! 325: ! 326: GLOBALVALUEREF(int, ijk); ! 327: ! 328: declares the variable `ijk' as an array of type `int [1]'. This is done ! 329: because a globalvalue is actually a constant; its "value" is what the ! 330: linker would normally consider an address. That is not how an integer ! 331: value works in C, but it is how an array works. So treating the symbol ! 332: as an array name gives consistent results--with the exception that the ! 333: value seems to have the wrong type. *Don't try to access an element of ! 334: the array.* It doesn't have any elements. The array "address" may not ! 335: be the address of actual storage. ! 336: ! 337: The fact that the symbol is an array may lead to warnings where the ! 338: variable is used. Insert type casts to avoid the warnings. Here is an ! 339: example; it takes advantage of the ANSI C feature allowing macros that ! 340: expand to use the same name as the macro itself. ! 341: ! 342: GLOBALVALUEREF (int, ss$_normal); ! 343: GLOBALVALUEDEF (int, xyzzy,123); ! 344: #ifdef __GNUC__ ! 345: #define ss$_normal ((int) ss$_normal) ! 346: #define xyzzy ((int) xyzzy) ! 347: #endif ! 348: ! 349: Don't use `globaldef' or `globalref' with a variable whose type is ! 350: an enumeration type; this is not implemented. Instead, make the ! 351: variable an integer, and use a `globalvaluedef' for each of the ! 352: enumeration values. An example of this would be: ! 353: ! 354: #ifdef __GNUC__ ! 355: GLOBALDEF (int, color, 0); ! 356: GLOBALVALUEDEF (int, RED, 0); ! 357: GLOBALVALUEDEF (int, BLUE, 1); ! 358: GLOBALVALUEDEF (int, GREEN, 3); ! 359: #else ! 360: enum globaldef color {RED, BLUE, GREEN = 3}; ! 361: #endif ! 362: ! 363: ! 364: File: gcc.info, Node: VMS Misc, Prev: Global Declarations, Up: VMS ! 365: ! 366: Other VMS Issues ! 367: ================ ! 368: ! 369: GNU CC automatically arranges for `main' to return 1 by default if ! 370: you fail to specify an explicit return value. This will be interpreted ! 371: by VMS as a status code indicating a normal successful completion. ! 372: Version 1 of GNU CC did not provide this default. ! 373: ! 374: GNU CC on VMS works only with the GNU assembler, GAS. You need ! 375: version 1.37 or later of GAS in order to produce value debugging ! 376: information for the VMS debugger. Use the ordinary VMS linker with the ! 377: object files produced by GAS. ! 378: ! 379: Under previous versions of GNU CC, the generated code would ! 380: occasionally give strange results when linked to the sharable `VAXCRTL' ! 381: library. Now this should work. ! 382: ! 383: A caveat for use of `const' global variables: the `const' modifier ! 384: must be specified in every external declaration of the variable in all ! 385: of the source files that use that variable. Otherwise the linker will ! 386: issue warnings about conflicting attributes for the variable. Your ! 387: program will still work despite the warnings, but the variable will be ! 388: placed in writable storage. ! 389: ! 390: Although the VMS linker does distinguish between upper and lower case ! 391: letters in global symbols, most VMS compilers convert all such symbols ! 392: into upper case and most run-time library routines also have upper case ! 393: names. To be able to reliably call such routines, GNU CC (by means of ! 394: the assembler GAS) converts global symbols into upper case like other ! 395: VMS compilers. However, since the usual practice in C is to distinguish ! 396: case, GNU CC (via GAS) tries to preserve usual C behavior by augmenting ! 397: each name that is not all lower case. This means truncating the name ! 398: to at most 23 characters and then adding more characters at the end ! 399: which encode the case pattern of those 23. Names which contain at ! 400: least one dollar sign are an exception; they are converted directly into ! 401: upper case without augmentation. ! 402: ! 403: Name augmentation yields bad results for programs that use ! 404: precompiled libraries (such as Xlib) which were generated by another ! 405: compiler. You can use the compiler option `/NOCASE_HACK' to inhibit ! 406: augmentation; it makes external C functions and variables ! 407: case-independent as is usual on VMS. Alternatively, you could write ! 408: all references to the functions and variables in such libraries using ! 409: lower case; this will work on VMS, but is not portable to other ! 410: systems. The compiler option `/NAMES' also provides control over ! 411: global name handling. ! 412: ! 413: Function and variable names are handled somewhat differently with GNU ! 414: C++. The GNU C++ compiler performs "name mangling" on function names, ! 415: which means that it adds information to the function name to describe ! 416: the data types of the arguments that the function takes. One result of ! 417: this is that the name of a function can become very long. Since the VMS ! 418: linker only recognizes the first 31 characters in a name, special ! 419: action is taken to ensure that each function and variable has a unique ! 420: name that can be represented in 31 characters. ! 421: ! 422: If the name (plus a name augmentation, if required) is less than 32 ! 423: characters in length, then no special action is performed. If the name ! 424: is longer than 31 characters, the assembler (GAS) will generate a hash ! 425: string based upon the function name, truncate the function name to 23 ! 426: characters, and append the hash string to the truncated name. If the ! 427: `/VERBOSE' compiler option is used, the assembler will print both the ! 428: full and truncated names of each symbol that is truncated. ! 429: ! 430: The `/NOCASE_HACK' compiler option should not be used when you are ! 431: compiling programs that use libg++. libg++ has several instances of ! 432: objects (i.e. `Filebuf' and `filebuf') which become indistinguishable ! 433: in a case-insensitive environment. This leads to cases where you need ! 434: to inhibit augmentation selectively (if you were using libg++ and Xlib ! 435: in the same program, for example). There is no special feature for ! 436: doing this, but you can get the result by defining a macro for each ! 437: mixed case symbol for which you wish to inhibit augmentation. The ! 438: macro should expand into the lower case equivalent of itself. For ! 439: example: ! 440: ! 441: #define StuDlyCapS studlycaps ! 442: ! 443: These macro definitions can be placed in a header file to minimize ! 444: the number of changes to your source code. ! 445: ! 446: ! 447: File: gcc.info, Node: Portability, Next: Interface, Prev: VMS, Up: Top ! 448: ! 449: GNU CC and Portability ! 450: ********************** ! 451: ! 452: The main goal of GNU CC was to make a good, fast compiler for ! 453: machines in the class that the GNU system aims to run on: 32-bit ! 454: machines that address 8-bit bytes and have several general registers. ! 455: Elegance, theoretical power and simplicity are only secondary. ! 456: ! 457: GNU CC gets most of the information about the target machine from a ! 458: machine description which gives an algebraic formula for each of the ! 459: machine's instructions. This is a very clean way to describe the ! 460: target. But when the compiler needs information that is difficult to ! 461: express in this fashion, I have not hesitated to define an ad-hoc ! 462: parameter to the machine description. The purpose of portability is to ! 463: reduce the total work needed on the compiler; it was not of interest ! 464: for its own sake. ! 465: ! 466: GNU CC does not contain machine dependent code, but it does contain ! 467: code that depends on machine parameters such as endianness (whether the ! 468: most significant byte has the highest or lowest address of the bytes in ! 469: a word) and the availability of autoincrement addressing. In the ! 470: RTL-generation pass, it is often necessary to have multiple strategies ! 471: for generating code for a particular kind of syntax tree, strategies ! 472: that are usable for different combinations of parameters. Often I have ! 473: not tried to address all possible cases, but only the common ones or ! 474: only the ones that I have encountered. As a result, a new target may ! 475: require additional strategies. You will know if this happens because ! 476: the compiler will call `abort'. Fortunately, the new strategies can be ! 477: added in a machine-independent fashion, and will affect only the target ! 478: machines that need them. ! 479: ! 480: ! 481: File: gcc.info, Node: Interface, Next: Passes, Prev: Portability, Up: Top ! 482: ! 483: Interfacing to GNU CC Output ! 484: **************************** ! 485: ! 486: GNU CC is normally configured to use the same function calling ! 487: convention normally in use on the target system. This is done with the ! 488: machine-description macros described (*note Target Macros::.). ! 489: ! 490: However, returning of structure and union values is done differently ! 491: on some target machines. As a result, functions compiled with PCC ! 492: returning such types cannot be called from code compiled with GNU CC, ! 493: and vice versa. This does not cause trouble often because few Unix ! 494: library routines return structures or unions. ! 495: ! 496: GNU CC code returns structures and unions that are 1, 2, 4 or 8 bytes ! 497: long in the same registers used for `int' or `double' return values. ! 498: (GNU CC typically allocates variables of such types in registers also.) ! 499: Structures and unions of other sizes are returned by storing them into ! 500: an address passed by the caller (usually in a register). The ! 501: machine-description macros `STRUCT_VALUE' and `STRUCT_INCOMING_VALUE' ! 502: tell GNU CC where to pass this address. ! 503: ! 504: By contrast, PCC on most target machines returns structures and ! 505: unions of any size by copying the data into an area of static storage, ! 506: and then returning the address of that storage as if it were a pointer ! 507: value. The caller must copy the data from that memory area to the place ! 508: where the value is wanted. This is slower than the method used by GNU ! 509: CC, and fails to be reentrant. ! 510: ! 511: On some target machines, such as RISC machines and the 80386, the ! 512: standard system convention is to pass to the subroutine the address of ! 513: where to return the value. On these machines, GNU CC has been ! 514: configured to be compatible with the standard compiler, when this method ! 515: is used. It may not be compatible for structures of 1, 2, 4 or 8 bytes. ! 516: ! 517: GNU CC uses the system's standard convention for passing arguments. ! 518: On some machines, the first few arguments are passed in registers; in ! 519: others, all are passed on the stack. It would be possible to use ! 520: registers for argument passing on any machine, and this would probably ! 521: result in a significant speedup. But the result would be complete ! 522: incompatibility with code that follows the standard convention. So this ! 523: change is practical only if you are switching to GNU CC as the sole C ! 524: compiler for the system. We may implement register argument passing on ! 525: certain machines once we have a complete GNU system so that we can ! 526: compile the libraries with GNU CC. ! 527: ! 528: On some machines (particularly the Sparc), certain types of arguments ! 529: are passed "by invisible reference". This means that the value is ! 530: stored in memory, and the address of the memory location is passed to ! 531: the subroutine. ! 532: ! 533: If you use `longjmp', beware of automatic variables. ANSI C says ! 534: that automatic variables that are not declared `volatile' have undefined ! 535: values after a `longjmp'. And this is all GNU CC promises to do, ! 536: because it is very difficult to restore register variables correctly, ! 537: and one of GNU CC's features is that it can put variables in registers ! 538: without your asking it to. ! 539: ! 540: If you want a variable to be unaltered by `longjmp', and you don't ! 541: want to write `volatile' because old C compilers don't accept it, just ! 542: take the address of the variable. If a variable's address is ever ! 543: taken, even if just to compute it and ignore it, then the variable ! 544: cannot go in a register: ! 545: ! 546: { ! 547: int careful; ! 548: &careful; ! 549: ... ! 550: } ! 551: ! 552: Code compiled with GNU CC may call certain library routines. Most of ! 553: them handle arithmetic for which there are no instructions. This ! 554: includes multiply and divide on some machines, and floating point ! 555: operations on any machine for which floating point support is disabled ! 556: with `-msoft-float'. Some standard parts of the C library, such as ! 557: `bcopy' or `memcpy', are also called automatically. The usual function ! 558: call interface is used for calling the library routines. ! 559: ! 560: These library routines should be defined in the library `libgcc.a', ! 561: which GNU CC automatically searches whenever it links a program. On ! 562: machines that have multiply and divide instructions, if hardware ! 563: floating point is in use, normally `libgcc.a' is not needed, but it is ! 564: searched just in case. ! 565: ! 566: Each arithmetic function is defined in `libgcc1.c' to use the ! 567: corresponding C arithmetic operator. As long as the file is compiled ! 568: with another C compiler, which supports all the C arithmetic operators, ! 569: this file will work portably. However, `libgcc1.c' does not work if ! 570: compiled with GNU CC, because each arithmetic function would compile ! 571: into a call to itself! ! 572: ! 573: ! 574: File: gcc.info, Node: Passes, Next: RTL, Prev: Interface, Up: Top ! 575: ! 576: Passes and Files of the Compiler ! 577: ******************************** ! 578: ! 579: The overall control structure of the compiler is in `toplev.c'. This ! 580: file is responsible for initialization, decoding arguments, opening and ! 581: closing files, and sequencing the passes. ! 582: ! 583: The parsing pass is invoked only once, to parse the entire input. ! 584: The RTL intermediate code for a function is generated as the function ! 585: is parsed, a statement at a time. Each statement is read in as a ! 586: syntax tree and then converted to RTL; then the storage for the tree ! 587: for the statement is reclaimed. Storage for types (and the expressions ! 588: for their sizes), declarations, and a representation of the binding ! 589: contours and how they nest, remain until the function is finished being ! 590: compiled; these are all needed to output the debugging information. ! 591: ! 592: Each time the parsing pass reads a complete function definition or ! 593: top-level declaration, it calls the function `rest_of_compilation' or ! 594: `rest_of_decl_compilation' in `toplev.c', which are responsible for all ! 595: further processing necessary, ending with output of the assembler ! 596: language. All other compiler passes run, in sequence, within ! 597: `rest_of_compilation'. When that function returns from compiling a ! 598: function definition, the storage used for that function definition's ! 599: compilation is entirely freed, unless it is an inline function (*note ! 600: Inline::.). ! 601: ! 602: Here is a list of all the passes of the compiler and their source ! 603: files. Also included is a description of where debugging dumps can be ! 604: requested with `-d' options. ! 605: ! 606: * Parsing. This pass reads the entire text of a function definition, ! 607: constructing partial syntax trees. This and RTL generation are no ! 608: longer truly separate passes (formerly they were), but it is ! 609: easier to think of them as separate. ! 610: ! 611: The tree representation does not entirely follow C syntax, because ! 612: it is intended to support other languages as well. ! 613: ! 614: Language-specific data type analysis is also done in this pass, ! 615: and every tree node that represents an expression has a data type ! 616: attached. Variables are represented as declaration nodes. ! 617: ! 618: Constant folding and some arithmetic simplifications are also done ! 619: during this pass. ! 620: ! 621: The language-independent source files for parsing are ! 622: `stor-layout.c', `fold-const.c', and `tree.c'. There are also ! 623: header files `tree.h' and `tree.def' which define the format of ! 624: the tree representation. ! 625: ! 626: The source files for parsing C are `c-parse.y', `c-decl.c', ! 627: `c-typeck.c', `c-convert.c', `c-lang.c', and `c-aux-info.c' along ! 628: with header files `c-lex.h', and `c-tree.h'. ! 629: ! 630: The source files for parsing C++ are `cp-parse.y', `cp-class.c', ! 631: `cp-cvt.c', `cp-decl.c', `cp-decl2.c', `cp-dem.c', `cp-except.c', ! 632: `cp-expr.c', `cp-init.c', `cp-lex.c', `cp-method.c', `cp-ptree.c', ! 633: `cp-search.c', `cp-tree.c', `cp-type2.c', and `cp-typeck.c', along ! 634: with header files `cp-tree.def', `cp-tree.h', and `cp-decl.h'. ! 635: ! 636: The special source files for parsing Objective C are ! 637: `objc-parse.y', `objc-actions.c', `objc-tree.def', and ! 638: `objc-actions.h'. Certain C-specific files are used for this as ! 639: well. ! 640: ! 641: The file `c-common.c' is also used for all of the above languages. ! 642: ! 643: * RTL generation. This is the conversion of syntax tree into RTL ! 644: code. It is actually done statement-by-statement during parsing, ! 645: but for most purposes it can be thought of as a separate pass. ! 646: ! 647: This is where the bulk of target-parameter-dependent code is found, ! 648: since often it is necessary for strategies to apply only when ! 649: certain standard kinds of instructions are available. The purpose ! 650: of named instruction patterns is to provide this information to ! 651: the RTL generation pass. ! 652: ! 653: Optimization is done in this pass for `if'-conditions that are ! 654: comparisons, boolean operations or conditional expressions. Tail ! 655: recursion is detected at this time also. Decisions are made about ! 656: how best to arrange loops and how to output `switch' statements. ! 657: ! 658: The source files for RTL generation include `stmt.c', ! 659: `function.c', `expr.c', `calls.c', `explow.c', `expmed.c', ! 660: `optabs.c' and `emit-rtl.c'. Also, the file `insn-emit.c', ! 661: generated from the machine description by the program `genemit', ! 662: is used in this pass. The header file `expr.h' is used for ! 663: communication within this pass. ! 664: ! 665: The header files `insn-flags.h' and `insn-codes.h', generated from ! 666: the machine description by the programs `genflags' and `gencodes', ! 667: tell this pass which standard names are available for use and ! 668: which patterns correspond to them. ! 669: ! 670: Aside from debugging information output, none of the following ! 671: passes refers to the tree structure representation of the function ! 672: (only part of which is saved). ! 673: ! 674: The decision of whether the function can and should be expanded ! 675: inline in its subsequent callers is made at the end of rtl ! 676: generation. The function must meet certain criteria, currently ! 677: related to the size of the function and the types and number of ! 678: parameters it has. Note that this function may contain loops, ! 679: recursive calls to itself (tail-recursive functions can be ! 680: inlined!), gotos, in short, all constructs supported by GNU CC. ! 681: The file `integrate.c' contains the code to save a function's rtl ! 682: for later inlining and to inline that rtl when the function is ! 683: called. The header file `integrate.h' is also used for this ! 684: purpose. ! 685: ! 686: The option `-dr' causes a debugging dump of the RTL code after ! 687: this pass. This dump file's name is made by appending `.rtl' to ! 688: the input file name. ! 689: ! 690: * Jump optimization. This pass simplifies jumps to the following ! 691: instruction, jumps across jumps, and jumps to jumps. It deletes ! 692: unreferenced labels and unreachable code, except that unreachable ! 693: code that contains a loop is not recognized as unreachable in this ! 694: pass. (Such loops are deleted later in the basic block analysis.) ! 695: It also converts some code originally written with jumps into ! 696: sequences of instructions that directly set values from the ! 697: results of comparisons, if the machine has such instructions. ! 698: ! 699: Jump optimization is performed two or three times. The first time ! 700: is immediately following RTL generation. The second time is after ! 701: CSE, but only if CSE says repeated jump optimization is needed. ! 702: The last time is right before the final pass. That time, ! 703: cross-jumping and deletion of no-op move instructions are done ! 704: together with the optimizations described above. ! 705: ! 706: The source file of this pass is `jump.c'. ! 707: ! 708: The option `-dj' causes a debugging dump of the RTL code after ! 709: this pass is run for the first time. This dump file's name is ! 710: made by appending `.jump' to the input file name. ! 711: ! 712: * Register scan. This pass finds the first and last use of each ! 713: register, as a guide for common subexpression elimination. Its ! 714: source is in `regclass.c'. ! 715: ! 716: * Jump threading. This pass detects a condition jump that branches ! 717: to an identical or inverse test. Such jumps can be `threaded' ! 718: through the second conditional test. The source code for this ! 719: pass is in `jump.c'. This optimization is only performed if ! 720: `-fthread-jumps' is enabled. ! 721: ! 722: * Common subexpression elimination. This pass also does constant ! 723: propagation. Its source file is `cse.c'. If constant propagation ! 724: causes conditional jumps to become unconditional or to become ! 725: no-ops, jump optimization is run again when CSE is finished. ! 726: ! 727: The option `-ds' causes a debugging dump of the RTL code after ! 728: this pass. This dump file's name is made by appending `.cse' to ! 729: the input file name. ! 730: ! 731: * Loop optimization. This pass moves constant expressions out of ! 732: loops, and optionally does strength-reduction and loop unrolling ! 733: as well. Its source files are `loop.c' and `unroll.c', plus the ! 734: header `loop.h' used for communication between them. Loop ! 735: unrolling uses some functions in `integrate.c' and the header ! 736: `integrate.h'. ! 737: ! 738: The option `-dL' causes a debugging dump of the RTL code after ! 739: this pass. This dump file's name is made by appending `.loop' to ! 740: the input file name. ! 741: ! 742: * If `-frerun-cse-after-loop' was enabled, a second common ! 743: subexpression elimination pass is performed after the loop ! 744: optimization pass. Jump threading is also done again at this time ! 745: if it was specified. ! 746: ! 747: The option `-dt' causes a debugging dump of the RTL code after ! 748: this pass. This dump file's name is made by appending `.cse2' to ! 749: the input file name. ! 750: ! 751: * Stupid register allocation is performed at this point in a ! 752: nonoptimizing compilation. It does a little data flow analysis as ! 753: well. When stupid register allocation is in use, the next pass ! 754: executed is the reloading pass; the others in between are skipped. ! 755: The source file is `stupid.c'. ! 756: ! 757: * Data flow analysis (`flow.c'). This pass divides the program into ! 758: basic blocks (and in the process deletes unreachable loops); then ! 759: it computes which pseudo-registers are live at each point in the ! 760: program, and makes the first instruction that uses a value point at ! 761: the instruction that computed the value. ! 762: ! 763: This pass also deletes computations whose results are never used, ! 764: and combines memory references with add or subtract instructions ! 765: to make autoincrement or autodecrement addressing. ! 766: ! 767: The option `-df' causes a debugging dump of the RTL code after ! 768: this pass. This dump file's name is made by appending `.flow' to ! 769: the input file name. If stupid register allocation is in use, this ! 770: dump file reflects the full results of such allocation. ! 771: ! 772: * Instruction combination (`combine.c'). This pass attempts to ! 773: combine groups of two or three instructions that are related by ! 774: data flow into single instructions. It combines the RTL ! 775: expressions for the instructions by substitution, simplifies the ! 776: result using algebra, and then attempts to match the result ! 777: against the machine description. ! 778: ! 779: The option `-dc' causes a debugging dump of the RTL code after ! 780: this pass. This dump file's name is made by appending `.combine' ! 781: to the input file name. ! 782: ! 783: * Instruction scheduling (`sched.c'). This pass looks for ! 784: instructions whose output will not be available by the time that ! 785: it is used in subsequent instructions. (Memory loads and floating ! 786: point instructions often have this behavior on RISC machines). It ! 787: re-orders instructions within a basic block to try to separate the ! 788: definition and use of items that otherwise would cause pipeline ! 789: stalls. ! 790: ! 791: Instruction scheduling is performed twice. The first time is ! 792: immediately after instruction combination and the second is ! 793: immediately after reload. ! 794: ! 795: The option `-dS' causes a debugging dump of the RTL code after this ! 796: pass is run for the first time. The dump file's name is made by ! 797: appending `.sched' to the input file name. ! 798: ! 799: * Register class preferencing. The RTL code is scanned to find out ! 800: which register class is best for each pseudo register. The source ! 801: file is `regclass.c'. ! 802: ! 803: * Local register allocation (`local-alloc.c'). This pass allocates ! 804: hard registers to pseudo registers that are used only within one ! 805: basic block. Because the basic block is linear, it can use fast ! 806: and powerful techniques to do a very good job. ! 807: ! 808: The option `-dl' causes a debugging dump of the RTL code after ! 809: this pass. This dump file's name is made by appending `.lreg' to ! 810: the input file name. ! 811: ! 812: * Global register allocation (`global.c'). This pass allocates hard ! 813: registers for the remaining pseudo registers (those whose life ! 814: spans are not contained in one basic block). ! 815: ! 816: * Reloading. This pass renumbers pseudo registers with the hardware ! 817: registers numbers they were allocated. Pseudo registers that did ! 818: not get hard registers are replaced with stack slots. Then it ! 819: finds instructions that are invalid because a value has failed to ! 820: end up in a register, or has ended up in a register of the wrong ! 821: kind. It fixes up these instructions by reloading the ! 822: problematical values temporarily into registers. Additional ! 823: instructions are generated to do the copying. ! 824: ! 825: The reload pass also optionally eliminates the frame pointer and ! 826: inserts instructions to save and restore call-clobbered registers ! 827: around calls. ! 828: ! 829: Source files are `reload.c' and `reload1.c', plus the header ! 830: `reload.h' used for communication between them. ! 831: ! 832: The option `-dg' causes a debugging dump of the RTL code after ! 833: this pass. This dump file's name is made by appending `.greg' to ! 834: the input file name. ! 835: ! 836: * Instruction scheduling is repeated here to try to avoid pipeline ! 837: stalls due to memory loads generated for spilled pseudo registers. ! 838: ! 839: The option `-dR' causes a debugging dump of the RTL code after ! 840: this pass. This dump file's name is made by appending `.sched2' ! 841: to the input file name. ! 842: ! 843: * Jump optimization is repeated, this time including cross-jumping ! 844: and deletion of no-op move instructions. ! 845: ! 846: The option `-dJ' causes a debugging dump of the RTL code after ! 847: this pass. This dump file's name is made by appending `.jump2' to ! 848: the input file name. ! 849: ! 850: * Delayed branch scheduling. This optional pass attempts to find ! 851: instructions that can go into the delay slots of other ! 852: instructions, usually jumps and calls. The source file name is ! 853: `reorg.c'. ! 854: ! 855: The option `-dd' causes a debugging dump of the RTL code after ! 856: this pass. This dump file's name is made by appending `.dbr' to ! 857: the input file name. ! 858: ! 859: * Conversion from usage of some hard registers to usage of a register ! 860: stack may be done at this point. Currently, this is supported only ! 861: for the floating-point registers of the Intel 80387 coprocessor. ! 862: The source file name is `reg-stack.c'. ! 863: ! 864: The options `-dk' causes a debugging dump of the RTL code after ! 865: this pass. This dump file's name is made by appending `.stack' to ! 866: the input file name. ! 867: ! 868: * Final. This pass outputs the assembler code for the function. It ! 869: is also responsible for identifying spurious test and compare ! 870: instructions. Machine-specific peephole optimizations are ! 871: performed at the same time. The function entry and exit sequences ! 872: are generated directly as assembler code in this pass; they never ! 873: exist as RTL. ! 874: ! 875: The source files are `final.c' plus `insn-output.c'; the latter is ! 876: generated automatically from the machine description by the tool ! 877: `genoutput'. The header file `conditions.h' is used for ! 878: communication between these files. ! 879: ! 880: * Debugging information output. This is run after final because it ! 881: must output the stack slot offsets for pseudo registers that did ! 882: not get hard registers. Source files are `dbxout.c' for DBX ! 883: symbol table format, `sdbout.c' for SDB symbol table format, and ! 884: `dwarfout.c' for DWARF symbol table format. ! 885: ! 886: Some additional files are used by all or many passes: ! 887: ! 888: * Every pass uses `machmode.def' and `machmode.h' which define the ! 889: machine modes. ! 890: ! 891: * Several passes use `real.h', which defines the default ! 892: representation of floating point constants and how to operate on ! 893: them. ! 894: ! 895: * All the passes that work with RTL use the header files `rtl.h' and ! 896: `rtl.def', and subroutines in file `rtl.c'. The tools `gen*' also ! 897: use these files to read and work with the machine description RTL. ! 898: ! 899: * Several passes refer to the header file `insn-config.h' which ! 900: contains a few parameters (C macro definitions) generated ! 901: automatically from the machine description RTL by the tool ! 902: `genconfig'. ! 903: ! 904: * Several passes use the instruction recognizer, which consists of ! 905: `recog.c' and `recog.h', plus the files `insn-recog.c' and ! 906: `insn-extract.c' that are generated automatically from the machine ! 907: description by the tools `genrecog' and `genextract'. ! 908: ! 909: * Several passes use the header files `regs.h' which defines the ! 910: information recorded about pseudo register usage, and ! 911: `basic-block.h' which defines the information recorded about basic ! 912: blocks. ! 913: ! 914: * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector ! 915: with a bit for each hard register, and some macros to manipulate ! 916: it. This type is just `int' if the machine has few enough hard ! 917: registers; otherwise it is an array of `int' and some of the ! 918: macros expand into loops. ! 919: ! 920: * Several passes use instruction attributes. A definition of the ! 921: attributes defined for a particular machine is in file ! 922: `insn-attr.h', which is generated from the machine description by ! 923: the program `genattr'. The file `insn-attrtab.c' contains ! 924: subroutines to obtain the attribute values for insns. It is ! 925: generated from the machine description by the program `genattrtab'. ! 926: ! 927: ! 928: File: gcc.info, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top ! 929: ! 930: RTL Representation ! 931: ****************** ! 932: ! 933: Most of the work of the compiler is done on an intermediate ! 934: representation called register transfer language. In this language, ! 935: the instructions to be output are described, pretty much one by one, in ! 936: an algebraic form that describes what the instruction does. ! 937: ! 938: RTL is inspired by Lisp lists. It has both an internal form, made ! 939: up of structures that point at other structures, and a textual form ! 940: that is used in the machine description and in printed debugging dumps. ! 941: The textual form uses nested parentheses to indicate the pointers in ! 942: the internal form. ! 943: ! 944: * Menu: ! 945: ! 946: * RTL Objects:: Expressions vs vectors vs strings vs integers. ! 947: * Accessors:: Macros to access expression operands or vector elts. ! 948: * Flags:: Other flags in an RTL expression. ! 949: * Machine Modes:: Describing the size and format of a datum. ! 950: * Constants:: Expressions with constant values. ! 951: * Regs and Memory:: Expressions representing register contents or memory. ! 952: * Arithmetic:: Expressions representing arithmetic on other expressions. ! 953: * Comparisons:: Expressions representing comparison of expressions. ! 954: * Bit Fields:: Expressions representing bit-fields in memory or reg. ! 955: * Conversions:: Extending, truncating, floating or fixing. ! 956: * RTL Declarations:: Declaring volatility, constancy, etc. ! 957: * Side Effects:: Expressions for storing in registers, etc. ! 958: * Incdec:: Embedded side-effects for autoincrement addressing. ! 959: * Assembler:: Representing `asm' with operands. ! 960: * Insns:: Expression types for entire insns. ! 961: * Calls:: RTL representation of function call insns. ! 962: * Sharing:: Some expressions are unique; others *must* be copied. ! 963: ! 964: ! 965: File: gcc.info, Node: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL ! 966: ! 967: RTL Object Types ! 968: ================ ! 969: ! 970: RTL uses five kinds of objects: expressions, integers, wide integers, ! 971: strings and vectors. Expressions are the most important ones. An RTL ! 972: expression ("RTX", for short) is a C structure, but it is usually ! 973: referred to with a pointer; a type that is given the typedef name `rtx'. ! 974: ! 975: An integer is simply an `int'; their written form uses decimal ! 976: digits. A wide integer is an integral object whose type is ! 977: `HOST_WIDE_INT' (*note Config::.); their written form used decimal ! 978: digits. ! 979: ! 980: A string is a sequence of characters. In core it is represented as a ! 981: `char *' in usual C fashion, and it is written in C syntax as well. ! 982: However, strings in RTL may never be null. If you write an empty ! 983: string in a machine description, it is represented in core as a null ! 984: pointer rather than as a pointer to a null character. In certain ! 985: contexts, these null pointers instead of strings are valid. Within RTL ! 986: code, strings are most commonly found inside `symbol_ref' expressions, ! 987: but they appear in other contexts in the RTL expressions that make up ! 988: machine descriptions. ! 989: ! 990: A vector contains an arbitrary number of pointers to expressions. ! 991: The number of elements in the vector is explicitly present in the ! 992: vector. The written form of a vector consists of square brackets ! 993: (`[...]') surrounding the elements, in sequence and with whitespace ! 994: separating them. Vectors of length zero are not created; null pointers ! 995: are used instead. ! 996: ! 997: Expressions are classified by "expression codes" (also called RTX ! 998: codes). The expression code is a name defined in `rtl.def', which is ! 999: also (in upper case) a C enumeration constant. The possible expression ! 1000: codes and their meanings are machine-independent. The code of an RTX ! 1001: can be extracted with the macro `GET_CODE (X)' and altered with ! 1002: `PUT_CODE (X, NEWCODE)'. ! 1003: ! 1004: The expression code determines how many operands the expression ! 1005: contains, and what kinds of objects they are. In RTL, unlike Lisp, you ! 1006: cannot tell by looking at an operand what kind of object it is. ! 1007: Instead, you must know from its context--from the expression code of ! 1008: the containing expression. For example, in an expression of code ! 1009: `subreg', the first operand is to be regarded as an expression and the ! 1010: second operand as an integer. In an expression of code `plus', there ! 1011: are two operands, both of which are to be regarded as expressions. In ! 1012: a `symbol_ref' expression, there is one operand, which is to be ! 1013: regarded as a string. ! 1014: ! 1015: Expressions are written as parentheses containing the name of the ! 1016: expression type, its flags and machine mode if any, and then the ! 1017: operands of the expression (separated by spaces). ! 1018: ! 1019: Expression code names in the `md' file are written in lower case, ! 1020: but when they appear in C code they are written in upper case. In this ! 1021: manual, they are shown as follows: `const_int'. ! 1022: ! 1023: In a few contexts a null pointer is valid where an expression is ! 1024: normally wanted. The written form of this is `(nil)'. 1.1 root 1025: 1026:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.