![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-5 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-5 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.3 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.47 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.3 ! root 14: that the sections entitled "GNU General Public License" and "Boycott" ! 15: are 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. 1.1 root 18: 19: Permission is granted to copy and distribute translations of this 20: manual into another language, under the above conditions for modified 1.1.1.3 ! root 21: versions, except that the sections entitled "GNU General Public ! 22: License" and "Boycott", and this permission notice, may be included in ! 23: translations approved by the Free Software Foundation instead of in the ! 24: original English. 1.1 root 25: 26: 1.1.1.3 ! root 27: File: gcc.info, Node: Function Attributes, Next: Function Prototypes, Prev: Case Ranges, Up: Extensions 1.1 root 28: 29: Declaring Attributes of Functions 30: ================================= 31: 32: In GNU C, you declare certain things about functions called in your 33: program which help the compiler optimize function calls. 34: 1.1.1.3 ! root 35: A few standard library functions, such as `abort' and `exit', cannot ! 36: return. GNU CC knows this automatically. Some programs define their ! 37: own functions that never return. You can declare them `volatile' to ! 38: tell the compiler this fact. For example, 1.1 root 39: 40: extern void volatile fatal (); 41: 42: void 43: fatal (...) 44: { 45: ... /* Print error message. */ ... 46: exit (1); 47: } 48: 49: The `volatile' keyword tells the compiler to assume that `fatal' 50: cannot return. This makes slightly better code, but more importantly 51: it helps avoid spurious warnings of uninitialized variables. 52: 53: It does not make sense for a `volatile' function to have a return 54: type other than `void'. 55: 56: Many functions do not examine any values except their arguments, and 1.1.1.3 ! root 57: have no effects except the return value. Such a function can be subject ! 58: to common subexpression elimination and loop optimization just as an ! 59: arithmetic operator would be. These functions should be declared 1.1 root 60: `const'. For example, 61: 62: extern int const square (); 63: 64: says that the hypothetical function `square' is safe to call fewer 65: times than the program says. 66: 1.1.1.3 ! root 67: Note that a function that has pointer arguments and examines the data ! 68: pointed to must *not* be declared `const'. Likewise, a function that ! 69: calls a non-`const' function usually must not be `const'. It does not ! 70: make sense for a `const' function to return `void'. ! 71: ! 72: We recommend placing the keyword `const' after the function's return ! 73: type. It makes no difference in the example above, but when the return ! 74: type is a pointer, it is the only way to make the function itself ! 75: const. For example, 1.1 root 76: 77: const char *mincp (int); 78: 1.1.1.3 ! root 79: says that `mincp' returns `const char *'--a pointer to a const object. ! 80: To declare `mincp' const, you must write this: 1.1 root 81: 82: char * const mincp (int); 83: 84: Some people object to this feature, suggesting that ANSI C's 85: `#pragma' should be used instead. There are two reasons for not doing 86: this. 87: 88: 1. It is impossible to generate `#pragma' commands from a macro. 89: 90: 2. The `#pragma' command is just as likely as these keywords to mean 91: something else in another compiler. 92: 93: These two reasons apply to almost any application that might be 94: proposed for `#pragma'. It is basically a mistake to use `#pragma' for 95: *anything*. 96: 97: 1.1.1.3 ! root 98: File: gcc.info, Node: Function Prototypes, Next: Dollar Signs, Prev: Function Attributes, Up: Extensions ! 99: ! 100: Prototypes and Old-Style Function Definitions ! 101: ============================================= ! 102: ! 103: GNU C extends ANSI C to allow a function prototype to override a ! 104: later old-style non-prototype definition. Consider the following ! 105: example: ! 106: ! 107: /* Use prototypes unless the compiler is old-fashioned. */ ! 108: #if __STDC__ ! 109: #define P((x)) (x) ! 110: #else ! 111: #define P((x)) () ! 112: #endif ! 113: ! 114: /* Prototype function declaration. */ ! 115: int isroot P((uid_t)); ! 116: ! 117: /* Old-style function definition. */ ! 118: int ! 119: isroot (x) /* ??? lossage here ??? */ ! 120: uid_t x; ! 121: { ! 122: return x == 0; ! 123: } ! 124: ! 125: Suppose the type `uid_t' happens to be `short'. ANSI C does not ! 126: allow this example, because subword arguments in old-style ! 127: non-prototype definitions are promoted. Therefore in this example the ! 128: function definition's argument is really an `int', which does not match ! 129: the prototype argument type of `short'. ! 130: ! 131: This restriction of ANSI C makes it hard to write code that is ! 132: portable to traditional C compilers, because the programmer does not ! 133: know whether the `uid_t' type is `short', `int', or `long'. Therefore, ! 134: in cases like these GNU C allows a prototype to override a later ! 135: old-style definition. More precisely, in GNU C, a function prototype ! 136: argument type overrides the argument type specified by a later ! 137: old-style definition if the former type is the same as the latter type ! 138: before promotion. Thus in GNU C the above example is equivalent to the ! 139: following: ! 140: ! 141: int isroot (uid_t); ! 142: ! 143: int ! 144: isroot (uid_t x) ! 145: { ! 146: return x == 0; ! 147: } ! 148: ! 149: ! 150: File: gcc.info, Node: Dollar Signs, Next: Character Escapes, Prev: Function Prototypes, Up: Extensions 1.1 root 151: 152: Dollar Signs in Identifier Names 153: ================================ 154: 155: In GNU C, you may use dollar signs in identifier names. This is 156: because many traditional C implementations allow such identifiers. 157: 158: Dollar signs are allowed on certain machines if you specify 159: `-traditional'. On a few systems they are allowed by default, even if 160: `-traditional' is not used. But they are never allowed if you specify 161: `-ansi'. 162: 163: There are certain ANSI C programs (obscure, to be sure) that would 164: compile incorrectly if dollar signs were permitted in identifiers. For 165: example: 166: 167: #define foo(a) #a 168: #define lose(b) foo (b) 169: #define test$ 170: lose (test) 171: 172: 173: File: gcc.info, Node: Character Escapes, Next: Variable Attributes, Prev: Dollar Signs, Up: Extensions 174: 175: The Character ESC in Constants 176: ============================== 177: 178: You can use the sequence `\e' in a string or character constant to 179: stand for the ASCII character ESC. 180: 181: 182: File: gcc.info, Node: Alignment, Next: Inline, Prev: Variable Attributes, Up: Extensions 183: 184: Inquiring on Alignment of Types or Variables 185: ============================================ 186: 187: The keyword `__alignof__' allows you to inquire about how an object 188: is aligned, or the minimum alignment usually required by a type. Its 189: syntax is just like `sizeof'. 190: 191: For example, if the target machine requires a `double' value to be 1.1.1.3 ! root 192: aligned on an 8-byte boundary, then `__alignof__ (double)' is 8. This 1.1 root 193: is true on many RISC machines. On more traditional machine designs, 194: `__alignof__ (double)' is 4 or even 2. 195: 1.1.1.3 ! root 196: Some machines never actually require alignment; they allow reference ! 197: to any data type even at an odd addresses. For these machines, ! 198: `__alignof__' reports the *recommended* alignment of a type. 1.1 root 199: 200: When the operand of `__alignof__' is an lvalue rather than a type, 201: the value is the largest alignment that the lvalue is known to have. 202: It may have this alignment as a result of its data type, or because it 203: is part of a structure and inherits alignment from that structure. For 204: example, after this declaration: 205: 206: struct foo { int x; char y; } foo1; 207: 208: the value of `__alignof__ (foo1.y)' is probably 2 or 4, the same as 209: `__alignof__ (int)', even though the data type of `foo1.y' does not 210: itself demand any alignment. 211: 212: 213: File: gcc.info, Node: Variable Attributes, Next: Alignment, Prev: Character Escapes, Up: Extensions 214: 215: Specifying Attributes of Variables 216: ================================== 217: 1.1.1.3 ! root 218: The keyword `__attribute__' allows you to specify special attributes ! 219: of variables or structure fields. The only attributes currently ! 220: defined are the `aligned' and `format' attributes. 1.1 root 221: 222: The `aligned' attribute specifies the alignment of the variable or 223: structure field. For example, the declaration: 224: 225: int x __attribute__ ((aligned (16))) = 0; 226: 227: causes the compiler to allocate the global variable `x' on a 16-byte 228: boundary. On a 68000, this could be used in conjunction with an `asm' 229: expression to access the `move16' instruction which requires 16-byte 230: aligned operands. 231: 232: You can also specify the alignment of structure fields. For 233: example, to create a double-word aligned `int' pair, you could write: 234: 235: struct foo { int x[2] __attribute__ ((aligned (8))); }; 236: 237: This is an alternative to creating a union with a `double' member that 238: forces the union to be double-word aligned. 239: 240: It is not possible to specify the alignment of functions; the 241: alignment of functions is determined by the machine's requirements and 1.1.1.3 ! root 242: cannot be changed. You cannot specify alignment for a typedef name ! 243: because such a name is just an alias, not a distinct type. 1.1 root 244: 245: The `format' attribute specifies that a function takes `printf' or 246: `scanf' style arguments which should be type-checked against a format 247: string. For example, the declaration: 248: 249: extern int 250: my_printf (void *my_object, const char *my_format, ...) 251: __attribute__ ((format (printf, 2, 3))); 252: 253: causes the compiler to check the arguments in calls to `my_printf' for 254: consistency with the `printf' style format string argument `my_format'. 255: 256: The first parameter of the `format' attribute determines how the 1.1.1.3 ! root 257: format string is interpreted, and should be either `printf' or `scanf'. ! 258: The second parameter specifies the number of the format string ! 259: argument (starting from 1). The third parameter specifies the number ! 260: of the first argument which should be checked against the format ! 261: string. For functions where the arguments are not available to be ! 262: checked (such as `vprintf'), specify the third parameter as zero. In ! 263: this case the compiler only checks the format string for consistency. 1.1 root 264: 265: In the example above, the format string (`my_format') is the second 266: argument to `my_print' and the arguments to check start with the third 267: argument, so the correct parameters for the format attribute are 2 and 268: 3. 269: 270: The `format' attribute allows you to identify your own functions 271: which take format strings as arguments, so that GNU CC can check the 272: calls to these functions for errors. The compiler always checks 273: formats for the ANSI library functions `printf', `fprintf', `sprintf', 274: `scanf', `fscanf', `sscanf', `vprintf', `vfprintf' and `vsprintf' 275: whenever such warnings are requested (using `-Wformat'), so there is no 276: need to modify the header file `stdio.h'. 277: 278: 279: File: gcc.info, Node: Inline, Next: Extended Asm, Prev: Alignment, Up: Extensions 280: 281: An Inline Function is As Fast As a Macro 282: ======================================== 283: 284: By declaring a function `inline', you can direct GNU CC to integrate 285: that function's code into the code for its callers. This makes 286: execution faster by eliminating the function-call overhead; in 287: addition, if any of the actual argument values are constant, their 1.1.1.3 ! root 288: known values may permit simplifications at compile time so that not all ! 289: of the inline function's code needs to be included. 1.1 root 290: 291: To declare a function inline, use the `inline' keyword in its 292: declaration, like this: 293: 294: inline int 295: inc (int *a) 296: { 297: (*a)++; 298: } 299: 1.1.1.3 ! root 300: (If you are writing a header file to be included in ANSI C programs, ! 301: write `__inline__' instead of `inline'. *Note Alternate Keywords::.) 1.1 root 302: 303: You can also make all "simple enough" functions inline with the 304: option `-finline-functions'. Note that certain usages in a function 305: definition can make it unsuitable for inline substitution. 306: 307: When a function is both inline and `static', if all calls to the 308: function are integrated into the caller, and the function's address is 1.1.1.3 ! root 309: never used, then the function's own assembler code is never referenced. 1.1 root 310: In this case, GNU CC does not actually output assembler code for the 1.1.1.3 ! root 311: function, unless you specify the option `-fkeep-inline-functions'. Some ! 312: calls cannot be integrated for various reasons (in particular, calls ! 313: that precede the function's definition cannot be integrated, and 1.1 root 314: neither can recursive calls within the definition). If there is a 315: nonintegrated call, then the function is compiled to assembler code as 316: usual. The function must also be compiled as usual if the program 317: refers to its address, because that can't be inlined. 318: 319: When an inline function is not `static', then the compiler must 320: assume that there may be calls from other source files; since a global 321: symbol can be defined only once in any program, the function must not 322: be defined in the other source files, so the calls therein cannot be 1.1.1.3 ! root 323: integrated. Therefore, a non-`static' inline function is always 1.1 root 324: compiled on its own in the usual fashion. 325: 326: If you specify both `inline' and `extern' in the function 327: definition, then the definition is used only for inlining. In no case 328: is the function compiled on its own, not even if you refer to its 329: address explicitly. Such an address becomes an external reference, as 330: if you had only declared the function, and had not defined it. 331: 1.1.1.3 ! root 332: This combination of `inline' and `extern' has almost the effect of a ! 333: macro. The way to use it is to put a function definition in a header ! 334: file with these keywords, and put another copy of the definition ! 335: (lacking `inline' and `extern') in a library file. The definition in ! 336: the header file will cause most calls to the function to be inlined. ! 337: If any uses of the function remain, they will refer to the single copy ! 338: in the library. 1.1 root 339: 340: 341: File: gcc.info, Node: Extended Asm, Next: Asm Labels, Prev: Inline, Up: Extensions 342: 343: Assembler Instructions with C Expression Operands 344: ================================================= 345: 346: In an assembler instruction using `asm', you can now specify the 347: operands of the instruction using C expressions. This means no more 348: guessing which registers or memory locations will contain the data you 349: want to use. 350: 351: You must specify an assembler instruction template much like what 1.1.1.3 ! root 352: appears in a machine description, plus an operand constraint string for ! 353: each operand. 1.1 root 354: 355: For example, here is how to use the 68881's `fsinx' instruction: 356: 357: asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 358: 359: Here `angle' is the C expression for the input operand while `result' 360: is that of the output operand. Each has `"f"' as its operand 1.1.1.3 ! root 361: constraint, saying that a floating point register is required. The `=' ! 362: in `=f' indicates that the operand is an output; all output operands' ! 363: constraints must use `='. The constraints use the same language used ! 364: in the machine description (*note Constraints::.). 1.1 root 365: 366: Each operand is described by an operand-constraint string followed by 367: the C expression in parentheses. A colon separates the assembler 368: template from the first output operand, and another separates the last 369: output operand from the first input, if any. Commas separate output 370: operands and separate inputs. The total number of operands is limited 371: to ten or to the maximum number of operands in any instruction pattern 372: in the machine description, whichever is greater. 373: 374: If there are no output operands, and there are input operands, then 375: there must be two consecutive colons surrounding the place where the 376: output operands would go. 377: 378: Output operand expressions must be lvalues; the compiler can check 1.1.1.3 ! root 379: this. The input operands need not be lvalues. The compiler cannot 1.1 root 380: check whether the operands have data types that are reasonable for the 381: instruction being executed. It does not parse the assembler 382: instruction template and does not know what it means, or whether it is 383: valid assembler input. The extended `asm' feature is most often used 384: for machine instructions that the compiler itself does not know exist. 385: 386: The output operands must be write-only; GNU CC will assume that the 1.1.1.3 ! root 387: values in these operands before the instruction are dead and need not be ! 388: generated. Extended asm does not support input-output or read-write 1.1 root 389: operands. For this reason, the constraint character `+', which 390: indicates such an operand, may not be used. 391: 392: When the assembler instruction has a read-write operand, or an 393: operand in which only some of the bits are to be changed, you must 394: logically split its function into two separate operands, one input 1.1.1.3 ! root 395: operand and one write-only output operand. The connection between them ! 396: is expressed by constraints which say they need to be in the same 1.1 root 397: location when the instruction executes. You can use the same C 398: expression for both operands, or different expressions. For example, 399: here we write the (fictitious) `combine' instruction with `bar' as its 400: read-only source operand and `foo' as its read-write destination: 401: 402: asm ("combine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar)); 403: 404: The constraint `"0"' for operand 1 says that it must occupy the same 405: location as operand 0. A digit in constraint is allowed only in an 406: input operand, and it must refer to an output operand. 407: 408: Only a digit in the constraint can guarantee that one operand will 1.1.1.3 ! root 409: be in the same place as another. The mere fact that `foo' is the value ! 410: of both operands is not enough to guarantee that they will be in the ! 411: same place in the generated assembler code. The following would not ! 412: work: 1.1 root 413: 414: asm ("combine %2,%0" : "=r" (foo) : "r" (foo), "g" (bar)); 415: 416: Various optimizations or reloading could cause operands 0 and 1 to 417: be in different registers; GNU CC knows no reason not to do so. For 418: example, the compiler might find a copy of the value of `foo' in one 1.1.1.3 ! root 419: register and use it for operand 1, but generate the output operand 0 in ! 420: a different register (copying it afterward to `foo''s own address). Of ! 421: course, since the register for operand 1 is not even mentioned in the ! 422: assembler code, the result will not work, but GNU CC can't tell that. 1.1 root 423: 424: Some instructions clobber specific hard registers. To describe 425: this, write a third colon after the input operands, followed by the 426: names of the clobbered hard registers (given as strings). Here is a 427: realistic example for the Vax: 428: 429: asm volatile ("movc3 %0,%1,%2" 430: : /* no outputs */ 431: : "g" (from), "g" (to), "g" (count) 432: : "r0", "r1", "r2", "r3", "r4", "r5"); 433: 434: If you refer to a particular hardware register from the assembler 435: code, then you will probably have to list the register after the third 436: colon to tell the compiler that the register's value is modified. In 437: many assemblers, the register names begin with `%'; to produce one `%' 438: in the assembler code, you must write `%%' in the input. 439: 1.1.1.3 ! root 440: If your assembler instruction can alter the condition code register, ! 441: add `cc' to the list of clobbered registers. GNU CC on some machines ! 442: represents the condition codes as a specific hardware register; `cc' ! 443: serves to name this register. On other machines, the condition code is ! 444: handled differently, and specifying `cc' has no effect. But it is ! 445: valid no matter what the machine. ! 446: 1.1 root 447: You can put multiple assembler instructions together in a single 1.1.1.3 ! root 448: `asm' template, separated either with newlines (written as `\n') or with ! 449: semicolons if the assembler allows such semicolons. The GNU assembler ! 450: allows semicolons and all Unix assemblers seem to do so. The input ! 451: operands are guaranteed not to use any of the clobbered registers, and ! 452: neither will the output operands' addresses, so you can read and write ! 453: the clobbered registers as many times as you like. Here is an example ! 454: of multiple instructions in a template; it assumes that the subroutine ! 455: `_foo' accepts arguments in registers 9 and 10: 1.1 root 456: 457: asm ("movl %0,r9;movl %1,r10;call _foo" 458: : /* no outputs */ 459: : "g" (from), "g" (to) 460: : "r9", "r10"); 461: 462: Unless an output operand has the `&' constraint modifier, GNU CC may 463: allocate it in the same register as an unrelated input operand, on the 1.1.1.3 ! root 464: assumption that the inputs are consumed before the outputs are produced. ! 465: This assumption may be false if the assembler code actually consists of ! 466: more than one instruction. In such a case, use `&' for each output ! 467: operand that may not overlap an input. *Note Modifiers::. 1.1 root 468: 469: If you want to test the condition code produced by an assembler 470: instruction, you must include a branch and a label in the `asm' 471: construct, as follows: 472: 473: asm ("clr %0;frob %1;beq 0f;mov #1,%0;0:" 474: : "g" (result) 475: : "g" (input)); 476: 477: This assumes your assembler supports local labels, as the GNU assembler 478: and most Unix assemblers do. 479: 1.1.1.3 ! root 480: Usually the most convenient way to use these `asm' instructions is to ! 481: encapsulate them in macros that look like functions. For example, 1.1 root 482: 483: #define sin(x) \ 484: ({ double __value, __arg = (x); \ 485: asm ("fsinx %1,%0": "=f" (__value): "f" (__arg)); \ 486: __value; }) 487: 488: Here the variable `__arg' is used to make sure that the instruction 1.1.1.3 ! root 489: operates on a proper `double' value, and to accept only those arguments ! 490: `x' which can convert automatically to a `double'. 1.1 root 491: 492: Another way to make sure the instruction operates on the correct 1.1.1.3 ! root 493: data type is to use a cast in the `asm'. This is different from using a ! 494: variable `__arg' in that it converts more different types. For 1.1 root 495: example, if the desired type were `int', casting the argument to `int' 496: would accept a pointer with no complaint, while assigning the argument 497: to an `int' variable named `__arg' would warn about using a pointer 498: unless the caller explicitly casts it. 499: 500: If an `asm' has output operands, GNU CC assumes for optimization 501: purposes that the instruction has no side effects except to change the 502: output operands. This does not mean that instructions with a side 503: effect cannot be used, but you must be careful, because the compiler 1.1.1.3 ! root 504: may eliminate them if the output operands aren't used, or move them out ! 505: of loops, or replace two with one if they constitute a common 1.1 root 506: subexpression. Also, if your instruction does have a side effect on a 507: variable that otherwise appears not to change, the old value of the 508: variable may be reused later if it happens to be found in a register. 509: 510: You can prevent an `asm' instruction from being deleted, moved 1.1.1.3 ! root 511: significantly, or combined, by writing the keyword `volatile' after the ! 512: `asm'. For example: 1.1 root 513: 514: #define set_priority(x) \ 515: asm volatile ("set_priority %0": /* no outputs */ : "g" (x)) 516: 517: An instruction without output operands will not be deleted or moved 518: significantly, regardless, unless it is unreachable. 519: 520: Note that even a volatile `asm' instruction can be moved in ways 521: that appear insignificant to the compiler, such as across jump 522: instructions. You can't expect a sequence of volatile `asm' 523: instructions to remain perfectly consecutive. If you want consecutive 524: output, use a single `asm'. 525: 526: It is a natural idea to look for a way to give access to the 527: condition code left by the assembler instruction. However, when we 1.1.1.3 ! root 528: attempted to implement this, we found no way to make it work reliably. ! 529: The problem is that output operands might need reloading, which would ! 530: result in additional following "store" instructions. On most machines, ! 531: these instructions would alter the condition code before there was time ! 532: to test it. This problem doesn't arise for ordinary "test" and ! 533: "compare" instructions because they don't have any output operands. 1.1 root 534: 535: If you are writing a header file that should be includable in ANSI C 1.1.1.3 ! root 536: programs, write `__asm__' instead of `asm'. *Note Alternate Keywords::. 1.1 root 537: 538: 539: File: gcc.info, Node: Asm Labels, Next: Explicit Reg Vars, Prev: Extended Asm, Up: Extensions 540: 541: Controlling Names Used in Assembler Code 542: ======================================== 543: 544: You can specify the name to be used in the assembler code for a C 545: function or variable by writing the `asm' (or `__asm__') keyword after 546: the declarator as follows: 547: 548: int foo asm ("myfoo") = 2; 549: 550: This specifies that the name to be used for the variable `foo' in the 551: assembler code should be `myfoo' rather than the usual `_foo'. 552: 553: On systems where an underscore is normally prepended to the name of 554: a C function or variable, this feature allows you to define names for 555: the linker that do not start with an underscore. 556: 1.1.1.3 ! root 557: You cannot use `asm' in this way in a function *definition*; but you ! 558: can get the same effect by writing a declaration for the function 1.1 root 559: before its definition and putting `asm' there, like this: 560: 561: extern func () asm ("FUNC"); 562: 563: func (x, y) 564: int x, y; 565: ... 566: 567: It is up to you to make sure that the assembler names you choose do 1.1.1.3 ! root 568: not conflict with any other assembler symbols. Also, you must not use a ! 569: register name; that would produce completely invalid assembler code. ! 570: GNU CC does not as yet have the ability to store static variables in ! 571: registers. Perhaps that will be added. 1.1 root 572: 573: 574: File: gcc.info, Node: Explicit Reg Vars, Next: Alternate Keywords, Prev: Asm Labels, Up: Extensions 575: 576: Variables in Specified Registers 577: ================================ 578: 579: GNU C allows you to put a few global variables into specified 580: hardware registers. You can also specify the register in which an 581: ordinary register variable should be allocated. 582: 1.1.1.3 ! root 583: * Global register variables reserve registers throughout the program. ! 584: This may be useful in programs such as programming language ! 585: interpreters which have a couple of global variables that are ! 586: accessed very often. 1.1 root 587: 588: * Local register variables in specific registers do not reserve the 589: registers. The compiler's data flow analysis is capable of 1.1.1.3 ! root 590: determining where the specified registers contain live values, and ! 591: where they are available for other uses. 1.1 root 592: 593: These local variables are sometimes convenient for use with the 594: extended `asm' feature (*note Extended Asm::.), if you want to 595: write one output of the assembler instruction directly into a 1.1.1.3 ! root 596: particular register. (This will work provided the register you 1.1 root 597: specify fits the constraints specified for that operand in the 598: `asm'.) 599: 600: * Menu: 601: 602: * Global Reg Vars:: 603: * Local Reg Vars:: 604: 605: 606: File: gcc.info, Node: Global Reg Vars, Next: Local Reg Vars, Up: Explicit Reg Vars 607: 608: Defining Global Register Variables 609: ---------------------------------- 610: 611: You can define a global register variable in GNU C like this: 612: 613: register int *foo asm ("a5"); 614: 615: Here `a5' is the name of the register which should be used. Choose a 616: register which is normally saved and restored by function calls on your 617: machine, so that library routines will not clobber it. 618: 619: Naturally the register name is cpu-dependent, so you would need to 620: conditionalize your program according to cpu type. The register `a5' 621: would be a good choice on a 68000 for a variable of pointer type. On 622: machines with register windows, be sure to choose a "global" register 623: that is not affected magically by the function call mechanism. 624: 625: In addition, operating systems on one type of cpu may differ in how 626: they name the registers; then you would need additional conditionals. 627: For example, some 68000 operating systems call this register `%a5'. 628: 629: Eventually there may be a way of asking the compiler to choose a 630: register automatically, but first we need to figure out how it should 631: choose and how to enable you to guide the choice. No solution is 632: evident. 633: 634: Defining a global register variable in a certain register reserves 635: that register entirely for this use, at least within the current 1.1.1.3 ! root 636: compilation. The register will not be allocated for any other purpose 1.1 root 637: in the functions in the current compilation. The register will not be 638: saved and restored by these functions. Stores into this register are 639: never deleted even if they would appear to be dead, but references may 640: be deleted or moved or simplified. 641: 642: It is not safe to access the global register variables from signal 643: handlers, or from more than one thread of control, because the system 644: library routines may temporarily use the register for other things 645: (unless you recompile them specially for the task at hand). 646: 1.1.1.3 ! root 647: It is not safe for one function that uses a global register variable ! 648: to call another such function `foo' by way of a third function `lose' ! 649: that was compiled without knowledge of this variable (i.e. in a 1.1 root 650: different source file in which the variable wasn't declared). This is 1.1.1.3 ! root 651: because `lose' might save the register and put some other value there. 1.1 root 652: For example, you can't expect a global register variable to be 653: available in the comparison-function that you pass to `qsort', since 654: `qsort' might have put something else in that register. (If you are 655: prepared to recompile `qsort' with the same global register variable, 656: you can solve this problem.) 657: 658: If you want to recompile `qsort' or other source files which do not 659: actually use your global register variable, so that they will not use 660: that register for any other purpose, then it suffices to specify the 661: compiler option `-ffixed-REG'. You need not actually add a global 662: register declaration to their source code. 663: 664: A function which can alter the value of a global register variable 1.1.1.3 ! root 665: cannot safely be called from a function compiled without this variable, ! 666: because it could clobber the value the caller expects to find there on ! 667: return. Therefore, the function which is the entry point into the part ! 668: of the program that uses the global register variable must explicitly ! 669: save and restore the value which belongs to its caller. 1.1 root 670: 671: On most machines, `longjmp' will restore to each global register 672: variable the value it had at the time of the `setjmp'. On some 673: machines, however, `longjmp' will not change the value of global 674: register variables. To be portable, the function that called `setjmp' 1.1.1.3 ! root 675: should make other arrangements to save the values of the global register ! 676: variables, and to restore them in a `longjmp'. This way, the same ! 677: thing will happen regardless of what `longjmp' does. 1.1 root 678: 679: All global register variable declarations must precede all function 680: definitions. If such a declaration could appear after function 681: definitions, the declaration would be too late to prevent the register 682: from being used for other purposes in the preceding functions. 683: 684: Global register variables may not have initial values, because an 685: executable file has no means to supply initial contents for a register. 686: 687: On the Sparc, there are reports that g3 ... g7 are suitable 688: registers, but certain library functions, such as `getwd', as well as 689: the subroutines for division and remainder, modify g3 and g4. g1 and 690: g2 are local temporaries. 691: 1.1.1.3 ! root 692: On the 68000, a2 ... a5 should be suitable, as should d2 ... d7. Of ! 693: course, it will not do to use more than a few of those. 1.1 root 694: 695: 696: File: gcc.info, Node: Local Reg Vars, Prev: Global Reg Vars, Up: Explicit Reg Vars 697: 698: Specifying Registers for Local Variables 699: ---------------------------------------- 700: 701: You can define a local register variable with a specified register 702: like this: 703: 704: register int *foo asm ("a5"); 705: 706: Here `a5' is the name of the register which should be used. Note that 707: this is the same syntax used for defining global register variables, 708: but for a local variable it would appear within a function. 709: 710: Naturally the register name is cpu-dependent, but this is not a 711: problem, since specific registers are most often useful with explicit 712: assembler instructions (*note Extended Asm::.). Both of these things 1.1.1.3 ! root 713: generally require that you conditionalize your program according to cpu ! 714: type. 1.1 root 715: 716: In addition, operating systems on one type of cpu may differ in how 717: they name the registers; then you would need additional conditionals. 718: For example, some 68000 operating systems call this register `%a5'. 719: 720: Eventually there may be a way of asking the compiler to choose a 721: register automatically, but first we need to figure out how it should 722: choose and how to enable you to guide the choice. No solution is 723: evident. 724: 725: Defining such a register variable does not reserve the register; it 1.1.1.3 ! root 726: remains available for other uses in places where flow control determines ! 727: the variable's value is not live. However, these registers are made ! 728: unavailable for use in the reload pass. I would not be surprised if ! 729: excessive use of this feature leaves the compiler too few available ! 730: registers to compile certain functions. 1.1 root 731: 732: 733: File: gcc.info, Node: Alternate Keywords, Next: Incomplete Enums, Prev: Explicit Reg Vars, Up: Extensions 734: 735: Alternate Keywords 736: ================== 737: 738: The option `-traditional' disables certain keywords; `-ansi' 1.1.1.3 ! root 739: disables certain others. This causes trouble when you want to use GNU C ! 740: extensions, or ANSI C features, in a general-purpose header file that 1.1 root 741: should be usable by all programs, including ANSI C programs and 742: traditional ones. The keywords `asm', `typeof' and `inline' cannot be 743: used since they won't work in a program compiled with `-ansi', while 1.1.1.3 ! root 744: the keywords `const', `volatile', `signed', `typeof' and `inline' won't ! 745: work in a program compiled with `-traditional'. 1.1 root 746: 747: The way to solve these problems is to put `__' at the beginning and 748: end of each problematical keyword. For example, use `__asm__' instead 749: of `asm', `__const__' instead of `const', and `__inline__' instead of 750: `inline'. 751: 752: Other C compilers won't accept these alternative keywords; if you 753: want to compile with another compiler, you can define the alternate 754: keywords as macros to replace them with the customary keywords. It 755: looks like this: 756: 757: #ifndef __GNUC__ 758: #define __asm__ asm 759: #endif 760: 761: `-pedantic' causes warnings for many GNU C extensions. You can 762: prevent such warnings within one expression by writing `__extension__' 763: before the expression. `__extension__' has no effect aside from this. 764: 765: 766: File: gcc.info, Node: Incomplete Enums, Prev: Alternate Keywords, Up: Extensions 767: 768: Incomplete `enum' Types 769: ======================= 770: 1.1.1.3 ! root 771: You can define an `enum' tag without specifying its possible values. 1.1 root 772: This results in an incomplete type, much like what you get if you write 773: `struct foo' without describing the elements. A later declaration 774: which does specify the possible values completes the type. 775: 776: You can't allocate variables or storage using the type while it is 777: incomplete. However, you can work with pointers to that type. 778: 779: This extension may not be very useful, but it makes the handling of 780: `enum' more consistent with the way `struct' and `union' are handled. 781: 782: 1.1.1.3 ! root 783: File: gcc.info, Node: Trouble, Next: Bugs, Prev: Extensions, Up: Top 1.1 root 784: 1.1.1.3 ! root 785: Known Causes of Trouble with GNU CC ! 786: *********************************** 1.1 root 787: 1.1.1.3 ! root 788: This section describes known problems that affect users of GNU CC. ! 789: Most of these are not GNU CC bugs per se--if they were, we would fix ! 790: them. But the result for a user may be like the result of a bug. ! 791: ! 792: Some of these problems are due to bugs in other software, some are ! 793: missing features that are too much work to add, and some are places ! 794: where people's opinions differ as to what is best. 1.1 root 795: 1.1.1.3 ! root 796: * Menu: 1.1 root 797: 1.1.1.3 ! root 798: * Actual Bugs:: Bugs we will fix later. ! 799: * Installation Problems:: Problems that manifest when you install GNU CC. ! 800: * Cross-Compiler Problems:: Common problems of cross compiling with GNU CC. ! 801: * Interoperation:: Problems using GNU CC with other compilers, ! 802: and with certain linkers, assemblers and debuggers. ! 803: * Incompatibilities:: GNU CC is incompatible with traditional C. ! 804: * Disappointments:: Regrettable things we can't change, but not quite bugs. ! 805: * Non-bugs:: Things we think are right, but some others disagree. 1.1 root 806: 1.1.1.3 ! root 807: ! 808: File: gcc.info, Node: Actual Bugs, Next: Installation Problems, Up: Trouble ! 809: ! 810: Actual Bugs We Haven't Fixed Yet ! 811: ================================ 1.1 root 812: 1.1.1.3 ! root 813: * Loop unrolling doesn't work properly for certain programs. This is ! 814: because of difficulty in updating the debugging information within ! 815: the loop being unrolled. We plan to revamp the representation of ! 816: debugging information so that this will work properly, but we have ! 817: not done this in version 2.2 because we don't want to delay it any ! 818: further. ! 819: ! 820: * There is a bug in producing DBX output which outputs a structure ! 821: tag even when a structure doesn't have a tag. The reason we ! 822: aren't fixing this now is that a clean fix requires ! 823: reorganizations that seem risky. We will do them after 2.2 is ! 824: released. 1.1 root 825: 826: 1.1.1.3 ! root 827: File: gcc.info, Node: Installation Problems, Next: Cross-Compiler Problems, Prev: Actual Bugs, Up: Trouble 1.1 root 828: 1.1.1.3 ! root 829: Installation Problems 1.1 root 830: ===================== 831: 1.1.1.3 ! root 832: This is a list of problems (and some apparent problems which don't ! 833: really mean anything is wrong) that show up during installation of GNU ! 834: CC. ! 835: ! 836: * On certain systems, defining certain environment variables such as ! 837: `CC' can interfere with the functioning of `make'. ! 838: ! 839: * If you encounter seemingly strange errors when trying to build the ! 840: compiler in a directory other than the source directory, it could ! 841: be because you have previously configured the compiler in the ! 842: source directory. Make sure you have done all the necessary ! 843: preparations. *Note Other Dir::. ! 844: ! 845: * In previous versions of GNU CC, the `gcc' driver program looked for ! 846: `as' and `ld' in various places such as files beginning with ! 847: `/usr/local/lib/gcc-'. GNU CC version 2 looks for them in the ! 848: directory `/usr/local/lib/gcc-lib/TARGET/VERSION'. ! 849: ! 850: Thus, to use a version of `as' or `ld' that is not the system ! 851: default, for example `gas' or GNU `ld', you must put them in that ! 852: directory (or make links to them from that directory). ! 853: ! 854: * Some commands executed when making the compiler may fail (return a ! 855: non-zero status) and be ignored by `make'. These failures, which ! 856: are often due to files that were not found, are expected, and can ! 857: safely be ignored. ! 858: ! 859: * It is normal to have warnings in compiling certain files about ! 860: unreachable code and about enumeration type clashes. These files' ! 861: names begin with `insn-'. ! 862: ! 863: * Sometimes `make' recompiles parts of the compiler when installing ! 864: the compiler. In one case, this was traced down to a bug in ! 865: `make'. Either ignore the problem or switch to GNU Make. ! 866: ! 867: * Sometimes on a Sun 4 you may observe a crash in the program ! 868: `genflags' or `genoutput' while building GCC. This is said to be ! 869: due to a bug in `sh'. You can probably get around it by running ! 870: `genflags' or `genoutput' manually and then retrying the `make'. ! 871: ! 872: * On some versions of Ultrix, the system supplied compiler cannot ! 873: compile `cp-parse.c' because it cannot handle so many cases in a ! 874: `switch' statement. You can avoid this problem by specifying ! 875: `LANGUAGES=c' when you compile GNU CC with the Ultrix compiler. ! 876: Then you can compile the entire GNU compiler with GNU CC. ! 877: ! 878: * If you use the 1.31 version of the MIPS assembler (such as was ! 879: shipped with Ultrix 3.1), you will need to use the ! 880: -fno-delayed-branch switch when optimizing floating point code. ! 881: Otherwise, the assembler will complain when the GCC compiler fills ! 882: a branch delay slot with a floating point instruction, such as ! 883: add.d. ! 884: ! 885: * Users have reported some problems with version 2.0 of the MIPS ! 886: compiler tools that were shipped with Ultrix 4.1. Version 2.10 ! 887: which came with Ultrix 4.2 seems to work fine. ! 888: ! 889: * On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a ! 890: bug in the assembler that must be fixed before GNU CC can be ! 891: built. This bug manifests itself during the first stage of ! 892: compilation, while building `libgcc2.a': ! 893: ! 894: _floatdisf ! 895: cc1: warning: `-g' option not supported on this version of GCC ! 896: cc1: warning: `-g1' option not supported on this version of GCC ! 897: ./gcc: Internal compiler error: program as got fatal signal 11 ! 898: ! 899: A patched version of the assembler is available by anonymous ftp ! 900: from `altdorf.ai.mit.edu' as the file ! 901: `archive/cph/hpux-8.0-assembler'. If you have HP software support, ! 902: the patch can also be obtained directly from HP, as described in ! 903: the following note: ! 904: ! 905: This is the patched assembler, to patch SR#1653-010439, where ! 906: the assembler aborts on floating point constants. ! 907: ! 908: The bug is not really in the assembler, but in the shared ! 909: library version of the function "cvtnum(3c)". The bug on ! 910: "cvtnum(3c)" is SR#4701-078451. Anyway, the attached ! 911: assembler uses the archive library version of "cvtnum(3c)" ! 912: and thus does not exhibit the bug. ! 913: ! 914: This patch is also known as PHCO_0800. ! 915: ! 916: * Another assembler problem on the HP PA results in an error message ! 917: like this while compiling part of `libgcc2.a': ! 918: ! 919: as: /usr/tmp/cca08196.s @line#30 [err#1060] ! 920: Argument 1 or 3 in FARG upper ! 921: - lookahead = RTNVAL=GR ! 922: ! 923: This happens because HP changed the assembler syntax after system ! 924: release 8.02. GNU CC assumes the newer syntax; if your assembler ! 925: wants the older syntax, comment out this line in the file ! 926: `pa1-hpux.h': ! 927: ! 928: #define HP_FP_ARG_DESCRIPTOR_REVERSED ! 929: ! 930: * Some versions of the Pyramid C compiler are reported to be unable ! 931: to compile GNU CC. You must use an older version of GNU CC for ! 932: bootstrapping. One indication of this problem is if you get a ! 933: crash when GNU CC compiles the function `muldi3' in file ! 934: `libgcc2.c'. ! 935: ! 936: You may be able to succeed by getting GNU CC version 1, installing ! 937: it, and using it to compile GNU CC version 2. The bug in the ! 938: Pyramid C compiler does not seem to affect GNU CC version 1. ! 939: ! 940: * On the Tower models 4N0 and 6N0, by default a process is not ! 941: allowed to have more than one megabyte of memory. GNU CC cannot ! 942: compile itself (or many other programs) with `-O' in that much ! 943: memory. ! 944: ! 945: To solve this problem, reconfigure the kernel adding the following ! 946: line to the configuration file: ! 947: ! 948: MAXUMEM = 4096 ! 949: ! 950: * On the Altos 3068, programs compiled with GNU CC won't work unless ! 951: you fix a kernel bug. This happens using system versions V.2.2 ! 952: 1.0gT1 and V.2.2 1.0e and perhaps later versions as well. See the ! 953: file `README.ALTOS'. ! 954: ! 955: ! 956: File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Installation Problems, Up: Trouble ! 957: ! 958: Cross-Compiler Problems ! 959: ======================= ! 960: ! 961: * Cross compilation can run into trouble for certain machines because ! 962: some target machines' assemblers require floating point numbers to ! 963: be written as *integer* constants in certain contexts. ! 964: ! 965: The compiler writes these integer constants by examining the ! 966: floating point value as an integer and printing that integer, ! 967: because this is simple to write and independent of the details of ! 968: the floating point representation. But this does not work if the ! 969: compiler is running on a different machine with an incompatible ! 970: floating point format, or even a different byte-ordering. ! 971: ! 972: In addition, correct constant folding of floating point values ! 973: requires representing them in the target machine's format. (The C ! 974: standard does not quite require this, but in practice it is the ! 975: only way to win.) ! 976: ! 977: It is now possible to overcome these problems by defining macros ! 978: such as `REAL_VALUE_TYPE'. But doing so is a substantial amount of ! 979: work for each target machine. *Note Cross-compilation::. ! 980: ! 981: * At present, the program `mips-tfile' which adds debug support to ! 982: object files on MIPS systems does not work in a cross compile ! 983: environment. 1.1 root 984: 1.1.1.3 ! root 985: ! 986: File: gcc.info, Node: Interoperation, Next: Incompatibilities, Prev: Cross-Compiler Problems, Up: Trouble 1.1 root 987: 1.1.1.3 ! root 988: Interoperation ! 989: ============== 1.1 root 990: 1.1.1.3 ! root 991: This section lists various difficulties encountered in using GNU C or ! 992: GNU C++ together with other compilers or with the assemblers, linkers ! 993: and debuggers on certain systems. ! 994: ! 995: * GNU C normally compiles functions to return small structures and ! 996: unions in registers. Most other compilers arrange to return them ! 997: just like larger structures and unions. This can lead to trouble ! 998: when you link together code compiled by different compilers. To ! 999: avoid the problem, you can use the option `-fpcc-struct-value' ! 1000: when compiling with GNU CC. ! 1001: ! 1002: * GNU C++ does not do name mangling in the same way as other C++ ! 1003: compilers. This means that object files compiled with one compiler ! 1004: cannot be used with another. ! 1005: ! 1006: GNU C++ also uses different techniques for arranging virtual ! 1007: function tables and the layout of class instances. In general, ! 1008: therefore, linking code compiled with different C++ compilers does ! 1009: not work. ! 1010: ! 1011: * Older GDB versions sometimes fail to read the output of GNU CC ! 1012: version 2. If you have trouble, get GDB version 4.4 or later. ! 1013: ! 1014: * DBX rejects some files produced by GNU CC, though it accepts ! 1015: similar constructs in output from PCC. Until someone can supply a ! 1016: coherent description of what is valid DBX input and what is not, ! 1017: there is nothing I can do about these problems. You are on your ! 1018: own. ! 1019: ! 1020: * The GNU assembler (GAS) does not support PIC. To generate PIC ! 1021: code, you must use some other assembler, such as `/bin/as'. ! 1022: ! 1023: * On some BSD systems including some versions of Ultrix, use of ! 1024: profiling causes static variable destructors (currently used only ! 1025: in C++) not to be run. ! 1026: ! 1027: * On a Sun, linking using GNU CC fails to find a shared library and ! 1028: reports that the library doesn't exist at all. ! 1029: ! 1030: This happens if you are using the GNU linker, because it does only ! 1031: static linking and looks only for unshared libraries. If you have ! 1032: a shared library with no unshared counterpart, the GNU linker ! 1033: won't find anything. ! 1034: ! 1035: We hope to make a linker which supports Sun shared libraries, but ! 1036: please don't ask when it will be finished--we don't know. ! 1037: ! 1038: * Sun forgot to include a static version of `libdl.a' with some ! 1039: versions of SunOS (mainly 4.1). This results in undefined symbols ! 1040: when linking static binaries (that is, if you use `-static'). If ! 1041: you see undefined symbols `_dlclose', `_dlsym' or `_dlopen' when ! 1042: linking, compile and link against the file `mit/util/misc/dlsym.c' ! 1043: from the MIT version of X windows. ! 1044: ! 1045: * On the HP PA machine, ADB sometimes fails to work on functions ! 1046: compiled with GNU CC. Specifically, it fails to work on functions ! 1047: that use `alloca' or variable-size arrays. This is because GNU CC ! 1048: doesn't generate HPUX unwind descriptors for such functions. It ! 1049: may even be impossible to generate them. ! 1050: ! 1051: * Profiling is not supported on the HP PA machine. Neither is ! 1052: debugging (`-g'), unless you use the preliminary GNU tools (*note ! 1053: Installation::.). ! 1054: ! 1055: * GNU CC on the HP PA handles variadic function arguments using a ! 1056: calling convention incompatible with the HP compiler. This is ! 1057: only a problem for routines that take `va_list' as parameters, ! 1058: such as `vprintf'. This may be fixed eventually. ! 1059: ! 1060: * The current version of the assembler (`/bin/as') for the RS/6000 ! 1061: has certain problems that prevent the `-g' option in GCC from ! 1062: working. ! 1063: ! 1064: IBM has produced a fixed version of the assembler. The replacement ! 1065: assembler is not a standard component of either AIX 3.1.5 or AIX ! 1066: 3.2, but is expected to become standard in a future distribution. ! 1067: This assembler is available from IBM as APAR IX22829. Yet more ! 1068: bugs have been fixed in a newer assembler, which will shortly be ! 1069: available as APAR IX26107. See the file `README.RS6000' for more ! 1070: details on these assemblers. 1.1 root 1071: 1.1.1.3 ! root 1072: * On the IBM RS/6000, compiling code of the form 1.1 root 1073: 1.1.1.3 ! root 1074: extern int foo; ! 1075: ! 1076: ... foo ... 1.1 root 1077: 1.1.1.3 ! root 1078: static int foo; ! 1079: ! 1080: will cause the linker to report an undefined symbol `foo'. ! 1081: Although this behavior differs from most other systems, it is not a ! 1082: bug because redefining an `extern' variable as `static' is ! 1083: undefined in ANSI C. ! 1084: ! 1085: * On VMS, GAS versions 1.38.1 and earlier may cause spurious warning ! 1086: messages from the linker. These warning messages complain of ! 1087: mismatched psect attributes. You can ignore them. *Note VMS ! 1088: Install::. ! 1089: ! 1090: * On the Alliant, the system's own convention for returning ! 1091: structures and unions is unusual, and is not compatible with GNU ! 1092: CC no matter what options are used. ! 1093: ! 1094: * On the IBM RT PC, the MetaWare HighC compiler (hc) uses yet another ! 1095: convention for structure and union returning. Use ! 1096: `-mhc-struct-return' to tell GNU CC to use a convention compatible ! 1097: with it. ! 1098: ! 1099: * On Ultrix, the Fortran compiler expects registers 2 through 5 to ! 1100: be saved by function calls. However, the C compiler uses ! 1101: conventions compatible with BSD Unix: registers 2 through 5 may be ! 1102: clobbered by function calls. ! 1103: ! 1104: GNU CC uses the same convention as the Ultrix C compiler. You can ! 1105: use these options to produce code compatible with the Fortran ! 1106: compiler: 1.1 root 1107: 1.1.1.3 ! root 1108: -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 1.1 root 1109: 1110:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.