![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to internals-2 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to internals-2 CVS log | Up to [GCC 1.x] / gcc |
1.1.1.4 ! root 1: Info file internals, produced by Makeinfo, -*- Text -*- from input ! 2: file internals.texinfo. ! 3: ! 4: This file documents the internals of the GNU compiler. ! 5: ! 6: Copyright (C) 1988 Free Software Foundation, Inc. ! 7: ! 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. ! 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 CC General Public License'' is ! 15: included exactly as in the original, and provided that the entire ! 16: resulting derived work is distributed under the terms of a permission ! 17: notice 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 CC 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: ! 27: ! 28: File: internals, Node: Incompatibilities, Next: Extensions, Prev: Trouble, Up: Top ! 29: ! 30: Incompatibilities of GNU CC ! 31: *************************** ! 32: ! 33: There are several noteworthy incompatibilities between GNU C and most ! 34: existing (non-ANSI) versions of C. ! 35: ! 36: Ultimately our intention is that the `-traditional' option will ! 37: eliminate most of these incompatibilities by telling GNU C to behave ! 38: like the other C compilers. ! 39: ! 40: * GNU CC normally makes string constants read-only. If several ! 41: identical-looking string constants are used, GNU CC stores only ! 42: one copy of the string. ! 43: ! 44: One consequence is that you cannot call `mktemp' with a string ! 45: constant argument. The function `mktemp' always alters the ! 46: string its argument points to. ! 47: ! 48: Another consequence is that `sscanf' does not work on some ! 49: systems when passed a string constant as its format control ! 50: string. This is because `sscanf' incorrectly tries to write ! 51: into the string constant. ! 52: ! 53: The best solution to these problems is to change the program to ! 54: use `char'-array variables with initialization strings for these ! 55: purposes instead of string constants. But if this is not ! 56: possible, you can use the `-fwritable-strings' flag, which ! 57: directs GNU CC to handle string constants the same way most C ! 58: compilers do. ! 59: ! 60: * GNU CC does not substitute macro arguments when they appear ! 61: inside of string constants. For example, the following macro in ! 62: GNU CC ! 63: ! 64: #define foo(a) "a" ! 65: ! 66: will produce output `"a"' regardless of what the argument A is. ! 67: ! 68: The `-traditional' option directs GNU CC to handle such cases ! 69: (among others) in the old-fashioned (non-ANSI) fashion. ! 70: ! 71: * When you use `setjmp' and `longjmp', the only automatic ! 72: variables guaranteed to remain valid are those declared ! 73: `volatile'. This is a consequence of automatic register ! 74: allocation. Consider this function: ! 75: ! 76: jmp_buf j; ! 77: ! 78: foo () ! 79: { ! 80: int a, b; ! 81: ! 82: a = fun1 (); ! 83: if (setjmp (j)) ! 84: return a; ! 85: ! 86: a = fun2 (); ! 87: /* `longjmp (j)' may be occur in `fun3'. */ ! 88: return a + fun3 (); ! 89: } ! 90: ! 91: Here `a' may or may not be restored to its first value when the ! 92: `longjmp' occurs. If `a' is allocated in a register, then its ! 93: first value is restored; otherwise, it keeps the last value ! 94: stored in it. ! 95: ! 96: If you use the `-W' option with the `-O' option, you will get a ! 97: warning when GNU CC thinks such a problem might be possible. ! 98: ! 99: * Declarations of external variables and functions within a block ! 100: apply only to the block containing the declaration. In other ! 101: words, they have the same scope as any other declaration in the ! 102: same place. ! 103: ! 104: In some other C compilers, a `extern' declaration affects all ! 105: the rest of the file even if it happens within a block. ! 106: ! 107: The `-traditional' option directs GNU C to treat all `extern' ! 108: declarations as global, like traditional compilers. ! 109: ! 110: * In traditional C, you can combine `long', etc., with a typedef ! 111: name, as shown here: ! 112: ! 113: typedef int foo; ! 114: typedef long foo bar; ! 115: ! 116: In ANSI C, this is not allowed: `long' and other type modifiers ! 117: require an explicit `int'. Because this criterion is expressed ! 118: by Bison grammar rules rather than C code, the `-traditional' ! 119: flag cannot alter it. ! 120: ! 121: * PCC allows typedef names to be used as function parameters. The ! 122: difficulty described immediately above applies here too. ! 123: ! 124: * PCC allows whitespace in the middle of compound assignment ! 125: operators such as `+='. GNU CC, following the ANSI standard, ! 126: does not allow this. The difficulty described immediately above ! 127: applies here too. ! 128: ! 129: * When compiling functions that return `float', PCC converts it to ! 130: a double. GNU CC actually returns a `float'. If you are ! 131: concerned with PCC compatibility, you should declare your ! 132: functions to return `double'; you might as well say what you mean. ! 133: ! 134: * When compiling functions that return structures or unions, GNU ! 135: CC output code uses a method different from that used on most ! 136: versions of Unix. As a result, code compiled with GNU CC cannot ! 137: call a structure-returning function compiled with PCC, and vice ! 138: versa. ! 139: ! 140: The method used by GCC is as follows: a structure or union which ! 141: is 1, 2, 4 or 8 bytes long is returned like a scalar. A ! 142: structure or union with any other size is stored into an address ! 143: supplied by the caller in a special, fixed register. ! 144: ! 145: PCC usually handles all sizes of structures and unions by ! 146: returning the address of a block of static storage containing ! 147: the value. This method is not used in GCC because it is slower ! 148: and nonreentrant. ! 149: ! 150: On systems where PCC works this way, you may be able to make ! 151: GCC-compiled code call such functions that were compiled with ! 152: PCC by declaring them to return a pointer to the structure or ! 153: union instead of the structure or union itself. For example, ! 154: instead of this: ! 155: ! 156: struct foo nextfoo (); ! 157: ! 158: write this: ! 159: ! 160: struct foo *nextfoo (); ! 161: #define nextfoo *nextfoo ! 162: ! 163: (Note that this assumes you are using the GNU preprocessor and ! 164: not `-traditional', so that the ANSI antirecursion rules for ! 165: macro expansions are effective.) ! 166: 1.1.1.2 root 167: 1.1.1.3 root 168: 169: File: internals, Node: Extensions, Next: Bugs, Prev: Incompatibilities, Up: Top 170: 171: GNU Extensions to the C Language 172: ******************************** 173: 1.1.1.4 ! root 174: GNU C provides several language features not found in ANSI standard C. ! 175: (The `-pedantic' option directs GNU CC to print a warning message if ! 176: any of these features is used.) To test for the availability of ! 177: these features in conditional compilation, check for a predefined ! 178: macro `__GNUC__', which is always defined under GNU CC. 1.1.1.3 root 179: 180: * Menu: 181: 182: * Statement Exprs:: Putting statements and declarations inside expressions. 183: * Naming Types:: Giving a name to the type of some expression. 184: * Typeof:: `typeof': referring to the type of an expression. 185: * Lvalues:: Using `?:', `,' and casts in lvalues. 186: * Conditionals:: Omitting the middle operand of a `?:' expression. 187: * Zero-Length:: Zero-length arrays. 188: * Variable-Length:: Arrays whose length is computed at run time. 189: * Subscripting:: Any array can be subscripted, even if not an lvalue. 190: * Pointer Arith:: Arithmetic on `void'-pointers and function pointers. 191: * Constructors:: Constructor expressions give structures, unions 192: or arrays as values. 193: * Dollar Signs:: Dollar sign is allowed in identifiers. 194: * Alignment:: Inquiring about the alignment of a type or variable. 195: * Inline:: Defining inline functions (as fast as macros). 196: * Extended Asm:: Assembler instructions with C expressions as operands. 197: (With them you can define ``built-in'' functions.) 198: * Asm Labels:: Specifying the assembler name to use for a C symbol. 199: 1.1.1.4 ! root 200: 1.1.1.3 root 201: 202: File: internals, Node: Statement Exprs, Next: Naming Types, Prev: Extensions, Up: Extensions 203: 204: Statements and Declarations inside of Expressions 205: ================================================= 206: 1.1.1.4 ! root 207: A compound statement in parentheses may appear inside an expression ! 208: in GNU C. This allows you to declare variables within an expression. ! 209: For example: 1.1.1.3 root 210: 211: ({ int y = foo (); int z; 212: if (y > 0) z = y; 213: else z = - y; 214: z; }) 215: 1.1.1.4 ! root 216: is a valid (though slightly more complex than necessary) expression ! 217: for the absolute value of `foo ()'. 1.1.1.3 root 218: 1.1.1.4 ! root 219: This feature is especially useful in making macro definitions ! 220: ``safe'' (so that they evaluate each operand exactly once). For ! 221: example, the ``maximum'' function is commonly defined as a macro in ! 222: standard C as follows: 1.1.1.3 root 223: 224: #define max(a,b) ((a) > (b) ? (a) : (b)) 225: 1.1.1.4 ! root 226: But this definition computes either A or B twice, with bad results if ! 227: the operand has side effects. In GNU C, if you know the type of the ! 228: operands (here let's assume `int'), you can define the macro safely ! 229: as follows: 1.1.1.3 root 230: 231: #define maxint(a,b) \ 232: ({int _a = (a), _b = (b); _a > _b ? _a : _b; }) 233: 1.1.1.4 ! root 234: Embedded statements are not allowed in constant expressions, such as ! 235: the value of an enumeration constant, the width of a bit field, or ! 236: the initial value of a static variable. ! 237: ! 238: If you don't know the type of the operand, you can still do this, but ! 239: you must use `typeof' (*note Typeof::.) or type naming (*note Naming ! 240: Types::.). 1.1.1.3 root 241: 242: 243: 244: File: internals, Node: Naming Types, Next: Typeof, Prev: Statement Exprs, Up: Extensions 245: 246: Naming an Expression's Type 247: =========================== 248: 249: You can give a name to the type of an expression using a `typedef' 1.1.1.4 ! root 250: declaration with an initializer. Here is how to define NAME as a ! 251: type name for the type of EXP: 1.1.1.3 root 252: 253: typedef NAME = EXP; 254: 255: This is useful in conjunction with the statements-within-expressions 256: feature. Here is how the two together can be used to define a safe 257: ``maximum'' macro that operates on any arithmetic type: 258: 259: #define max(a,b) \ 260: ({typedef _ta = (a), _tb = (b); \ 261: _ta _a = (a); _tb _b = (b); \ 262: _a > _b ? _a : _b; }) 263: 264: The reason for using names that start with underscores for the local 1.1.1.4 ! root 265: variables is to avoid conflicts with variable names that occur within ! 266: the expressions that are substituted for `a' and `b'. Eventually we ! 267: hope to design a new form of declaration syntax that allows you to ! 268: declare variables whose scopes start only after their initializers; ! 269: this will be a more reliable way to prevent such conflicts. ! 270: 1.1.1.3 root 271: 272: 273: File: internals, Node: Typeof, Next: Lvalues, Prev: Naming Types, Up: Extensions 274: 275: Referring to a Type with `typeof' 276: ================================= 277: 1.1.1.4 ! root 278: Another way to refer to the type of an expression is with `typeof'. ! 279: The syntax of using of this keyword looks like `sizeof', but the ! 280: construct acts semantically like a type name defined with `typedef'. 1.1.1.3 root 281: 1.1.1.4 ! root 282: There are two ways of writing the argument to `typeof': with an ! 283: expression or with a type. Here is an example with an expression: 1.1.1.3 root 284: 285: typeof (x[0](1)) 286: 1.1.1.4 ! root 287: This assumes that `x' is an array of functions; the type described is ! 288: that of the values of the functions. 1.1.1.3 root 289: 290: Here is an example with a typename as the argument: 291: 292: typeof (int *) 293: 294: Here the type described is that of pointers to `int'. 295: 1.1.1.4 ! root 296: A `typeof'-construct can be used anywhere a typedef name could be ! 297: used. For example, you can use it in a declaration, in a cast, or ! 298: inside of `sizeof' or `typeof'. 1.1.1.3 root 299: 300: * This declares `y' with the type of what `x' points to. 301: 302: typeof (*x) y; 303: 304: * This declares `y' as an array of such values. 1.1 root 305: 1.1.1.3 root 306: typeof (*x) y[4]; 1.1 root 307: 1.1.1.3 root 308: * This declares `y' as an array of pointers to characters: 1.1 root 309: 1.1.1.3 root 310: typeof (typeof (char *)[4]) y; 1.1 root 311: 1.1.1.3 root 312: It is equivalent to the following traditional C declaration: 1.1 root 313: 1.1.1.3 root 314: char *y[4]; 1.1 root 315: 1.1.1.4 ! root 316: To see the meaning of the declaration using `typeof', and why it ! 317: might be a useful way to write, let's rewrite it with these ! 318: macros: 1.1 root 319: 1.1.1.3 root 320: #define pointer(T) typeof(T *) 321: #define array(T, N) typeof(T [N]) 1.1 root 322: 1.1.1.3 root 323: Now the declaration can be rewritten this way: 1.1 root 324: 1.1.1.3 root 325: array (pointer (char), 4) y; 326: 1.1.1.4 ! root 327: Thus, `array (pointer (char), 4)' is the type of arrays of 4 ! 328: pointers to `char'. ! 329: 1.1 root 330: 331: 1.1.1.2 root 332: File: internals, Node: Lvalues, Next: Conditionals, Prev: Typeof, Up: Extensions 333: 334: Generalized Lvalues 335: =================== 336: 1.1.1.4 ! root 337: Compound expressions, conditional expressions and casts are allowed ! 338: as lvalues provided their operands are lvalues. This means that you ! 339: can take their addresses or store values into them. 1.1.1.2 root 340: 341: For example, a compound expression can be assigned, provided the last 342: expression in the sequence is an lvalue. These two expressions are 343: equivalent: 344: 345: (a, b) += 5 346: a, (b += 5) 347: 1.1.1.4 ! root 348: Similarly, the address of the compound expression can be taken. ! 349: These two expressions are equivalent: 1.1.1.2 root 350: 351: &(a, b) 352: a, &b 353: 1.1.1.4 ! root 354: A conditional expression is a valid lvalue if its type is not void ! 355: and the true and false branches are both valid lvalues. For example, ! 356: these two expressions are equivalent: 1.1.1.2 root 357: 358: (a ? b : c) = 5 359: (a ? b = 5 : (c = 5)) 360: 1.1.1.4 ! root 361: A cast is a valid lvalue if its operand is valid. Taking the address ! 362: of the cast is the same as taking the address without a cast, except ! 363: for the type of the result. For example, these two expressions are ! 364: equivalent (but the second may be valid when the type of `a' does not ! 365: permit a cast to `int *'). 1.1.1.2 root 366: 367: &(int *)a 368: (int **)&a 369: 1.1.1.4 ! root 370: A simple assignment whose left-hand side is a cast works by ! 371: converting the right-hand side first to the specified type, then to ! 372: the type of the inner left-hand side expression. After this is ! 373: stored, the value is converter back to the specified type to become ! 374: the value of the assignment. Thus, if `a' has type `char *', the ! 375: following two expressions are equivalent: 1.1.1.2 root 376: 377: (int)a = 5 378: (int)(a = (char *)5) 379: 1.1.1.4 ! root 380: An assignment-with-arithmetic operation such as `+=' applied to a ! 381: cast performs the arithmetic using the type resulting from the cast, ! 382: and then continues as in the previous case. Therefore, these two ! 383: expressions are equivalent: 1.1.1.2 root 384: 385: (int)a += 5 386: (int)(a = (char *) ((int)a + 5)) 387: 1.1.1.4 ! root 388: 1.1.1.2 root 389: 390: File: internals, Node: Conditionals, Next: Zero-Length, Prev: Lvalues, Up: Extensions 391: 392: Conditional Expressions with Omitted Middle-Operands 393: ==================================================== 394: 1.1.1.4 ! root 395: The middle operand in a conditional expression may be omitted. Then ! 396: if the first operand is nonzero, its value is the value of the ! 397: conditional expression. 1.1.1.2 root 398: 399: Therefore, the expression 400: 401: x ? : y 402: 403: has the value of `x' if that is nonzero; otherwise, the value of `y'. 404: 405: This example is perfectly equivalent to 406: 407: x ? x : y 408: 409: In this simple case, the ability to omit the middle operand is not 1.1.1.4 ! root 410: especially useful. When it becomes useful is when the first operand ! 411: does, or may (if it is a macro argument), contain a side effect. ! 412: Then repeating the operand in the middle would perform the side ! 413: effect twice. Omitting the middle operand uses the value already ! 414: computed without the undesirable effects of recomputing it. ! 415: 1.1.1.2 root 416: 417: 418: File: internals, Node: Zero-Length, Next: Variable-Length, Prev: Conditionals, Up: Extensions 419: 420: Arrays of Length Zero 1.1 root 421: ===================== 422: 1.1.1.4 ! root 423: Zero-length arrays are allowed in GNU C. They are very useful as the ! 424: last element of a structure which is really a header for a ! 425: variable-length object: 1.1.1.2 root 426: 427: struct line { 428: int length; 429: char contents[0]; 430: }; 431: 432: { 433: struct line *thisline 434: = (struct line *) malloc (sizeof (struct line) + this_length); 1.1.1.4 ! root 435: thisline->length = this_length; 1.1.1.2 root 436: } 437: 1.1.1.4 ! root 438: In standard C, you would have to give `contents' a length of 1, which ! 439: means either you waste space or complicate the argument to `malloc'. ! 440: 1.1 root 441: 442: 1.1.1.2 root 443: File: internals, Node: Variable-Length, Next: Subscripting, Prev: Zero-Length, Up: Extensions 1.1 root 444: 1.1.1.2 root 445: Arrays of Variable Length 446: ========================= 1.1 root 447: 1.1.1.4 ! root 448: Variable-length automatic arrays are allowed in GNU C. These arrays ! 449: are declared like any other automatic arrays, but with a length that ! 450: is not a constant expression. The storage is allocated at that time ! 451: and deallocated when the brace-level is exited. For example: 1.1.1.2 root 452: 453: FILE *concat_fopen (char *s1, char *s2, char *mode) 454: { 455: char str[strlen (s1) + strlen (s2) + 1]; 456: strcpy (str, s1); 457: strcat (str, s2); 458: return fopen (str, mode); 459: } 460: 1.1.1.4 ! root 461: You can also define structure types containing variable-length ! 462: arrays, and use them even for arguments or function values, as shown ! 463: here: 1.1.1.2 root 464: 465: int foo; 466: 467: struct entry 468: { 469: char data[foo]; 470: }; 471: 472: struct entry 473: tester (struct entry arg) 474: { 475: struct entry new; 476: int i; 477: for (i = 0; i < foo; i++) 478: new.data[i] = arg.data[i] + 1; 479: return new; 480: } 481: 482: (Eventually there will be a way to say that the size of the array is 483: another member of the same structure.) 484: 1.1.1.4 ! root 485: The length of an array is computed on entry to the brace-level where ! 486: the array is declared and is remembered for the scope of the array in ! 487: case you access it with `sizeof'. ! 488: ! 489: Jumping or breaking out of the scope of the array name will also ! 490: deallocate the storage. Jumping into the scope is not allowed; you ! 491: will get an error message for it. 1.1.1.2 root 492: 493: You can use the function `alloca' to get an effect much like 1.1.1.4 ! root 494: variable-length arrays. The function `alloca' is available in many ! 495: other C implementations (but not in all). On the other hand, ! 496: variable-length arrays are more elegant. ! 497: ! 498: There are other differences between these two methods. Space ! 499: allocated with `alloca' exists until the containing *function* returns. ! 500: The space for a variable-length array is deallocated as soon as the ! 501: array name's scope ends. (If you use both variable-length arrays and ! 502: `alloca' in the same function, deallocation of a variable-length ! 503: array will also deallocate anything more recently allocated with ! 504: `alloca'.) ! 505: 1.1 root 506: 507: 1.1.1.2 root 508: File: internals, Node: Subscripting, Next: Pointer Arith, Prev: Variable-Length, Up: Extensions 1.1 root 509: 1.1.1.2 root 510: Non-Lvalue Arrays May Have Subscripts 511: ===================================== 1.1 root 512: 1.1.1.4 ! root 513: Subscripting is allowed on arrays that are not lvalues, even though ! 514: the unary `&' operator is not. For example, this is valid in GNU C ! 515: though not valid in other C dialects: 1.1 root 516: 1.1.1.2 root 517: struct foo {int a[4];}; 1.1 root 518: 1.1.1.2 root 519: struct foo f(); 1.1 root 520: 1.1.1.2 root 521: bar (int index) 522: { 523: return f().a[index]; 524: } 525: 1.1.1.4 ! root 526: 1.1.1.2 root 527: 528: File: internals, Node: Pointer Arith, Next: Initializers, Prev: Subscripting, Up: Extensions 529: 530: Arithmetic on `void'-Pointers and Function Pointers 531: =================================================== 532: 1.1.1.4 ! root 533: In GNU C, addition and subtraction operations are supported on ! 534: pointers to `void' and on pointers to functions. This is done by ! 535: treating the size of a `void' or of a function as 1. ! 536: ! 537: A consequence of this is that `sizeof' is also allowed on `void' and ! 538: on function types, and returns 1. 1.1.1.2 root 539: 1.1 root 540: 541: 1.1.1.2 root 542: File: internals, Node: Initializers, Next: Constructors, Prev: Pointer Arith, Up: Extensions 543: 544: Non-Constant Initializers 545: ========================= 546: 1.1.1.4 ! root 547: The elements of an aggregate initializer are not required to be ! 548: constant expressions in GNU C. Here is an example of an initializer ! 549: with run-time varying elements: 1.1.1.2 root 550: 551: foo (float f, float g) 552: { 553: float beat_freqs[2] = { f-g, f+g }; 554: ... 555: } 1.1 root 556: 1.1.1.4 ! root 557: 1.1.1.2 root 558: 559: File: internals, Node: Constructors, Next: Dollar Signs, Prev: Initializers, Up: Extensions 560: 561: Constructor Expressions 1.1 root 562: ======================= 563: 1.1.1.4 ! root 564: GNU C supports constructor expressions. A constructor looks like a ! 565: cast containing an initializer. Its value is an object of the type ! 566: specified in the cast, containing the elements specified in the ! 567: initializer. The type must be a structure, union or array type. 1.1 root 568: 1.1.1.2 root 569: Assume that `struct foo' and `structure' are declared as shown: 1.1 root 570: 1.1.1.2 root 571: struct foo {int a; char b[2];} structure; 1.1 root 572: 1.1.1.2 root 573: Here is an example of constructing a `struct foo' with a constructor: 1.1 root 574: 1.1.1.2 root 575: structure = ((struct foo) {x + y, 'a', 0}); 1.1 root 576: 1.1.1.2 root 577: This is equivalent to writing the following: 1.1 root 578: 1.1.1.2 root 579: { 580: struct foo temp = {x + y, 'a', 0}; 581: structure = temp; 582: } 1.1 root 583: 1.1.1.4 ! root 584: You can also construct an array. If all the elements of the ! 585: constructor are (made up of) simple constant expressions, suitable ! 586: for use in initializers, then the constructor is an lvalue and can be ! 587: coerced to a pointer to its first element, as shown here: 1.1.1.2 root 588: 589: char **foo = (char *[]) { "x", "y", "z" }; 590: 1.1.1.4 ! root 591: Array constructors whose elements are not simple constants are not ! 592: very useful, because the constructor is not an lvalue. There are ! 593: only two valid ways to use it: to subscript it, or initialize an ! 594: array variable with it. The former is probably slower than a ! 595: `switch' statement, while the latter does the same thing an ordinary ! 596: C initializer would do. 1.1.1.2 root 597: 598: output = ((int[]) { 2, x, 28 }) [input]; 1.1 root 599: 1.1.1.4 ! root 600: 1.1 root 601: 1.1.1.2 root 602: File: internals, Node: Dollar Signs, Next: Alignment, Prev: Constructors, Up: Extensions 1.1 root 603: 1.1.1.2 root 604: Dollar Signs in Identifier Names 605: ================================ 1.1 root 606: 1.1.1.4 ! root 607: In GNU C, you may use dollar signs in identifier names. This is ! 608: because many traditional C implementations allow such identifiers. ! 609: 1.1 root 610: 1.1.1.2 root 611: 612: File: internals, Node: Alignment, Next: Inline, Prev: Dollar Signs, Up: Extensions 1.1 root 613: 1.1.1.2 root 614: Inquiring about the Alignment of a Type or Variable 615: =================================================== 1.1 root 616: 1.1.1.2 root 617: The keyword `__alignof' allows you to inquire about how an object is 1.1.1.4 ! root 618: aligned, or the minimum alignment usually required by a type. Its ! 619: syntax is just like `sizeof'. 1.1 root 620: 1.1.1.4 ! root 621: For example, if the target machine requires a `double' value to be ! 622: aligned on an 8-byte boundary, then `__alignof (double)' is 8. This ! 623: is true on many RISC machines. On more traditional machine designs, ! 624: `__alignof (double)' is 4 or even 2. ! 625: ! 626: Some machines never actually require alignment; they allow reference ! 627: to any data type even at an odd addresses. For these machines, ! 628: `__alignof' reports the *recommended* alignment of a type. ! 629: ! 630: When the operand of `__alignof' is an lvalue rather than a type, the ! 631: value is the largest alignment that the lvalue is known to have. It ! 632: may have this alignment as a result of its data type, or because it ! 633: is part of a structure and inherits alignment from that structure. ! 634: For example, after this declaration: 1.1.1.2 root 635: 636: struct foo { int x; char y; } foo1; 637: 638: the value of `__alignof (foo1.y)' is probably 2 or 4, the same as 1.1.1.4 ! root 639: `__alignof (int)', even though the data type of `foo1.y' does not ! 640: itself demand any alignment. ! 641: 1.1.1.2 root 642: 643: 644: File: internals, Node: Inline, Next: Extended Asm, Prev: Alignment, Up: Extensions 645: 646: An Inline Function is As Fast As a Macro 647: ======================================== 648: 1.1.1.4 ! root 649: By declaring a function `inline', you can direct GNU CC to integrate ! 650: that function's code into the code for its callers. This makes ! 651: execution faster by eliminating the function-call overhead; in ! 652: addition, if any of the actual argument values are constant, their ! 653: known values may permit simplifications at compile time so that not ! 654: all of the inline function's code needs to be included. 1.1.1.2 root 655: 1.1.1.4 ! root 656: To declare a function inline, use the `inline' keyword in its ! 657: declaration, like this: 1.1.1.2 root 658: 659: inline int 660: inc (int *a) 661: { 662: (*a)++; 663: } 664: 1.1.1.4 ! root 665: You can also make all ``simple enough'' functions inline with the ! 666: option `-finline-functions'. Note that certain usages in a function ! 667: definition can make it unsuitable for inline substitution. ! 668: ! 669: When a function is both inline and `static', if all calls to the ! 670: function are integrated into the caller, then the function's own ! 671: assembler code is never referenced. In this case, GNU CC does not ! 672: actually output assembler code for the function, unless you specify ! 673: the option `-fkeep-inline-functions'. Some calls cannot be ! 674: integrated for various reasons (in particular, calls that precede the ! 675: function's definition cannot be integrated, and neither can recursive ! 676: calls within the definition). If there is a nonintegrated call, then ! 677: the function is compiled to assembler code as usual. ! 678: ! 679: When an inline function is not `static', then the compiler must ! 680: assume that there may be calls from other source files; since a ! 681: global symbol can be defined only once in any program, the function ! 682: must not be defined in the other source files, so the calls therein ! 683: cannot be integrated. Therefore, a non-`static' inline function is ! 684: always compiled on its own in the usual fashion. ! 685: 1.1.1.2 root 686: 687: 688: File: internals, Node: Extended Asm, Next: Asm Labels, Prev: Inline, Up: Extensions 689: 690: Assembler Instructions with C Expression Operands 691: ================================================= 692: 1.1.1.4 ! root 693: In an assembler instruction using `asm', you can now specify the ! 694: operands of the instruction using C expressions. This means no more ! 695: guessing which registers or memory locations will contain the data ! 696: you want to use. ! 697: ! 698: You must specify an assembler instruction template much like what ! 699: appears in a machine description, plus an operand constraint string ! 700: for each operand. 1.1.1.2 root 701: 702: For example, here is how to use the 68881's `fsinx' instruction: 703: 704: asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 705: 1.1.1.4 ! root 706: Here `angle' is the C expression for the input operand while `result' ! 707: is that of the output operand. Each has `"f"' as its operand ! 708: constraint, saying that a floating-point register is required. The ! 709: constraints use the same language used in the machine description ! 710: (*note Constraints::.). ! 711: ! 712: Each operand is described by an operand-constraint string followed by ! 713: the C expression in parentheses. A colon separates the assembler ! 714: template from the first output operand, and another separates the ! 715: last output operand from the first input, if any. Commas separate ! 716: output operands and separate inputs. The number of operands is ! 717: limited to the maximum number of operands in any instruction pattern ! 718: in the machine description. ! 719: ! 720: Output operand expressions must be lvalues; the compiler can check ! 721: this. The input operands need not be lvalues. The compiler cannot ! 722: check whether the operands have data types that are reasonable for ! 723: the instruction being executed. It does not parse the assembler ! 724: instruction template and does not know what it means, or whether it ! 725: is valid assembler input. The extended `asm' feature is most often ! 726: used for machine instructions that the compiler itself does not know ! 727: exist. ! 728: ! 729: If there are no output operands, and there are input operands, then ! 730: you should write two colons in a row where the output operands would ! 731: go. ! 732: ! 733: The output operands must be write-only; GNU CC will assume that the ! 734: values in these operands before the instruction are dead and need not ! 735: be generated. For an operand that is read-write, or in which not all ! 736: bits are written and the other bits contain useful information, you ! 737: must logically split its function into two separate operands, one ! 738: input operand and one write-only output operand. The connection ! 739: between them is expressed by constraints which say they need to be in ! 740: the same location when the instruction executes. You can use the ! 741: same C expression for both operands, or different expressions. For ! 742: example, here we write the (fictitious) `combine' instruction with ! 743: `bar' as its read-only source operand and `foo' as its read-write ! 744: destination: 1.1.1.2 root 745: 746: asm ("combine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar)); 747: 748: The constraint `"0"' for operand 1 says that it must occupy the same 1.1.1.4 ! root 749: location as operand 0. ! 750: ! 751: Only a digit in the constraint can guarantee that one operand will be ! 752: in the same place as another. The mere fact that `foo' is the value ! 753: of both operands is not enough to guarantee that they will be in the ! 754: same place in the generated assembler code. The following would not ! 755: work: ! 756: ! 757: asm ("combine %2,%0" : "=r" (foo) : "r" (foo), "g" (bar)); ! 758: ! 759: Various optimizations or reloading could cause operands 0 and 1 to be ! 760: in different registers; GNU CC knows no reason not to do so. For ! 761: example, the compiler might find a copy of the value of `foo' in one ! 762: register and use it for operand 1, but generate the output operand 0 ! 763: in a different register (copying it afterward to `foo''s own ! 764: address). Of course, since the register for operand 1 is not even ! 765: mentioned in the assembler code, the result will not work, but GNU CC ! 766: can't tell that. ! 767: ! 768: Unless an output operand has the `&' constraint modifier, GNU CC may ! 769: allocate it in the same register as an unrelated input operand, on ! 770: the assumption that the inputs are consumed before the outputs are ! 771: produced. This assumption may be false if the assembler code ! 772: actually consists of more than one instruction. In such a case, use ! 773: `&' for each output operand that may not overlap an input. *Note ! 774: Modifiers::. ! 775: ! 776: Some instructions clobber specific hard registers. To describe this, ! 777: write a third colon after the input operands, followed by the names ! 778: of the clobbered hard registers (given as strings). For example, on ! 779: the vax, ! 780: ! 781: asm volatile ("movc3 %0,%1,%2" ! 782: : /* no outputs */ ! 783: : "g" (from), "g" (to), "g" (count) ! 784: : "r0", "r1", "r2", "r3", "r4", "r5"); 1.1.1.2 root 785: 786: Usually the most convenient way to use these `asm' instructions is to 787: encapsulate them in macros that look like functions. For example, 788: 789: #define sin(x) \ 790: ({ double __value, __arg = (x); \ 791: asm ("fsinx %1,%0": "=f" (__value): "f" (__arg)); \ 792: __value; }) 793: 794: Here the variable `__arg' is used to make sure that the instruction 1.1.1.4 ! root 795: operates on a proper `double' value, and to accept only those ! 796: arguments `x' which can convert automatically to a `double'. 1.1.1.2 root 797: 1.1.1.4 ! root 798: Another way to make sure the instruction operates on the correct data ! 799: type is to use a cast in the `asm'. This is different from using a ! 800: variable `__arg' in that it converts more different types. For ! 801: example, if the desired type were `int', casting the argument to ! 802: `int' would accept a pointer with no complaint, while assigning the ! 803: argument to an `int' variable named `__arg' would warn about using a ! 804: pointer unless the caller explicitly casts it. ! 805: ! 806: GNU CC assumes for optimization purposes that these instructions have ! 807: no side effects except to change the output operands. This does not ! 808: mean that instructions with a side effect cannot be used, but you ! 809: must be careful, because the compiler may eliminate them if the ! 810: output operands aren't used, or move them out of loops, or replace ! 811: two with one if they constitute a common subexpression. Also, if ! 812: your instruction does have a side effect on a variable that otherwise ! 813: appears not to change, the old value of the variable may be reused ! 814: later if it happens to be found in a register. ! 815: ! 816: You can prevent an `asm' instruction from being deleted, moved or ! 817: combined by writing the keyword `volatile' after the `asm'. For ! 818: example: 1.1.1.2 root 819: 820: #define set_priority(x) \ 821: asm volatile ("set_priority %1": \ 822: "=m" (*(char *)0): "g" (x)) 823: 1.1.1.4 ! root 824: Note that we have supplied an output operand which is not actually ! 825: used in the instruction. This is because `asm' requires at least one ! 826: output operand. This requirement exists for internal implementation ! 827: reasons and we might be able to relax it in the future. ! 828: ! 829: In this case output operand has the additional benefit effect of ! 830: giving the appearance of writing in memory. As a result, GNU CC will ! 831: assume that data previously fetched from memory must be fetched again ! 832: if needed again later. This may be desirable if you have not ! 833: employed the `volatile' keyword on all the variable declarations that ! 834: ought to have it. ! 835: 1.1.1.2 root 836: 837: 838: File: internals, Node: Asm Labels, Prev: Extended Asm, Up: Extensions 839: 840: Controlling Names Used in Assembler Code 841: ======================================== 842: 1.1.1.4 ! root 843: You can specify the name to be used in the assembler code for a C ! 844: function or variable by writing the `asm' keyword after the ! 845: declarator as follows: 1.1.1.2 root 846: 847: int foo asm ("myfoo") = 2; 848: 849: This specifies that the name to be used for the variable `foo' in the 850: assembler code should be `myfoo' rather than the usual `_foo'. 851: 1.1.1.4 ! root 852: On systems where an underscore is normally prepended to the name of a ! 853: C function or variable, this feature allows you to define names for ! 854: the linker that do not start with an underscore. ! 855: ! 856: You cannot use `asm' in this way in a function *definition*; but you ! 857: can get the same effect by writing a declaration for the function ! 858: before its definition and putting `asm' there, like this: 1.1.1.2 root 859: 860: extern func () asm ("FUNC"); 1.1 root 861: 1.1.1.2 root 862: func (x, y) 863: int x, y; 864: ... 865: 1.1.1.4 ! root 866: It is up to you to make sure that the assembler names you choose do ! 867: not conflict with any other assembler symbols. Also, you must not ! 868: use a register name; that would produce completely invalid assembler ! 869: code. GNU CC does not as yet have the ability to store static ! 870: variables in registers. Perhaps that will be added. ! 871: 1.1 root 872: 873: 1.1.1.2 root 874: File: internals, Node: Bugs, Next: Portability, Prev: Extensions, Up: Top 1.1 root 875: 1.1.1.2 root 876: Reporting Bugs 877: ************** 878: 879: Your bug reports play an essential role in making GNU CC reliable. 880: 1.1.1.4 ! root 881: Reporting a bug may help you by bringing a solution to your problem, ! 882: or it may not. But in any case the important function of a bug ! 883: report is to help the entire community by making the next version of ! 884: GNU CC work better. Bug reports are your contribution to the ! 885: maintenance of GNU CC. 1.1.1.2 root 886: 887: In order for a bug report to serve its purpose, you must include the 888: information that makes for fixing the bug. 1.1 root 889: 890: * Menu: 891: 1.1.1.2 root 892: * Criteria: Bug Criteria. Have you really found a bug? 893: * Reporting: Bug Reporting. How to report a bug effectively. 894: 1.1.1.4 ! root 895: 1.1 root 896: 1.1.1.2 root 897: File: internals, Node: Bug Criteria, Next: Bug Reporting, Prev: Bugs, Up: Bugs 1.1 root 898: 1.1.1.2 root 899: Have You Found a Bug? 900: ===================== 1.1 root 901: 1.1.1.4 ! root 902: If you are not sure whether you have found a bug, here are some ! 903: guidelines: 1.1 root 904: 1.1.1.4 ! root 905: * If the compiler gets a fatal signal, for any input whatever, ! 906: that is a compiler bug. Reliable compilers never crash. 1.1 root 907: 1.1.1.4 ! root 908: * If the compiler produces invalid assembly code, for any input ! 909: whatever (except an `asm' statement), that is a compiler bug, ! 910: unless the compiler reports errors (not just warnings) which ! 911: would ordinarily prevent the assembler from being run. ! 912: ! 913: * If the compiler produces valid assembly code that does not ! 914: correctly execute the input source code, that is a compiler bug. ! 915: ! 916: However, you must double-check to make sure, because you may ! 917: have run into an incompatibility between GNU C and traditional C ! 918: (*note Incompatibilities::.). These incompatibilities might be ! 919: considered bugs, but they are inescapable consequences of ! 920: valuable features. ! 921: ! 922: Or you may have a program whose behavior is undefined, which ! 923: happened by chance to give the desired results with another C ! 924: compiler. ! 925: ! 926: For example, in many nonoptimizing compilers, you can write `x;' ! 927: at the end of a function instead of `return x;', with the same ! 928: results. But the value of the function is undefined if `return' ! 929: is omitted; it is not a bug when GNU CC produces different ! 930: results. ! 931: ! 932: Problems often result from expressions with two increment ! 933: operators, as in `f (*p++, *p++)'. Your previous compiler might ! 934: have interpreted that expression the way you intended; GNU CC ! 935: might interpret it another way; neither compiler is wrong. ! 936: ! 937: After you have localized the error to a single source line, it ! 938: should be easy to check for these things. If your program is ! 939: correct and well defined, you have found a compiler bug. 1.1.1.2 root 940: 1.1.1.4 ! root 941: * If the compiler produces an error message for valid input, that ! 942: is a compiler bug. 1.1.1.2 root 943: 1.1.1.4 ! root 944: Note that the following is not valid input, and the error ! 945: message for it is not a bug: 1.1.1.2 root 946: 947: int foo (char); 948: 949: int 950: foo (x) 951: char x; 952: { ... } 953: 1.1.1.4 ! root 954: The prototype says to pass a `char', while the definition says ! 955: to pass an `int' and treat the value as a `char'. This is what ! 956: the ANSI standard says, and it makes sense. ! 957: ! 958: * If the compiler does not produce an error message for invalid ! 959: input, that is a compiler bug. However, you should note that ! 960: your idea of ``invalid input'' might be my idea of ``an ! 961: extension'' or ``support for traditional practice''. ! 962: ! 963: * If you are an experienced user of C compilers, your suggestions ! 964: for improvement of GNU CC are welcome in any case. 1.1.1.2 root 965: 1.1 root 966: 967: 1.1.1.2 root 968: File: internals, Node: Bug Reporting, Prev: Bug Criteria, Up: Bugs 969: 970: How to Report Bugs 971: ================== 972: 973: Send bug reports for GNU C to one of these addresses: 974: 975: [email protected] 976: {ucbvax|mit-eddie|uunet}!prep.ai.mit.edu!bug-gcc 977: 978: As a last resort, snail them to: 979: 980: GNU Compiler Bugs 981: 545 Tech Sq 982: Cambridge, MA 02139 983: 1.1.1.4 ! root 984: The fundamental principle of reporting bugs usefully is this: *report ! 985: all the facts*. If you are not sure whether to mention a fact or ! 986: leave it out, mention it! 1.1.1.2 root 987: 988: Often people omit facts because they think they know what causes the 1.1.1.4 ! root 989: problem and they conclude that some details don't matter. Thus, you ! 990: might assume that the name of the variable you use in an example does ! 991: not matter. Well, probably it doesn't, but one cannot be sure. ! 992: Perhaps the bug is a stray memory reference which happens to fetch ! 993: from the location where that name is stored in memory; perhaps, if ! 994: the name were different, the contents of that location would fool the ! 995: compiler into doing the right thing despite the bug. Play it safe ! 996: and give an exact example. ! 997: ! 998: If you want to enable me to fix the bug, you should include all these ! 999: things: ! 1000: ! 1001: * The version of GNU CC. You can get this by running it with the ! 1002: `-v' option. ! 1003: ! 1004: Without this, I won't know whether there is any point in looking ! 1005: for the bug in the current version of GNU CC. ! 1006: ! 1007: * A complete input file that will reproduce the bug. If the bug ! 1008: is in the C preprocessor, send me a source file and any header ! 1009: files that it requires. If the bug is in the compiler proper ! 1010: (`cc1'), run your source file through the C preprocessor by ! 1011: doing `gcc -E SOURCEFILE > OUTFILE', then include the contents ! 1012: of OUTFILE in the bug report. (Any `-I', `-D' or `-U' options ! 1013: that you used in actual compilation should also be used when ! 1014: doing this.) ! 1015: ! 1016: A single statement is not enough of an example. In order to ! 1017: compile it, it must be embedded in a function definition; and ! 1018: the bug might depend on the details of how this is done. ! 1019: ! 1020: Without a real example I can compile, all I can do about your ! 1021: bug report is wish you luck. It would be futile to try to guess ! 1022: how to provoke the bug. For example, bugs in register ! 1023: allocation and reloading frequently depend on every little ! 1024: detail of the function they happen in. ! 1025: ! 1026: * The command arguments you gave GNU CC to compile that example ! 1027: and observe the bug. For example, did you use `-O'? To ! 1028: guarantee you won't omit something important, list them all. 1.1 root 1029: 1.1.1.4 ! root 1030: If I were to try to guess the arguments, I would probably guess ! 1031: wrong and then I would not encounter the bug. 1.1 root 1032: 1.1.1.4 ! root 1033: * The names of the files that you used for `tm.h' and `md' when ! 1034: you installed the compiler. 1.1.1.2 root 1035: 1.1.1.4 ! root 1036: * The type of machine you are using, and the operating system name ! 1037: and version number. 1.1.1.2 root 1038: 1039: * A description of what behavior you observe that you believe is 1.1.1.4 ! root 1040: incorrect. For example, ``It gets a fatal signal,'' or, ``There ! 1041: is an incorrect assembler instruction in the output.'' ! 1042: ! 1043: Of course, if the bug is that the compiler gets a fatal signal, ! 1044: then I will certainly notice it. But if the bug is incorrect ! 1045: output, I might not notice unless it is glaringly wrong. I ! 1046: won't study all the assembler code from a 50-line C program just ! 1047: on the off chance that it might be wrong. ! 1048: ! 1049: Even if the problem you experience is a fatal signal, you should ! 1050: still say so explicitly. Suppose something strange is going on, ! 1051: such as, your copy of the compiler is out of synch, or you have ! 1052: encountered a bug in the C library on your system. (This has ! 1053: happened!) Your copy might crash and mine would not. If you ! 1054: told me to expect a crash, then when mine fails to crash, I ! 1055: would know that the bug was not happening for me. If you had ! 1056: not told me to expect a crash, then I would not be able to draw ! 1057: any conclusion from my observations. ! 1058: ! 1059: In cases where GNU CC generates incorrect code, if you send me a ! 1060: small complete sample program I will find the error myself by ! 1061: running the program under a debugger. If you send me a large ! 1062: example or a part of a larger program, I cannot do this; you ! 1063: must debug the compiled program and narrow the problem down to ! 1064: one source line. Tell me which source line it is, and what you ! 1065: believe is incorrect about the code generated for that line. ! 1066: ! 1067: * If you send me examples of output from GNU CC, please use `-g' ! 1068: when you make them. The debugging information includes source ! 1069: line numbers which are essential for correlating the output with ! 1070: the input. ! 1071: ! 1072: * If you wish to suggest changes to the GNU CC source, send me ! 1073: context diffs. If you even discuss something in the GNU CC ! 1074: source, refer to it by context, not by line number. 1.1.1.2 root 1075: 1.1.1.4 ! root 1076: The line numbers in my development sources don't match those in ! 1077: your sources. They won't tell me anything. 1.1.1.2 root 1078: 1079: Here are some things that are not necessary: 1080: 1081: * A description of the envelope of the bug. 1082: 1.1.1.4 ! root 1083: Often people who encounter a bug spend a lot of time ! 1084: investigating which changes to the input file will make the bug ! 1085: go away and which changes will not affect it. ! 1086: ! 1087: This is often time consuming and not very useful, because the ! 1088: way I will find the bug is by running a single example under the ! 1089: debugger with breakpoints, not by pure deduction from a series ! 1090: of examples. 1.1.1.2 root 1091: 1092: Of course, it can't hurt if you can find a simpler example that 1.1.1.4 ! root 1093: triggers the same bug. Errors in the output will be easier to ! 1094: spot, running under the debugger will take less time, etc. An ! 1095: easy way to simplify an example is to delete all the function ! 1096: definitions except the one where the bug occurs. Those earlier ! 1097: in the file may be replaced by external declarations. 1.1.1.2 root 1098: 1.1.1.4 ! root 1099: However, simplification is not necessary; if you don't want to ! 1100: do this, report the bug anyway. 1.1.1.2 root 1101: 1102: * A patch for the bug. 1103: 1.1.1.4 ! root 1104: A patch for the bug does help me if it is a good one. But don't ! 1105: omit the necessary information, such as the test case, because I ! 1106: might see problems with your patch and decide to fix the problem ! 1107: another way. ! 1108: ! 1109: Sometimes with a program as complicated as GNU CC it is very ! 1110: hard to construct an example that will make the program go ! 1111: through a certain point in the code. If you don't send me the ! 1112: example, I won't be able to verify that the bug is fixed. 1.1.1.2 root 1113: 1114: * A guess about what the bug is or what it depends on. 1115: 1.1.1.4 ! root 1116: Such guesses are usually wrong. Even I can't guess right about ! 1117: such things without using the debugger to find the facts. They ! 1118: also don't serve a useful purpose. ! 1119: 1.1 root 1120: 1121: 1.1.1.2 root 1122: File: internals, Node: Portability, Next: Interface, Prev: Bugs, Up: Top 1.1 root 1123: 1.1.1.2 root 1124: GNU CC and Portability 1125: ********************** 1.1 root 1126: 1.1.1.4 ! root 1127: The main goal of GNU CC was to make a good, fast compiler for ! 1128: machines in the class that the GNU system aims to run on: 32-bit ! 1129: machines that address 8-bit bytes and have several general registers. ! 1130: Elegance, theoretical power and simplicity are only secondary. ! 1131: ! 1132: GNU CC gets most of the information about the target machine from a ! 1133: machine description which gives an algebraic formula for each of the ! 1134: machine's instructions. This is a very clean way to describe the ! 1135: target. But when the compiler needs information that is difficult to ! 1136: express in this fashion, I have not hesitated to define an ad-hoc ! 1137: parameter to the machine description. The purpose of portability is ! 1138: to reduce the total work needed on the compiler; it was not of ! 1139: interest for its own sake. ! 1140: ! 1141: GNU CC does not contain machine dependent code, but it does contain ! 1142: code that depends on machine parameters such as endianness (whether ! 1143: the most significant byte has the highest or lowest address of the ! 1144: bytes in a word) and the availability of autoincrement addressing. ! 1145: In the RTL-generation pass, it is often necessary to have multiple ! 1146: strategies for generating code for a particular kind of syntax tree, ! 1147: strategies that are usable for different combinations of parameters. ! 1148: Often I have not tried to address all possible cases, but only the ! 1149: common ones or only the ones that I have encountered. As a result, a ! 1150: new target may require additional strategies. You will know if this ! 1151: happens because the compiler will call `abort'. Fortunately, the new ! 1152: strategies can be added in a machine-independent fashion, and will ! 1153: affect only the target machines that need them. ! 1154: 1.1 root 1155: 1156: 1.1.1.2 root 1157: File: internals, Node: Interface, Next: Passes, Prev: Portability, Up: Top 1.1 root 1158: 1.1.1.2 root 1159: Interfacing to GNU CC Output 1160: **************************** 1.1 root 1161: 1.1.1.4 ! root 1162: GNU CC is normally configured to use the same function calling ! 1163: convention normally in use on the target system. This is done with ! 1164: the machine-description macros described (*note Machine Macros::.). ! 1165: ! 1166: However, returning of structure and union values is done differently. ! 1167: As a result, functions compiled with PCC returning such types cannot ! 1168: be called from code compiled with GNU CC, and vice versa. This ! 1169: usually does not cause trouble because the Unix library routines ! 1170: don't return structures and unions. ! 1171: ! 1172: Structures and unions that are 1, 2, 4 or 8 bytes long are returned ! 1173: in the same registers used for `int' or `double' return values. (GNU ! 1174: CC typically allocates variables of such types in registers also.) ! 1175: Structures and unions of other sizes are returned by storing them ! 1176: into an address passed by the caller in a register. This method is ! 1177: faster than the one normally used by PCC and is also reentrant. The ! 1178: register used for passing the address is specified by the ! 1179: machine-description macro `STRUCT_VALUE'. ! 1180: ! 1181: GNU CC always passes arguments on the stack. At some point it will ! 1182: be extended to pass arguments in registers, for machines which use ! 1183: that as the standard calling convention. This will make it possible ! 1184: to use such a convention on other machines as well. However, that ! 1185: would render it completely incompatible with PCC. We will probably ! 1186: do this once we have a complete GNU system so we can compile the ! 1187: libraries with GNU CC. ! 1188: ! 1189: If you use `longjmp', beware of automatic variables. ANSI C says ! 1190: that automatic variables that are not declared `volatile' have ! 1191: undefined values after a `longjmp'. And this is all GNU CC promises ! 1192: to do, because it is very difficult to restore register variables ! 1193: correctly, and one of GNU CC's features is that it can put variables ! 1194: in registers without your asking it to. ! 1195: ! 1196: If you want a variable to be unaltered by `longjmp', and you don't ! 1197: want to write `volatile' because old C compilers don't accept it, ! 1198: just take the address of the variable. If a variable's address is ! 1199: ever taken, even if just to compute it and ignore it, then the ! 1200: variable cannot go in a register: 1.1.1.2 root 1201: 1202: { 1203: int careful; 1204: &careful; 1205: ... 1206: } 1207: 1.1.1.4 ! root 1208: Code compiled with GNU CC may call certain library routines. The ! 1209: routines needed on the Vax and 68000 are in the file `gnulib.c'. You ! 1210: must compile this file with the standard C compiler, not with GNU CC, ! 1211: and then link it with each program you compile with GNU CC. (In ! 1212: actuality, many programs will not need it.) The usual function call ! 1213: interface is used for calling the library routines. Some standard ! 1214: parts of the C library, such as `bcopy', are also called automatically. ! 1215: 1.1.1.2 root 1216:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.